Counting internal iterations

Hello,
I'm really enjoying using divan and I think it lives up to its namesake of being easier to create quick benchmarks.
One issue I've come up against is how to benchmark functions that perform an operation multiple times. I think there are two items here, the first one being an opportunity to improve some of the docs, which I'm happy to help with. Between sample_size, sample_count, item_count, iterations it's not entirely obvious what affects what. I think I can quickly improve that though.
The second is I believe a missing feature that can make it look like there is buggy behaviour. I'm using the demo code below, with two functions. One adds a pairs of numbers together n times, ones sleeps for 100us n times. I've added the sleep because the compiler likes to optimise the add, and sleep makes the issue very clear.
I'd like to be able to indicate to divan that the function I'm running already has some iterations baked into it, and to account for that in its reporting. What's confusing (and initially made me think there was a bug) is that if I add an ItemsCount the throughput correctly accounts for this, but the total time doesn't.
Demo code:
// main.rs
use std::hint::black_box;
use std::thread::sleep;
use std::time::Duration;

pub fn add_multiple(left: usize, right: usize, n: usize) -> usize {
    let mut sum = 0;
    for _ in 0..n {
        sum += black_box(left) + right
    }
    sum
}

pub fn sleeper(micros: usize, n: usize) {
    for _ in 0..n {
        sleep(Duration::from_micros(micros as u64))
    }
}

#[divan::bench(args = [1, 10, 100, 1000, 10000])]
fn add_n_times(bencher: divan::Bencher, n: usize) {
    bencher.counter(n).bench_local(|| add_multiple(3, 4, n));
}

#[divan::bench(args = [1, 10, 100, 1000], sample_count=10)]
fn sleep_n_times(bencher: divan::Bencher, n: usize) {
    bencher.counter(n).bench_local(|| sleeper(100, n));
}

fn main() {
    divan::Divan::from_args().run_benches();
}

Output
$ cargo -q run --release
Timer precision: 100 ns
divan_n           fastest       │ slowest       │ median        │ mean          │ samples │ iters
├─ add_n_times                  │               │               │               │         │
│  ├─ 1           1.188 ns      │ 2.262 ns      │ 1.2 ns        │ 1.298 ns      │ 100     │ 819200
│  │              841.7 Mitem/s │ 442 Mitem/s   │ 833.3 Mitem/s │ 770.4 Mitem/s │         │
│  ├─ 10          3.715 ns      │ 9.208 ns      │ 3.91 ns       │ 4.15 ns       │ 100     │ 409600
│  │              2.691 Gitem/s │ 1.086 Gitem/s │ 2.557 Gitem/s │ 2.409 Gitem/s │         │
│  ├─ 100         46.63 ns      │ 59.91 ns      │ 47.02 ns      │ 48.45 ns      │ 100     │ 25600
│  │              2.144 Gitem/s │ 1.669 Gitem/s │ 2.126 Gitem/s │ 2.063 Gitem/s │         │
│  ├─ 1000        474.7 ns      │ 577.8 ns      │ 477.8 ns      │ 478.1 ns      │ 100     │ 3200
│  │              2.106 Gitem/s │ 1.73 Gitem/s  │ 2.092 Gitem/s │ 2.091 Gitem/s │         │
│  ╰─ 10000       4.749 µs      │ 5.924 µs      │ 4.774 µs      │ 4.807 µs      │ 100     │ 400
│                 2.105 Gitem/s │ 1.687 Gitem/s │ 2.094 Gitem/s │ 2.08 Gitem/s  │         │
╰─ sleep_n_times                │               │               │               │         │
   ├─ 1           533.4 µs      │ 555.2 µs      │ 537.9 µs      │ 541.1 µs      │ 10      │ 10
   │              1.874 Kitem/s │ 1.8 Kitem/s   │ 1.858 Kitem/s │ 1.847 Kitem/s │         │
   ├─ 10          5.271 ms      │ 5.792 ms      │ 5.322 ms      │ 5.37 ms       │ 10      │ 10
   │              1.897 Kitem/s │ 1.726 Kitem/s │ 1.878 Kitem/s │ 1.862 Kitem/s │         │
   ├─ 100         54.41 ms      │ 57.03 ms      │ 55.95 ms      │ 55.96 ms      │ 10      │ 10
   │              1.837 Kitem/s │ 1.753 Kitem/s │ 1.787 Kitem/s │ 1.786 Kitem/s │         │
   ╰─ 1000        559.7 ms      │ 597.5 ms      │ 577.4 ms      │ 575.6 ms      │ 10      │ 10
                  1.786 Kitem/s │ 1.673 Kitem/s │ 1.731 Kitem/s │ 1.737 Kitem/s │         │

It's easier to see on sleep, but it's pretty clear that the time jumps by an order of magnitude per line, but throughput stays consistent.
Just focussing on the median, for each line the output gives:
n | total_time | (n / time) | iterations=iterations
I'd like a way to make it output:
 n | total_time / n | (n / time) | iterations=iterations * n
Solutions
1. Make ItemCount affect the reported time taken
I actually think this is the clearest, but it's a breaking change, and it's confusing with the other members of the enum, BytesCount and CharCount which presumably wouldn't affect the reported time
2. Add another way of indicating to bencher that there are multiple iterations
This would be fine, apart from there are already lots of very similar concepts used (samples, iterations, items) which mean different things, and adding another one adds to the mental load. That solution might look something like:
#[divan::bench(args = [1, 10, 100, 1000], sample_count=10)]
fn sleep_n_times(bencher: divan::Bencher, n: usize) {
    bencher
        .internal_iterations(n)
        .bench_local(|| sleeper(100, n));
}

I'd be happy to make either change, but I suspect it might be contentious, so I'd love to hear your thoughts! Note that the above functionality code of course be achieved by adding / sleeping once, and having divan handle all of the iterations. But there are some realworld functions that are either vectorised, or simply do more than one iteration already.
And if what I'm asking is already possible, I'm very happy to add it to the documentation!

I didn't consider this initially but you're right that there should be a way to focus benchmarks on throughput rather than latency. Right now the output prioritizes minimum time spent. If each benchmark has the same number of internal iterations, or internal iterations get externally normalized, then benchmarks across functions are somewhat comparable.
While individual SIMD benchmarks are valuable, I feel that end-to-end benchmarking of an algorithm that uses high-throughput SIMD techniques would be more valuable/concrete.

I think I understand what you're saying, but just in case I haven't the issue to my eye is not that there is anything wrong with the throughput measurements or reporting, but their inconsistency to the latency. I would say the throughput is displayed correctly, and is very helpful, it's the latency reporting that I'd like to change to account for internal iterations. Maybe I didn't express that very well though!
Comparing to similar tools, pyperf takes inner_loops as a argument, and it doesn't look like criterion supports this use case, it looks similar to the way that divan does it.


install ... services

Hello, thx for reply.
Installed elementary, did all the install steps and reboot the system.
magent.service and mwserver.service didnt start. startet agent with "sudo systemctl start magent.service" <- this services runs
then tried to start mwserver.service -> error -> failed to start service

tried to start unicorn app:app -> error

EDIT:
Deleted VM and installed it another time - next clean install ;-)
mserver.service is now running, Logon is working =)
Now I try to get the agent to work.....
EDIT2:

any ideas?

Try running sudo python3.8 /opt/monitoring/agent/agent.py <-if it creates a sqlite database in the agent directory then it should be working.  The agent should run on python3.6 or newer fine.  There is no asyncio component like the server uses.  The agent will run even if the collector is dead.  It just writes the data to the sqlite db and stores it there until it can send.  It does require higher permissions to write to the agent directory and to run some of the subprocess commands to collect data.

Try running sudo python3.8 /opt/monitoring/agent/agent.py <-if it creates a sqlite database in the agent directory then it should be working.  The agent should run on python3.6 or newer fine.  There is no asyncio component like the server uses.  The agent will run even if the collector is dead.  It just writes the data to the sqlite db and stores it there until it can send.  It does require higher permissions to write to the agent directory and to run some of the subprocess commands to collect data.

Thx for your reply. It's running with python3.8 - thought I tested it before....
The service doesn't start..Error.. I added some lines in magent.service:

Now its running fine.
I like your Projekt. Its small and a minimal GUI. All I need. I want to monitor my 14 Windows 2019 Servers.
Lets test =)
PS: The WEB-interface....cant connect from an other Client to the Webpage.

Thx for your reply. It's running with python3.8 - thought I tested it before....
The service doesn't start..Error.. I added some lines in magent.service:

Now its running fine.
I like your Projekt. Its small and a minimal GUI. All I need. I want to monitor my 14 Windows 2019 Servers.
Lets test =)
PS: The WEB-interface....cant connect from an other Client to the Webpage.

Thanks.  As for the connecting from another computer to the web interface it may be a IP or port issue.  Try setting to 80 or enabling ssl on 443.  I include two self signed certs if you go ssl.
/opt/monitoring/env/bin/gunicorn --bind <IP_ADDRESS>:443 --certfile /opt/monitoring/certificates/localhost.crt --keyfile /opt/monitoring/certificates/localhost.pem run_both:app
or
/opt/monitoring/env/bin/gunicorn --bind <IP_ADDRESS>:80 run_both:app
The agent rules are controlled by the setting.ini file on the agent.  I think I put in a default rule to alert at CPU over 1% for 5 minutes so you may want to turn that off.  You can also add services to be monitored here.  And there is also the ability to run the agent communication via ssl if you want.  It has to be configured on the collector and the agent through settings.ini.  It should still work but I missed testing it in the last update.

Thanks.  As for the connecting from another computer to the web interface it may be a IP or port issue.  Try setting to 80 or enabling ssl on 443.  I include two self signed certs if you go ssl.
/opt/monitoring/env/bin/gunicorn --bind <IP_ADDRESS>:443 --certfile /opt/monitoring/certificates/localhost.crt --keyfile /opt/monitoring/certificates/localhost.pem run_both:app
or
/opt/monitoring/env/bin/gunicorn --bind <IP_ADDRESS>:80 run_both:app
The agent rules are controlled by the setting.ini file on the agent.  I think I put in a default rule to alert at CPU over 1% for 5 minutes so you may want to turn that off.  You can also add services to be monitored here.  And there is also the ability to run the agent communication via ssl if you want.  It has to be configured on the collector and the agent through settings.ini.  It should still work but I missed testing it in the last update.


Let Travis lint using node make lint, instead of a hard-coded command

Re: https://github.com/mozilla/pdf.js/pull/6683#discussion_r46820487.
This seems to work fine locally when running npm test, let's see if Travis agrees.

Please notice that in umd patch I changed make.js to return an error code in case of failure. You can move that in this PR.

