Cannot install on Debian 7 i386

Debian 7 is python 2.7.3 for reference.
I've tried both system python and a virtualenv, using pip and installing from source. After failing to install in system python, I rm -rf'ed spacy from system python before attempting a virtualenv pip install.
While pip install itself succeeds on both system python and in a virtualenv, but after downloading the model (3x tries to download with consistent md5sums, even) I get data integrity failures:
(virt1)[514 atypical:joant virt1] $ python
Python 2.7.3 (default, Mar 14 2014, 11:57:14)
[GCC 4.7.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from __future__ import unicode_literals, print_function
>>> from spacy.en import English
>>> nlp = English()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/joant/mcguffey/virt1/local/lib/python2.7/site-packages/spacy/en/__init__.py", line 92, in __init__
    oov_prob=oov_prob)
  File "spacy/vocab.pyx", line 59, in spacy.vocab.Vocab.__init__ (spacy/vocab.cpp:2836)
  File "spacy/vocab.pyx", line 224, in spacy.vocab.Vocab.load_lexemes (spacy/vocab.cpp:5453)
IOError: Error reading from lexemes.bin. Integrity check fails.
>>> exit()
(virt1)[515 atypical:joant virt1] $ md5sum ./lib/python2.7/site-packages/spacy/en/data/vocab/lexemes.bin
0545807daed0f40d95502a21223dc35f  ./lib/python2.7/site-packages/spacy/en/data/vocab/lexemes.bin

What am I doing wrong? At a guess, is there a mismatch between model and data file versions?
For reference, Installing from source fails during compilation with no .c files found, see https://gist.github.com/wohali/028bc16e820d4e0932c4 for details of the failing step (following your steps to the letter from http://spacy.io/#install)

FYI I have managed to get it to install on another Debian 7 install that is 64-bit. This VM is 32-bit. Does spaCy require a 64-bit system?

If it does, that's a bug. Thanks for the report, I'll look into this.

Okay, I'm pretty sure I see the problem. Will have this fixed shortly.

I'm still trying to work out what's wrong with the compilation, though. Those steps are working for me on Ubuntu, and I see from your log that everything looks right.
I'll make a Debian instance on AWS and work through this.

I'm still having trouble replicating this. You've definitely done everything correctly.
The first line of the log that's in error is on line 210 of your log:
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -I. -I/home/joant/mcguffey/spaCy/.env/include -I/usr/include/python2.7 -c murmurhash/mrmr.c -o build/temp.linux-x86_64-2.7/murmurhash/mrmr.o
gcc: error: murmurhash/mrmr.c: No such file or directory

setuptools has executed the build command for murmurhash/mrmr.c, when it should be murmurhash/mrmr.cpp .
This reminds me of an old bug in setuptools, where Cython extensions would be forced to compile as .c files:
http://bugs.python.org/setuptools/issue138
https://bitbucket.org/pypa/setuptools/issues/288/cannot-specify-cython-under-setup_requires
However, the build works for me on the default version of setuptools on Ubuntu (2.2), and the latest (18.1). It looks like Debian Jessie ships with setuptools 5.5.1, and I tried that and it worked as well. Can you please try the following (in a fresh directory)
virtualenv .env && source .env/bin/activate
pip list

And paste the output?
Next steps:

Try installing cython and murmurhash in sequence, rather than relying on the dependency resolution
pip install cython
pip install murmurhash

Does that succeed?  The setup_requires mechanism in setuptools can be unreliable.

Try updating setuptools
pip install --upgrade setuptools
pip install cython
pip install murmurhash

Again, thanks for your patience on this. I really want the install process to go smoothly, and I appreciate the time you've put in to trying the library and reporting problems.

Output of pip list on the system Python:
chardet (2.3.0)
defusedxml (0.4.1)
docutils (0.12)
Pillow (2.6.1)
pip (7.1.2)
Pygments (2.0.1)
python-apt (<IP_ADDRESS>)
python-debian (0.1.27)
python-debianbts (1.11)
reportbug (6.6.3)
roman (2.0.0)
setuptools (18.3.1)
six (1.8.0)
SOAPpy (0.12.22)
virtualenv (13.1.2)
wheel (0.24.0)
wstools (0.4.3)

Output of pip list from a brand new virtualenv:
pip (7.1.2)
setuptools (18.2)
wheel (0.24.0)

Doing pip install cython followed by pip install murmurhash is fine:
(.env) $ pip install cython
Collecting cython
Installing collected packages: cython
Successfully installed cython-0.23.2
(.env) $ pip install murmurhash
Collecting murmurhash
Installing collected packages: murmurhash
Successfully installed murmurhash-0.24

I then proceeded to pip install -r requirements.txt which installed:
Successfully installed cymem-1.11 numpy-1.9.2 pathlib-1.0.1 plac-0.9.1 preshed-0.41 six-1.9.0 thinc-3.3 ujson-1.33 unidecode-0.4.18 wget-2.2

but the build still fails in the same way:
(.env) $ pip install -r requirements.txt
Requirement already satisfied (use --upgrade to upgrade): cython in /home/joant/.env/lib/python2.7/site-packages (from -r requirements.txt (line 1))
Collecting cymem==1.11 (from -r requirements.txt (line 2))
Collecting pathlib (from -r requirements.txt (line 3))
Collecting preshed==0.41 (from -r requirements.txt (line 4))
Collecting thinc==3.3 (from -r requirements.txt (line 5))
Requirement already satisfied (use --upgrade to upgrade): murmurhash==0.24 in /home/joant/.env/lib/python2.7/site-packages (from -r requirements.txt (line 6))
Collecting unidecode (from -r requirements.txt (line 7))
Collecting numpy (from -r requirements.txt (line 8))
Collecting wget (from -r requirements.txt (line 9))
Collecting plac (from -r requirements.txt (line 10))
Collecting six (from -r requirements.txt (line 11))
  Using cached six-1.9.0-py2.py3-none-any.whl
Collecting ujson (from -r requirements.txt (line 12))
Installing collected packages: cymem, pathlib, preshed, thinc, unidecode, numpy, wget, plac, six, ujson
Successfully installed cymem-1.11 numpy-1.9.2 pathlib-1.0.1 plac-0.9.1 preshed-0.41 six-1.9.0 thinc-3.3 ujson-1.33 unidecode-0.4.18 wget-2.2
(.env)[669 atypical:joant spaCy] $ python setup.py build_ext --inplace
running build_ext
cythoning spacy/parts_of_speech.pyx to spacy/parts_of_speech.cpp
building 'spacy.parts_of_speech' extension
creating build
creating build/temp.linux-x86_64-2.7
creating build/temp.linux-x86_64-2.7/spacy
x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fno-strict-aliasing -D_FORTIFY_SOURCE=2 -g -fstack-protector-strong -Wformat -Werror=format-security -fPIC -I. -I/home/joant/.env/include -I/usr/include/python2.7 -c spacy/parts_of_speech.cpp -o build/temp.linux-x86_64-2.7/spacy/parts_of_speech.o -O3 -Wno-strict-prototypes
cc1plus: warning: command line option ‘-Wno-strict-prototypes’ is valid for C/ObjC but not for C++
c++ -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions -Wl,-z,relro -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -D_FORTIFY_SOURCE=2 -g -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro -D_FORTIFY_SOURCE=2 -g -fstack-protector-strong -Wformat -Werror=format-security build/temp.linux-x86_64-2.7/spacy/parts_of_speech.o -o /home/joant/spaCy/spacy/parts_of_speech.so
cythoning spacy/strings.pyx to spacy/strings.cpp
building 'spacy.strings' extension
x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fno-strict-aliasing -D_FORTIFY_SOURCE=2 -g -fstack-protector-strong -Wformat -Werror=format-security -fPIC -I. -I/home/joant/.env/include -I/usr/include/python2.7 -c spacy/strings.cpp -o build/temp.linux-x86_64-2.7/spacy/strings.o -O3 -Wno-strict-prototypes
cc1plus: warning: command line option ‘-Wno-strict-prototypes’ is valid for C/ObjC but not for C++
spacy/strings.cpp:249:36: fatal error: murmurhash/MurmurHash3.h: No such file or directory
 #include "murmurhash/MurmurHash3.h"
                                    ^
compilation terminated.
error: command 'x86_64-linux-gnu-gcc' failed with exit status 1

I tried your suggestion 2 (upgrade setuptools, manually install cython/murmurhash, then proceed to install -r requirements.txt and python setup.py build_ext --inplace.) It fails at exactly the same place.
If you want I can probably arrange for a temporary shell login on the test box for you to try and diagnose the problem yourself. That said, installing/launching a brand new Debian Jessie 64-bit instance and trying to follow your own install steps should work...

Do you have the package:
python-dev

Installed? I think this might be the problem. When this package isn't installed, virtualenv silently behaves differently. It doesn't create an include/ directory within the env directory, which is where my install scripts are trying to install the Murmurhash headers.
This was a frustrating one to debug, because I mindlessly install the same set of build dependencies when I launch a new instance. It didn't occur to me that this could be the issue.

Yes, I had python-dev installed already. Was hoping this was it, but it's not.
 I'll reboot the instance and try again.

Okay so the following just worked for me on a fresh EC2 instance:
Instance type: t2-medium
AMI: debian-jessie-amd64-hvm-2015-06-07-12-27-ebs (ami-116d857a)
(Login as admin, sudo adduser me sudo, su - me)
sudo apt-get update
sudo apt-get install git build-essential python-dev python-virtualenv
git clone https://github.com/honnibal/spaCy
cd spaCy
virtualenv .env && source .env/bin/activate
export PYTHONPATH=`pwd`
pip install -r requirements.txt
python setup.py build_ext --inplace

In your output above, what does this mean:
.env/include:
python2.7@

Is that a symlink or something? Because, it's supposed to be a directory with a bunch of header files.

This appears to be the output of ls -RF. It means that the directory .env/include only contains "python2.7", which is a symlink to something else.

Thanks.
That's correct then --- that's what I have after creating the virtualenv.

$ ls -la .env/include/
total 8
drwxr-xr-x 2 joant joant 4096 Sep 22 17:56 ./
drwxr-xr-x 6 joant joant 4096 Sep 22 17:56 ../
lrwxrwxrwx 1 joant joant   22 Sep 22 17:56 python2.7 -> /usr/include/python2.7/

That directory includes all of the python 2.7 files.
Not sure what to say. You're still welcome to an account on the box to poke around if you wish, drop me an email at<EMAIL_ADDRESS>

Aha! If your script is trying to copy header files to .env/include, it will fail because that's a symlink to /usr/include/python2.7, writable only by root:
drwxr-xr-x 2 root root 4096 Sep  8 01:56 /usr/include/python2.7/

Did you try your test build on your instance as a root-capable user, perhaps?

Shoot, I thought I was close. I added an --always-copy flag to the virtualenv build, but still failure at the same place.
FYI, after running that script:
$ pwd
/home/joant/spaCy
$ find . -name MurmurHash3.h
./.env/lib/python2.7/site-packages/murmurhash/headers/murmurhash/MurmurHash3.h

I read your setup.py and I see that your headers_workaround isn't being called because use_cython is true (we're calling `python setup.py build_ext). So I'm not sure how this can work on your instance at all.....starting to get very confused here.

The directory include/ should be physical, but it's okay if the python2.7 within it is a symbolic link.
I think it makes sense to log into your box, if that's still a workable option for you. Email me on<EMAIL_ADDRESS>. In the meantime, and for anyone else reading, here's a brain-dump of what I know about these issues.
The deal with headers_workaround is this: there are two arguments of setup(), install_requires and setup_requires. This is supposed to allow you to use a dependency required by the setup.py. For instance, we need the MurmurHash headers to compile the library thinc, preshed and spacy.
setuptools reads the setup_requires values, and downloads them locally, to import them. Unfortunately, there's a long-standing bug: when it then goes to read install_requires, the import of the libraries downloaded during setup_requires succeeds! These libraries then fail to be installed in the virtualenv, because setuptools thinks they're already present.
The upshot of all this is that you can't actually specify the same library in both install_requires and setup_requires! It doesn't work. I gave up hoping anyone would sort out this mess, and made my own workaround: I made a little package, headers_workaround, which I could specify as a setup_requires dependency. This copies the headers into the virtualenv. It copies two batches of headers: the MurmurHash headers, and the numpy headers. The same mechanism is used for my hash-table library, preshed, and my averaged perceptron library, thinc (which depends on preshed).
Note that this only applies to installation via pip --- that's the only time the dependency specifications matter. So, if you're running
python setup.py build_ext --inplace

You need to have all the dependencies installed already. But, the headers_workaround is still important, because it's being used in preshed and thinc. You can't simply specify the order of the libraries in requirements.txt: the order is ignored. So the headers_workaround thing is still being used there.
However. I'm not actually so sure the headers_workaround is the culprit here. The initial error looks a lot like an error I had to deal with in old versions of setuptools. Old versions of setuptools used to have this "feature" that detected files ending in .pyx, checked whether Pyrex (the pre-decessor of Cython) was installed, and if it wasn't, attempted to compile a .c file, whether or not one existed. This prevented Cython from being run, and made it impossible to supply the .pyx source files in the package. The thing that makes me suspect this or a similar issue is, your log says that it's trying to compile murmurhas/mrmr.c, when the correct file would be murmurhash/mrmr.cpp. I can't see why it would be trying to compile a .c file, apart from this issue.
We established that you're running the correct version of virtualenv and setuptools, but things can sometimes be misleading? virtualenv is quite flakey, and sometimes I've had issues where old versions of libraries are being run unexpectedly.

Same problem here
dayvid@notebook:~/Downloads/packages/spaCy$ python setup.py build_ext --inplace
running build_ext
cythoning spacy/parts_of_speech.pyx to spacy/parts_of_speech.cpp
building 'spacy.parts_of_speech' extension
x86_64-linux-gnu-gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -I. -I/usr/include -I/usr/include/python2.7 -c spacy/parts_of_speech.cpp -o build/temp.linux-x86_64-2.7/spacy/parts_of_speech.o -O3 -Wno-strict-prototypes -Wno-unused-function
cc1plus: warning: command line option ‘-Wno-strict-prototypes’ is valid for C/ObjC but not for C++ [enabled by default]
Assembler messages:
Fatal error: can't create build/temp.linux-x86_64-2.7/spacy/parts_of_speech.o: Permission denied
error: command 'x86_64-linux-gnu-gcc' failed with exit status 1

These issues should finally be fixed.
We now have a redesigned build process, and CI running on 32 bit and 64 bit builds of Linux and Windows. The new version should be released today.
So, hopefully this shouldn't reoccur. Please reopen if you still experience problems


Update version to 1.2.66-0 on production

Update version to 1.2.66-0

Hey! I see that you made changes to our Form component. Make sure to update the docs in FORMS.md accordingly. Cheers!


2 spaces option

I am wondering could we have options to use 2 instead of 4 spaces, thanks! ☺

Just found
{
  "@html-eslint/indent": ["error", 2]
}

😃


Can this be detected on device?

Is the model available to detect on-device(Android) through ML Kit?

Is this maintained? I want to use this in my project. Pls reply

Let me know if you get any issue!

Is the model available to detect on-device(Android) through ML Kit?

Yes

Hi. Could you please provide the java code for the following kotlin code
NSFWDetector.isNSFW(bitmap,confidenceThreshold) { isNSFW, confidence, image ->
if (isNSFW){
Toast.makeText(this, "NSFW with confidence: $confidence", Toast.LENGTH_SHORT).show()
} else {
Toast.makeText(this, "SFW with confidence: $confidence", Toast.LENGTH_SHORT).show()
}
}
I am facing lamda issues.

I believe you may need to do somthing like this;
NSFWDetector.isNSFW(bitmap,confidenceThreshold, this::result)

private Unit failure(Boolean isNSFW, Float confidence, Bitmap image ) {
        // do something java here
        return Unit.INSTANCE; //This is important
}

I did not test this and read more on here. Also Java 8 is directly supported as far I know


feat: update to eye v10.11.0

feat: update to eye v10.11.0

:tada: This PR is included in version 16.10.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release
v16.10.0

Your semantic-release bot :package::rocket:


Rename Repo from terra-ui.com to terra-ui

Issue Description
I propose we rename this repo from terra-ui.com to terra-ui. The reason for this change is to make the gh-pages url less strange. Currently the url is engineering.cerner.com/terra-ui.com which is weird. After the name change it would be engineering.cerner.com/terra-ui

+1

@emilyrohrbough the current plan would be to redirect from terra-ui.com to engineering.cerner.com/terra-ui

@ryanthemanuel, @JakeLaCombe Could i get a 👍 from you guys on this change?

👍


Menu Entry Event

Is your feature request related to a problem? Please describe.
An Event for on hover menu option so contextual icons can be added
Describe the solution you'd like
Like the on click event for the menu but this event fires when you hover over the menu and outputs the id of the entry or returns the data for MenuEntry
Describe alternatives you've considered
I've looked into just doing it the cheap way by getting the mouse position and working it out based on the height of the menu but I also can't seem to be able to get the menu height

Why have the menu entry added event.


No more Thumbnails in Notifications

Hi,
No more Thumbnails in Notifications
HTTP API doesn't work! I get ERR_CONNECTION_REFUSED
ssl:default Connect call failed
This happened after I upgrade the frigate!
Frigate
Current version: 0.11.1
I have read that need to delete the installation and install it again! I delete the frigate from custom_components and installed it again from add-ons! Now I don't see it in custom_components either!
Can anyone help me?
Thank you

You need to install the integration from HACS (the addon and the integration are entirely different pieces of software)

I also just discovered this. Is this not a service that the proxy can provide? I moved to HA Yellow (from a small NUC) and it's pretty weak and can't run Frigate - even with Coral. So I switched to using the proxy with Frigate on a separate host (as recommended by the Frigate documentation), but lost the notifications API.
Seems like that API is something the proxy should provide.

It's not something the proxy can provide. The integration works fine when Frigate runs on a separate machine.

@blakeblackshear How do I force the prompt to re-configure so that I can point the integration at a remote instance? Or what file needs to be adjusted to make that effective? I've tried:

Remove proxy and integration components.
Remove HACS frigate repository.
Confirm custom_components folders are deleted.
Remove config/frigate.yml
Restart HA.
Install Frigate integration (strangely, I didn't need to re-install the HACS component to have this show up in the Add-On store so I figured I'd try it).
Attempt to start Frigate (it doesn't start because there's no frigate.yml file, naturally).
Notice that the Configuration tab is not populated at all, so I figured that must be because the HACS repository wasn't installed.
Uninstall Frigate integration again and restart HA.
Install HACS repository (v3.0.1).
Restart HA.
Verify that custom_components/frigate is in place.
Install the Frigate integration (v0.11.1). Installation completes without prompting for a URL.
Check the configuration tab. It exists, but there is no option for a remote URL.
Attempt to start the integration to see if maybe that generates the configuration prompt. It does not.

At no point am I prompted to enter a URL for a remote instance.


Server side integration with Node v 14.16.1

Instructions
Please fill out the template below to the best of your ability and include a label indicating which tool/service you were working with when you encountered the problem.
Issue To Be Solved
Call transactions on the server side with Node, with the expectation that the code will be deployed on remote env. such as Firestore. For example, with Ethereum, we execute contract in remote server env with:
        // load contract
        const contract = new web3.eth.Contract(CONTRACT.abi, contract_address, {
            from: PUBLIC_KEY,
            gasPrice: '20000000000'
        });
     var nonce = await web3.eth.getTransactionCount(PUBLIC_KEY, "pending");

     const fn = contract.methods.adminMintGroup(targetPks, tokenIds, tokenAmts, '0x00');
      let gas = await fn.estimateGas();

   // Create the tx;
    const tx = {
        'from' : PUBLIC_KEY,
        'to'   : contract_address,
        'nonce': nonce,
        'gas'  : gas,
       'data' : fn.encodeABI()
    };

    const signPromise = web3.eth.accounts.signTransaction(tx, PRIVATE_KEY);
    signPromise.then((signedTx) => {
        web3.eth.sendSignedTransaction(signedTx.rawTransaction, function(err, hash) { ... }
   })

It would be nice if we can do the same with FCL.
(Optional): Suggest A Solution
N/A
If there are multiple solutions, please present each one separately. Save comparisons for the very end.)
(Optional): Context
<what are you currently working on that this is blocking?>

@10thfloor noted on the web3 aspect. I was providing a script from a different env. to demonstrate use case. Just to be clear, this nodeJS app is on a remote server env. Is there a ready-made example in fcl-js of this use case?

Hey @lingxiao you can use https://github.com/onflow/fcl-js and https://docs.onflow.org/cadence/ to send transactions from your NodeJS app.
Flow dapps are not compatible with web3. Flow is a new Layer 1 blockchain.
Let us know if you have any more questions!

Hey can I get an update on this? When I run simple script to authenticate on local emulator on the terminal, I am already getting an error: (node:54137) UnhandledPromiseRejectionWarning: ReferenceError: sessionStorage is not defined. It appears as if it's because I'm not running the script from say a Chrome browser.  This is what I'm attempting to do:
after starting flow emulator with flow emulator on terminal, and with a flow.json file of form:
    {
      "emulators": {
        "default": {
          "port": 3569,
          "serviceAccount": "emulator-account"
        }
      },
      "contracts": {
        "HelloWorld": "./contracts/HelloWorld.cdc"
      },
      "networks": {
        "emulator": "<IP_ADDRESS>:3569",
        "mainnet": "access.mainnet.nodes.onflow.org:9000",
        "testnet": "access.devnet.nodes.onflow.org:9000"
      },
      "accounts": {
        "emulator-account": {
          "address": "f8d6e0586b0a20c7",
          "key": [redacted]
        }
      },
      "deployments": {}
    }

I am trying to run this script

const fcl = require("@onflow/fcl")
const sdk = require("@onflow/sdk")
const types = require("@onflow/types")

    fcl.config()
        .put("env", "local")
        .put("accessNode.api", "http://localhost:8080")
        .put("discovery.wallet", "http://localhost:8080/fcl/authn")
        .put("app.detail.title", "Local Harness")

    fcl.authenticate()

    const currentUser = await fcl.currentUser().snapshot()
    console.log("The Current User", currentUser)

I have to say, the documentation you guys have is extremely confusing, with this (https://docs.onflow.org/fcl/reference/configure-fcl/), this(https://docs.onflow.org/concepts/accounts-and-keys/) and this(https://docs.onflow.org/flow-cli/account-add-contract/), it's hard to say which does what.

@chasefleming is there any update on this backend limitation? I would like to implement a Discord Bot that interacts with Flow Wallets.


Changing ::clerk/width does not report spec failures for invalid values

Following through in the workshop, in https://github.com/nextjournal/clerk-demo/blob/master/workshop/exercises/ex_2_table_viewer.clj#L45:
changing ::clerk/width :full to ::clerk/width :foo does not report an error for invalid values .
In contrast, invalid values for :code in ::clerk/visibility {:code :fold} report spec failures on invalid states.
Thanks!

Closed by #294.


Revise documentation of <source>

In v4.0.0 <source> underwent heavy changes that are not reflected in the documentation. This leads to confusion (cf. https://github.com/music-encoding/music-encoding/issues/579) and should be fixed

connected to #82

@riedde @doerners @bwbohl May I ask you to have a look if this is still an ongoing issue? (At least, all corresponding issues that I could find on music-encoding/music-encoding have been closed.)

I just had a quick look at the element definition of <source> and the guidelines as well. It seems that <source> is sufficiently documented. There are also several notes pointing out that in previous MEI versions <source> was used for manifestation-level descriptions - which schould aid to alienate the confusion. So to me it seems that this issue could be closed if @bwbohl and @riedde don't object.

yes, @doerners is right. In the guidelines (3.2) it is clarified. But in <IP_ADDRESS> an additional sentence (as in 3.5.1 'Please note: Until MEI 3.0.0, the source element in sourceDesc was used for manifestation-level descriptions.') would be nice.
In 3.8.3 the example clarifies the distinction.
in the End 12.1.1 has to be improved, because this is really unclear or outdated (focussing on the source element).

Transferring to main repo


[CI] In TC-DM-3.1 maxNetworks and networks attributes read is disabled

Problem
TC-DM-3.1 has some disabled tests.
fixes #8147
fixes #8148
Change overview

Enable them and add the missing pieces

Testing
2 new tests has been enabled.

Fast tracking, given this is adding test.

@vivien-apple @woody-apple - this broke BLE commssioning at least for ESP32 and probably across the board (because it returns a featuremap of 0 for devices). See  #14683


HBASE-28696 Partition BackupSystemTable queries

When successfully taking an incremental backup, one of our final steps is to delete bulk load metadata from the system table for the bulk loads that needed to be captured in the given backup. This means that we will basically truncate the entire bulk loads system table in a single batch of the deletes after successfully taking an incremental backup. Depending on your usage, one may run tons of bulk loads between backups, so this design is needlessly fragile. We should partition these deletes so that we never erroneously fail a backup due to this; there are a few other cases where we generated unbounded multi requests in the BackupSystemTable that this PR addresses too.
A few questions here:

Do we want to make the batch size configurable? Seems like yet another config in hbase that I'd like to avoid since it will plausibly never be customized
It is okay to just use Table#batch like this, correct?
I've tested this code in our QA environment, and unit testing feels like we're just testing the Lists class. That said, would people prefer that I add a unit test?

@charlesconnell @ndimiduk

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 19s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
hbaseanti
0m  0s

Patch does not have any anti-patterns.

_ master Compile Tests _

+1 :green_heart:
mvninstall
3m  5s

master passed

+1 :green_heart:
compile
0m 30s

master passed

+1 :green_heart:
checkstyle
0m 12s

master passed

+1 :green_heart:
spotbugs
0m 31s

master passed

+1 :green_heart:
spotless
0m 46s

branch has no errors when running spotless:check.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
2m 48s

the patch passed

+1 :green_heart:
compile
0m 30s

the patch passed

+1 :green_heart:
javac
0m 30s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
checkstyle
0m 11s

the patch passed

+1 :green_heart:
spotbugs
0m 36s

the patch passed

-1 :x:
hadoopcheck
5m 46s

The patch causes 10 errors with Hadoop v3.4.0.

+1 :green_heart:
spotless
0m 43s

patch has no errors when running spotless:check.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
3m 27s

the patch passed

+1 :green_heart:
compile
0m 23s

the patch passed

+1 :green_heart:
javac
0m 23s

the patch passed

+1 :green_heart:
javadoc
0m 15s

the patch passed

+1 :green_heart:
shadedjars
6m  4s

patch has no errors when building our shaded downstream artifacts.

_ Other Tests _

+1 :green_heart:
unit
10m 46s

hbase-backup in the patch passed.

33m 22s

Subsystem
Report/Notes

Docker
ClientAPI=1.46 ServerAPI=1.46 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6067/1/artifact/yetus-jdk17-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/6067

Optional Tests
javac javadoc unit compile shadedjars

uname
Linux 43a43f8e4ff8 5.4.0-177-generic #197-Ubuntu SMP Thu Mar 28 22:45:47 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / cda4d705620ecc2cec52046a09783705d97c89e1

Default Java
Eclipse Adoptium-17.0.11+9

Test Results
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6067/1/testReport/

Max. process+thread count
3014 (vs. ulimit of 30000)

modules
C: hbase-backup U: hbase-backup

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6067/1/console

versions
git=2.34.1 maven=3.9.8

Powered by
Apache Yetus 0.15.0 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 25s

Docker mode activated.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
2m 56s

the patch passed

+1 :green_heart:
compile
0m 27s

the patch passed

+1 :green_heart:
javac
0m 27s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
checkstyle
0m  8s

the patch passed

+1 :green_heart:
spotbugs
0m 34s

the patch passed

+1 :green_heart:
hadoopcheck
11m 14s

Patch does not cause any errors with Hadoop 3.3.6 3.4.0.

+1 :green_heart:
spotless
0m 42s

patch has no errors when running spotless:check.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
3m 35s

the patch passed

+1 :green_heart:
compile
0m 23s

the patch passed

+1 :green_heart:
javac
0m 23s

the patch passed

+1 :green_heart:
javadoc
0m 15s

the patch passed

+1 :green_heart:
shadedjars
6m  6s

patch has no errors when building our shaded downstream artifacts.

_ Other Tests _

+1 :green_heart:
unit
11m  3s

hbase-backup in the patch passed.

33m 39s

Subsystem
Report/Notes

Docker
ClientAPI=1.46 ServerAPI=1.46 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6067/2/artifact/yetus-jdk17-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/6067

Optional Tests
javac javadoc unit compile shadedjars

uname
Linux 859f9fe58251 5.4.0-177-generic #197-Ubuntu SMP Thu Mar 28 22:45:47 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / cda4d705620ecc2cec52046a09783705d97c89e1

Default Java
Eclipse Adoptium-17.0.11+9

Test Results
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6067/2/testReport/

Max. process+thread count
3237 (vs. ulimit of 30000)

modules
C: hbase-backup U: hbase-backup

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6067/2/console

versions
git=2.34.1 maven=3.9.8

Powered by
Apache Yetus 0.15.0 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 25s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
hbaseanti
0m  0s

Patch does not have any anti-patterns.

_ master Compile Tests _

+1 :green_heart:
mvninstall
3m 14s

master passed

+1 :green_heart:
compile
0m 29s

master passed

+1 :green_heart:
checkstyle
0m  9s

master passed

+1 :green_heart:
spotbugs
0m 29s

master passed

+1 :green_heart:
spotless
0m 45s

branch has no errors when running spotless:check.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
3m  3s

the patch passed

+1 :green_heart:
compile
0m 27s

the patch passed

+1 :green_heart:
javac
0m 27s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
checkstyle
0m  9s

the patch passed

+1 :green_heart:
spotbugs
0m 33s

the patch passed

+1 :green_heart:
hadoopcheck
11m 40s

Patch does not cause any errors with Hadoop 3.3.6 3.4.0.

+1 :green_heart:
spotless
0m 43s

patch has no errors when running spotless:check.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
3m 59s

the patch passed

+1 :green_heart:
compile
0m 25s

the patch passed

+1 :green_heart:
javac
0m 25s

the patch passed

+1 :green_heart:
javadoc
0m 18s

the patch passed

+1 :green_heart:
shadedjars
6m 24s

patch has no errors when building our shaded downstream artifacts.

_ Other Tests _

+1 :green_heart:
unit
11m 36s

hbase-backup in the patch passed.

35m 10s

Subsystem
Report/Notes

Docker
ClientAPI=1.46 ServerAPI=1.46 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6067/3/artifact/yetus-jdk17-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/6067

Optional Tests
javac javadoc unit compile shadedjars

uname
Linux b0d7754fdbd0 5.4.0-177-generic #197-Ubuntu SMP Thu Mar 28 22:45:47 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 01f1c9e7f12ae7b6474edd3324a29c4f826d498b

Default Java
Eclipse Adoptium-17.0.11+9

Test Results
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6067/3/testReport/

Max. process+thread count
3168 (vs. ulimit of 30000)

modules
C: hbase-backup U: hbase-backup

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6067/3/console

versions
git=2.34.1 maven=3.9.8

Powered by
Apache Yetus 0.15.0 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 16s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+1 :green_heart:
@author
0m  1s

The patch does not contain any @author tags.

+1 :green_heart:
hbaseanti
0m  0s

Patch does not have any anti-patterns.

_ master Compile Tests _

+1 :green_heart:
mvninstall
3m  5s

master passed

+1 :green_heart:
compile
0m 31s

master passed

+1 :green_heart:
checkstyle
0m 12s

master passed

+1 :green_heart:
spotbugs
0m 32s

master passed

+1 :green_heart:
spotless
0m 45s

branch has no errors when running spotless:check.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
2m 56s

the patch passed

+1 :green_heart:
compile
0m 30s

the patch passed

+1 :green_heart:
javac
0m 30s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
checkstyle
0m 11s

the patch passed

+1 :green_heart:
spotbugs
0m 38s

the patch passed

+1 :green_heart:
hadoopcheck
10m 36s

Patch does not cause any errors with Hadoop 3.3.6 3.4.0.

+1 :green_heart:
spotless
0m 43s

patch has no errors when running spotless:check.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
3m  4s

the patch passed

+1 :green_heart:
compile
0m 21s

the patch passed

+1 :green_heart:
javac
0m 21s

the patch passed

+1 :green_heart:
javadoc
0m 15s

the patch passed

+1 :green_heart:
shadedjars
5m 21s

patch has no errors when building our shaded downstream artifacts.

_ Other Tests _

+1 :green_heart:
unit
10m 25s

hbase-backup in the patch passed.

30m  1s

Subsystem
Report/Notes

Docker
ClientAPI=1.46 ServerAPI=1.46 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6067/4/artifact/yetus-jdk17-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/6067

Optional Tests
javac javadoc unit compile shadedjars

uname
Linux 0ec85006cb35 5.4.0-177-generic #197-Ubuntu SMP Thu Mar 28 22:45:47 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 41ab60d1c66469b2aeb0dc2409f5e276cdc45429

Default Java
Eclipse Adoptium-17.0.11+9

Test Results
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6067/4/testReport/

Max. process+thread count
3189 (vs. ulimit of 30000)

modules
C: hbase-backup U: hbase-backup

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6067/4/console

versions
git=2.34.1 maven=3.9.8

Powered by
Apache Yetus 0.15.0 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 30s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
hbaseanti
0m  0s

Patch does not have any anti-patterns.

_ master Compile Tests _

+1 :green_heart:
mvninstall
3m 16s

master passed

+1 :green_heart:
compile
0m 29s

master passed

+1 :green_heart:
checkstyle
0m 10s

master passed

+1 :green_heart:
spotbugs
0m 31s

master passed

+1 :green_heart:
spotless
0m 46s

branch has no errors when running spotless:check.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
3m  3s

the patch passed

+1 :green_heart:
compile
0m 28s

the patch passed

+1 :green_heart:
javac
0m 28s

the patch passed

+1 :green_heart:
blanks
0m  1s

The patch has no blanks issues.

+1 :green_heart:
checkstyle
0m  9s

the patch passed

+1 :green_heart:
spotbugs
0m 35s

the patch passed

+1 :green_heart:
hadoopcheck
11m 38s

Patch does not cause any errors with Hadoop 3.3.6 3.4.0.

+1 :green_heart:
spotless
0m 44s

patch has no errors when running spotless:check.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
4m 41s

the patch passed

+1 :green_heart:
compile
0m 37s

the patch passed

+1 :green_heart:
javac
0m 37s

the patch passed

+1 :green_heart:
javadoc
0m 26s

the patch passed

+1 :green_heart:
shadedjars
8m 34s

patch has no errors when building our shaded downstream artifacts.

_ Other Tests _

+1 :green_heart:
unit
15m 23s

hbase-backup in the patch passed.

45m 29s

Subsystem
Report/Notes

Docker
ClientAPI=1.46 ServerAPI=1.46 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6067/5/artifact/yetus-jdk17-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/6067

Optional Tests
javac javadoc unit compile shadedjars

uname
Linux 9525c1b490fa 5.4.0-177-generic #197-Ubuntu SMP Thu Mar 28 22:45:47 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 162a10d6c7d19107c0828a7433020f984ef0b50b

Default Java
Eclipse Adoptium-17.0.11+9

Test Results
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6067/5/testReport/

Max. process+thread count
3334 (vs. ulimit of 30000)

modules
C: hbase-backup U: hbase-backup

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6067/5/console

versions
git=2.34.1 maven=3.9.8

Powered by
Apache Yetus 0.15.0 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 44s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
hbaseanti
0m  0s

Patch does not have any anti-patterns.

_ master Compile Tests _

+1 :green_heart:
mvninstall
3m  5s

master passed

+1 :green_heart:
compile
0m 32s

master passed

+1 :green_heart:
checkstyle
0m 12s

master passed

+1 :green_heart:
spotbugs
0m 33s

master passed

+1 :green_heart:
spotless
0m 45s

branch has no errors when running spotless:check.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
2m 55s

the patch passed

+1 :green_heart:
compile
0m 30s

the patch passed

+1 :green_heart:
javac
0m 30s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
checkstyle
0m 11s

the patch passed

+1 :green_heart:
spotbugs
0m 38s

the patch passed

+1 :green_heart:
hadoopcheck
10m 37s

Patch does not cause any errors with Hadoop 3.3.6 3.4.0.

+1 :green_heart:
spotless
0m 44s

patch has no errors when running spotless:check.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
4m 45s

the patch passed

+1 :green_heart:
compile
0m 32s

the patch passed

+1 :green_heart:
javac
0m 32s

the patch passed

+1 :green_heart:
javadoc
0m 28s

the patch passed

+1 :green_heart:
shadedjars
7m 49s

patch has no errors when building our shaded downstream artifacts.

_ Other Tests _

+1 :green_heart:
unit
13m 57s

hbase-backup in the patch passed.

42m 59s

Subsystem
Report/Notes

Docker
ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6067/6/artifact/yetus-jdk17-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/6067

Optional Tests
javac javadoc unit compile shadedjars

uname
Linux 742f99fc7a5a 5.4.0-1103-aws #111~18.04.1-Ubuntu SMP Tue May 23 20:04:10 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 6c5020ac84d2bad817f74fb53c88b15a15272b44

Default Java
Eclipse Adoptium-17.0.11+9

Test Results
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6067/6/testReport/

Max. process+thread count
3792 (vs. ulimit of 30000)

modules
C: hbase-backup U: hbase-backup

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6067/6/console

versions
git=2.34.1 maven=3.9.8

Powered by
Apache Yetus 0.15.0 https://yetus.apache.org

This message was automatically generated.


Feature: Spin Up Servers With DemoApp for Every PR

It might be a firebase server, or AppEngine.  I would consider building a docker on Travis as a Part I and then sending that docker to a server as Part 2.

One possible approach:

Add GitHub hook to remote server when a PR is opened / updated
Remote server pulls the PR, builds, copies build output to a directory and serves it.
Bot posts to the PR with a link to the preview

So, I'm working on this issue.
The following steps will be executed:

Waiting for Github Webhooks
Applies PR patch to a extra branch for the PR (preview/pr-517)
Builds Distribution with Angular CLI
Bundles required dependencies into a bundle (accelerates firebase deploy and load time significant)
Modifies the index.html with a virtual DOM, to use the bundle file.
Removes unnecessary vendors (e.g ´@angular` - it's now in the bundle)
Deploys new change to the Firebase Hosting
Post's link to the PR preview to the PR.