This looks good to me. I'm not sure exactly why it is still a work in progress, i.e., what needs to be done here? I'm also fine with doing the error code handling in another PR as it seems a bit out of scope here.

Error code is what let Travis know if linting failed. Can you try commit with failed js file as a test ?

I see, the jshint command that we have right now does that. In that case, yes, we probably need to use error codes in this commit. Thanks for clarifying that!

Error code is what let Travis know if linting failed. Can you try commit with failed js file as a test ?

I did try that previously, and it seemed to work as expected: https://travis-ci.org/mozilla/pdf.js/builds/95454119. But I suppose it can't hurt to do this more explicitly, so I'll push an update patch!

Build where linting fails: https://travis-ci.org/mozilla/pdf.js/builds/95986147.
Build that passes: https://travis-ci.org/mozilla/pdf.js/builds/95986493.

Let's also check that this doesn't mess with the lint command on e.g. the bots.
/botio lint

Nice, thank you!


Add Algorithms Strings Content

Feature:
Description of the problem you're trying to solve, including why you think this should be added
Add algorithms/strings section documentation, implemented algorithms (i.e. example questions), and tests
An overview of the suggested solution
See above
If the feature changes current behavior, reasons why your solution is better
N/A

Closing in favor of alternative organization


Add and fix index.md in chinese angular

Fix Key Commands and add ng add in index.md of chinese  guide angular-cli

[x] I have read freeCodeCamp's contribution guidelines.
[x] My pull request has a descriptive title (not a vague title like Update index.md)
[x] My pull request targets the master branch of freeCodeCamp.
[x] None of my changes are plagiarized from another source without proper attribution.
[x] My article does not contain shortened URLs or affiliate links.

If your pull request closes a GitHub issue, replace the XXXXX below with the issue number.
Closes #XXXXX

Closed and Reopened this PR to attempt to resolve a specific Travis build failure.


⚠ Bofrost.at has degraded performance

In abaece1, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 1527 ms

Resolved: Bofrost.at performance has improved in b4fd2b8 after 35 minutes.


[Question] dose last 2 version exclude IE?

Technically microsoft ditched IE for Edge and are no longer working on IE.
IE become Edge... And it have been a few Edge releases after that
So when you say "last 2 versions" those it exclude IE?

Nope. It requires 2 versions of every browser (Edge and IE are separated browsers according Microsoft).
User last 2 versions, not IE > 0. But I recommend last 2 versions, not dead (it removes IE 10, and will remove IE 11, when Microsoft will stop security updates for IE 11).

Ok, thanks for clearing that up.


Using waitExitOrRemoved for docker start

Currently start command will invoke getExitCode - which is based on
Inspect API - to get returned exit code after container exits, there's
two race conditions here:

if container is started with Restart Policy, there's chance that the
container is restarted quickly before it calls getExitCode, under such
circumstance, the exit code is wrong.

if container is started with --rm, it's possible that container is
removed before getExitCode, in this situation, you can't get correct
exit code either.

Replace getExitCode with waitExitOrRemoved can solve this problem.
Signed-off-by: Zhang Wei<EMAIL_ADDRESS>

@cpuguy83 How about this one.
PS: win2lin test case failure is unrelated

@cpuguy83 updated as per your suggestion. PTAL. :smile:

One minor nit otherwise LGTM.

@cpuguy83 fixed

LGTM

LGTM


Add ulimit

Need to investigate if 6.0 is handling any of this.

Interesting, DSE 5.0 prints this at startup now:
DSE daemon starting with only Cassandra enabled (edit /etc/default/dse to enable other features)
The linux limit 'memlock' is '64'. The minimum recommended is 'unlimited'. Check your configuration.
The linux limit 'nofile' is '4096'. The minimum recommended is '100000'. Check your configuration.
The linux limit 'nproc' is '13724'. The minimum recommended is '32768'. Check your configuration.
Check our documentation for more details. http://docs.datastax.com/en/cassandra/3.x/cassandra/install/installRecommendSettings.html?scroll=installRecommendSettings__user-resource-limits


Implement Validate for Cow

Resolves #7

Ah - I was a bit too trigger-happy there, there is an error with the impl constraint. Will try to figure out what is correct.

Fixed and tested with the following:
Availability(<Cow<'static, [Availability<'static>]> as ::semval::Validate>::Invalidity),

Thanks for this extension! Cow is a very reasonable use case.


Package from git URL BUG - Unity 2020.3.9f Packager Manager