I've already finished this and it's working very well.
I saved a lot of time, by building / enhancing the internal Angular Bot for Material 1 (in progress)
@jelbourn If you wan't to chat about the implementation or how we should continue, let me know :)

Here is a live preview, how it currently looks like.
It has a build time of ~ 1-2 minutes (minus wasted time for manually executing the hook).

https://github.com/DevVersion/material2/pull/2

Notice, how the bot posts the link of the automatically built preview. (Message is just temporary)

@DevVersion wow, that was fast.

Bundles required dependencies into a bundle (accelerates firebase deploy and load time significant)

Are you just running npm install on each PR to get the latest clean dependencies?
Overall sounds great. Once you make a PR, I can spin up a new firebase instance and we can simply point the code to that.


feat(WEG-160): phone number parser

This PR makes sure that only the first phone number is displayed for a facility, even though some facilities have multiple phone numbers in the backend table.

Are you sure that this is thé intended behavior? I thought that both phone numbers were supposed to show up. Maybe I got it wrong.

Are you sure that this is thé intended behavior?

It was my understanding, yes. But I will double-check that.

Ok! If I'm wrong, ship it! :)

@vogelino would you take another look? We are now displaying all phone numbers. I have opted for simply displaying a new row for each phone number, because we had the previous requirement that the icons should be clickable as well. That's why I would suggest adding the new row as opposed to having 2 or 3 phone numbers in one row with one icon.

@vogelino would you take another look?

Great! That makes it very handy! Well done!


Lodash: Fix issue in type of result of _.keyBy

_.keyBy returns an object with a finite set of values, which means that sometimes accessing an attribute will result in undefined instead of the result you may have expected.
Thanks for this project, it's been fantastic for us so far. Please let me know if there's anything I can do to make this PR better! :)

I don't really agree with this change. From the flow docs:

When an object type has an indexer property, property accesses are assumed to have the annotated type, even if the object does not have a value in that slot at runtime. It is the programmer’s responsibility to ensure the access is safe, as with arrays.

Your change suggests that lodash might write undefined values for keys returned by the iteratee function, but clearly this does not happen. According to your reasoning, arrays can only hold optional types, since arrays are finite, too.


#2 Extended documentation for upgrading from CI3 to CI4

Description
We have extended the documentation for upgrading 3.x projects to 4.x
Checklist:

[X] Securely signed commits
[ ] Component(s) with PHPdocs
[ ] Unit testing, with >80% coverage
[X] User guide updated
[X] Conforms to style guide

Wow, this was a ton of work! I will look through it when I have more time. I'd like @lonnieezell to take a look as well. Thank you for your effort.

At a glance this looks awesome. Thanks so much for taking the time to do this! I noticed a couple of tiny things, but won't have a chance to dig deeper into all of until tonight. I'll leave comments then. There are a few headings that our linter is throwing warnings at if you want to look into those.

Nice review @totoprayogo1916. I would also like @kenjis to review this since he made the Upgrade Helper.

@lonnieezell how do you feel about a third-party section, listing some tools to help with the upgrade (without endorsing them)?

This is out of scope for this PR.
But related to DB Migrations.
The Migration table migrations contents are changed.
But it is not documented.
If you upgrade CI3 to CI4 and use the same database,
You need to upgrade  table migrations contents.
The following is the how to upgrade it that I think:

Drop (or rename) the table migrations.
Create a new table migrations for CI4.
Run the CI4 migration in the development environment or so, to create the migration data.
Import the new migration data of CI4 into your production migrations table.

Is it okay? or is there another way? or something missing?

I sent new PR based on this. See  #5078


Clustering of Circles

Use case
We use Circles and Markers combined to display a radius specific to a marker. However, we are unable to hide Circles for these Markers when markers are clustered using the new Cluster Manager.
Proposal
Please could you allow Circles a property of ClusterManagerId that will enable the circle to be clustered alongside with the Marker if clustered.

google_maps_flutter is a wrapper around the existing Google Maps SDK on each supported platform; it only provides access to functionality those SDKs provide. Cluster managers in the SDK only support makers, not other object types, so this can't be implemented in the plugin. You'd need to file this feature request against the Google Maps SDKs themselves.


Update Ui images

Codecov Report
Base: 71.54% // Head: 71.54% // No change to project coverage :thumbsup:

Coverage data is based on head (fb7efdf) compared to base (def84b6).
Patch coverage: 0.00% of modified lines in pull request are covered.

Additional details and impacted files
@@            Coverage Diff            @@
##             master     #235   +/-   ##
=========================================
  Coverage     71.54%   71.54%
  Complexity      659      659
=========================================
  Files           106      106
  Lines          2035     2035
  Branches        242      242
=========================================
  Hits           1456     1456
  Misses          482      482
  Partials         97       97

Impacted Files
Coverage Δ

src/main/java/seedu/intrack/MainApp.java
0.00% <0.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Routing on graphs

Support routing on multiple graphs.
Others

[x] It's not a hack or at least an unauthorized hack :).
[x] The author of the MR has made its own review before assigning the reviewer.
[x] The title means something for a human being.
[x] Labels applied. if it's a release? a hotfix?
[x] Tests added.

@oterral thanks for your suggestions, should be good now.


Add a Gitter chat badge to README.md