Hi! I tried to download YarnSpinner via the Package Manager in unity but there's an error every time I try to copy and past the GitHub link in the PackageManager.
What I did, step by step:
Opened unity > Package Manager > " + " > ADD package from git URL > Paste the link ( https://github.com/YarnSpinnerTool/YarnSpinner-Unity.git) > Error
I followed this Youtube tutorial: https://youtu.be/4n3AvsB6JRo?t=84

Can you give us any more information about the error?
Did it have any additional information we can use to work out what's happened?
Also what version of Unity are you using?

I tried to download the  Package via "add package from link URL" and there's this text telling the error. I don't know WHY! =(

that error is most often found when you have a mistake in the URL, it looks right but there might be a rogue space, https://docs.unity3d.com/Manual/upm-errors.html#bad-url does following that help?

There's been no movement on this for a while now, closing them.
Feel free to reopen if the issue persists.


Issue setting up NAD AMP with HA

i'm getting the following error message when trying to setup NAD amp ... any ideas what i'm doing wrong ? i'm able to program it's internal web page
2024-02-28 04:59:37.942 ERROR (MainThread) [homeassistant.config_entries] Error setting up entry NAD 16-60 DSP for nad_controller
Traceback (most recent call last):
File "/srv/homeassistant_3.11/lib/python3.11/site-packages/homeassistant/config_entries.py", line 444, in async_setup
result = await component.async_setup_entry(hass, self)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/homeassistant/.homeassistant/custom_components/nad_controller/init.py", line 38, in async_setup_entry
hass.config_entries.async_setup_platforms(entry, PLATFORMS)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'ConfigEntries' object has no attribute 'async_setup_platforms'

Looks like a bug, haven't updated this integration to the latest HA version. Let me fix that for you.

Fixed in https://github.com/Breina/nad_controller/releases/tag/v0.1.0.


The select component is not fetching more pages on scroll after a search has been made

How to reproduce the bug

Open the AsyncSelect storybook
Search for 'Michael'
Close the Select
Re-open the Select
Scroll down to fetch more pages

Expected results
The Select fetches the remaining pages.
Actual results
No pages are fetched.
Screenshots
https://user-images.githubusercontent.com/70410625/157240355-f35e30fa-ae3c-406a-bb87-fef5edc10eeb.mov
Environment

browser type and version: latest Chrome
superset version: master

Checklist
Make sure to follow these steps before submitting your issue - thank you!

[x] I have checked the superset logs for python stacktraces and included it here as text if there are any.
[x] I have reproduced the issue with at least the latest released version of superset.
[x] I have checked the issue tracker for the same issue and I haven't found one similar.

I wasn't able to reproduce it anymore. Maybe it was some development glitch.


proposal: spatial package: add Box, Triangle types and Elem functions

Background
I am developing a replacement for a Signed Distance Function (SDF) library for generating 2D and 3D shapes. This module I am writing makes as heavy use of spatial types and algorithms, notably

Vectors (Already implemented as rn.Vec types)
Bounding Boxes (Implemented only as r2.Box)
Triangles (Not implemented by gonum)
Elem functions such as the Hadamard product. These functions operate on individual elements of vectors.

I am keen on using gonum as the defacto package for all this logic, but it requires the types be added. I am available to contribute this feature.
Proposal
I've been working with these types for the past two weeks, so keep in mind my experience is far from thorough.
Adding Box types and utility methods
The Box type is already present in r2, this proposal would seek to add it to r3 as well.
This proposal would also seek to add utility methods to the Box type. I have the library I wrote to measure how often I've used these methods:

Size.  Size returns the size of a 3d box. Very commonly used in bounding box operations.
Center.  Center returns the center of a 3d box. Very commonly used in bounding box operations.
Vertices.  Vertices returns a slice of 3d box corner vertices. Very commonly used in bounding box operations.
9 uses of Extend. Extend returns a box enclosing two 3d boxes.
8 uses of Translate. Translate translates a 3d box with a Vec
2 uses of Enlarge . Enlarge returns a new 3d box enlarged by a size vector
1 use of func (a Box) MinMaxDist2(p r3.Vec) (min, max float64) returns the minimum and maximum dist * dist from a point to a box. Is quite complex for such a simple objective.

I think gonum is a well suited place for these kind of functions. That said I'd like to open the floor for discussion on how best to combine the functions (or even add others not mentioned here) so that more can be done with less.
Add Triangle types
Adding triangle types for r2 and r3 packages.
Renderers require using triangles for representing 3D and 2D models. Below is the type declaration of Triangle from the sdf package.
type Triangle3 struct {
	// Triangle vertices. Ordering of these vertices decides Normal vector direction. Inverting ordering of two vertices inverts the resulting direction.
	V [3]r3.Vec
}

As of today there are only two methods on the Triangle type which are commonly used. I'd like for these to be added to gonum as well!

func (t Triangle3) Normal() r3.Vec Normal returns the normal vector to the plane defined by the 3D triangle given the numbering scheme of the vertices
func (t Triangle3) Degenerate(tolerance float64) bool Degenerate returns true if the triangle is degenerate. Implementation is incorrect in sdf library.

This functionality and types should also be added to r2 package.
Elem functions
Add all or a subset of proposed Elem functions to r2 and r3 packages.
Now this is where it gets opinionated. I am unsure if the Elem functions are a good fit for gonum mainly because I have yet to have needed them outside of the sdf package (with some exceptions), something which is not true for the previous types and functions. Here are some numbers to illustrate why I have included them in this proposal:

The Elem function has been used a total of 91 times, only in the sdf module. I have also made use of it outside of sdf on several occasions.

// Elem returns a vector with all components set to `f`
func Elem(f float64) r3.Vec {
	return r3.Vec{
		X: f,
		Y: f,
		Z: f,
	}
}

Find these function implementations here at vector.go

30 combined uses of MinElem and MaxElem. MinElem return a vector with the minimum element-wise components of two vectors.
13 uses. func EqualWithin(a, b r3.Vec, tol float64) bool returns true if vectors are within tol of eachother, element wise. Could be renamed to EqualElem
8 uses of AbsElem. returns vector with components set to their absolute value.
9 uses of MulElem. Performs Hadamard product between two vectors
6 uses of DivElem. Performs Hadamard product between a vector a and the inverse components of a vector b.

Potential impact of proposal
This proposal seeks to only add functionality. No breaking changes intended.
Pros:

This package would bring gonum into the forefront as a viable module to be used with 3D libraries.
Minimal API footprint added for Box and Triangle types

Cons

Requires adding a significant API footprint for Elem functions.

This sounds OK to me at least to start a PR to discuss, though I think the elems part should wait as it looks like a significant additions.
Also, I would suggest Extend => Union, Translate => Add, Enlarge => Scale.

Triangle and Box types have been added. Elem functions can wait, as they can easily be implemented as external functions without breaking interface APIs, which was my primary concern in adding Box and Triangle types.


Stateful passes lead to unexpected behavior

What is the expected enhancement?
Running the program below yields an error.
from qiskit import *
from qiskit.transpiler import CouplingMap, PassManager
from qiskit.transpiler.passes import *

qc1 = QuantumCircuit(2, 2)
qc1.h(0)
qc1.cx(0, 1)

qc2 = QuantumCircuit(4, 4)
qc2.h([0,1,2,3])

# making a pass manager to compile the circuits
coupling_map = CouplingMap([[1, 0], [2, 0], [2, 1], [3, 2], [3, 4], [4, 2]])

pm = PassManager()
pass1 = TrivialLayout(coupling_map)
pass2 = FullAncillaAllocation(coupling_map)
pass3 = EnlargeWithAncilla()
pm.append(pass1)
pm.append(pass2)
pm.append(pass3)

qc1_new = pm.run(qc1)
pm.reset()
qc2_new = pm.run(qc2)

The reason is that the same pass manager object is used for transpiling both circuits.
Note that even thought pm.reset() is called in between the invocations, it is not able to reset the pass instances contained within the pass manager, which are themselves stateful. In this case, pass3.layout is modified when it is invoked once, which affects its future invocations.
I think passes should not have global state.

I think this is solved. Can you check it again? pm.reset() was removed in https://github.com/Qiskit/qiskit-terra/pull/3286/files#diff-c62cce1ef62cc854fa7269f6c2c85dd8L193. And that refactor probably solved it. Feel free to reopen.

The general problem is still a potential issue (though I'm not aware of any other concrete instances, so I think low-priority is fine.)
Even after #3286, pass instances are only constructed once, and re-used if the pass manager is re-run, so if any pass writes something to self (other than the arguments to its constructor), it could affect future runs. e.g. The issue in this case with EnlargeWithAncilla was fixed in #3363 by the removal of an assignment in self.layout in pass.run.

hmm... you are right.
An example would be awesome tho.

I'm going to close this issue now as old.  Several of Qiskit's built-in transpiler passes are still stateful (and certainly there are plenty that aren't re-entrant), but they all should be resetting any per-run state once their run is called.  We don't require passes to be re-entrant or otherwise concurrency safe from the same instance.
If there are any existing passes that cause problems when re-run, we can open specific issues for them to provide fixes.


Assess Eagle-i Resource Ontology terms (ERO)

ERO has is officially no longer actively developed:
https://github.com/OBOFoundry/OBOFoundry.github.io/issues/909#issuecomment-816298651
When ERO was being built, ERO developers were an active part of OBI development. The scope or ERO and OBI overlap -- I'm not 100% clear on how much they overlap. Are there terms that OBI should adopt from ERO or coin anew in OBI?
These are the steps I propose:

a quick analysis of what's in ERO
a query of how ERO is used by other OBO ontologies as represented in Ontobee
ask OBO Discuss who is using ERO and what for

Hopefully this would give use a solid sense of what ERO terms are most valuable. Then we could try an group them and try to line them up with OBI branches or templates.
I am chronically over-tasked, so I don't expect to get to this any time soon. Help would be appreciated.

All - leave a comment here with sets of terms that you think are worth salvaging.

immunoassay http://purl.obolibrary.org/obo/ERO_0001362

'patient screening' http://purl.obolibrary.org/obo/ERO_0000722
It is defined as an assay and has the context of an investigation.

Discussed on 2021-09-20. ERO 'patient screening' term may be too broad.

Confirm that "patient screening" is very broad. If search google using "patient screening", there are multiple situations doing screening of patients: 1. clinical trial, 2. research study, 3. general cancer preventive screening, 4. screening a patient to see if fits for a surgical procedure, or even 5. the COVID-19 screening tests.

This PR has been open for a long time now. I will go ahead and close it.  If there are other terms that OBI should adopt from ERO we can reopen this issue and discuss those terms.


create AAQ resource

Short description: AAQ can be enabled from CNV. Need to add support for this kind: https://github.com/kubevirt/application-aware-quota/blob/main/README.md
More details:
What this PR does / why we need it:
Which issue(s) this PR fixes:
Special notes for reviewer:
Bug:

/verified

/verified

/cherry-pick v4.15


About CI3 maintenance

@narfbg @lonnieezell @michalsn @MGatner @paulbalandan @samsonasik
Thank you for maintaining CI!
Recently, CI3 repository has less activities, but many users wish CI3 is maintained and support php8+, if it is possible.
There are many candidates to help maintaining CI3 in forum, but no one has been selected yet.
I also would like to help maintaining CI3 repository.
Anyway, I would like to talk about the future of CI3.
(add maintainers, switch to 3.2.0+ or  continue 3.1.12+, php8+ support, and so on)

Adding maintainers would be a decision for the Foundation to make.
Personally I have no objections to the community keeping up CI3, but from a documentation and logistics standpoint I would like it to stop being the "standard" and see the majority of developers move on with CI4.
CI3 was a deeply loved framework and filled a crucial niche but its sensitivity to backwards-compatibility has kept around habits that are now 10+ years old. The larger PHP (and even larger webdev, and even even larger development) community won't take CodeIgniter seriously as long as CI3 is its iconic representation.

Adding maintainers would be a decision for the Foundation to make.
Personally I have no objections to the community keeping up CI3, but from a documentation and logistics standpoint I would like it to stop being the "standard" and see the majority of developers move on with CI4.
CI3 was a deeply loved framework and filled a crucial niche but its sensitivity to backwards-compatibility has kept around habits that are now 10+ years old. The larger PHP (and even larger webdev, and even even larger development) community won't take CodeIgniter seriously as long as CI3 is its iconic representation.

@MGatner Thank you for your response!
I understand your opinion that CI4 is the standard framework and we need to wait the Foundation decision.
For me, the main problem is the "migration" from 3 to 4.
The CI4 is the completely new framework, if it has the same concept. Thus, there are no simple migration. https://codeigniter4.github.io/userguide/installation/upgrade_4xx.html
My main hope is to add maintainers to bcit-ci group.
If it is difficult for the Foundation to choose someone as maintainer, I would be grateful if you could let us know.

@MGatner Thank you for your response!
I understand your opinion that CI4 is the standard framework and we need to wait the Foundation decision.
For me, the main problem is the "migration" from 3 to 4.
The CI4 is the completely new framework, if it has the same concept. Thus, there are no simple migration. https://codeigniter4.github.io/userguide/installation/upgrade_4xx.html
My main hope is to add maintainers to bcit-ci group.
If it is difficult for the Foundation to choose someone as maintainer, I would be grateful if you could let us know.

Admittedly I've been way too busy lately so it's been a while since I checked that thread, but IIRC none of the people that volunteered to contribute had any experience, many without having even made PRs. Ideally, we'd like to see someone that has been active in the issues already.
To be honest, I have not kept a close eye on the C3 repo to see who has been active. I talked to Narf about it at one point and pointed him to the thread to see what he thought of the people, and then didn't hear back. He's been pretty busy I guess, also, but he's also the one with the most experience and guidance on that repo.
I would love to see someone(s) help out with that repo, though.

Admittedly I've been way too busy lately so it's been a while since I checked that thread, but IIRC none of the people that volunteered to contribute had any experience, many without having even made PRs. Ideally, we'd like to see someone that has been active in the issues already.
To be honest, I have not kept a close eye on the C3 repo to see who has been active. I talked to Narf about it at one point and pointed him to the thread to see what he thought of the people, and then didn't hear back. He's been pretty busy I guess, also, but he's also the one with the most experience and guidance on that repo.
I would love to see someone(s) help out with that repo, though.

@lonnieezell Thank you for your response!
And thank you for setting up the board in forum.
I understand that CI4 members have less attention to CI3 ;)
If the recommendation is allowed, I would like to recommend @gxgpet from many candidates in forum.
I am not CI specialist, but I think that @gxgpet have some knowledges about CI and @gxgpet contributes from 2016.
Could you check @gxgpet work?
commits: https://github.com/bcit-ci/CodeIgniter/commits?author=gxgpet
pull requests: https://github.com/bcit-ci/CodeIgniter/pulls?q=is%3Apr+author%3Agxgpet+
comments to issues and prs: https://github.com/bcit-ci/CodeIgniter/issues?q=commenter:gxgpet

@lonnieezell Thank you for your response!
And thank you for setting up the board in forum.
I understand that CI4 members have less attention to CI3 ;)
If the recommendation is allowed, I would like to recommend @gxgpet from many candidates in forum.
I am not CI specialist, but I think that @gxgpet have some knowledges about CI and @gxgpet contributes from 2016.
Could you check @gxgpet work?
commits: https://github.com/bcit-ci/CodeIgniter/commits?author=gxgpet
pull requests: https://github.com/bcit-ci/CodeIgniter/pulls?q=is%3Apr+author%3Agxgpet+
comments to issues and prs: https://github.com/bcit-ci/CodeIgniter/issues?q=commenter:gxgpet

Thank you for your statements, @sapics. Much appreciated, yet I'm not considering myself a really perfect contributor from the points of view stated here and on the forum.
I think that @narfbg is a very important and essential member of this project, and while I agree that I could, for the foreseeable future, continue to answer new issues/comments/responses/maybe even create PRs here, as well as the others could do it too, it would be great if the activity from here would be backed up/approved/checked by Andrey, in the end.
Maybe not much activity has happened around here in the past months or weeks, but let's be honest, the CI3 is in a good shape, for its stability and functionality, as it is a mature project. Because of this, I think that this version of CI is already on a good course of action, and thus, you couldn't really say that it's not maintained.
So in my opinion, there's nothing to be worried about CI3.

Thank you for your statements, @sapics. Much appreciated, yet I'm not considering myself a really perfect contributor from the points of view stated here and on the forum.
I think that @narfbg is a very important and essential member of this project, and while I agree that I could, for the foreseeable future, continue to answer new issues/comments/responses/maybe even create PRs here, as well as the others could do it too, it would be great if the activity from here would be backed up/approved/checked by Andrey, in the end.
Maybe not much activity has happened around here in the past months or weeks, but let's be honest, the CI3 is in a good shape, for its stability and functionality, as it is a mature project. Because of this, I think that this version of CI is already on a good course of action, and thus, you couldn't really say that it's not maintained.
So in my opinion, there's nothing to be worried about CI3.

@gxgpet Thank you for your comment!
I agree that @narfbg is a important and essential member and @narfbg's knowledge, programming skill and hard work have kept CI3 stable and of high quality.
On the other hand, I'm worried that one maintainer do all the CI repository work, which puts a lot of strain on maintainer.
For example, it would be a stress for maintainer to handle "how to" or "CI4 relates" issue.
Besides, prs for typo do not require knowledge of php and CI, so anyone can handle it.
(I'm not sure if @narfbg is stressed or not by these issues.)
One idea is to add a "sub" maintainer(s) after making the rule that only @narfbg can merge prs related to CI3 programs and publish.
By adding the "sub" maintainer(s), we could get insurance for the repository to survive if we lose contact with main maintainer.
(I'm not good at English, so I use google translation. I'm sorry if I make any rude expressions or misunderstandings.)

@gxgpet Thank you for your comment!
I agree that @narfbg is a important and essential member and @narfbg's knowledge, programming skill and hard work have kept CI3 stable and of high quality.
On the other hand, I'm worried that one maintainer do all the CI repository work, which puts a lot of strain on maintainer.
For example, it would be a stress for maintainer to handle "how to" or "CI4 relates" issue.
Besides, prs for typo do not require knowledge of php and CI, so anyone can handle it.
(I'm not sure if @narfbg is stressed or not by these issues.)
One idea is to add a "sub" maintainer(s) after making the rule that only @narfbg can merge prs related to CI3 programs and publish.
By adding the "sub" maintainer(s), we could get insurance for the repository to survive if we lose contact with main maintainer.
(I'm not good at English, so I use google translation. I'm sorry if I make any rude expressions or misunderstandings.)

I creates a patch for php8.0 and it passes all tests!
I also switch from travis-ci to github actions.
https://github.com/sapics/CodeIgniter/commit/9581af18a1e14b26a9febdc121221ead7e3f3305
https://github.com/sapics/CodeIgniter/actions/runs/479455234
For fixing error in mikey179/vfsstream (composer), I use my own repository as
https://github.com/sapics/CodeIgniter/commit/9581af18a1e14b26a9febdc121221ead7e3f3305#diff-d2ab9925cad7eac58e0ff4cc0d251a937ecf49e4b6bf57f8b95aab76648a9d34R23.
But, this is bad as official code and it also needs to set up secret environment variable in github repository.
It would be better to create a new composer package like codeigniter/vfsstream with bcit-ci/vfsStream repository.
I would like to create a PR with fixing the commit, after composer codeigniter/vfsstream is made.
Could someone in CI member make a new composer?

I creates a patch for php8.0 and it passes all tests!
I also switch from travis-ci to github actions.
https://github.com/sapics/CodeIgniter/commit/9581af18a1e14b26a9febdc121221ead7e3f3305
https://github.com/sapics/CodeIgniter/actions/runs/479455234
For fixing error in mikey179/vfsstream (composer), I use my own repository as
https://github.com/sapics/CodeIgniter/commit/9581af18a1e14b26a9febdc121221ead7e3f3305#diff-d2ab9925cad7eac58e0ff4cc0d251a937ecf49e4b6bf57f8b95aab76648a9d34R23.
But, this is bad as official code and it also needs to set up secret environment variable in github repository.
It would be better to create a new composer package like codeigniter/vfsstream with bcit-ci/vfsStream repository.
I would like to create a PR with fixing the commit, after composer codeigniter/vfsstream is made.
Could someone in CI member make a new composer?

@sapics Why don't you send a PR to mikey179/vfsstream?
What is the error? Is it CodeIgniter specific?

@sapics Why don't you send a PR to mikey179/vfsstream?
What is the error? Is it CodeIgniter specific?

@kenjis Currently, CI3 using mikey179/vfsstream "v1.1.0", but current version is "v.1.6.x", and they are now working for "v2.x".
Thus, there are no way to send a PR to old version, I think.
I also guess that most of the repository owner would not accept old version's update patch.
The error is just one line error ;)
https://github.com/sapics/vfsStream/commit/00b34280d2c43edb0ad5a64719110fe7e7590350

@kenjis Currently, CI3 using mikey179/vfsstream "v1.1.0", but current version is "v.1.6.x", and they are now working for "v2.x".
Thus, there are no way to send a PR to old version, I think.
I also guess that most of the repository owner would not accept old version's update patch.
The error is just one line error ;)
https://github.com/sapics/vfsStream/commit/00b34280d2c43edb0ad5a64719110fe7e7590350

@sapics I got it.
Even v1.x-dev requires PHP >=5.6.0.
https://packagist.org/packages/mikey179/vfsStream#v1.x-dev
Probably you're right.

@sapics I got it.
Even v1.x-dev requires PHP >=5.6.0.
https://packagist.org/packages/mikey179/vfsStream#v1.x-dev
Probably you're right.

There were errors with v1.2.0 as #2526 😢

There were errors with v1.2.0 as #2526 😢

I have created followings which all tests are passed in php5.3-8.0.
codeigniter31/framework in composer with repo. https://github.com/CodeIgniter31/CodeIgniter31
I created it because I need CI3 to work with the latest PHP that can be tested for myself.
Because, the currently released 3.1.11 is more than one year old and doesn't include fixes for php7.4 and php8.0.
And there are no new updates or informations from the Foundation or CI members.
CAUTION
The repository (CodeIgniter31/CodeIgniter31) is not an official one, it is just a personal one.
I do not guarantee future updates or operations of them.
Please use it for a temporary tests, if anyone uses it. I recommend to wait for official release for production use.

I have created followings which all tests are passed in php5.3-8.0.
codeigniter31/framework in composer with repo. https://github.com/CodeIgniter31/CodeIgniter31
I created it because I need CI3 to work with the latest PHP that can be tested for myself.
Because, the currently released 3.1.11 is more than one year old and doesn't include fixes for php7.4 and php8.0.
And there are no new updates or informations from the Foundation or CI members.
CAUTION
The repository (CodeIgniter31/CodeIgniter31) is not an official one, it is just a personal one.
I do not guarantee future updates or operations of them.
Please use it for a temporary tests, if anyone uses it. I recommend to wait for official release for production use.

@sapics It is better to write the CAUTION in the README of the package/repository.

@sapics It is better to write the CAUTION in the README of the package/repository.

Just my opinion, because I am unaware if there are any legal ramifications, but creating a GitHub organization intentionally mimicking an existing legal entity seems like a bad idea. You would not need your disclaimer if the code were already hosted under your personal fork.

Just my opinion, because I am unaware if there are any legal ramifications, but creating a GitHub organization intentionally mimicking an existing legal entity seems like a bad idea. You would not need your disclaimer if the code were already hosted under your personal fork.

I made it with the hope of helping someone, but I deleted it because I don't want it to be a legal issue.

I made it with the hope of helping someone, but I deleted it because I don't want it to be a legal issue.

@sapics You have already published https://github.com/sapics/vfsStream/tree/v1.1.x
and https://github.com/sapics/CodeIgniter/tree/jit80
Are they the same as deleted repositories under CodeIgniter31?
If so, you already would help someone who wants PHP8 compatible CodeIgniter 3.

@sapics You have already published https://github.com/sapics/vfsStream/tree/v1.1.x
and https://github.com/sapics/CodeIgniter/tree/jit80
Are they the same as deleted repositories under CodeIgniter31?
If so, you already would help someone who wants PHP8 compatible CodeIgniter 3.

@kenjis Thanks! Yes, it is the similar one which adds php80+jit tests. If it helps someone's work, I am happy :)
Some hours ago, I deleted the group and the composer, and all repositories which relates to CI3.
Sorry to CI member, if you feel bad to my action, I apologize.

@kenjis Thanks! Yes, it is the similar one which adds php80+jit tests. If it helps someone's work, I am happy :)
Some hours ago, I deleted the group and the composer, and all repositories which relates to CI3.
Sorry to CI member, if you feel bad to my action, I apologize.

I created pr #6014 which works well without changing composer with a bit hacky way.
If someone wants to try to test in php8.0, please use #6014's commit.
And we also need to merge the other pr for php8.0.

I created pr #6014 which works well without changing composer with a bit hacky way.
If someone wants to try to test in php8.0, please use #6014's commit.
And we also need to merge the other pr for php8.0.

@sapics you've done good work and it is worth sharing. I am not a member of the CodeIgniter Foundation nor do I have any knowledge of GitHub's legal stance. But the fact that you felt the need to put a disclaimer on the repo I think was telling. Sharing the code out of your personal account seems to me a much better approach, no disclaimer necessary. I also hope whoever is on the CI3 team will work with you on getting any appropriate changes made to the main repo.

@sapics you've done good work and it is worth sharing. I am not a member of the CodeIgniter Foundation nor do I have any knowledge of GitHub's legal stance. But the fact that you felt the need to put a disclaimer on the repo I think was telling. Sharing the code out of your personal account seems to me a much better approach, no disclaimer necessary. I also hope whoever is on the CI3 team will work with you on getting any appropriate changes made to the main repo.

Thanks @MGatner for reply! I am relieved by your reply.
The PR could pass all tests in php8.0, thus, I hope CI3 will be easier to merge the other PRs.

Thanks @MGatner for reply! I am relieved by your reply.
The PR could pass all tests in php8.0, thus, I hope CI3 will be easier to merge the other PRs.

Years ago when I started with the first line of code I stumbled across a book with some recommendations for "how to release software" and one key point was made to try and create specific stable versions catering to a particular set of requirements rather than constantly changing a core part and potentially breaking or changing features in undesirable manners. This stuck with me for a long time and I think it very much applies to the underlying issue of PHP compatibility CI3 faces now.
It very much is just the opinion of the author of that book and myself, but CI3 as it stands should probably strive to achieve compatibility with the last version of PHP 7 before attempting the change to 8. A CI3.1 only really making sense as a breaking change that embraces PHP 8 changes in ways that might even require PHP 8 to function. The main reason for that is the changes made in PHP in some regards are quite severe, but also offer so much more.
I been slowly reading through the changes and following development of PHP 8 and it finally, at least seems, that the push is towards rejuvenating some older concepts and structures that were not able to adapt to the changes made since they were first thought up. A lot of these changes seem to want to make PHP 8 more relevant and less likely to develop pitfalls that can break modern application projects. It does seem odd to a veteran of PHP in a lot of ways, but seeing other languages evolve and bringing new concepts to the table it feels like the right move.
From the perspective of a hosting provider it is also easier to handle complications arising from major version changes of dependencies via discrete versions rather than constant development and I say that as a fan of the latter. It affords more time for application development when you don't have to debug due to underlying compatibility issues.
Few days ago I started looking into the same thing @sapics had, but ended up giving up trying to update all the way to 8 and instead wanted to just attempt to redo for 7.4 what was needed to take advantage of some fixes and enhancements. Not much seems to be needed for just that goal, but I am also pretty rusty with bare metal PHP nowadays. It just seemed so much more logical to let PHP 8 mature further and get the s*** tested out of it before potentially doing an upgrade and then later having to throw stuff out again as faults are found.
Again, just my point of view and advice. I'm well confident a good decision will be made and CI3 will continue to make my life easier as it has for so many years now. :)

Years ago when I started with the first line of code I stumbled across a book with some recommendations for "how to release software" and one key point was made to try and create specific stable versions catering to a particular set of requirements rather than constantly changing a core part and potentially breaking or changing features in undesirable manners. This stuck with me for a long time and I think it very much applies to the underlying issue of PHP compatibility CI3 faces now.
It very much is just the opinion of the author of that book and myself, but CI3 as it stands should probably strive to achieve compatibility with the last version of PHP 7 before attempting the change to 8. A CI3.1 only really making sense as a breaking change that embraces PHP 8 changes in ways that might even require PHP 8 to function. The main reason for that is the changes made in PHP in some regards are quite severe, but also offer so much more.
I been slowly reading through the changes and following development of PHP 8 and it finally, at least seems, that the push is towards rejuvenating some older concepts and structures that were not able to adapt to the changes made since they were first thought up. A lot of these changes seem to want to make PHP 8 more relevant and less likely to develop pitfalls that can break modern application projects. It does seem odd to a veteran of PHP in a lot of ways, but seeing other languages evolve and bringing new concepts to the table it feels like the right move.
From the perspective of a hosting provider it is also easier to handle complications arising from major version changes of dependencies via discrete versions rather than constant development and I say that as a fan of the latter. It affords more time for application development when you don't have to debug due to underlying compatibility issues.
Few days ago I started looking into the same thing @sapics had, but ended up giving up trying to update all the way to 8 and instead wanted to just attempt to redo for 7.4 what was needed to take advantage of some fixes and enhancements. Not much seems to be needed for just that goal, but I am also pretty rusty with bare metal PHP nowadays. It just seemed so much more logical to let PHP 8 mature further and get the s*** tested out of it before potentially doing an upgrade and then later having to throw stuff out again as faults are found.
Again, just my point of view and advice. I'm well confident a good decision will be made and CI3 will continue to make my life easier as it has for so many years now. :)

@Tampa you could well be correct.  We have CI3 working fine under PHP 7.4.  We won't upgrade to PHP8 until security support for 7.4 ends in November 2022, which is actually not that far away.  Some assurances that CI3 will eventually support PHP8 would be nice, but I realise nobody is paying any money for CI so such an expectation cannot be justified.

Does anyone know what exactly is broken with CI3 on PHP 8?

Largely  nothing.
I've been using CI3 on PHP8 on my dev machine for a few weeks.
Theres a couple of logic changes though such as comparing numbers to strings that have changed and behaviours in the language which need to be tested for.
Most notably affected are sessions and flash data however several fixes have been proposed but nothing merged in. The problem is nobody uses... everything! so we can't be sure and no doubt a few more will come forward.
I suppose it depends on if CI intend on supporting v3 (and PHP8) going forward to address them. Sadly CI4 isnt a option for me (yet) as the amount of work to essentially rewrite them is too large at present.
Get Outlook for Androidhttps://aka.ms/ghei36

From: Andrew Suares<EMAIL_ADDRESS>Sent: Thursday, February 4, 2021 7:32:16 AM
To: bcit-ci/CodeIgniter<EMAIL_ADDRESS>Cc: Subscribed<EMAIL_ADDRESS>Subject: Re: [bcit-ci/CodeIgniter] About CI3 maintenance (#6012)
Does anyone know what exactly is broken with CI3 on PHP 8?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://github.com/bcit-ci/CodeIgniter/issues/6012#issuecomment-773097216, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ADDFJ4KIBNDPMWKXHHV6R3TS5JEQBANCNFSM4VULBQIQ.

Similar findings to me - I tested one of our projects in CI3 using PHP8.  The most apparent thing that was broken was flash data.  This was a really easy fix.  I also heard that migrations are broken (I didn't test them), but again I think it's easy to fix.
We're also in the same boat, some of our CI3 projects are working well and do everything that's required, so a complete re-write in CI4 isn't justified at the moment.

We've deployed CI 3 on a large project. Works fine on PHP 7.3. HMVC modules makes it easy to manage all the parts of the system. The CI API works great. All in all, everything works.

I think the fact that people consider version 4 a "kill" instead of an upgrade is pretty telling of the gap that version 3 created by its focus on backwards-compatibility. I've written about this on the forums but basically: backwards-compatibility is easier on developers because it makes a quicker upgrade path but I accumulates "development debt" that a future version will always need to pay for. Version 4 is paying that coin.
An example. PHP 5.3 (2009 I think?) introduced namespaces and PSR-0 established standards for namespaces and autoloading. In 2014 FIG deprecated these standards for a second set (PSR-4) which still holds today (7 years old mind you). CodeIgniter 3 was released in 2015 without native spl class loading and chose to maintain "Autoloading" as "components for the framework to initialize during bootstrap". Still to this day we get people switching to version 4 confused about autoloading, a PHP feature of 12 years and standard for 7.
Version 3 was awesome, and I still have and maintain many CI3 projects most of which are unlikely to get rewritten. But trying to keep CI3 in active development is creating legacy developers, people unfamiliar with the last ten years of improvements in PHP, web development, and coding in general.
My advice: take the time to learn CI4 (or another modern framework). Figure it out, learn what has changed in PHP, learn to collaborate on open-source libraries and work with developers outside of CI3 context. Then if you still love CI3, come back and make it better.

Oh I understand the reasoning behind it.
I don’t know what the foundations plan is with 3 and I don’t have hours to trawl though forum posts but the last time I looked it was remarkably quiet on the topic other than concerned posts. I have been using CI for a couple of Years now and used 3 as that’s what was “active”. In fact if you go to the CI Homepage and click downloads at the top it still says 3 is the current branch with 4 “upcoming” 🤷♂
I fully intend to port projects and start new ones on CI4 but that takes time and meanwhile I have servers that will get upgraded to PHP8 in the next 12 months and I need to make sure projects still on CI3 will continue to run even if it means I have to patch in code to fix issues myself.
I fully understand that this is a free project and it takes time to maintain older stuff but PHP8 is unlikely to require major changes but even after months or discussion and pulls on basic stuff like the session issue were still at 3.1.11. I think many people are perplexed that support was seemingly dropped overnight last March.
Even if the foundation have no plans to support 3 themselves at least let the community maintain it and state on the downloads page that it’s a defunct branch and publicly maintained.
From: MGatner<EMAIL_ADDRESS>Sent: 04 February 2021 13:40
To: bcit-ci/CodeIgniter<EMAIL_ADDRESS>Cc: Robin Hickmott<EMAIL_ADDRESS>Comment<EMAIL_ADDRESS>Subject: Re: [bcit-ci/CodeIgniter] About CI3 maintenance (#6012)
Its insanely ridiculous and arrogant on how the CI foundation decided to dump v3 and move to v4.
I think the fact that people consider version 4 a "kill" instead of an upgrade is pretty telling of the gap that version 3 created by its focus on backwards-compatibility. I've written about this on the forumshttps://forum.codeigniter.com/thread-78339-post-383335.html#pid383335 but basically: backwards-compatibility is easier on developers because it makes a quicker upgrade path but I accumulates "development debt" that a future version will always need to pay for. Version 4 is paying that coin.
An example. PHP 5.3 (2009 I think?) introduced namespaces and PSR-0 established standards for namespaces and autoloading. In 2014 FIG deprecated these standards for a second set (PSR-4) which still holds today (7 years old mind you). CodeIgniter 3 was released in 2015 without native spl class loading and chose to maintain "Autoloading" as "components for the framework to initialize during bootstrap". Still to this day we get people switching to version 4 confused about autoloading, a PHP feature of 12 years and standard for 7.
Version 3 was awesome, and I still have and maintain many CI3 projects most of which are unlikely to get rewritten. But trying to keep CI3 in active development is creating legacy developers, people unfamiliar with the last ten years of improvements in PHP, web development, and coding in general.
My advice: take the time to learn CI4 (or another modern framework). Figure it out, learn what has changed in PHP, learn to collaborate on open-source libraries and work with developers outside of CI3 context. Then if you still love CI3, come back and make it better.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/bcit-ci/CodeIgniter/issues/6012#issuecomment-773309399, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ADDFJ4I3HIEWR6AHHQXC7N3S5KPSZANCNFSM4VULBQIQ.

Oh I understand the reasoning behind it.
I don’t know what the foundations plan is with 3 and I don’t have hours to trawl though forum posts but the last time I looked it was remarkably quiet on the topic other than concerned posts. I have been using CI for a couple of Years now and used 3 as that’s what was “active”. In fact if you go to the CI Homepage and click downloads at the top it still says 3 is the current branch with 4 “upcoming” 🤷♂
I fully intend to port projects and start new ones on CI4 but that takes time and meanwhile I have servers that will get upgraded to PHP8 in the next 12 months and I need to make sure projects still on CI3 will continue to run even if it means I have to patch in code to fix issues myself.
I fully understand that this is a free project and it takes time to maintain older stuff but PHP8 is unlikely to require major changes but even after months or discussion and pulls on basic stuff like the session issue were still at 3.1.11. I think many people are perplexed that support was seemingly dropped overnight last March.
Even if the foundation have no plans to support 3 themselves at least let the community maintain it and state on the downloads page that it’s a defunct branch and publicly maintained.

So let's make CI3 compatible with PHP8.
I can see that the #6013 PR is addressing the flashdata issue. Now we need it only to be merged.
As for other opinions here, there goes mine...

I suppose it depends on if CI intend on supporting v3 (and PHP8) going forward to address them. Sadly CI4 isnt a option for me (yet) as the amount of work to essentially rewrite them is too large at present.

We're also in the same boat, some of our CI3 projects are working well and do everything that's required, so a complete re-write in CI4 isn't justified at the moment.

In my opinion, CI3 should be a long-living PHP framework, which by grandfathering many things that made this framework famous, won't follow today's trends (usually called "standards", "PSRs", and so on). If anyone requires those, then you should go with CI4. By the way, having CI3 doesn't force your code to be written in a certain way. You can use whatever you want for your app code.
In fact, if you look at every PHP framework from the present day, it makes this ecosystem to be full of just copy-cat software. Has anyone from here used a JavaScript framework? Like AngularJS, Vue JS or React? They are fundamentally different and thus, they increase the real pool of decisions you can take on deciding the one you should use.
I hardly believe that there's a PHP framework out there that does the things so different, as CI3 does. So how about thinking about diversity when thinking on CI3?

An example. PHP 5.3 (2009 I think?) introduced namespaces and PSR-0 established standards for namespaces and autoloading. In 2014 FIG deprecated these standards for a second set (PSR-4) which still holds today (7 years old mind you). CodeIgniter 3 was released in 2015 without native spl class loading and chose to maintain "Autoloading" as "components for the framework to initialize during bootstrap". Still to this day we get people switching to version 4 confused about autoloading, a PHP feature of 12 years and standard for 7.

CI3 doesn't care about PSR definition about how you should namespace the classes and how autoloading is done. Others do, such as CI4. In fact, CI3 has the "Composer autoload" feature, which enables bringing composer libraries right into CI3 instance, if you need them.

Version 3 was awesome, and I still have and maintain many CI3 projects most of which are unlikely to get rewritten. But trying to keep CI3 in active development is creating legacy developers, people unfamiliar with the last ten years of improvements in PHP, web development, and coding in general.

That has nothing to do with people's own development skills. Ah, and the "legacy" non-argument argument used for someone who doesn't blindly follow the magic unicorns out there.
CI3 is compatible up to the latest PHP 7 version. And that make it very up-to-date for the PHP language itself.

My advice: take the time to learn CI4 (or another modern framework). Figure it out, learn what has changed in PHP, learn to collaborate on open-source libraries and work with developers outside of CI3 context. Then if you still love CI3, come back and make it better.

If that fits your needs, by all means, do it (CI4 / any other "modern" framework). That's why are out there CI3 and CI4. Because they are different. Otherwise, CI3 would have been changed until there would be no actual difference between it and CI4.

An example. PHP 5.3 (2009 I think?) introduced namespaces and PSR-0 established standards for namespaces and autoloading. In 2014 FIG deprecated these standards for a second set (PSR-4) which still holds today (7 years old mind you).

Who is FIG to dictate to me on how I run by business. Is FIG going to fund all of the extensive re-write and all of the testing involved to port my apps over to CI 4? I care about rolling out new features to give the benefit to users immediately over the shortest time possible. My userbase does not care about namespaces.

the "legacy" non-argument argument used for someone who doesn't blindly follow the magic unicorns out there

@gxgpet Just to be clear, I have no issues with people running legacy code (like I said, I have plenty of projects myself) nor does "legacy" mean "bad". I am no trying to demean developers, I still work with many who write vanilla PHP and have never touched a framework. But PHP is a language, and it evolves and changes, and versions are dropped from support and projects (and developers) who stick to unsupported versions become legacy. Sometimes it's possible to patch these, but generally speaking production code is better either a) kept on the latest versions or b) not tampered with.

Who is FIG to dictate to me on how I run by business

Definitely not the intention of FIG, you do you! What FIG provides is a collaborative context for PHP developers to agree on "meta-language standards". Does that mean it is the only way to do things? No. But being able to say "PSR-7 compliant" up front saves a whole lot of time for a developer to use a project and collaborate on things. CI3 (or CI4 for that matter) need never adopt any of FIG's standards but it will come at a collaboration cost with the larger PHP community.

This is not really the point of this topic, but as someone from the background of writing straight php code for a long time looking for a framework that is both easy to understand and use, all while delivering a way to reduce workload and make it easier to write code that is sane and stable CI3 appealed the most. Other options such as Laravel, cake and what have you, similarly to CI4 in fact, just seem to make changes for the sake of change or are built for specific types of "web apps". The big appeal with CI3 is that it is relatively easy to use for php beginners and offers a way to elevate the understanding of functions and code that is flexible.
I consciously made the decision not to even bother with CI4 after looking at the docs and not even being able to gather what really changed and how I could even approach to re-create my "apps"(god it's a website not an app ffs) in CI4.
CI3 on the other hand actually still brings me joy in writing code that I can re-use in a manner that feels somewhat at home with the concept of other languages such as c++ even(cpp and header files, controllers and models). At first I struggled with this concept and wrote code in view, not understanding why the complexity of three different files. However, as things got bigger being able to re-use models, alter data in controllers and output new views is really quite useful and a big strong point of CI3 I think.
To me it seems CI4 exists to please those looking for even faster, thrown together "web apps" rather than building stronger and more reliable websites and systems that can still be made very flexible. I had hoped it was more of the same, but to be so vastly different and far more "complex" is not making it easy to like. Maybe I am just lazy or not smart enough for CI4.
Back on topic. Last I checked there had been maintainers selected to handle CI3 from now on or has this changed recently?
The other question for a pull request, so long as it does not go into a specific release is whether PHP8 changes are breaking toward PHP7, which pretty much determines whether a new, specific, release is needed or changes can be made and released as update.
As some have said there is no one really using all parts of CI3 and would thus be the first to notice compatibility changes. Is that not something that can be crowd-sourced though? Tests. Each user following this project or even this issue ticket might use a different part, but in this has a pretty good idea of what they use and how to notice if it does not work. Extrapolating test cases from this should not be all too difficult and then it just becomes a matter of conducting those tests. Equally either a past or current maintainer likely has a relatively good overview of the parts CI3 is comprised of and thus could provide input into a checklist of things to probe for issues.
So perhaps the first order of business should be to create a list of all parts of CI3.
Then establish expected behaviors of these parts based on examples or code similarly to what users run.
Lastly, change PHP and see whether results have changed and adjust accordingly, either just for PHP8 or all supported PHP versions.

Maybe I am just lazy or not smart enough for CI4

I would suggest that probably the biggest thing you are noticing is "familiarity". CI4 has kept the same principles that have always guided CodeIgniter and set it apart from the Symfonies and Laravels of the world: straightforward, use-only-what-you-need, comprehensive docs, lightweight, no "magic". CI4 does look very different, because PHP looks very different, but if you spent some time on it for your apps ("websites" 🥳) you might find it less jarringly foreign.

Re: PHP 8... some just needs to download the framework and slap PHPStan on it and run a static code analysis. That should catch 99.9% of PHP 8 compatibility issues.

After all, it seems that no experienced developer is qualified to be an additional maintainer.
So nobody can help @narfbg to develop CI3. He is an only maintainer of CI3 now.
Is this correct?

Re: PHP 8... some just needs to download the framework and slap PHPStan on it and run a static code analysis under PHP 8. That should catch 99.9% of compatibility issues.

That sounds interesting, do you have some links or more info on that?

Sure! You can think of static analysis like a robot that reads your code and catches problems. This can be simple things like syntax errors (echo strtolower('HI';) or more complex logic errors that still "work" ($test = true; if ($test && true)...). You can read more about it and play with it here: https://phpstan.org
I did a quick run-through:
git clone https://github.com/bcit-ci/CodeIgniter.git
cd CodeIgniter
composer require phpstan/phpstan
./vendor/bin/phpstan analyze application/ system/ tests/ index.php

There are a lot of issues on PHP 7.4 and 8.0 and while there are a lot of issues the list is identical, suggesting that the framework itself is as safe in PHP 8 as 7.4 (as far as static analysis goes). It looks like some of the dependencies might have issues though, like vfsStream - but I think that's known?

Conversations here really makes it clear people still love CI3. I remember I also joined in on the forum as one interested in maintaining CI3 but it did not happen, so I have decided to extend CI3 myself and use it for my personal projects and I have made the source available on GitHub.
What I did first was to pull the "system" folder and make it a composer repository "sylynder/codeigniter". I would want to know if that is bad to do. If not I decided I will visit the issues and pull request to use it to upgrade on the said repository.
I then worked on the extension and named it "Webby" which I'm still working on. I have planned to make it have a similar tradition as CI3, where only the "system" folder used to be upgraded. It is still a work in progress.
The whole idea is to help beginners and also developers who love CI3 to move to CI4 slowly because I have made it possible to use namespaces and a little mimicking the 'service()' helper function in CI4 by powering "ci()" function which uses the codeigniter instance from an external class that acts as the old known "get_instance()" function to do something similar. Still learning and upgrading my understanding on some concepts.
And I can say CI3 is very easy to extend without touching the core classes. Most extensions can be done in "core" folder and the "library" folder when you prefix it with "MY_" or "Whatever_".  This is making what I'm working on possible.
Suggestions, coaching and advice are welcomed. If anybody is interested check it out here:
https://github.com/sylynder/webby

OK people, I could say a lot about a lot of what's been written here, but I'll stick to the most important part ...
First, the foundation hasn't decided anything about CI3 - it never needed to, never had to, and to my knowledge was never intended to deal with CI3 at all. I've been at the helm since forever and this is all on me.
And secondly, we (everybody who's ever been involved) have actually always been looking for more people to have on the team, but it's no surprise that you can't just pick a random person from a crowd. I believe we've found someone suitable right now in @gxgpet and he's welcome to the team.
@lonnieezell As I'm not sure what adding someone to the teams we already have setup would mean in terms of access to other repos, can you sort out the proper permissions for him?

@narfbg Awesome that you found someone! I've invited @gxgpet to the Reactor Team which gives him access to only the CodeIgniter repo, but that can always be adjusted down the road if needed.

Thanks @narfbg I'm sure I won't be the only one that will say they appreciate the work of yourself (and the other devs) in maintaining CI3 :) it's good to know the project is being maintained while everyone ports projects.

thanks for maintaining the project <3

Thanks for keeping CI3 alive. It means a lot to me and my projects 👍

@narfbg Awesome that you found someone! I've invited @gxgpet to the Reactor Team which gives him access to only the CodeIgniter repo, but that can always be adjusted down the road if needed.

@gxgpet can also merge PRs in the translations repository?
https://github.com/bcit-ci/codeigniter3-translations

@narfbg Thanks for your excellent work on CI 3. I've been testing CI 3 on PHP 8 and it works great! You've done all of this behind the scenes so thank you for that.


Lot of warning in Firefox about : "resource at *** preloaded with link preload was not used within a few seconds"

Describe the bug
Hello, we are building a single page application in vue.js with vite.
According to the doc :
Vite automatically generates <link rel="modulepreload"> directives for entry chunks and their direct imports in the built HTML.
However Firefox is not supporting modulepreload so it's look like vite is generating automatically the following on Firefox :
<link rel="preload" as="script" crossorigin="" href="/assets/Component.469e8f3b.js">
which create the following warning :
The resource at “***/assets/Component.469e8f3b.js” preloaded with link preload was not used within a few seconds. Make sure all attributes of the preload tag are set correctly.
We don't have any warning in chrome who is injecting the following in the html :
<link rel="modulepreload" as="script" crossorigin="" href="/assets/Component.469e8f3b.js">
but in Firefow we have a lot of them and it's quiet annoying. Do you have a solution for us ?
Reproduction
I guess that you will have this warning for all singlePage App with vuejs. If really needed I can share by personnal message the url of our app.
System Info
  System:
    OS: Windows 10 10.0.19042
    CPU: (8) x64 Intel(R) Core(TM) i7-3630QM CPU @ 2.40GHz
    Memory: 1.40 GB / 5.89 GB
  Binaries:
    Node: 16.0.0 - C:\Program Files\nodejs\node.EXE
    Yarn: 1.22.10 - ~\AppData\Roaming\npm\yarn.CMD
    npm: 7.14.0 - ~\Desktop\Genario\genario-frontend\node_modules\.bin\npm.CMD
  Browsers:
    Chrome: 91.0.4472.77
    Edge: Spartan (44.19041.964.0), Chromium (90.0.818.66)
    Internet Explorer: 11.0.19041.1
  npmPackages:
    @vitejs/plugin-vue: ^1.2.1 => 1.2.2
    vite: ^2.1.5 => 2.3.4

You can test on or staging url : https://genario-frontend-staging.herokuapp.com/ . On the home page you will have the warning for our HomeIndex component.

I shared to you an internal url that I should not :s This is not our priority at the moment so we will come back to you later.
Have a good day,
Ben

I am also seeing this error, I will try and reproduce.

@JohnPangalos Were you able to reproduce it in a small github repo by any chance ? Do you have any news about this warning ?

No I have not been able to reproduce, and am not sure what the issue is. We are doing a monorepo where we import packages that we build and I haven’t had time to setup an example like that. I’ve done simpler implementations with no luck as of yet.

Okay, I have a repo that reproduces the bug. https://github.com/JohnPangalos/vite-preload-firefox-error
In order to get this to occur run the following:
npm i
cd application
npm run build
npm run server

Then open the http://localhost:5000 in Firefox. Look in the console and wait, the warning should show up after a minute.

@JohnPangalos would you open a new issue against the latest version using that reproduction so we can better track this? Thanks!

Okay I was wrong in that the problem had anything to do with a monorepo, for us it seems to be lazy loading.
npm i
npm run build
npm run server

Then open the http://localhost:5000 in Firefox. Look in the console and wait, the warning should show up after a minute.

@patak-js yeah sure!

Here is the new issue #4051


feat: new track management

The beta version which is 1.4.0 does have the new way of track management with effects integrated as well

@arun3528 You should be able to integrate the new public web-media-effects library into this PR. You just need to pass an authToken into the constructor of each effect and you won't need to use the .npmrc anymore or whatever you're doing for an NPM token.

@bbaldino  have fixed the review comments
the publish is just a enum and does not get used in the track file , we export it with other events

We'll incorporate the concepts in separate PRs at a later time.


Filter Bar Orientation Resets to Vertical After Reopening Dashboard

Hello everyone, I have a question. In several dashboards, I have configured the filter bar to appear horizontally (on top) instead of vertically. However, when I close the dashboard and reopen it, this configuration doesn't stay, and it goes back to appearing vertically. Any ideas on how to fix this?

Huh, I have never experienced this.  Does this happen to all of your dashboards with horizontal filter bars?  Any more detail you can provide to reproduce the problem?  What version of Superset are you using?

@sfirke Hello!! Honestly, I don't quite understand the logic behind the issue because, without making any updates, I've been running some tests, and it hasn't changed on its own again; it's staying as it is. If it happens again, I'll let you know why.

Thanks for following up! I'm glad to hear the problem seems to have resolved itself. Given that we can't reproduce it, I'll close this issue, but feel free to comment again if you learn anything else or if it recurs.

Hi @sfirke!!
I just discovered the issue with the orientation. I took some screenshots, although a video might be more ideal in this case, but I hope I can explain it clearly. I noticed the error when I created a new dashboard. As you can see in the images, there's an empty dashboard, I add a couple of sample visualizations and set the filter orientation, as well as adding a sample filter. When I reload the dashboard page for the first time after setting this, instead of it appearing as I left it, the dashboard appears as if I had clicked "Edit", and when I cancel, for example, that’s when the filters switch to vertical format. I hope I’ve explained it well, and if this helps in any way, then great.

![image](https://github.com/user-a

ttachments/assets/524f6e70-2ee8-4a30-b76a-e3abb86bcee6)
another example

Thanks for providing additional documentation!  What version of Superset are you running?
The testing environment for the next release of Superset is here: http://<IP_ADDRESS>:8080/ (user: admin, password: admin, remember to clear any data that you add)  If that test environment is still up, you could try to replicate the bug there to see if persists in the latest version.

I'm using version 4.0.0.
I've tried to replicate it in the test environment, but the functionality to change the orientation of the filters is not active.
I will try updating Superset, and if this issue persists, I will let you know.
Thank you so much, Sam! @sfirke


no proper shopping cart behavior

I had several strains open in tabs and clicked to add into cart, and then called up another strain and added that. And each time, it created one strain in so many different carts. And I'm even logged in!
Our current cart knows by browser to keep things in cart even when you stop in-between. This is not present in new database. it treats every addition to cart as single order.

it only works when you click 'continue shopping on current cart, but this is not what people will always do

I'm using Safari typically, but also tested this in Firefox, same behavior. You cannot add strains from different strain detail pages that are open to the same cart. This works without problems in the current / old database.
And this is what people do. They first inspect the details and any phenotypes before they order, at least often.


Bug/uar 1296 improve trust load failure handling

JIRA link
https://companieshouse.atlassian.net/browse/UAR-1296
Change description
Add missing try / catch to post handler for change journey
Add two missing awaits
Work checklist

[ ] Tests added where applicable
[ ] UI changes meet accessibility criteria

Merge instructions
We are committed to keeping commit history clean, consistent and linear.  A BREAKING CHANGE can be part of commits of any type,
types other than fix: and feat: are allowed, for example build:, chore:, ci:, docs:, style:, refactor:, perf:, test:, and others,
footers other than BREAKING CHANGE: <description> may be provided.

Being held for now.


[py] bump version 1.1.1 -> 1.1.2 -> 1.1.3

[py] bump version 1.1.1 -> 1.1.2 -> 1.1.3
What
bump pytoml version to encompass Bug Fix in diff below. Package was republished under 1.1.2
Edit:
bumped to 1.1.3 to incorporate PR#318

this is a week old but is in line with current pypi release


To Do List Structure

What?
I created the structure for a to-do list that helps people manage their activities.
Why?
This is to help them manage their activities and also help them plan their days easily.
How?

I installed webpack and made all the necessary configurations to ensure a good front-end environment.
Created the structure of the page in my index.html file which can be found in the source folder.
I then imported styles.css to index.js and then used it to style the HTML file.
I dynamically created the ul where the task will be added.
I created an array in the index.js file and looped through each object in the array to populate the ul with a li
I made sure to use modules in my structure so I imported and exported variables and functions between index.js, Variables.js and Functions.js

@zainsadaqat Thank you for the review. My linters are working perfectly on my editor. Do you think there is something I should do? Please?

@zieeco Thank you for reviewing my project.


browserpass icon not showing in chromium

General information

Operating system + version: Ubuntu 16.04
Browser + version: ungoogled-chromium 65.0
Information about the host app:

How did you install it? ./install.sh

Installed via a package manager, downloaded a pre-built binary, compiled yourself? pre-built binary

If installed an official release, put a version: v2.0.22

In the recent versions it can be obtained with $ browserpass -v Browserpass host app version: 2.0.22
If in doubt what version you have, download and re-install the latest version!

If built from sources, put a commit id ($ git describe --always):

Information about the browser extension:

How did you install it? Downloaded seperately from the releases page (same version as the binary) prior to installing the host app, drag and drop into extensions page

Installed via webstore, downloaded a pre-built extension, compiled yourself? pre-built

Browserpass extension version as reported by your browser: 2.0.22

Exact steps to reproduce the problem

Icon doesn't show, even after restarting chromium and rebooting

What should happen?
The icon was visible before installing the host app

Hey, check if the extension is present and enabled on chrome://extensions, sounds like it was disabled maybe? Also, I have some icons hidden in the "three-dots" menu in Chromium, maybe browserpass is there for you:

I checked the three-dots-hidden-extension-menu, it's not there either.
Also it seems that the extension can't be manually enabled.

@mstarodub What happens when you attempt to check the 'enable' checkbox?

@erayd It does nothing / isn't clickable.

If there's any additional informaion required, please tell me the names of the relevant command outputs
/ logfiles, so that I can post them.

@mstarodub Are you able to remove the manually-installed extension, and install it from the chrome store instead? Does that work?

Also try to remove the policy file, its location depends on what you chose in ./install.sh, but this is the file - see where it got added and remove it.
https://github.com/browserpass/browserpass/blob/33d9be90d664362613f606914f603f8a9a0dcf3b/install.sh#L133
Policy is there to automatically install the extension for you from Chrome Webstore, if you don't want auto-updates and want to install extension manually, you don't need policy anyway.

@erayd I can't seem to remove it through normal means.
@maximbaz removed it, but so far nothing changed on the "extensions" page.

removed the entire folder, but weirdly, it's still there and I can't disable or remove it.

Double check that you found all locations where chrome-policy.json was installed, the message "extension is managed and cannot be removed" can only mean that the policy is active.


Thanks!

No issues, just wanted to say thank you for making this public. It's really helpful to be able to look at a solution from a more idiomatic point of view than I am able to muster. Cheers!

No problem! I don't know if I'll be able to keep up or do all the puzzles, but I'm giving it a shot!


feat: cnc rich text editor upload image

Pull request type

New feature (non-breaking change which adds functionality)

Description
Enable upload in the rich-text-editor image dialog.
The PR for Mendix Docs changes is here
The developer must provide an upload endpoint to receive the image file and then return the file URL in the same endpoint. We also have created a Mendix module to make it easier.

What should be covered while testing?
If the upload-image is disabled in the setting, then the end user should not see the upload tab in the insert image dialog.
If the upload-image is enabled and configured, the end user should be able to upload an image from their local computer to the Mendix server.

I added a commit.
If the upload image is enabled then for drag&drop also the image will be uploaded to the server.

Since the underlying lib has changed the changes are not valid anymore

Closing as PR not got review for a long time and new major version of the widget was released.


Fixed a typo in the description of a column

This is a minor fix to the .inspect aws_organizations_account command; the text currently refers to a permission set, but should refer to an AWS account. This PR corrects the text in the description.
Current output:
> .inspect aws_organizations_account
+------------------+--------------------------+----------------------------------------------------------------------------------+
| column           | type                     | description                                                                      |
+------------------+--------------------------+----------------------------------------------------------------------------------+
| _ctx             | jsonb                    | Steampipe context in JSON form, e.g. connection_name.                            |
| account_id       | text                     | The AWS Account ID in which the resource is located.                             |
| akas             | jsonb                    | Array of globally unique identifier strings (also known as) for the resource.    |
| arn              | text                     | The Amazon Resource Name (ARN) of the account.                                   |
| email            | text                     | The email address associated with the AWS account.                               |
| id               | text                     | The unique identifier (account ID) of the member account.                        |
| joined_method    | text                     | The method by which the account joined the organization.                         |
| joined_timestamp | timestamp with time zone | The date the account became a part of the organization.                          |
| name             | text                     | The description of the permission set.                                           |
| partition        | text                     | The AWS partition in which the resource is located (aws, aws-cn, or aws-us-gov). |
| region           | text                     | The AWS Region in which the resource is located.                                 |
| status           | text                     | The status of the account in the organization.                                   |
| tags             | jsonb                    | A map of tags for the resource.                                                  |
| tags_src         | jsonb                    |                                                                                |
| title            | text                     | Title of the resource.                                                           |
+------------------+--------------------------+----------------------------------------------------------------------------------+

Correct output should be
| name             | text                     |  The name of the member account.                                         |

Integration test logs

Logs
Add passing integration test logs here

Example query results

Results
Add example SQL query results here (please include the input queries as well)

@cbruno10 yup, accepted the proposed change. I think this is the friendly name, but there's at least a couple of ways to name an AWS account. 😖 But your proposal more aligns with the documentation most likely associated with this result... I think.

Thanks @badideasforsale for the fix!


Sample app needs the performance tab

We should think on how to automate the Chrome created performance data and feed it into the page that shows the that information per each control

We may create a timer to help us on the performance work of the grid, but I don't see the value of this elsewhere

Regardless of the method we use, I think that is a good idea to have some performance comparisons between our bridge and Telerik's original implementation. Since we are adding some code on top of Telerik's internal use of jQuery, I expect that we ought to be slower, so the value of our solution is to enable Aurelia users to use KendoUI

lets track this in one issue: https://github.com/aurelia-ui-toolkits/aurelia-kendoui-bridge/issues/158


Tweak IAM perms on sierra_to_dynamo so it only has Put access to DynamoDB

It may well end up reading for an audit trail on items bibs; let's not do this after all!


Which repo i have to use

Very Confused on which one i have to use to develop my app
Wallpaperboard Master or
Wallpaperboard sample ?
If Wallpaperboard master have to be used i cant able to run that.
Need Help
thank you

Sample, read the wiki site before asking https://github.com/danimahardhika/wallpaperboard/wiki

If you want to add admob, you need to modify the library by yourself and don't ask me how.


Background image

Background image

Not using this Pull Request as code was modified >> refer new request to follow


414 (Request-URI Too Large)

Nginx status of 414 (Request-URI Too Large)

Ubuntu 16.04
PHP 7.0
Laravel 5.2
Laravel-Datatables ~6.0

Yes, this is possible to happen due to the design of the plugin. A quick google search appears that this can be fixed by configuring the server as suggested on SO. Another way is to use post method on your ajax request.


Update for Meteor 2.3

Makes this package compatible with Meteor 2.3.x.
NOTE:
I wasn't able to run tests locally since the following dependency can't be resolved:
"spacejam": "https://github.com/serut/spacejam/tarball/windows-suppport-rc4"
Tried using version from NPM  but it's failing with the following error:
Fontconfig error: "/etc/fonts/local.conf", line 1: XML declaration not well-formed
phantomjs: Running tests at http://localhost:4096/local using test-in-console
phantomjs: TypeError: undefined is not an object (evaluating 'Package.modules.meteorInstall')

let's see what CI says.

Tried using a version of space jam from NPM which requires Node v10 to properly run, but tests are failing anyway. Could you help me with that?


Limit fields for adds/updates

I can't figure out how to get the append_fields parameter to not throw Error 500 (unknown error)s. So for now, new dataframe fields must match existing fields. Later I can figure out how to get append_fields working properly (may need to chat w/Esri).

Where does append_fields get used?

It's listed in the FeatureLayer.append() arguments.
After a little more (inadvertent) testing, it looks like it doesn't throw the error if append_fields includes all the fields in the live layer (which negates the point of subsetting with append_fields...)

can this operation be done in the pro gui and exported to python to see what it's expected?

I don't think so- this is ArcGIS API for Python, not arcpy. The "try the different/native form" check would be an HTTP post request using https://developers.arcgis.com/rest/services-reference/enterprise/append-feature-service-layer-.htm

so something like this example?
POST /webadaptor/rest/services/MyService/FeatureServer/0/append HTTP/1.1
Host: machine.domain.com
Content-Type: application/x-www-form-urlencoded
Content-Length: []

sourceTableName=MyShapes&fieldMappings=[{"source":"myShapeDate","name":"datefield"},{"source":"myData","name":"mydata"},{"source":"myData2","name":"mydata2"},{"source":"FID","name":"objectid"}]&upsert=true&skipInserts=false&updateGeometry=true&appendFields=["datefield","mydata","mydata2","objectid"]&appendUploadId=62b7e088a2ff4b3da1a240d72f9994e3&appendUploadFormat=shapefile&rollbackOnFailure=true&f=json


bug: <useContractsRead caused vscode CPU 100%>

Is there an existing issue for this?

[X] I have searched the existing issues

Package Version
0.7.5
Current Behavior
When vscode tsserver scan the node_modules/wagmi/dist/declarations/src/hooks/contracts/useContractReads.d.ts file, it will cause the CPU to 100% by vscode.
Expected Behavior
No response
Steps To Reproduce
open vscode, open node_modules/wagmi/dist/declarations/src/hooks/contracts/useContractReads.d.ts file. You can see the CPU status.
Link to Minimal Reproducible Example (CodeSandbox, StackBlitz, etc.)
No response
Anything else?
No response

Find new version fix this issue, ignore me.

lol my nvim and vscode both died from just looking up the type definition 😅


Version for node?

I'm trying to add CustomEvent so that a library I've built will work in both browser and Node.  Your code looks like its what is needed EXCEPT it calls document.createEventObject, and in node there is document.createEvent, but not document.createEventObject.
Do you know of a version of custom-event that works in Node? Or is there a way to add that functionality.

A bit of digging and I've found a solution for myself which is to define "document" before requiring custom-event, however this breaks the common practice of requiring everything at the top of the file BEFORE creating anything.
I could also get it to work by replacing the line
('undefined' !== typeof document && 'function' === typeof document.createEvent) ? function CustomEvent (type, params) {

with
('undefined' === typeof document || 'function' === typeof document.createEvent) ? function CustomEvent (type, params) {

Since the IE9 version is fine for node, and document will have been defined before CustomEvent gets called.
That might be a good alternative ?


Lots of warnings in developer console for each file edited.

Using:
Version:          Code - Insiders 1.38.0-insider (c23cacdc97b54e6056400599dad329cabc7facfb, 2019-08-16T06:33:21.339Z)
OS Version:       Darwin x64 18.7.0
CPUs:             Intel(R) Core(TM) i7-7820HQ CPU @ 2.90GHz (8 x 2900)

This is in an Angular application. For each file that is opened, there is a warning message displayed in the console:

Looks like duplicate of #21


SAP Host Agent Version Differences

The page says to:
"Make sure to use SAP Host Agent 7.21 PL 47 or higher."
However the SAP notes say this is the minimum versions:
"For Azure monitoring, at least SAP Host Agent 7.21 Patch Level 14 must be used"
Does the note need to be updated to reflect the latest version requirements?

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

ID: 3ea8dbf7-4305-1342-c073-8c7b20564fd3
Version Independent ID: a3692496-1cf4-854c-94da-419058bd3e60
Content: Azure Virtual Machines deployment for SAP NetWeaver - Azure Virtual Machines
Content Source: articles/virtual-machines/workloads/sap/deployment-guide.md
Service: virtual-machines-linux
GitHub Login: @MSSedusch
Microsoft Alias: sedusch

Thanks for the feedback! I have assigned the issue to the content author to investigate further and update the document as appropriate.

@jahobson75 SAP Host Agent 7.21 PL47 is only required if you use the new version of the extension. The default/old extension works with PL14. We will update the SAP Note to reflect that as well. Thanks for your feedback.

SAP Not 1409604 and 2191498 were updated to match our guides. 1102124 will also be updated soon.

#please-close


Pod not updating to 2.0.9

Hey @xiongxiong ! Here again.
Was PodScpec updated? Keeps showing 2.0.8 and can't update
Thanks

@perroyverde Sorry, I forgot to do it, sometimes my network is poor, and it's updated now.

Cool!


[r2.1:Cherrypick][Intel MKL] Klocwork fix

Closing this PR as this not against master, please open a new PR against master

@rthadur There is already one against master branch #35390, but I created this because eventually we need to cherry-pick it to r2.1.

No worries this will be cherry picked , we only accept security fixes.

Reopening as the 2.1 final release is not done yet, so we can get cherry-picks until then.

Actually closing for now, let's wait for #35390 to land on master. Then make a PR against r2.1 with git cherry-pick ${hash_of_commit_on_master}. This way we ensure that both branches are in sync w.r.t. this patch.

Thank you @mihaimaruseac


BuiltIn: Enhance error reporting of comparison keywords especially when ignore_case=True

Case-insensitivity support added in RF 3.0.1 (#2439) works fine otherwise, but error reporting isn't always consistent. Sometimes error messages show the compared values turned to lower case, and in others they show the original values. It would probably be best to to always show the original values but add a note like (case-insensitive) to the message automatically.
There are also other inconsistencies in error reporting (e.g. do messages end with . or not) that can be fixed when refactoring error reporting in general. Having a better way to report errors involving large strings or containers with many items would be great too, but that is probably so big task that it would deserve a separate issue.

I don't have time to implement this before RF 3.1. If someone else is interested, I can help. Shouldn't be too complicated even for new contributors, but decided not to add the good first issue label because there can be quite a bit of work to go through all related keywords.