ondrejbartas/sidekiq-cron now has a Chat Room on Gitter
@ondrejbartas has just created a chat room. You can visit it here: https://gitter.im/ondrejbartas/sidekiq-cron.
This pull-request adds this badge to your README.md:

If my aim is a little off, please let me know.
Happy chatting.
PS: Click here if you would prefer not to receive automatic pull-requests from Gitter in future.

Coverage increased (+1.4%) to 92.172% when pulling be29e601d543f9b58e8a81918201ee3477671d29 on gitter-badger:gitter-badge into 6ccf80803dafef5b819fb7ed08af3cbb073d2052 on ondrejbartas:master.


[Code Cleaning]: Use "HaveLen()" instead of "len(...).To(Equal(..)" in cache test

What this PR does / why we need it:
This small PR replaces all appearences of Expect(len(X)).To(Equal(Y)) to Expect(X).To(HaveLen(Y)) for better readability and error presentation.
Release note:

NONE

20 PRs are too some kind of a noise, with respect to builds, reviews, retests, etc. Maybe consider compacting them to several single PRs?

20 PRs are too some kind of a noise, with respect to builds, reviews, retests, etc. Maybe consider compacting them to several single PRs?

Sure, I will post future PRs with several related files.
Most of the PRs already passed all lanes so there's no real reason to close them now

/retest

/lgtm

/test pull-kubevirt-e2e-k8s-1.23-sig-compute-cgroupsv2

/test pull-kubevirt-e2e-k8s-1.23-sig-compute-cgroupsv2

/approve
/retest


Collapsed not working (3.4.0)

I have expanded drag view and clicked on fade part its not collapsing. I have resolved this issue by downgrade the version 3.3.0 and its fixed. Please look in to it so i can upgrade with newer version.
Thanks,
Nirav Patel

I got the same problem, too.


add a queuelock to be used by nim

Will use this to make sure that nim does one activity at a time (verify current DPC, test a new DPC, update DPCL based on new config from zedagent etc).

LGTM

Quick question @eriknordmark -- what do you plan to use specifically for in min? Can you give a brief summary of operations that are currently suffering without this in place?

Quick question @eriknordmark -- what do you plan to use specifically for in min? Can you give a brief summary of operations that are currently suffering without this in place?

We have lots of complexity in nim due to things like testing a new DevicePortConfig at index zero (which is a multi-step process waiting for DHCP etc) and while doing that zedagent provides a new DevicePortConfig, which becomes the new index zero.
To handle this nim has code to check if the entry that was tested moved etc.
The thrird activity we do is to periodically verify that the connectivity still works, and the forth is to check (if we are not running the highest priority DevicePortConfig) if a higher priority DPC is now working.
queuelock will be used to ensure that we do one of those at a time.

LGTM


Unhandled Execution Error

Hi
I am randomly getting this error on a Hello World example-code on a "clean" asp.net project.
The error happens very randomly, with no apparent pattern.
I am using this nuget package:
<package id="Noesis.Javascript" version="<IP_ADDRESS>" targetFramework="net471" />

This is the code:

App pool settings:

C++ installations:

If the site starts up without the error, it is able to run like that for a long time. Therefore i created a Powershell script to better provoke the error:

The script will continuously do an issreset and then call the page. The result is about 50/50 chance of getting a 200 statuscode back and getting the error back.

I suspect that this is a cross-threading issue.  Try creating your context for each request.

Thank you for your response.
However i am creating my context for each request. The Page_Load method will run for each request.

With some further testing i have found that this only happens when i use the x64 version of Noesis.Javascript.dll.
When i switch to x86 and set "Enable 32-bit Applications" to True in the App pool, i do not get the error.
This is not a fix for me, as i need to be able to run x64.


az keyvault certificate show returning null for x509CertificateProperties.subjectAlternativeNames in 4.9.0

Related command

az keyvault
Describe the bug

In 4.8.1, az keyvault certificate show would successfully return the x509CertificateProperties.subjectAlternativeNames.

In 4.9.0, x509CertificateProperties.subjectAlternativeNames is null:

I didn't see this listed in the breaking changes, though I'm not sure if I missed something.
To Reproduce

Query for a certificate in 4.9.0.
Expected behavior

x509CertificateProperties.subjectAlternativeNames should not be null.
Environment summary

I've recreated this on both Debian (fish and bash) and Windows (Powershell).
Additional context

Thank you for opening this issue, we will look into it.

Looking into this.


Don't use a pipe for output capturing in Python's test runner

May or may not fix #5779, we'll see.

Python green.

Optional: consider converting output from a public field to an internal field with a public accessor method that raises an exception if called at the wrong stage of the CapturePipe object life cycle.

Turns out that I'd forgotten that the 'output' basically needs to be available at all times (e.g. if the user interrupts the test runner before anything's happened).

 Python

Both failures are known flakes.


not working? maybe? confusing messages being sent

hey there,
I am seeing the following:

from running
npx git-issues-downloader https://github.com/teselagen/lims

this is the output:
npx: installed 186 in 9.641s
username: tnrich
password:
Requesting API...
Successfully requested 1. page of 29
Requesting API...
Successfully requested 0. page of 3
Requesting API...
Successfully requested 1. page of 29
Requesting API...
Successfully requested 0. page of 3
Requesting API...
Successfully requested 1. page of 29
Requesting API...
Successfully requested 0. page of 3
Requesting API...
Successfully requested 1. page of 29
Requesting API...
Successfully requested 0. page of 3
Requesting API...
Successfully requested 1. page of 29
Requesting API...
Successfully requested 0. page of 3
Requesting API...
Successfully requested 1. page of 29
Requesting API...
Successfully requested 0. page of 3
Requesting API...
Successfully requested 1. page of 29
Requesting API...
Successfully requested 0. page of 3
Requesting API...
Successfully requested 1. page of 29
Requesting API...
Successfully requested 0. page of 3
Requesting API...
Successfully requested 1. page of 29
Requesting API...
Successfully requested 0. page of 3
Requesting API...
Successfully requested 1. page of 29
Requesting API...

Thank you for reporting. I will take a look on that.
Beside this message, was you able to download the issues?

Hey @pavelbinar nope. Just kept looping like that on and on.

Looks like you've probably got some faulty parsing here:

@pavelbinar

I'll put a PR in

@pavelbinar fixed it in the above PR

This should be fixed in v0.1.4.
Please try.

Thank you @tnrich and @jeremysuriel for PR.
After all @jeremysuriel code made it into the release.
You both very helpful.
Sorry for the delay with the actual fix release.


pull updated version and done required changes

pull updated version and done required changes
Description
There was a total mess in responsiveness in mobile view previously it was looking like this

now my code is looking like this
IN Desktop View

In Phone View

https://user-images.githubusercontent.com/55352601/112039301-ea14f100-8b69-11eb-8262-922d305b475b.mp4
Fixes #40
Code/Quality Assurance Only

Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?
I had uploaded a video to show how its looking
**I had open a pull request before #42  but because of some conflicts i had to done the changes again after pulling the latest code of master branch . It was reviewed by all 3 reviewers successfully just because of some conflicts it was not able to merge I hope now It will fine **

Thank You @sakshi300699 mam

@sakshi300699  mam Please merge this PR before merging another otherwise i had to the changes again 😅

@ishubham21 please review it sir.

@ishubham21  sir please review it before any conflicts occur again

Thank you @ishubham21 sir

@sakshi300699 mam please merge it

@rupeshmohanty sir please merge this PR 😅


Couldn't execute stack setup --silent

I am experiencing a problem with stack projects both while manually running hie-bios as well as via HLS.
Here is an excerpt from VSCodium's log (HLS version 1.4.0, OS: Arch Linux):
setInitialDynFlags cradle: Cradle {cradleRootDir = "/path-to-my-project", cradleOptsProg = CradleAction: Stack}
Couldn't load cradle for libdir: (CradleError {cradleErrorDependencies = [], cradleErrorExitCode = ExitSuccess, cradleErrorStderr = ["Couldn't execute stack setup --silent"]},"/path-to-my-project",Nothing,Cradle {cradleRootDir = "/path-to-my-project", cradleOptsProg = CradleAction: Stack})

Note the cradleErrorExitCode = ExitSuccess yet cradleErrorStderr = ["Couldn't execute stack setup --silent"].
Originally posted by @mkoloberdin in https://github.com/haskell/haskell-language-server/issues/236#issuecomment-921837122

If I modify Cradle.sh to run stack via env -S ... this issue goes away but hie-bios then dies with this error message:
hie-bios: stack: streamingProcess: exec: invalid argument (Bad file descriptor)

What happens if you execute stack setup in the root of your project? What is the error message?

It works fine. No error message but this goes to stderr:
stack will use a sandboxed GHC it installed
For more information on paths, see 'stack path' and 'stack exec env'
To use this GHC and packages outside of a project, consider using:
stack ghc, stack ghci, stack runghc, or stack exec

If I do a rm -rf ~/.stack first, then this gets spit out to stderr:
Preparing to install GHC (tinfo6) to an isolated location.
This will not interfere with any system-level installation.
Downloaded ghc-tinfo6-8.10.7.
Installed GHC.
stack will use a sandboxed GHC it installed
For more information on paths, see 'stack path' and 'stack exec env'
To use this GHC and packages outside of a project, consider using:
stack ghc, stack ghci, stack runghc, or stack exec

And stack setup --silent does not fail with an error-code?

Nope:
$ stack setup --silent && echo "Success"
Success

but hie-bios fails, claiming it can't execute stack setup --silent? Can you change that to stack setup instead (in hie-bios), so you see stdout and stderr in the error message.

Just tried this with no other modifications and lts-18.7:
hie-bios: CradleError {cradleErrorDependencies = [], cradleErrorExitCode = ExitSuccess, cradleErrorStderr = ["Couldn't execute stack setup"]}


Raster overlay refactoring

This is the Unreal side of CesiumGS/cesium-native#325.

Thanks for the pull request @kring!

:heavy_check_mark: Signed CLA found.
:grey_question: CHANGES.md was not updated.

If this change updates the public API in any way, please add a bullet point to CHANGES.md.

Reviewers, don't forget to make sure that:

[ ] Cesium for Unreal Samples works.

When deleting the overlay component from a tileset (e.g. when removing the Bing Maps from the CWT that was Quick-Added), then the textures are not properly removed. It still displays the textures that had been loaded (with the specific level), and zooming in or out (changing the level) makes then disappear or re-appear. Maybe a missing call to RefreshTileset somewhere? 😁

I tried it out in a branch that is "close" to main (not exactly main, but without these updates, and that's the main point), and there, deleting the overlay causes the tileset to become gray/untextured.

I'll probably need to read more about Material Layers in the first place in order to actually try that out (or is there already some sort of instructions/draft tutorial for that part that I could use?).
Until then, a detail: ML_CesiumRasterOverlay seems to contain an unused part:

When deleting the overlay component from a tileset (e.g. when removing the Bing Maps from the CWT that was Quick-Added), then the textures are not properly removed. It still displays the textures that had been loaded (with the specific level), and zooming in or out (changing the level) makes then disappear or re-appear.

Good catch @javagl! There were two problems here (both now fixed).
First, when we detached raster overlay texture from a geometry tile, we weren't resetting the material's texture to its default (a 1x1 transparent pixel). So it whould just stay set to whatever overlay texture until set to something else. The texture itself was handled by UE's garbage collector so no major drama there, but it caused the symptom you described until adding another overlay or explicitly calling RefreshTileset.
The second (and more serious) problem was that RasterOverlayTile was never being deleted, ever. I don't think that was causing any symptoms beyond a memory leak, but it was a quite serious leak.

Until then, a detail: ML_CesiumRasterOverlay seems to contain an unused part

Fixed.

Thanks @kring!


Simplify layout using flex box

Flex box would allow us to simplify the markup we produce as well as allowing us to support commands that rely on the stretchiness/shrinkiness of glue.  Here's a prototype that use flex box for layout:
Rendering:

HTML

  1 +

      1

        1 +

            1

            x + 1

CSS
body {
  font-size: 48px;
}

.vbox {
  display: inline-flex;
  flex-direction: column;
}

.hbox {
  display: inline-flex;
  flex-direction: row;
  width: 100%;
}

.rule {
  height: 4px;
  background: black;
}

.glue {
  flex-grow: 1;
  flex-shrink: 1;
}

https://jsfiddle.net/evhxcym0/14/

Wow. That HTML is a lot simpler than what we get now from makeVList.
IE apparently has a number of flex bugs. Looking at the list, though, they don't seem much more difficult to work around than the stuff that makeVList currently does to work within Safari.

My hope is that the IE flex bugs aren't too bad.  We should probably make a small test suite of different layouts using this pattern and try it out on IE to see what breaks.  I'm also curious to see how our stretchy SVG interacts with this.

Unfortunately, IE9 doesn't support flex, and we should drop IE9 support first.

Khan Academy has dropped support for IE9 and IE10.  I'm interested how others feel about dropping IE9 support.

FWIW, for the most recent million users to IntMath. only 247 were using IE9 and 397 were on IE10.
I'd say drop support...

@mbourne thanks for the real world usage stats.

If this would be done, would it be possible to examine relative positions in the same way as https://github.com/Khan/KaTeX/wiki/Examining-TeX#boxes?

I suppose you reverse engineer what the boxes were.  Using ems instead of pxs would simplify things a bit.

I tried implementing this suggestion and failed, for reasons described here.

Thanks for investigating.  That's unfortunate.  I think the CSS Layout API will eventually give us what we need, unfortunately it's still being implemented.


Bind address both in jboss.properties and command line

Hi again
There's a WILDFLY_BIND in /etc/wildfly/wildfly.conf which end up in service start
ExecStart=/bin/bash -x /opt/wf10/bin/launch.sh $WILDFLY_MODE $WILDFLY_CONFIG $WILDFLY_BIND

But I also have this in jboss.properties
[root@testcentos ~]# cat /opt/wf10/jboss.properties
jboss.ajp.port = 8009
jboss.bind.address = <IP_ADDRESS>
jboss.bind.address.management = <IP_ADDRESS>
jboss.http.port = 8080
jboss.https.port = 8443
jboss.management.http.port = 9990
jboss.management.https.port = 9993

I dunno which one is taken into account, and I'ld prefer not having both

As I said in the other issue, I brought this from the official Wildfly distribution cause I'd rather use bundled init scripts then provide my own.
But since I'll be fully managing these scripts due to #161. I'll remove -b $3 .
Thanks for being an early adopter. :smile:
There is a lot of tests for this version, but some details still pass unnoticed.

Oh, and I think Wildfly will use -b bind instead of properties.

Fixed in v1.0.1. Thanks again.


Image caching for Graphics.Collage.sprite

I am resurrecting @silverio's pull request #191 from earlier this year. This fixes the performance problem with sprite sheets (see #419 and #332).
Here is a comparison that highlights the improvements. Each of these examples animates this sprite at 30 fps.
The first example uses Graphics.Element.croppedImage. This function inserts an img node into the DOM. The position of the cropping frame gets set in an onload callback. This means that for a moment when the image is loaded, the crop frame is positioned at (0, 0). Leads to a fierce flicker.
The second example uses the current implementation of sprite, which lurks unpublished in Graphics.Collage. On Chrome, I see the frame-rate plummet after about a second. On Firefox, the animation simply doesn't work.
The third example uses the sprite implementation in this pull request. It works great on my machine in both Firefox and Chrome. No flickering or drop in fps.
What do other people see?
EDIT: Fixed hyperlink to the examples page

This is not the only place this bug is present.
You might want to also cache the Graphics.Collage.textured
renderForm with form.ctor of FShape calls drawShape which calls setFillStyle which then calls the texture function which also creates a new Image every time.
What's even worse is that it seems that every time an image is created the img.onload forces the update which then creates even more images which do the same over and over again.
It's surprising that this issue has been present for so long. It makes images in Graphics.Collage effectively unusable (and most likely quite frustrating).
Note: the title of this PR doesn't reflect the nature of the problem. It reads like a feature addition but it's actually more like a major bug fix.

@thisredone Thanks for pointing that out. I renamed the issue to highlight the problem instead of the solution. I will take a look at Graphics.Collage.textured when I get a chance.

Indeed this makes Craphics.Collage quite unusable for me, because I was doing an Elm demo that had a rolling background. Except in the Edge browser, the flickering makes the game simply unplayable.
Is there any workaround? Maybe specifically applied to croppedImage?

Sorry for the slow reply. It has been busy times. All the Graphics.* modules have moved to evancz/elm-graphics so it makes sense to retarget stuff like this. There is a lot going on still, but I expect to be thinking about improving <canvas> support and the learning avenue in the future.

@evancz Should I re-open this PR over on evancz/elm-graphics?

Anything that is adding to the public API, I'd rather not add in right now. If there's also a bug fix in here, the bug fix should be moved.


Linter rule to check for existence of the License file

All our packages should have a License file with the same content as https://github.com/Azure/azure-sdk-for-js/blob/main/LICENSE
We should have a linter rule that checks for this.
Code pointers:

Set up your dev env if you have not already
ESLint Plugin source package
Once you have the rule in place, add the License file to any package that is missing it in the same PR

I am interested in resolving this issue. I think it is viable to check if the contents of LICENCE is identical, but to my knowledge, there is no way for eslint to check if a file exists. (refer eslint and stackoverflow) May I get suggestions to relevant resources that would be helpful?

Fair point.
@deyaaeldeen, @witemple-msft, Any thoughts here?

One idea: @witemple-msft was advocating to use dev-tool to do lint checks on our json files (e.g. package.json and tsconfig.json) because it will be more efficient/natural than using eslint. We could expand on this by making dev-tool also handle existence checks on certain files. To generalize this further, we could make it the entry point to linting (akin to how it handles the new testing stuff now).
Since this is a bit complicated, I suggest that @WeiJun428 ignores it for now.
@WeiJun428 if you're looking for suggestions on a next issue to work on, https://github.com/Azure/azure-sdk-for-js/issues/15746 is pretty cool and I think we could use a 3rd party rule for it.

Turns out this is a check we want to have for other language repos as well. Therefore, we will be having a separate issue https://github.com/Azure/azure-sdk-tools/issues/2353 tracking this requirement such that we add this check in the pipeline instead of linter.
Thanks everyone!


user can close the task

closes #127

@rultor merge

@rultor merge

@h1alexbel OK, I'll try to merge now. You can check the progress of the merge here

@rultor merge

@h1alexbel Done! FYI, the full log is here (took me 1min)


Add Dockerfile for modelmesh-minio-examples image

Closes #297 #302
Signed-off-by: ted chang<EMAIL_ADDRESS>Motivation
Provide instructions to build a MinIO model examples image
Modifications
N/A
Result
N/A

/cc @ckadner

Hi @tedhtchang -- thank you for your PR. Do you know where all those large model files originate from? Since they are so large, I think it would be great if we don't have to keep a copy of those files in the repo, instead, maybe they could be copied/downloaded from their original source at the time we build the image? Or whenever we need them for testing. And delete them afterwards.

Thanks @tedhtchang this is really helpful.
Probably a question for @njhill and @ckadner, I'm wondering whether fvt would be the correct directory to host both Dockerfiles. Maybe it'd be a new quickstart directory for the examples-only Dockerfile while the FVT-related image stays here?

Yes thanks @tedhtchang. I think we should add just the Dockerfile(s) for now while we figure out where to host the larger model files, maybe we could do that in a separate PR so that we keep this branch with all the files until we figure that out.
I agree with @rafvasq that the existing fvt dir probably isn't the best place for this to live. Probably it makes sense to have a new top-level dir called something like mino_build, since I can't really see anywhere else that it would fit very well.

Hi Ted,
I moved the files to into a new minio-examples folder at the project root level, for now.
Although I don’t think we should add this to the modelmesh-serving repo — a 600 MB addition is just too large.
I think we create a new repo soon modelmesh-minio-examples with it's own CI/CD and figure out a way to offload the model files either to COS buckets with public read-access (or even credentialed access for MM maintainers only) or we use another mechanism like Git LFS for Large File Storage as @njhill has suggested

@rafvasq -- I pushed a new modelmesh-minio-dev-examples:latest image with the FVT models you added
https://hub.docker.com/r/kserve/modelmesh-minio-dev-examples/tags

I created a new repository https://github.com/kserve/modelmesh-minio-examples/ from the commits in this PR with a few modifications to

remove the biggest unused models:

fvt/onnx/onnx-mobilenet         (14 MB)
fvt/onnx/onnx-pytorch-converted (4.5 MB)
fvt/onnx/onnx-test-model        (38 MB)
fvt/tensorflow/tfmnist              (78 MB)
fvt/tensorflow/tfmnistnew       (39 MB)

removing any duplicate models in favor of doing COPYs in the Dockerfile:

fvt/keras                           (6.5 MB)
fvt/pytorch/pytorch-mar-dup         (4.6 MB)
fvt/tensorflow/keras-mnist          (6.5 MB)
fvt/tensorflow/keras-mnistnew       (6.5 MB)
fvt/tensorflow/mnist-dup.savedmodel (39 MB)
fvt/tensorflow/mnist.savedmodel     (39 MB)
tensorflow/mnist.savedmodel         (39 MB)

@tedhtchang -- thank you again for this PR. It was really helpful to get the new  https://github.com/kserve/modelmesh-minio-examples/ repo seeded. If you don't mind keeping you fork and branch alive for the coming weeks so we can go back to it in case some of my trimming down was over eager ;-)

@tedhtchang -- thank you again for this PR. It was really helpful to get the new https://github.com/kserve/modelmesh-minio-examples/ repo seeded.

Good good. Thanks.

If you don't mind keeping your fork and branch alive for the coming weeks so we can go back to it in case some of my trimming down was over eager ;-)

I don't mind.


raspberry pi zero w 1.3 lcd hat not displaying and giving error

i enter the command ./fbcp and get this error
vc_dispmanx_display_open failed! Make sure to have hdmi_force_hotplug=1 setting in /boot/config.txt

and i have entered the setting hdmi_force_hotplug=1 and still gives the error

@pokedijimone, which version of Raspbian are you running?

@Edman274 Having the same issue, using Raspbian 1:6.6.31-1+rpt1 (2024-05-29) armv7l / bookworm 32-bit with desktop. I've been screwing around with different settings and gotten nowhere except having the dstatistics show up I think.

@pokedijimone, which version of Raspbian are you running?

the last version avalible on the raspberry imager raspberry pi zero w

Use the legacy "Bullseye" os 32 bit.
run raspi-config to set

SPI Interface in Interface Options -> SPI -> Enabled
Enable the GL driver using Advanced options -> GL driver
reboot
build the fbcp with the -D driver on your LCD. I had a ST7789v with 320 and 240 aspect ratio so had to change C code refered in the issue.

comment the line dtoverlay=vc4-kms-v3d in /boot/config.txt, like this:
# Enable DRM VC4 V3D driver
#dtoverlay=vc4-kms-v3d

Waveshare said it's not supported on bookworm.
Maybe try bullseye?

ok i changed to bullseye what shoukd i do now

Use the legacy "Bullseye" os 32 bit. run raspi-config to set

SPI Interface in Interface Options -> SPI -> Enabled
Enable the GL driver using Advanced options -> GL driver
reboot
build the fbcp with the -D driver on your LCD.
I had a ST7789v with 320 and 240 aspect ratio so had to change C code refered in the issue.

how do i build fbcp

You have do create a build folder in the directory you clone this repo to:
For eg.
cd ~
sudo apt-get install cmake
git clone https://github.com/juj/fbcp-ili9341.git
cd fbcp-ili9341
mkdir build
cd build
You can use many different arguments according to your requirements.
For eg.
You need to put the driver of you LCD (in my case DST7789) and the DC and Reset GPIO pin number (software, not hardare pin numbers, generally mentioned in the usage manual of your LCD screen)
cmake -DST7789=ON -DGPIO_TFT_DATA_CONTROL=25 -DGPIO_TFT_RESET_PIN=27 -DSPI_BUS_CLOCK_DIVISOR=8 -DUSE_DMA_TRANSFERS=OFF -DSTATISTICS=0 ..
Backlight control to switch off automatically after a while of inactivity
cmake -DST7789=ON -DGPIO_TFT_DATA_CONTROL=25 -DGPIO_TFT_RESET_PIN=27 -DSPI_BUS_CLOCK_DIVISOR=8 -DUSE_DMA_TRANSFERS=OFF -DSTATISTICS=0 -DGPIO_TFT_BACKLIGHT=18 -DBACKLIGHT_CONTROL=ON ..
Rotate the screen
cmake -DST7789=ON -DGPIO_TFT_DATA_CONTROL=25 -DGPIO_TFT_RESET_PIN=27 -DSPI_BUS_CLOCK_DIVISOR=8 -DUSE_DMA_TRANSFERS=OFF -DSTATISTICS=0 -DDISPLAY_ROTATE_180_DEGREES=ON ..

In my case for Waveshare 1.44inch LCD HAT I had to disable #dtoverlay=vc4-kms-v3d (https://github.com/juj/fbcp-ili9341/issues/311#issuecomment-1751712711) and compile with the following flags under Bullseye 32bit:
cmake -DST7789=ON -DGPIO_TFT_DATA_CONTROL=25 -DGPIO_TFT_RESET_PIN=27 -DSPI_BUS_CLOCK_DIVISOR=20 -DWAVESHARE_ST7735S_HAT=ON -DUSE_DMA_TRANSFERS=OFF -DGPIO_TFT_BACKLIGHT=18 -DBACKLIGHT_CONTROL=ON -DSTATISTICS=0 ..

(via https://github.com/juj/fbcp-ili9341/blob/d0ebacf7c1f30b19b50997ebb67ba4f70ab95368/README.md?plain=1#L131)


Crashes if there are multiple query params

parseURL("http://example.com?test1=some&test2=more");

Crashes with the following error:
url.URLException@../../.dub/packages/urld/3.0.1/urld/source/url.d(31): domain name 'example.com?test1=some&test2=other' contains illegal character '&' at position 22
Interestingly, I see that the lib handles URLS like this in unit tests:
https://example.org/this?query=value&other=value2
but it will fail with a simler version
https://example.org?query=value&other=value2

I beg to differ. RFC 1738 indeed demands "/" (albeit indirectly), but it's mostly superseded by a more recent RFC 3986 that does not impose such restrictions.

Javascript's URL class does not.

const url = new URL("https://example.org?query=value&other=value2 ");
console.log(url);

will work just fine and correctly define query string

I believe #19 is related


Azure deployment nodejs x64

Is there a way to use a 64 bit nodejs binary when building node modules during deployment?
It seems that trying to use a downloaded x64 nodejs binary to issue the npm install still fails on subequents node-gyp calls, which resort back to using the global command node (which points to D:\Program Files (x86)\...).
I ask this beause some native modules need the 64bit binary to correctly be built. (for example lovell/sharp)

We run node through iisnode. This should do it:
https://azure.microsoft.com/en-us/documentation/articles/nodejs-specify-node-version-azure-apps/

Create an iisnode.yml file in the same directory as the server.js file, and then add the following content to the iisnode.yml file:
nodeProcessCommandLine: "D:\home\site\wwwroot\bin\node.exe"
This path is where the node.exe file within your project will be located once you have published your application to the Azure Website.

However since you seem to hit that problem at deployment time you probably need to alter the PATH env var and add the path to your x64 binary before the x86 node stuff.
https://github.com/projectkudu/kudu/wiki/Xdt-transform-samples

I think @francesconero is referring to npm building native modules. I made a fix which puts the VC++ compiler and a bunch of other lib and h files on azure VMs to support building native npm modules but I only included the files needed for building x86 modules because I figured we don't even have x64 bit node on the server. @francesconero are you bringing your own node runtime?

Right. I remember that. Referencing the issue for context: https://github.com/projectkudu/kudu/issues/1076

@ahmelsayed yes, exactly, @snobu sorry if I wasn't clear. If I remember correctly, I tried to issue a npm install through a downloaded x64 node executable. I gave up pretty quick though, since it's easier right now to just build on an external windows machine and just copy the node modules over.

its still a pain, I'm trying to deploy https://github.com/lovell/sharp to my azure app, which is only readily available for x64 windows.
I can replace node with the 64 bit version, but npm will still be stuck with 32 bit :(

@Freundschaft   same problem with me ,did you solved it?

in the end the only soltuion that worked for me was to upload the compiled binaries directly instead going through NPM, back then I wasnt able to find a more elegant workaround, not sure if something changed now.

Now there's App Service on Linux workers and you can bring your own Docker container or use the_blessed_ ones that come with the service. The service is generally available and offers SLA.

ah nice, that makes totally sense, docker solves a lot of problem for you in that case

bumping this since ive struggled with the same problem all day. eventually i tried the app service on linux with docker, but the node image seems to lack python so i still cant build sharp. what a total nightmare this seemingly easy thing has turned out to be.
has anybody found a solution that doesnt involve uploading compiled binaries?

Build your own container, import from a node one, add the python deps and publish to either Dockerhub or Azure Container Registry.

Thanks for working suggestion, but does someone cares about fixing this bug?
For me, using Linux App Service is not an option, because it lacks of Consumption Plan (which is required in my project). Neither I want to upload a compiled binaries and create child process and other shims and hacks.
:relaxed:

Hi,
is there already a solution apart from uploading my "own" nodejs.
Thanks

We are currently making certain 64 bits nodes available on Azure App Service VM.   Anyone would be able to use it.  @mhoeger can provide more details (ETA, what versions etc).

Thanks a lot, in the meantime It tried:
@mhoeger

Upload node 10.15.3 64 bit via kudu to d:\home\node-10.15.3
Set languageWorkers:node:defaultExecutablePath containing that path in azure portal, section "configuration"
added iisnode.yml pointing to new node-10.15.3. to my deployment
restarted app
redeployed via git (local rep): during the process, kudu correctly recognizes the node version in iisnode.yml (output says: "the iisnode.yml file explicitly...") but the node install process still uses "...\program files(x86)..."

thanks

@thomas-mindruptive - Ashley Grant's recommendation here should be helpful! https://github.com/Azure/azure-functions-nodejs-worker/issues/158#issuecomment-480023626
As a note, we do currently have one 64-bit node version deployed (mainly for testing before we switch logic) try changing languageWorkers:node:defaultExecutablePath to D:\Program Files\nodejs\10.15.2 and it should work.
I'll update this thread later with details on how the official support works when it is ready!

@mhoeger
Thanks, I changed the languageWorkers:node:defaultExecutablePath as mentioned but get the same errors
ERR! sharp Windows x86 (32-bit) node.exe ...
...
remote: gyp ERR! command "D:\\Program Files (x86)\\nodejs\\10.14.1\\node.exe"
Should I change the path env-variable or create a ".deployment" file maybe?
Thanks and best

PS: If I remove WEBSITE_NODE_DEFAULT_VERSION from the app configuration (so languageWorkers:node:defaultExecutablePath) is the only setting pointing to a node version/path, I get errors containing the path D:\Program Files (x86)\npm\1.4.28\node_modules.... So it falls back to an old npm/node version.
Best

Sorry to bother you again. Found a way it works:
Set WEBSITE_NODE_DEFAULT_VERSION to D:\Program Files\nodejs\10.15.2, too.
Thanks and best
Thomas

Hi
Kudu will continue to run in Azure App Service. However, this repo will no longer be maintained.
If the problem persists and is related to running on Azure App Service, please open a support incident in Azure:
https://learn.microsoft.com/en-us/azure/azure-portal/supportability/how-to-create-azure-support-request
This way we can better track and assist you on this case
Thanks,
Joaquin Vano
Azure App Service


arrow-cpp: 12.0.1 -> 13.0.0

Description of changes
https://arrow.apache.org/blog/2023/08/24/13.0.0-release/
Things done
python3Packages.pyarrow, arrow-glib, and gdal still build on x86_64-linux. Didn't do a full nixpkgs-review yet. @veprbl can you test on darwin?

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

This could be related to an optimized codepath in arrow that is only used on certain hardware. Can you tell me what CPU Model you used for the review?

Strangely enough, dask fails for me with:
> FAILED dask/dataframe/tests/test_multi.py::test_concat_categorical[True-False-True] - AssertionError: Series are different
> FAILED dask/dataframe/tests/test_multi.py::test_concat_categorical[False-False-True] - AssertionError: Series are different

It seems upstream has similar observations.
This could be related to an optimized codepath in arrow that is only used on certain hardware. Can you tell me what CPU Model you used for the review?

13th Gen Intel® Core™ i7-13700K × 24

Mine is 11th Gen Intel(R) Core(TM) i7-1165G7, which has some AVX512 extensions. Not sure if arrow makes use of these though. I'll disable that test for now.

@cpcloud could you look into the ibis failure?
https://gist.github.com/tobim/4cdbf4ae0f544c2d46e9afee93279baa

@tobim we haven't added support for pyarrow 13 yet. It looks like most things work, but I'd guess all the new stuff around pandas and pyarrow types is causing this breakage in ibis.


Correct extras_require for conditional install

Here's some docs from a presentation I gave: https://github.com/anthonywritescode/episodes-py3/blob/master/03-backports/slides.md#writing-setuppy-5
There were a couple mistakes here:

Stray single quote
1.7 => 2.7
extra_requires => extras_require

can probably remove this block too once merged: https://github.com/timothycrosley/isort/commit/104b2e4ae4eee050ccef764f2cd7fb276a889b32#diff-2eeaed663bd0d25b7e608891384b7298R44

Looks good, thanks!


add RBAC info for GKE 1.6

Based on https://github.com/coreos/prometheus-operator/issues/357
Not sure how you would like this document structured.

Great! Thanks for writing this up @gytisgreitai ! lgtm


Lag on iOS when sending small pieces of data quickly

Okay so I'm writing an app that sends touch drag events as mouse movements to PC. I'm throttling the requests so that its manageable whilst retaining performance and this seems to work flawlessly on Android. However on iOS the mouse becomes increasingly more laggy, almost like the packets start getting buffered more and more before being sent.
Originally I thought this was because the ability to turn of Nagle's algorithm was missing from the iOS implementation. But I've commented out setNoDelay on the Android side and still have great performance there with no slow down.
I know this is difficult to debug without actually seeing the code but I'm just curious off hand if you guys know what low level implementations in GCDAsyncSocket differ from the java implementation that may contribute to this anomaly.

Okay just a little more insight. I started profiling my app when I was receiving Memory Errors in Xcode console. Below are some screenshots:
http://i.imgur.com/xN9lzAV.png  - Note JS Garbage Collector is increasing in size after every tcp event
http://i.imgur.com/Ya1aMj1.png - The app caps out at about 140 mb on my test device, at this point tcp is unusable
I've profiled the application with DDMS and the android version seems to have no leaks at all. I think I can deduce that the iOS version of the plugin is the culprit? I will run some more profiling tests to see what leaks I can find in my code but so far there's nothing.

Nevermind, was related to this bug: https://issues.apache.org/jira/browse/CB-8002


[New feature] Can remove validation badge.

Hi,
by default, index.html add validation badge link to http://online.swagger.io/validator/debug?url=<my swagger file>.
If you are agree, I suggest to I create merge request to change this behaviours.
Just add validatorUrl: null in section window.swaggerUi = new SwaggerUi({.
Regards,

I close issue, cause I've no response :-(


Support Okta Fastpass

Is your feature request related to a problem? Please describe.
Okta now has a feature called FastPass that can show up as a button on the rendered page for the user to click.

But results in

Describe the solution you'd like
It would be nice if this workflow was supported.
Describe alternatives you've considered
It still works fine with username/password and push/code authentication.

@AlainODea  ;) <3

@andrew-lethbridge-vgh it's been quite a while since I looked at this tool. I'd seriously consider using aws-vault with Okta and AWS IAM Identity Center instead now. That's what we do where I am now.


Update document about routing #1266

The document said "you can include x-swagger-router-controller in your
operation definition, making operationId relative", however,
'x-swagger-router-controller' is obsoleted and the users should use
'x-openapi-router-controller' instead.
Fixes #1266

Hi @wbcchsyn, thx for the PR. x-swagger-router-controller is not obsolete though, it's still used for Swagger 2 specifications:
https://github.com/zalando/connexion/blob/f46551cee8056dca65c1177e8252f19805d95d50/connexion/operations/swagger2.py#L80
It would be good to update the documentation to update both.
Also, we moved to the main branch, so can you please rebase and change the target of your PR?

@RobbeSneyders I think that's already done in #1353 and merged

Thx for pointing that out @aminalaee. Closing this one.


feat(server): including project and files on server side.

Ticket
Title: ETQ Member, je peux créer, modifier et suprimir Projects et Files.
Notion Link: https://www.notion.so/jkergal/ETQ-Member-je-peux-cr-er-modifier-et-suprimir-Projects-et-Files-56a04fd006244cc78bca234b574a2152?pvs=4
Description

Include Language, SandpackTemplate, Project and FileProject entities, services and resolvers with args.
Include relations between Project and Members, Project and FileProject, Project and Language, Project and SandpackTemplate.
Refactor Searchs
Coded without export defaults
Include 1 test in FileProject (need a new PR to include others tests)

Guidelines
🔗 Link your PRs to their related Notion tickets
✍ Use the commit convention to your pull request title
📃 If your code affects the build, update README.md
🚫 Do not merge a PR until all comments are resolved
🗑 Remove your branch after merging

Included followers and following in MemberModel to include social feature.
Included myProjects in Member Model to split projects that i am owner and projects that i am editor.
Included followMember and getAllMembers mutation in MemberResolver.
Include getAllByOwner in ProjectResolver


prevent exploitation of deposit and depositFrom via re-entrance attack

Otherwise attacking token can be used to produce deposit block with blknum ending in 000. This can be exploited by attacker to create a situation when operator is spending the deposit which later disappears. Depending on implementation, this has a potential of invalidating of chain in eyes of client nodes.

Exact scenario is in #161138274

Interesting. This seems like the correct fix assuming 999 deposits per block, although I guess you could also "fix" by increasing the number of intermediate deposit blocks to some number high enough that this will never happen.
LGTM :+1:


BUG in dataset.py

COCO have no methods like filter_by_words() in line 75 and all_captions() in line 69 in dataset.py.

I added these functions by myself such as:
    def filter_by_words(self, words):
        print("Removing captions contain words not in worddict...")
        keep_ann = {}
        keep_img = {}
        for ann in self.dataset['annotations']:
            flag = 1
            q = ann['caption']
            q = q.lower()
            for w in q.split(' '):
                if w not in words:
                    flag = 0
                    break
            if flag == 1:
                keep_ann[ann['id']] = keep_ann.get(ann['id'], 0) + 1
                keep_img[ann['image_id']] = keep_img.get(ann['image_id'], 0) + 1

        self.dataset['annotations'] = [ann for ann in self.dataset['annotations'] if keep_ann.get(ann['id'],0)>0]
        self.dataset['images'] = [img for img in self.dataset['images'] if keep_img.get(img['id'],0)>0]

        self.createIndex()

But I got some trouble when I was training the network then.

add all_captions:
    def all_captions(self):
        captions = []
        for ann in self.dataset['annotations']:
            captions.append(ann['caption'])
        return captions

It seems there remains some other bugs after adding the two functions. For example, there is no run_cell attribute in nn.py

@elviswf can you provide the function for filter_by_words as well? The one above doesn't seem to work.

@pranavr93 Sorry, the code was in my intern company which I can't find now. You can modify the filter_by_words above. It may be easily debugged with a IDE like pycharm.


New Versions

Testing against new python/postgres versions.  Reformatting and optimizing imports

Coverage remained the same at 100.0% when pulling 51710a18d25f787b008930d9fb67dbadd23974c7 on feature/new-versions into ac3257faa3a7a4353a2f83e3e3f260bd38f543c1 on master.


Having trouble running

logs.txt
built from source
Running the executable exits with no output
I'm on linux with a vpn

fixed, had to relogin


Default value for Approx.scale curious

Description
I have found a weird behaviour in approximate comparisons, and I think it's due to a weird default value of 1 for doctest::Approx.scale.
The docs advise that epsilon is "relative -- in percentages" and "the amount within which a difference either way is ignored".
This example suggests that an epsilon of 0.01 allows for a 1% error. Straightforward enough!

REQUIRE(22.0/7 == doctest::Approx(3.141).epsilon(0.01)); // allow for a 1% error

A simple test bears this out:
   CHECK(1.0 == doctest::Approx(0.91).epsilon(0.1));

OK, that's a 9% difference, this passes.
Now, the following is a 11% difference, but the comparison is not false -- very confusing, as we supplied an epsilon of 0.1!
   CHECK_FALSE(1.0 == doctest::Approx(0.89).epsilon(0.1));

This is very much surprising, and seems to be against the intent of epsilon as stated.
Analysis
Upon digging in the code one finds that apparently the default value for scale is 1.
If we set that to 0, the behaviour is as expected:
   CHECK_FALSE(1.0 == doctest::Approx(0.89).epsilon(0.1).scale(0.0));

The docs don't shed much light on how scaleis supposed to work, or why we have to set it 0:

When dealing with very large or very small numbers it can be useful to specify a scale, which can be achieved by calling the scale() method on the doctest::Approx instance.

The implementation is
std::fabs(lhs - rhs.m_value) < rhs.m_epsilon * (rhs.m_scale + std::max<double>(std::fabs(lhs), std::fabs(rhs.m_value)));

seems to just weirdly mutate the difference between the arguments. In the present case, to get 10% tolerance, I have to actually specify an epsilon of 5%! 😕
CHECK_FALSE(1.0 == doctest::Approx(0.89).epsilon(0.05));

Expected behaviour
Without reading the code, I would have assumed that scale works like Fortran's standard library's is_close function , or the absolute tolerance argument of Python's math.isclose(a, b, *, rel_tol=1e-09, abs_tol=0.0):
abs(a-b) <= max(rel_tol * max(abs(a), abs(b)), abs_tol)

or Numpy's numpy.isclose(a, b, rtol=1e-05, atol=1e-08, equal_nan=False), which works similar to Approx

"absolute(a - b) <= (atol + rtol * absolute(b))"

Note how the "epsilon"/rtol is not multiplied on the "scale"/atol.
Note also the following remark in its docs:

The default value is appropriate for expected values of order unity: if the expected values are significantly smaller than one, it can result in false positives. atol should be carefully selected for the use case at hand. A zero value for atol will result in False if either a or b is zero.

However, numpy.isclose has very different default arguments, with atol << rtol, while here scale >> epsilon.
Questions:

What is the intention behind this choice of scale and its default argument? Can that be documented? I tried to find a past issue/PR, but got lost in the succession of restructurings.
Can that default be adapted? AFAICT, a value of 1-e3 would match numpy's difference between atol and reltol of 3 orders of magnitude, and 0 would make the comparison truly "relative".

Extra information

doctest version: v2.4.8.
Operating System: win10
Compiler+version: msys gcc 12.2

See also #389

Also, I think the comparison operator used in == should be <=, not <, because now doctest says 0 is not approximately 0:
CHECK(0.0 == doctest::Approx(0.0).scale(0.0));

Also, I think the comparison operator used in == should maybe be <=, not <, because now doctest says 0 is not approximately 0:

I believe this is the point of scale.
I agree that it needs to be documented.

Also, I think the comparison operator used in == should maybe be <=, not <, because now doctest says 0 is not approximately 0:

I believe this is the point of scale. I agree that it needs to be documented.

I'm not sure I agree that any value of scale should make two identical/equal values compare as "not approximately equal".
Anyway, this is a minor aspect of this (maybe I should have reported that as a separate issue?)...what do you think about the main/first report?