Allow string in 'root_sass' configuration

Allow both string and array to configure root_sass. (follows discussion here
symfony_cast:
    root_sass: '%kernel.project_dir%/assets/scss/app.scss'

symfony_cast:
    root_sass:
        - '%kernel.project_dir%/assets/scss/app.scss'

Magic done in the dependency extension, so it does not impact any domain code

Update: still think the documentation / recipes should contains the array version, as it's easier to understand that multiple values are allowed, and how to add them :)

Of course, even better :)
Just anticipated issues/requests "how can i use multiple pathes" elsewhen :)

Easy win, thanks!

still think the documentation / recipes should contains the array version, as it's easier to understand that multiple values are allowed, and how to add them

Why not use both? :) I think we can show "string" example first (as it will fit most users), but below mention you can specify more values with an array. Wdyt?

@smnandre, I update my PR #52 to update the docs with the array version :)

Thank you!

I just discover this could be written in a cleaner / shorter way:
->beforeNormalization()->castToArray()->end()

CF: https://symfony.com/doc/current/components/config/definition.html#array-nodes
Should i update the code ?

I just discover this could be written in a cleaner / shorter way:
->beforeNormalization()->castToArray()->end()

CF: https://symfony.com/doc/current/components/config/definition.html#array-nodes
Should i update the code ?

@smnandre I can do it you don't mind?

Of course you can :)

I just discover this could be written in a cleaner / shorter way:
->beforeNormalization()->castToArray()->end()

CF: https://symfony.com/doc/current/components/config/definition.html#array-nodes
Should i update the code ?

the PR is here: #55
cc: @smnandre @bocharsky-bw


Nickname for Joe Biden

In the executives data could a nickname of "Joe" be added for current president Joe Biden?

I'd be OK with that. Will wait for feedback from others.

It looks this was added at some point.
https://github.com/unitedstates/congress-legislators/blob/main/executive.yaml#L1508
I'm guessing this could probably be closed?


killing waybar leaves orphans processes that started by the custom blocks

killing waybar leaves orphans processes that started by custom blocks scripts. This happens with scripts types that are running not based on intervals, but looping by itself producing outputs. orphans processes move under init process when their parent (waybar) dies. It seems the termination signal is not passed to the children processes under waybar.
Thanks

Similar to #369


Outdated note?

Isn't this note outdated?
"You must close the NetworkStream when you are through sending and receiving data. Closing TcpClient does not release the NetworkStream."

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

ID: fe7d0846-14ff-cce4-2ce5-4df4ba9b5ee5
Version Independent ID: c1cc7165-fee6-6af3-087b-36a337774399
Content: TcpClient.GetStream Method (System.Net.Sockets)
Content Source: xml/System.Net.Sockets/TcpClient.xml
Service: unspecified
GitHub Login: @dotnet-bot
Microsoft Alias: dotnetcontent

Could you clarify? What makes you think the note is outdated?

It looks like TCPClient.Close method disposes the NetworkStream :
https://referencesource.microsoft.com/#System/net/System/Net/Sockets/TCPClient.cs,d7b14dbe8a2a1aca
Also TcpClient.Close document states that "Calling this method will eventually result in the close of the associated Socket and will also close the associated NetworkStream that is used to send and receive data if one was created."


Pdfjs

Codecov Report

Merging #2997 (fba762b) into development (3f4027c) will not change coverage.
The diff coverage is n/a.

@@             Coverage Diff              @@
##           development    #2997   +/-   ##
============================================
  Coverage        86.75%   86.75%
============================================
  Files             1892     1892
  Lines            67228    67228
============================================
  Hits             58325    58325
  Misses            8903     8903

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 3f4027c...fba762b. Read the comment docs.


import setupLayouts with 'virtual:' prefix

#9 mentions that vite-plugin-pages now uses import routes from 'virtual:generated-pages'
Is this something we would want to have ourselves?
I don't know enough about rollup to understand if there is a benefit or if this is simply a convention. In the latter case, I think it looks nicer if we followed their example.
import { seputLayouts } from 'virtual:genreated-layouts'
import routes from 'virtual:generated-pages';

Agreed :)   I apologize to all for the delays; life and work have been keeping me from coding; trying to find my way back.

I do like the clearly labeled use of virtual, so yes, lets do this.  It will be a breaking change.

Hi, we now get this:
Cannot find module 'virtual:generated-layouts' or its corresponding type declarations.ts(2307)
I have updated : "types": ["vite/client","vite-plugin-vue-layouts/client"],


Introduce the barrier API

This PR is the continuity of @carlocaione work: https://github.com/zephyrproject-rtos/zephyr/pull/41977
Then all comments have been taken into account before push this version.
For now, SMP is no longer include in the barrier API
It is basically introducing support for the barrier operations (mb, wmb, rmb). This is done introducing a generic fallback implementation in include/barrier.h to be specialized (if needed) by each arch. The name is taken from Linux but the implementation is slimmer.
In this PR I specialize the operations for ARM, ARM64 and RISC-V because I'm only familiar with these architectures.

I fail to see the point of ARCH_HAS_MEMORY_BARRIER.
What does it bring?

I fail to see the point of ARCH_HAS_MEMORY_BARRIER. What does it bring?

@npitre
As @andyross comment suggest: https://github.com/zephyrproject-rtos/zephyr/pull/41977#discussion_r788060538
Briefly, it's safer to use a kconfig flag to chose between 2 implementations instead of chain #ifndef . Then I took atomic operations management as model.

One annoyance but not real complaints.
Just to get the bikeshed started, though: I'll note that the API picked is basically an expression of the ARM instructions and their language ("barrier", "read", "write") and not e.g. the standard C++ memory model ("fence",  "acquire", "release") or the existing GCC builtins (__sync_synchronize() et. al.).
I have no strong feelings, but in general conforming to standards means that we can rely on implementations thereof or this stuff as it matures and don't have to forever maintain our own assembly on architectures that like to evolve.  In particular I'll note that many RISCV implementations are in-order and thus the fence instructions are noops.  Being able to have the toolchain skip them for us based on the output subarchitecture would be a nice win.

I'd suggest that barrier.h (maybe it should be sys/barrier.h in fact)
has something like:
#if defined(CONFIG_ARCH_HAS_MEMORY_BARRIER)

/* include arch specific definitions */

#elif defined(__GNUC__)

/* provide default implementations using compiler intrinsics */
#define arch_mb() __sync_synchronize()
[...]

#else

#error "missing barrier definitions"

#endif

The ARM specific definitions can be done in terms of __ISB() and such
so to remain backward compatible with existing code. But non-ARM
architectures shouldn't have to use those symbols.
And this way, if some architecture/toolchain combination needs to
compile code that makes use of barrier.h without having a proper
definition then it will fail to build instead of being provided with empty
definitions which would be worse than a successful build. If some
architectures do not need any barrier at all then they should define
their own empty macros explicitly and not rely on empty defaults.

DMB/DSB/ISB and friends are ARM-isms. That shouldn't be used as some primitive names for all architectures if we can help it.

Just to soften my point a little: I'd feel more strongly about that if the ARM names weren't so transparently clear and the C++ ones (in particular) such a disaster of obfuscation and overgeneralization.  This is a realm where clarity of understanding is everything, and the "barrier" idea ("all writes before this point are seen by other parallel elements of the system before any write after this point", and the converse for reads) is about the simplest way to express this problem.
I think ARM did it right, basically.  But I'm worried that the toolchain builtins don't quite map to that 1:1, and I see a lot of value in leaning on the toolchain here too.

In particular I'll note that many RISCV implementations are in-order and thus the fence instructions are noops. Being able to have the toolchain skip them for us based on the output subarchitecture would be a nice win.

Sorry I don't understand. Are you saying for some RISCV CPU, when __asm__ volatile ("fence iorw, iorw" : : : "memory") is issued, it's equal to do "no operation" ? __asm__ volatile ("" : : : "memory")
Then, do you wish something like that?
#if defined(CONFIG_ARCH_HAS_MEMORY_BARRIER)
#ifdef __ANOTHER_COMPILER__
#define arch_isb()	__builtin_fence_instruction()
#define arch_mb()	__builtin_fence()
#define arch_rmb()	__builtin_aquire()
#define arch_wmb()	__builtin_release()
#else
#define arch_isb()	__asm__ volatile ("fence.i")
#define arch_mb()	__asm__ volatile ("fence iorw, iorw" : : : "memory")
#define arch_rmb()	__asm__ volatile ("fence ir, ir" : : : "memory")
#define arch_wmb()	__asm__ volatile ("fence ow, ow" : : : "memory")
#endif /* __ANOTHER_COMPILER__ */
#endif /* !CONFIG_ARCH_HAS_MEMORY_BARRIER */

Sorry, for clarity: what I'm saying is that when you're using e.g. gcc, and you call the __atomic_thread_fence() builtin to effect a barrier, and the current compiler was invoked with e.g. a -mcpu= argument that specifies an in-order single core device, then the compiler would be able to optimize that into no code at all instead of emitting the fence instruction that would just be a noop.
Again, I'm not an expert on gcc's memory model intrinsics.  I just know that they exist and that the gcc maintainers are probably better than we are at this stuff in most cases, just like they are with atomics.

I'd suggest that barrier.h (maybe it should be sys/barrier.h in fact) has something like:
#if defined(CONFIG_ARCH_HAS_MEMORY_BARRIER)

/* include arch specific definitions */

#elif defined(__GNUC__)

/* provide default implementations using compiler intrinsics */
#define arch_mb() __sync_synchronize()
[...]

#else

#error "missing barrier definitions"

#endif

The ARM specific definitions can be done in terms of __ISB() and such so to remain backward compatible with existing code. But non-ARM architectures shouldn't have to use those symbols.
And this way, if some architecture/toolchain combination needs to compile code that makes use of barrier.h without having a proper definition then it will fail to build instead of being provided with empty definitions which would be worse than a successful build. If some architectures do not need any barrier at all then they should define their own empty macros explicitly and not rely on empty defaults.

The arch files are including barrier.h that is, in turn, including back an arch-specific header file? Why the arch files cannot directly include the proper implementation? The only difference is you can't retrieve generic stuff from sys/barrier.h to your arch specific barrier.h. Currently I don't see what could be needed, and it seems doesn't need on Linux barrier API.

@andyross
AFAIU from these articles/documents 1, there are 2 kind of barrier:
Software, (builtin acquire/release,...) that only affects the compiler.
Hardware, (architecture specific ASM command) that affects both the compiler and the processor.
Also, there are 2 hardware memory model families: x86-TSO and ARM-POWER.
C++11 memory model provide implicit barriers to support or match x86-TSO and ARM-POWER.

I think ARM did it right, basically. But I'm worried that the toolchain builtins don't quite map to that 1:1, and I see a lot of value in leaning on the toolchain here too.

This article [2] says the C++11 memory model migrates to ARM-POWER. These articles [3] provide mapping between architectures and C++11 functions, and you’re right, they aren’t 1:1.
My conclusion is that trying to have the zephyr barrier API matching with C++11 isn’t worth it because it’s a software barrier and seems to join the ARM-POWER model. The current API follow the Linux barrier API which already has a good match with hardware barriers which affects both the compiler and the processor.

when you're using e.g. gcc, and you call the __atomic_thread_fence() builtin to effect a barrier, and the current compiler was invoked with e.g. a -mcpu= argument that specifies an in-order single core device, then the compiler would be able to optimize that into no code at all instead of emitting the fence instruction that would just be a noop.

Agree, this will be the default API implementation.
http://bruceblinn.com/linuxinfo/MemoryBarriers.html
https://wiki.aalto.fi/display/t1065450/LLVM+atomics
https://www.kernel.org/doc/Documentation/memory-barriers.txt
https://arxiv.org/abs/1803.04432
[2]:
https://www.arangodb.com/2021/02/cpp-memory-model-migrating-from-x86-to-arm/
[3]:
https://www.cl.cam.ac.uk/~pes20/cpp/cpp0xmappings.html
https://five-embeddev.com/riscv-isa-manual/latest/memory.html

Hello
@andyross @npitre
Have you some new suggestions ?
@carlocaione If you think I've done your requested change, could you validate it please ?

Hi @amergnat,
Thanks for the work.
However, we probably should be more explicit about the usage cases we introduce this API for.
From my understanding there are following use cases of HW data memory bariers in Zephyr:

[1] IO operation synchronization. I.e: ordering of several MMIO accesses (if it isn't done by HW itself) or ordering between DMA descriptor access and IO access.
[2] Data accesses ordering when we accessing same data from different CPUs in SMP system.

As it seems to me,

in case [1] we don't need barrier instructions / macros explicitly in code. Instead, we should add them in IO accessors (i.e sys_read32) itself (if the architecture requires to use it). We can also provide relaxed IO accessors version without barriers.
the case [2] can be covered by existing C11 atomic API, which allows to specify memory order even for simple operations like store / load.

So, am I missing some use cases where we require to use HW barrier macros explicitly in generic code?

Hello @evgeniy-paltsev

in case [1] we don't need barrier instructions / macros explicitly in code. Instead, we should add them in IO accessors (i.e sys_read32) itself (if the architecture requires to use it). We can also provide relaxed IO accessors version without barriers.

After taking a look to sys_read32 for different architecture, it could be optimized by using memory barrier API to be more consistent (detail below). (i.e.) Is volatile cast usage for x86 and arc architecture is the most robust/optimized way ? [1]
`
Within a thread of execution, accesses (reads and writes) through volatile glvalues cannot be reordered past observable side-effects (including other volatile accesses) that are sequenced-before or sequenced-after within the same thread, but this order is not guaranteed to be observed by another thread, since volatile access does not establish inter-thread synchronization.
In addition, volatile accesses are not atomic (concurrent read and write is a data race) and do not order memory (non-volatile memory accesses may be freely reordered around the volatile access).
`

the case [2] can be covered by existing C11 atomic API, which allows to specify memory order even for simple operations like store / load.

I agree but it isn't optimized.
The reason for using barriers is to prevent our compiler and hardware from performing unsafe optimizations. Also, the different types of barriers exist in order to describe exactly which memory ordering you need to enforce. This means that starting to insert barriers everywhere, or to use full barrier wherever a barrier is needed (like atomic_builtin does), can have a negative impact on the software performance.
The barrier API should simplify barrier usage in drivers or Zephyr low level layers. It allows to use a generic function (z_****_mb) which is optimized for the current used architecture if architecture specific function are provided. As I said above, C11 atomic API will affect compiler behavior, whereas architecture specific function act on both hardware and compiler behavior, then more optimized. Briefly, this API try:

to be easy to use because not all software developers need to be deeply aware of memory access ordering or barriers.
avoid confusion between all different fence conceptions because the compiler directives, barrier instructions and other system operations will differ between vendors, architectures and overall set of system components.

I understand that can be confusing with atomic API, but the barrier API is an additional tool which wish to be abstract, scalable, easy and flexible to use.
I believe barrier is the simplest way to prevent data race, but I'm not an expert, I can misunderstood some aspects, so let me know if you think I'm on the wrong way.
Inspired from:

https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/memory-access-ordering-part-2---barriers-and-the-linux-kernel

[1] https://en.cppreference.com/w/cpp/atomic/memory_order

in case [1] we don't need barrier instructions / macros explicitly in code. Instead, we should add them in IO accessors (i.e sys_read32) itself (if the architecture requires to use it). We can also provide relaxed IO accessors version without barriers.

After taking a look to sys_read32 for different architecture, I think it could be implemented by using memory barrier API to be more consistent (detail below). (i.e.) Is volatile cast usage for x86 and arc architecture is the most robust/optimized way, even if it works ? [1]

First of all - volatile cast doesn't guarantee that access isn't reordered by compiler or the HW. It only guarantee that compiler won't remove memory access.
So we need to guarantee at least four things here:

[1.1] IO memory accesses are not optimized away (it can be done with volatile cast)
[1.2] IO memory accesses are not reordered by compiler (can be done with compiler barriers, i.e: ARC implementation, see https://github.com/zephyrproject-rtos/zephyr/blob/main/include/arch/arc/sys-io-common.h#L70)
[1.3] IO memory accesses are not reordered with each other by HW. On many HW platforms it is guaranteed by HW itself. Otherwise we may need to use HW memory barriers in IO accessors. For ARC it is ordered on HW level, so we don't have HW memory barriers in current IO accessors.
[1.4] IO memory accesses are not reordered with regular memory accesses. This is important if we are using DMA-enabled peripherals and we want guarantee that accesses to DMA payload / descriptors are not reordered with IO accesses to DMA control registers. We need to use HW memory barriers for that. That currently is missing for ARC Zephyr port, however it's implemented the exact this way in Linux kernel.

All of the cases can be covered by proper IO accessors API.
We can look into how it is implemented in Linux and have two accessor versions, i.e: sys_read32 and sys_read32_relaxed.
sys_read32 will have all [1.1] - [1.4] guarantees, sys_read32_relaxed will be less constrained (and less heavy one) - it will have [1.1] - [1.3] guarantees.
All architectures should add proper barriers to sys_read32 and sys_read32_relaxed if required.

I think the thread drifted a bit.
Currently, every architecture is implementing a different barrier API and mostly non based on the C11 atomic API. This work should focus on having a common API for that to be used mainly for DMA and SMP cases.

Briefly, you prefer follow C11 model and try to adapt HW models (ARM, RISCV,...). I think it will works, but this method will be harder to maintain/expanse and less readable, but it's a subjective opinion.
Some hardware implementation doesn't allow to have atomic operation with barrier argument like C11 method does.

Not all the SW developers aware about the hw barriers and their usage across the various architectures.

IMO, people who miss to put barrier will be same people that don't know which one chose between sys_readXX or sys_readXX_relaxed or atomic_load or atomic_store. When I don't know how something works, I try to find an example somewhere (often in Linux). There are a lot of example in linux code, like the following example:
About "optimization", to ensure A, B and C are read from memory before read D:
atomic_load(regA,A);
atomic_load(regB,B);
atomic_load(regC,C);
atomic_load(regD,D);

This method raise 4 barriers
load(regA,A);
load(regB,B);
load(regC,C);
z_read_mb();
atomic_load(regD,D);

This method raise 1 barriers to do the same job.
I think, in a RTOS, we should keep the optimization handmade instead of try to hard simplify things that could reduce performance. The difficulty is to know when it's worth.
My choice is to use barrier API, again, it's a subjective opinion and I understand your point.

Hello @andyross
Nobody bounce from my last comment. Do you consider this pull request reviewed ? Do you think this PR is worth it ?

Hi @evgeniy-paltsev
The provided API in this PR isn't suited for SMP (even if it can be used, but as you said, not optimized for). We tried to include it in the first PR https://github.com/zephyrproject-rtos/zephyr/pull/41977 , but in a second time we finally prefer to just introduce this new API properly and add SMP support later: z_read_mb_smp
To be clear, in my mind, we should reach the same API as Linux at the end.

@evgeniy-paltsev
Is the previous comment answer your question ?

Hello, sorry for the delay.
Changes:

rebase + test
Improve memory barrier documentation

@evgeniy-paltsev The covered use case should be clear now: https://github.com/zephyrproject-rtos/zephyr/pull/42625/files#diff-3afa00bd90e1bcb7241370343653811e499d1615a4370ae6f001d073d32be49aR41


fixes(typo): adds closing quote

Why:
Closes: #30712

What's being changed (if available, include any code snippets, screenshots, or gifs):
The last sentence in this paragraph is missing a closing quote:

Check off the following:

[x] I have reviewed my changes in staging, available via the View deployment link in this PR's timeline.

For content changes, you will also see an automatically generated comment with links directly to pages you've modified. The comment won't appear if your PR only edits files in the data directory.

[x] For content changes, I have completed the self-review checklist.

@massivebird Thanks so much for opening a PR! I'll get this triaged for review ✨

@massivebird The typo fix looks great - I'll update the branch and get this merged once tests are passing ✨


support for IMDS v2 only

Description
I run a set of userdata commands to spin up Graph Explorer in an EC2.
Auth is via IAM auth and EC2 have the necessary IAM role attached.
#!/bin/bash
cd /home/ec2-user
TOKEN=`curl -X PUT "http://<IP_ADDRESS>/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"`
EC2_IP=$(curl -H "X-aws-ec2-metadata-token: $TOKEN" -v http://<IP_ADDRESS>/latest/meta-data/public-ipv4)
EC2_HOSTNAME="https://"$EC2_IP
echo $EC2_HOSTNAME
yum update -y
yum install git docker -y
git clone https://github.com/aws/graph-explorer/
systemctl start docker
docker buildx build graph-explorer -t "graph-explorer"
docker run -p 80:80 -p 443:443 --env HOST=$EC2_HOSTNAME --env PUBLIC_OR_PROXY_ENDPOINT=$EC2_HOSTNAME --env GRAPH_TYPE=gremlin --env USING_PROXY_SERVER=true --env IAM=true --env AWS_REGION=us-east-1 --env GRAPH_CONNECTION_URL=https://[redacted].us-east-1.neptune.amazonaws.com:8182 --env PROXY_SERVER_HTTPS_CONNECTION=true --env GRAPH_EXP_FETCH_REQUEST_TIMEOUT=240000 graph-explorer

This setup has been working well for months but recently it started to fail with this error:
[01:57:58.914] ERROR (40): Could not load credentials from any providers
    err: {
      "type": "CredentialsProviderError",
      "message": "Could not load credentials from any providers",
      "stack":
          CredentialsProviderError: Could not load credentials from any providers
              at /graph-explorer/node_modules/.pnpm/@aws-sdk+credential-provider-node@3.669.0_@aws-sdk+client-sso-oidc@3.669.0_@aws-sdk+client-st_jgfgvmcemvjj3jgtiyicg7kanm/node_modules/@aws-sdk/credential-provider-node/dist-cjs/index.js:136:13
              at /graph-explorer/node_modules/.pnpm/@smithy+property-provider@3.1.7/node_modules/@smithy/property-provider/dist-cjs/index.js:97:33
              at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
              at async coalesceProvider (/graph-explorer/node_modules/.pnpm/@smithy+property-provider@3.1.7/node_modules/@smithy/property-provider/dist-cjs/index.js:124:18)
              at async /graph-explorer/node_modules/.pnpm/@smithy+property-provider@3.1.7/node_modules/@smithy/property-provider/dist-cjs/index.js:142:18
              at async getIAMHeaders (file:///graph-explorer/packages/graph-explorer-proxy-server/dist/node-server.js:21:19)
              at async retryFetch (file:///graph-explorer/packages/graph-explorer-proxy-server/dist/node-server.js:36:26)
              at async fetchData (file:///graph-explorer/packages/graph-explorer-proxy-server/dist/node-server.js:96:26)
      "name": "CredentialsProviderError",
      "tryNextLink": false
    }

Graph Explorer could not synchronise with Neptune Database as a result.
Environment

OS: Amazon Linux 2
Browser: Any browser
Graph Explorer Version: latest or 1.10.1
Graph Database & Version: <IP_ADDRESS>

Expected Behavior
To use IAM auth from EC2 and connect to Neptune Database.

[!IMPORTANT]
If you are interested in working on this issue or have submitted
a pull request, please leave a comment.

[!TIP]
Please use a 👍 reaction to provide a +1/vote.
This helps the community and maintainers prioritize this request.

Got it to work again if i update my EC2 Instance to run on imds v1 and v2.  If only v2 is allowed, this will break.
Can this be fixed please?

Related to

#119


Invalid parameter: redirect_uri

For hackathon 2022, we are planning to use this application to enhace further for our requirement.  I have changed API refrences with preprod api.  While invoking the url http://localhost:3000 or http://hostname:3000 its thowing "Invalid Parameter :redirect_uri" error in the browser.
the URL is  :https://api.preprod.fusionfabric.cloud/login/v1/sandbox/oidc/authorize?client_id=a0d47a7e-89b8-4fc3-a19d-1ffe4ccd2b8f&scope=openid&response_type=code&redirect_uri=http%3A%2F%2FBLRL82XGVT2%3A3000%2Flogin%2Fcallback&nonce=7758c0a5-2d36-4f71-8865-4b7ea344ae47&state=7fde01ed-71d0-4b3e-abbc-747667e1484a
Please kindly let me know how to fix this error ASAP.

Resolved by changing the app config on Dev portal to use a B2C api instead of B2B


Cache usability check

Description:
For more information see the link below.
https://github.com/ballerina-platform/ballerina-standard-library/blob/main/docs/library-development-process.md#usability-check

Cache init()  needs to return an error instead of panic. This is the usability issue in the cache module but we can't change this now as this is an API change.
Closing this issue as already this issue was reported.
Issue: https://github.com/ballerina-platform/ballerina-standard-library/issues/1435


Update rdf4j-model, rdf4j-query, ... to 4.2.4

About this PR
📦 Updates

org.eclipse.rdf4j:rdf4j-model
org.eclipse.rdf4j:rdf4j-query
org.eclipse.rdf4j:rdf4j-queryalgebra-evaluation
org.eclipse.rdf4j:rdf4j-queryalgebra-model
org.eclipse.rdf4j:rdf4j-queryparser-sparql
org.eclipse.rdf4j:rdf4j-rio-rdfxml
org.eclipse.rdf4j:rdf4j-storage

from 3.7.7 to 4.2.4 ⚠
📜 GitHub Release Notes - Version Diff
Usage
✅ Please merge!
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

⚙ Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.eclipse.rdf4j" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "org.eclipse.rdf4j" }
}]

labels: library-update, early-semver-major, semver-spec-major, commit-count:1

Superseded by #84.


New Hosting Model, Investigate if any action needed in the module

Support is being added in #184.
Note: The support does not fully remove that warning. It adds support for the new model where the warning will not be presented; without removing support for the old model, where the warning will still be generated.
It may be that the DA for example, being new, should be implemented to only accept the new model. So there may still be work to do under this issue.

https://github.com/terraform-ibm-modules/terraform-ibm-icd-elasticsearch/releases/tag/v1.13.0


feat: Provide a simple CLI example

There is already an example that reads from stdin. Everything else is currently not too relevant for imap-flow.


⚠ ClamAV has degraded performance

In 1ebbdc1, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 205 ms

Resolved: ClamAV performance has improved in 6652a16.


assert_contains! takes ownership of passed variable

If I use assert_eq!, this works:
                    let response = ureq::get(&url).call().unwrap();
                    assert_eq!(response.into_string().unwrap(), "Expected response body");

However if I instead use assert_contains!:
                    let response = ureq::get(&url).call().unwrap();
                    assert_contains!(response.into_string().unwrap(), "Expected response body");

...I get this error:
error[E0382]: use of moved value: `response`
   --> examples/basics/tests/integration_test.rs:33:38
    |
31  |                     let response = ureq::get(&url).call().unwrap();
    |                         -------- move occurs because `response` has type `Response`, which does not implement the `Copy` trait
32  |                     // let body = response.into_string().unwrap();
33  |                     assert_contains!(response.into_string().unwrap(), "Expected response body");
    |                                      ^^^^^^^^ ------------- `response` moved due to this method call
    |                                      |
    |                                      value used here after move
    |
note: this function takes ownership of the receiver `self`, which moves `response`
   --> /Users/emorley/.cargo/registry/src/github.com-1ecc6299db9ec823/ureq-2.5.0/src/response.rs:380:24
    |
380 |     pub fn into_string(self) -> io::Result<String> {
    |                        ^^^^

error[E0382]: use of moved value: `response`
  --> examples/basics/tests/integration_test.rs:33:38
   |
31 |                     let response = ureq::get(&url).call().unwrap();
   |                         -------- move occurs because `response` has type `Response`, which does not implement the `Copy` trait
32 |                     // let body = response.into_string().unwrap();
33 |                     assert_contains!(response.into_string().unwrap(), "Expected response body");
   |                                      ^^^^^^^^ ------------- `response` moved due to this method call
   |                                      |
   |                                      value used here after move

For more information about this error, try `rustc --explain E0382`.

This forces me to have to write the assertion with an intermediate variable instead:
                    let response = ureq::get(&url).call().unwrap();
                    let body = response.into_string().unwrap();
                    assert_contains!(body, "Expected response body");

It would be great if assert_contains! could be adjusted so this workaround was not necessary.

xref #483


Uploaded photos can get wrong orientation

UPDATE: Following the investigation below, this was folded into the server-side issue zulip/zulip#8177 .

A user reports:

Photos uploaded on mobile are a "raw" orientation, which if a photo was taking "portrait" means it's presented in "landscape" causing whiplash. This doesn't seem to occur on the Desktop.

In quick testing, I don't reproduce this:

I go to a narrow, open the compose menu, and hit the "camera" icon.
I keep the device in portrait orientation, take a photo, and OK it.
It uploads and shows up in portrait, just like I took it.

That's on both Android and iOS, on v26.0.123.
Not sure what variable is different between my attempted repro and the user seeing the issue. One thing to try would be to take the photo from the camera app, then upload it from the camera roll, rather than taking it directly from the Zulip app.

The user adds:

Android- and reportedly also iPhone- users who take a photo, and then add it to a Zulip conversation don't have the photo orientation "adjusted" (screenshot attached). If that same picture is sent to a desktop, e.g. by way of Google Drive and uploaded with the Desktop client, the orientation is correct. Sequence: Zulip Mobile Client, "+" -> image select -> choose a previously taken photo in "portrait" orientation (or "landscape" if you took it "upside down").

(The screenshot showed a Zulip message, I think from the web/desktop app, with a photo that is clearly rotated 90deg from life. The image has the sky to the left and the ground to the right. Its size in the sky-ground axis is longer than the other -- i.e. its proper orientation is portrait -- and it's displayed with that long axis as the width, i.e. in landscape.)
I tried this exact repro just now, on v26.1.124 on my Pixel 2 XL running Android 9:

Sequence: Zulip Mobile Client, "+" -> image select -> choose a previously taken photo in "portrait" orientation

and it didn't reproduce, though -- the real-life top of the photo displays at the top.
Also tried two variations on how to take the photo (in each case, taking it from the camera app and then in Zulip using "+" -> "photo" icon to select and upload it):

Turned the phone physically to landscape orientation, but left the screen in portrait ("auto-rotate" was disabled) and took the photo.
Turned the phone physically to landscape orientation, then also tapped the rotation button to let the screen switch to landscape orientation.

Neither of those reproduced it either -- the real-life top of the photo displayed at the top each time.

I am also not able to reproduce it.
Tried uploading images from gallery and taking images from camera in both the orientation, and image is uploaded in the right orientation.
We need to ask user for video/GIF of reproducing this issue, it will help a lot. Also on which device he is facing this issue?

Thanks @jainkuniya ! Would you add details of what device model, what OS version, and what Zulip version you were using in the attempted repro?

Confirmed Correct: iPhone 6, iOS 12.3, 12.4; Samsung Phones of numerous flavors
Confirmed Incorrect: MotoZ3, Android 8,9; MotoZ2, Android 8; iPhone 6, iOS 12.1.4

@cognusion Very interesting, thanks!
Would you say a bit more about what you observed? In particular, on these devices:

Confirmed Incorrect: MotoZ3, Android 8,9; MotoZ2, Android 8; iPhone 6, iOS 12.1.4

is it the case that you hit this issue every time you try? If so, that seems like a very helpful clue.
Oh another detail that would potentially be quite helpful:

Confirmed Correct: ..., Samsung Phones of numerous flavors

Could you track down the OS version and/or device model of one or two of these phones? (And I believe you're saying that on these devices, you've tried uploading photos and you don't see the symptoms of this issue.)

@cognusion Very interesting, thanks!
Would you say a bit more about what you observed? In particular, on these devices:

Confirmed Incorrect: MotoZ3, Android 8,9; MotoZ2, Android 8; iPhone 6, iOS 12.1.4

Photos taken on those devices using the phone camera in a "portrait" orientation, and then uploaded using the Zulip client, are shown in "landscape" as described. I'm not using the in-Zulip "take a photo", rather the gallery for previously-taken photos.
Also, of note, downloading a portrait picture onto the phone from somewhere, and then uploading it to Zulip Mobile does not result in the "landscaping". Also, uploading the portrait picture using the Zulip Desktop client does not result in the "landscaping".

is it the case that you hit this issue every time you try? If so, that seems like a very helpful clue.

Yes, 100% reproducible.

Oh another detail that would potentially be quite helpful:

Confirmed Correct: ..., Samsung Phones of numerous flavors

Could you track down the OS version and/or device model of one or two of these phones? (And I believe you're saying that on these devices, you've tried uploading photos and you don't see the symptoms of this issue.)

I didn't pay especially close access to the ones that worked. I can send out a request for more details, but they aren't phones I have access to directly.

Fascinating, thanks @cognusion ! That suggests that this issue interacts with something that varies between OS versions... both between iOS versions and between Android versions, which means two different changes (something in iOS changed, and something in Android changed or was introduced by an Android OEM.)
Especially interesting is that it seems to differ between minor versions of iOS 12, and moreover with a single device model (iPhone 6).
One thing I wonder is if there's some other variable on the devices that is affecting the issue. Perhaps a setting? ... I don't see any relevant-looking setting in Android 9 on my Pixel 2 XL. My iPhone is out of battery, so can't immediately check there; charging now.
Also very helpful, if you can, would be to get your hands on one of the devices where the issue is not happening, and attempt to repro there yourself. I wonder if there's some subtle difference between what you're doing and what people who aren't seeing the issue (including both me and @jainkuniya so far) are doing, something we're all just not successfully communicating in text. So if you can try the exact same recipe on two devices, one after the other, and it repros on one and not the other, that will be very helpful confirmation that it's not that... and conversely, if it does repro on someone's device who hadn't been seeing it, then that will be an excellent lead.

One thing I wonder is if there's some other variable on the devices that is affecting the issue. Perhaps a setting? ... I don't see any relevant-looking setting in Android 9 on my Pixel 2 XL. My iPhone is out of battery, so can't immediately check there; charging now.

Just looked at the camera settings in iOS 12.4.1 on my iPhone 7, and I don't see anything that looks like it could be relevant there either. :man_shrugging:

A Samsung Galaxy S9, running Android 9, in my hands with the same process yields properly-portraited uploads via Zulip Mobile.
Additionally, I used the in-Zulip photo option on both that S9 and a MotoZ3, the S9 was properly-portraited, the Z3 was improperly-landscaped (which it does from the gallery as well).

@cognusion Cool. Thanks for pinning that down!

OK, another report today from @timabbott in chat... and I think we have a diagnosis!
Tim ran into the issue on a Samsung Galaxy S9+ running Android 9. His encounter with it was in the chat.zulip.org realm where I could see it directly, so that helped me investigate.
It turns out that if I just click through to open the image URL itself in my browser... it shows up correctly oriented! So the server has the image just fine, but it shows up wrong when part of a webpage, and similarly when part of the message list in the mobile app.
Looking closer, if I download the photo to my desktop and run file, it reports:
JPEG image data, Exif standard: ..., orientation=upper-right, ...

I believe that means the pixel at coordinates (0, 0) is supposed to go in the upper-right corner (rather than the usual upper-left) -- and the issue is that <img> in HTML doesn't respect that EXIF orientation metadata. That would completely explain what we're seeing.
When I take photos with my Pixel 2 XL running Android 10, in any orientation, the same EXIF metadata always comes out as the default orientation=upper-left. I.e., the device is handling rotation by rearranging the actual pixels, to avoid relying on orientation metadata.
Given that diagnosis, I think the proper place to fix this is on the server and/or the webapp: the same files will produce the same result if uploaded from a desktop, without involving the mobile app at all. (If there ends up being a piece the web frontend takes care of at display time, we'll then do something similar in the mobile app.)
This thread is long enough that rather than move it between repos, I'll go make a fresh thread in zulip/zulip .

Oho, and this is already zulip/zulip#8177. So I'll just bring the new information over there.

Given what we've now learned, this is a duplicate of zulip/zulip#8177 . I'm going to close it to consolidate discussion there; I'll edit the description to point there, too.

(Thanks again @cognusion for the many observations which helped us understand this better, and @jainkuniya for the effort to reproduce!)

Reopening this, to serve as a sort of mirror of the status of the main issue zulip/zulip#8177.
That issue naturally doesn't show up when searching this repo's issue tracker, so it's confusing to have the issue with this title show up as closed when the issue is still unfixed.
Discussion should still be concentrated at zulip/zulip#8177.

I noticed that in a recent mobile release, this has been resolved, and mobile uploads are appearing in the correct orientation on the mobile client! :smiley:  Mobile uploads viewed in the desktop client, however, are still unoriented, however. :cry:  Glad to see there's progress! :+1:

This is now getting fixed in browsers! :confetti_ball: Details here: https://github.com/zulip/zulip/issues/8177#issuecomment-621468621
Thanks to @cognusion for noticing the change (and the detailed investigation over on zulip/zulip#8177.)
I've filed zulip/zulip-desktop#946 for the desktop client to ship the update. Webapp users should see the problem resolved as their browser updates -- the latest Chrome and Safari should already have the fix, and in Firefox it's coming soon. Android users will see the problem resolve with the latest Chrome update, and I believe iOS users should see the problem resolve with iOS 13, possibly earlier.

Should we close this now that the desktop app is on Electron 9 and thus zulip/zulip-desktop#946 is resolved?

Thanks for the follow-up, Tim! That looks correct to me; closing now.


HashMap is not thread safe. Field storageMap is typically synchronized by storageMap. However, in one place, field storageMap is not protected with synchronized.

The field storageMap  (a HashMap)
https://github.com/apache/hadoop/blob/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/blockmanagement/DatanodeDescriptor.java#L155
is typically protected by synchronization on storageMap, e.g.,
https://github.com/apache/hadoop/blob/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/blockmanagement/DatanodeDescriptor.java#L294
https://github.com/apache/hadoop/blob/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/blockmanagement/DatanodeDescriptor.java#L443
https://github.com/apache/hadoop/blob/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/blockmanagement/DatanodeDescriptor.java#L484
For a total of 9 locations.
The reason is because HashMap is not thread safe.
However, here:
https://github.com/apache/hadoop/blob/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/blockmanagement/DatanodeDescriptor.java#L455
DatanodeStorageInfo storage =
  storageMap.get(report.getStorage().getStorageID());

It is not synchronized.
Note that in the same method (about 30 lines below):
https://github.com/apache/hadoop/blob/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/blockmanagement/DatanodeDescriptor.java#L484
storageMap is again protected by synchronization:
synchronized (storageMap) {
  storageMapSize = storageMap.size();
}

This CR protected the above instance (line 455 ) with synchronization
like in line 484 and in all other occurrences.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
31
Docker mode activated.

_ Prechecks _

+1
dupname
0
No case conflicting files found.

+1
@author
0
The patch does not contain any @author tags.

-1
test4tests
0
The patch doesn't appear to include any new or modified tests.  Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch.

_ trunk Compile Tests _

+1
mvninstall
1059
trunk passed

+1
compile
70
trunk passed

+1
checkstyle
44
trunk passed

+1
mvnsite
63
trunk passed

+1
shadedclient
749
branch has no errors when building and testing our client artifacts.

+1
javadoc
49
trunk passed

0
spotbugs
163
Used deprecated FindBugs config; considering switching to SpotBugs.

+1
findbugs
161
trunk passed

_ Patch Compile Tests _

+1
mvninstall
59
the patch passed

+1
compile
58
the patch passed

+1
javac
58
the patch passed

+1
checkstyle
39
the patch passed

+1
mvnsite
61
the patch passed

+1
whitespace
0
The patch has no whitespace issues.

+1
shadedclient
731
patch has no errors when building and testing our client artifacts.

+1
javadoc
43
the patch passed

+1
findbugs
162
the patch passed

_ Other Tests _

-1
unit
4979
hadoop-hdfs in the patch failed.

+1
asflicense
31
The patch does not generate ASF License warnings.

8452

Reason
Tests

Failed junit tests
hadoop.hdfs.server.diskbalancer.TestDiskBalancer

hadoop.hdfs.TestDecommission

hadoop.hdfs.server.datanode.TestBPOfferService

hadoop.hdfs.TestDFSStripedOutputStream

hadoop.hdfs.TestDFSStripedInputStreamWithRandomECPolicy

hadoop.hdfs.web.TestWebHdfsTimeouts

hadoop.hdfs.server.datanode.TestNNHandlesBlockReportPerStorage

hadoop.hdfs.server.namenode.ha.TestFailureToReadEdits

hadoop.hdfs.TestFileChecksum

hadoop.hdfs.server.datanode.TestDirectoryScanner

Subsystem
Report/Notes

Docker
Client=17.05.0-ce Server=17.05.0-ce base: https://builds.apache.org/job/hadoop-multibranch/job/PR-1015/1/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/1015

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle

uname
Linux 4744b8b8a361 4.4.0-139-generic #165-Ubuntu SMP Wed Oct 24 10:58:50 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / 4b50981

Default Java
1.8.0_212

unit
https://builds.apache.org/job/hadoop-multibranch/job/PR-1015/1/artifact/out/patch-unit-hadoop-hdfs-project_hadoop-hdfs.txt

Test Results
https://builds.apache.org/job/hadoop-multibranch/job/PR-1015/1/testReport/

Max. process+thread count
5036 (vs. ulimit of 5500)

modules
C: hadoop-hdfs-project/hadoop-hdfs U: hadoop-hdfs-project/hadoop-hdfs

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-1015/1/console

versions
git=2.7.4 maven=3.3.9 findbugs=3.1.0-RC1

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

I see some tests failed.  I don't know why this small change would break those tests.  Maybe somebody more familiar with the project can take a look.
Either way, the original problem --- using a thread-unsafe HashMap concurrently without synchronization --- remains.


[INFO] Flink : Connectors : ............................... SUCCESS [  0.092 s]
[INFO] Flink : Connectors : File Sink Common .............. SUCCESS [  0.005 s]
[INFO] Flink : Streaming Java ............................. SUCCESS [  0.056 s]
[INFO] Flink : Clients .................................... SUCCESS [  0.025 s]
[INFO] Flink : Test utils : Utils ......................... SUCCESS [  0.006 s]
[INFO] Flink : DSTL ....................................... SUCCESS [  0.004 s]
[INFO] Flink : DSTL : DFS ................................. SUCCESS [  0.006 s]
[INFO] Flink : State backends : ........................... SUCCESS [  0.024 s]
[INFO] Flink : State backends : RocksDB ................... SUCCESS [  0.012 s]
[INFO] Flink : State backends : Changelog ................. SUCCESS [  0.010 s]
[INFO] Flink : Runtime web ................................ SUCCESS [  0.621 s]
[INFO] Flink : Test utils : Connectors .................... SUCCESS [  0.004 s]
[INFO] Flink : Connectors : Base .......................... SUCCESS [  0.006 s]
[INFO] Flink : Connectors : Files ......................... SUCCESS [  0.012 s]
[INFO] Flink : Examples : ................................. SUCCESS [  0.023 s]
[INFO] Flink : Examples : Batch ........................... SUCCESS [  0.010 s]
[INFO] Flink : Connectors : Hadoop compatibility .......... SUCCESS [  0.011 s]
[INFO] Flink : Tests ...................................... SUCCESS [  0.052 s]
[INFO] Flink : Streaming Scala ............................ SUCCESS [  0.018 s]
[INFO] Flink : Connectors : HCatalog ...................... SUCCESS [  0.005 s]
[INFO] Flink : Table : .................................... SUCCESS [  0.215 s]
[INFO] Flink : Table : Common ............................. SUCCESS [  0.020 s]
[INFO] Flink : Table : API Java ........................... SUCCESS [  0.011 s]
[INFO] Flink : Table : API Java bridge .................... SUCCESS [  0.006 s]
[INFO] Flink : Formats : .................................. SUCCESS [  0.028 s]
[INFO] Flink : Format : Common ............................ SUCCESS [  0.002 s]
[INFO] Flink : Table : API Scala .......................... SUCCESS [  0.004 s]
[INFO] Flink : Table : API Scala bridge ................... SUCCESS [  0.004 s]
[INFO] Flink : Table : SQL Parser ......................... SUCCESS [  0.006 s]
[INFO] Flink : Table : SQL Parser Hive .................... SUCCESS [  0.006 s]
[INFO] Flink : Table : Code Splitter ...................... SUCCESS [  0.008 s]
[INFO] Flink : Libraries : ................................ SUCCESS [  0.039 s]
[INFO] Flink : Libraries : CEP ............................ SUCCESS [  0.014 s]
[INFO] Flink : Table : Runtime ............................ SUCCESS [  0.027 s]
[INFO] Flink : Table : Planner ............................ SUCCESS [  0.139 s]
[INFO] Flink : Formats : Json ............................. SUCCESS [  0.005 s]
[INFO] Flink : Connectors : Elasticsearch base ............ SUCCESS [  0.005 s]
[INFO] Flink : Connectors : Elasticsearch 5 ............... SUCCESS [  0.004 s]
[INFO] Flink : Connectors : Elasticsearch 6 ............... SUCCESS [  0.004 s]
[INFO] Flink : Connectors : Elasticsearch 7 ............... SUCCESS [  0.004 s]
[INFO] Flink : Connectors : HBase base .................... SUCCESS [  0.004 s]
[INFO] Flink : Connectors : HBase 1.4 ..................... SUCCESS [  0.004 s]
[INFO] Flink : Connectors : HBase 2.2 ..................... SUCCESS [  0.004 s]
[INFO] Flink : Formats : Hadoop bulk ...................... SUCCESS [  0.004 s]
[INFO] Flink : Formats : Orc .............................. SUCCESS [  0.005 s]
[INFO] Flink : Formats : Orc nohive ....................... SUCCESS [  0.003 s]
[INFO] Flink : Formats : Avro ............................. SUCCESS [  0.019 s]
[INFO] Flink : Formats : Parquet .......................... SUCCESS [  0.055 s]
[INFO] Flink : Formats : Csv .............................. SUCCESS [  0.005 s]
[INFO] Flink : Connectors : Hive .......................... SUCCESS [  0.024 s]
[INFO] Flink : Connectors : JDBC .......................... SUCCESS [  0.012 s]
[INFO] Flink : Connectors : RabbitMQ ...................... SUCCESS [  0.005 s]
[INFO] Flink : Connectors : Twitter ....................... SUCCESS [  0.002 s]
[INFO] Flink : Connectors : Nifi .......................... SUCCESS [  0.004 s]
[INFO] Flink : Connectors : Cassandra ..................... SUCCESS [  0.005 s]
[INFO] Flink : Metrics : JMX .............................. SUCCESS [  0.004 s]
[INFO] Flink : Formats : Avro confluent registry .......... SUCCESS [  0.005 s]
[INFO] Flink : Connectors : Kafka ......................... SUCCESS [  0.016 s]
[INFO] Flink : Connectors : Google PubSub ................. SUCCESS [  0.006 s]
[INFO] Flink : Connectors : Kinesis ....................... SUCCESS [  0.011 s]
[INFO] Flink : Connectors : SQL : Elasticsearch 6 ......... SUCCESS [  0.004 s]
[INFO] Flink : Connectors : SQL : Elasticsearch 7 ......... SUCCESS [  0.004 s]
[INFO] Flink : Connectors : SQL : HBase 1.4 ............... SUCCESS [  0.003 s]
[INFO] Flink : Connectors : SQL : HBase 2.2 ............... SUCCESS [  0.002 s]
[INFO] Flink : Connectors : SQL : Hive 1.2.2 .............. SUCCESS [  0.003 s]
[INFO] Flink : Connectors : SQL : Hive 2.2.0 .............. SUCCESS [  0.005 s]
[INFO] Flink : Connectors : SQL : Hive 2.3.6 .............. SUCCESS [  0.003 s]
[INFO] Flink : Connectors : SQL : Hive 3.1.2 .............. SUCCESS [  0.003 s]
[INFO] Flink : Connectors : SQL : Kafka ................... SUCCESS [  0.003 s]
[INFO] Flink : Connectors : SQL : Kinesis ................. SUCCESS [  0.003 s]
[INFO] Flink : Formats : Sequence file .................... SUCCESS [  0.004 s]
[INFO] Flink : Formats : Compress ......................... SUCCESS [  0.004 s]
[INFO] Flink : Formats : Avro AWS Glue Schema Registry .... SUCCESS [  0.004 s]
[INFO] Flink : Formats : SQL Orc .......................... SUCCESS [  0.002 s]
[INFO] Flink : Formats : SQL Parquet ...................... SUCCESS [  0.003 s]
[INFO] Flink : Formats : SQL Avro ......................... SUCCESS [  0.004 s]
[INFO] Flink : Formats : SQL Avro Confluent Registry ...... SUCCESS [  0.003 s]
[INFO] Flink : Examples : Streaming ....................... SUCCESS [  0.020 s]
[INFO] Flink : Examples : Table ........................... SUCCESS [  0.010 s]
[INFO] Flink : Examples : Build Helper : .................. SUCCESS [  0.004 s]
[INFO] Flink : Examples : Build Helper : Streaming Twitter  SUCCESS [  0.003 s]
[INFO] Flink : Examples : Build Helper : Streaming State machine SUCCESS [  0.002 s]
[INFO] Flink : Examples : Build Helper : Streaming Google PubSub SUCCESS [  0.004 s]
[INFO] Flink : Container .................................. SUCCESS [  0.003 s]
[INFO] Flink : Queryable state : Runtime .................. SUCCESS [  0.004 s]
[INFO] Flink : Kubernetes ................................. SUCCESS [  0.016 s]
[INFO] Flink : Yarn ....................................... SUCCESS [  0.007 s]
[INFO] Flink : Libraries : Gelly .......................... SUCCESS [  0.018 s]
[INFO] Flink : Libraries : Gelly scala .................... SUCCESS [  0.006 s]
[INFO] Flink : Libraries : Gelly Examples ................. SUCCESS [  0.013 s]
[INFO] Flink : External resources : ....................... SUCCESS [  0.003 s]
[INFO] Flink : External resources : GPU ................... SUCCESS [  0.003 s]
[INFO] Flink : Metrics : Dropwizard ....................... SUCCESS [  0.003 s]
[INFO] Flink : Metrics : Graphite ......................... SUCCESS [  0.003 s]
[INFO] Flink : Metrics : InfluxDB ......................... SUCCESS [  0.004 s]
[INFO] Flink : Metrics : Prometheus ....................... SUCCESS [  0.004 s]
[INFO] Flink : Metrics : StatsD ........................... SUCCESS [  0.002 s]
[INFO] Flink : Metrics : Datadog .......................... SUCCESS [  0.003 s]
[INFO] Flink : Metrics : Slf4j ............................ SUCCESS [  0.004 s]
[INFO] Flink : Libraries : CEP Scala ...................... SUCCESS [  0.006 s]
[INFO] Flink : Table : Uber ............................... SUCCESS [  0.004 s]
[INFO] Flink : Python ..................................... SUCCESS [  0.020 s]
[INFO] Flink : Table : SQL Client ......................... SUCCESS [  0.008 s]
[INFO] Flink : Libraries : State processor API ............ SUCCESS [  0.010 s]
[INFO] Flink : Dist ....................................... SUCCESS [  0.007 s]
[INFO] Flink : Yarn Tests ................................. SUCCESS [  0.005 s]
[INFO] Flink : E2E Tests : ................................ SUCCESS [  0.042 s]
[INFO] Flink : E2E Tests : CLI ............................ SUCCESS [  0.002 s]
[INFO] Flink : E2E Tests : Parent Child classloading program SUCCESS [  0.002 s]
[INFO] Flink : E2E Tests : Parent Child classloading lib-package SUCCESS [  0.003 s]
[INFO] Flink : E2E Tests : Dataset allround ............... SUCCESS [  0.002 s]
[INFO] Flink : E2E Tests : Dataset Fine-grained recovery .. SUCCESS [  0.003 s]
[INFO] Flink : E2E Tests : Datastream allround ............ SUCCESS [  0.004 s]
[INFO] Flink : E2E Tests : Batch SQL ...................... SUCCESS [  0.003 s]
[INFO] Flink : E2E Tests : Stream SQL ..................... SUCCESS [  0.002 s]
[INFO] Flink : E2E Tests : Distributed cache via blob ..... SUCCESS [  0.003 s]
[INFO] Flink : E2E Tests : High parallelism iterations .... SUCCESS [  0.003 s]
[INFO] Flink : E2E Tests : Stream stateful job upgrade .... SUCCESS [  0.002 s]
[INFO] Flink : E2E Tests : Queryable state ................ SUCCESS [  0.004 s]
[INFO] Flink : E2E Tests : Local recovery and allocation .. SUCCESS [  0.002 s]
[INFO] Flink : E2E Tests : Elasticsearch 5 ................ SUCCESS [  0.003 s]
[INFO] Flink : E2E Tests : Elasticsearch 6 ................ SUCCESS [  0.002 s]
[INFO] Flink : Quickstart : ............................... SUCCESS [  0.051 s]
[INFO] Flink : Quickstart : Java .......................... SUCCESS [  0.003 s]
[INFO] Flink : Quickstart : Scala ......................... SUCCESS [  0.002 s]
[INFO] Flink : E2E Tests : Quickstart ..................... SUCCESS [  0.004 s]
[INFO] Flink : E2E Tests : Confluent schema registry ...... SUCCESS [  0.003 s]
[INFO] Flink : E2E Tests : Stream state TTL ............... SUCCESS [  0.003 s]
[INFO] Flink : E2E Tests : SQL client ..................... SUCCESS [  0.002 s]
[INFO] Flink : E2E Tests : File sink ...................... SUCCESS [  0.003 s]
[INFO] Flink : E2E Tests : State evolution ................ SUCCESS [  0.005 s]
[INFO] Flink : E2E Tests : RocksDB state memory control ... SUCCESS [  0.003 s]
[INFO] Flink : E2E Tests : Common ......................... SUCCESS [  0.005 s]
[INFO] Flink : E2E Tests : Metrics availability ........... SUCCESS [  0.002 s]
[INFO] Flink : E2E Tests : Metrics reporter prometheus .... SUCCESS [  0.004 s]
[INFO] Flink : E2E Tests : Heavy deployment ............... SUCCESS [  0.002 s]
[INFO] Flink : E2E Tests : Connectors : Google PubSub ..... SUCCESS [  0.004 s]
[INFO] Flink : E2E Tests : Streaming Kafka base ........... SUCCESS [  0.002 s]
[INFO] Flink : E2E Tests : Streaming Kafka ................ SUCCESS [  0.002 s]
[INFO] Flink : E2E Tests : Plugins : ...................... SUCCESS [  0.003 s]
[INFO] Flink : E2E Tests : Plugins : Dummy fs ............. SUCCESS [  0.003 s]
[INFO] Flink : E2E Tests : Plugins : Another dummy fs ..... SUCCESS [  0.003 s]
[INFO] Flink : E2E Tests : TPCH ........................... SUCCESS [  0.002 s]
[INFO] Flink : E2E Tests : Streaming Kinesis .............. SUCCESS [  0.002 s]
[INFO] Flink : E2E Tests : Elasticsearch 7 ................ SUCCESS [  0.003 s]
[INFO] Flink : E2E Tests : Common Kafka ................... SUCCESS [  0.003 s]
[INFO] Flink : E2E Tests : TPCDS .......................... SUCCESS [  0.006 s]
[INFO] Flink : E2E Tests : Netty shuffle memory control ... SUCCESS [  0.002 s]
[INFO] Flink : E2E Tests : Python ......................... SUCCESS [  0.003 s]
[INFO] Flink : E2E Tests : HBase .......................... SUCCESS [  0.004 s]
[INFO] Flink : E2E Tests : AWS Glue Schema Registry ....... SUCCESS [  0.002 s]
[INFO] Flink : State backends : Heap spillable ............ SUCCESS [  0.004 s]
[INFO] Flink : Contrib : .................................. SUCCESS [  0.003 s]
[INFO] Flink : Contrib : Connectors : Wikiedits ........... SUCCESS [  0.004 s]
[INFO] Flink : FileSystems : Tests ........................ SUCCESS [  0.003 s]
[INFO] Flink : Docs ....................................... SUCCESS [  0.003 s]
[INFO] Flink : Walkthrough : .............................. SUCCESS [  0.005 s]
[INFO] Flink : Walkthrough : Common ....................... SUCCESS [  0.003 s]
[INFO] Flink : Walkthrough : Datastream Java .............. SUCCESS [  0.002 s]
[INFO] Flink : Walkthrough : Datastream Scala ............. SUCCESS [  0.004 s]
[INFO] Flink : Tools : CI : Java .......................... SUCCESS [  0.002 s]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  6.428 s
[INFO] Finished at: 2021-08-03T10:48:14+08:00
[INFO] ------------------------------------------------------------------------

Process finished with exit code 0

@flinkbot run azure

@KarlManong It seems that I do not have permissions to push commit to the master branch of git@github.com:KarlManong/flink.git. Do you have unchecked the "Allow edits by maintainers"?
Another suggestion, usually we create a new branch for opening a PR, not using the master branch. That's why I close this PR accidentally.

Closed for #16697.


$ is not a function

Hi, I want use materializeCSS with ionic 2 app, so I install these :
npm install materialize-css --save
npm install angular2-materialize --save
npm install<EMAIL_ADDRESS>--save
npm install hammerjs --save

but I still get this error :
$ is not a function
What I should do?

What bundler are you using? You need to bind $ to jQuery so MaterializeCSS can find it.

@rubyboy how can i do that without using webpack?

Okay guys it works now.
My solution was to correct the angular-cli.json. I´ve added
"../node_modules/materialize-css/dist/css/materialize.css"  to apps -> styles
and
"../node_modules/jquery/dist/jquery.js",
"../node_modules/hammerjs/hammer.js",
"../node_modules/materialize-css/dist/js/materialize.js" to apps -> scripts

@moh3n9595 have you figured out how to integrate with ionic2?

I am waiting for IONIC 2 solution


Allow GovCloud managed policies and profiles

I was attempting a new GovCloud deployment that required me to reference existing IAM instance policies, and I wasn't able to so without this change. This might be a problem for other regions too.

Codecov Report

Merging #1124 into master will not change coverage.
The diff coverage is 0%.

@@           Coverage Diff           @@
##           master    #1124   +/-   ##
=======================================
  Coverage   35.23%   35.23%
=======================================
  Files          63       63
  Lines        3735     3735
=======================================
  Hits         1316     1316
  Misses       2207     2207
  Partials      212      212

Impacted Files
Coverage Δ

model/iamconfig.go
0% <0%> (ø)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 890ac66...c6035d9. Read the comment docs.

@amdonov Btw, thank you very much for testing it in GovCloud 👍

On Tue, Feb 6, 2018 at 3:13 AM KUOKA Yusuke<EMAIL_ADDRESS>wrote:

@amdonov https://github.com/amdonov Btw, thank you very much for
testing it in GovCloud 👍
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes-incubator/kube-aws/pull/1124#issuecomment-363343744,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AArhFJ_PqJ4ZYMuXNztcZ8GMpiHKVE8jks5tSAnCgaJpZM4R4rrK
.

I will have time today to fix it and write a test. I think there is another
pattern used in a different region too. I will look for it.

Been a bit since I did this, but I don’t recall removing any tests on
purpose. I know that I had to change a couple because of error messages
changes. Feel free to revert any deletes, and I will revisit the pull
request if their are build issues.
On Thu, Mar 15, 2018 at 8:55 AM KUOKA Yusuke<EMAIL_ADDRESS>wrote:

@mumoshu commented on this pull request.
In test/integration/maincluster_test.go
https://github.com/kubernetes-incubator/kube-aws/pull/1124#discussion_r174771216
:

			cp := c.ControlPlane()

			controllerUserdataS3Part := cp.UserDataController.Parts[model.USERDATA_S3].Asset.Content

			if !strings.Contains(controllerUserdataS3Part, `--feature-gates=PodPriority=true`) {

				t.Error("missing controller feature gate: PodPriority=true")

			}

			if !strings.Contains(controllerUserdataS3Part, `scheduling.k8s.io/v1alpha1=true` <http://scheduling.k8s.io/v1alpha1=true>) {

				t.Error("missing controller runtime config: scheduling.k8s.io/v1alpha1=true")

			}

			re, _ := regexp.Compile("--admission-control=[a-zA-z,]*,Priority")

			if len(re.FindString(controllerUserdataS3Part)) == 0 {

				t.Error("missing controller --admission-control config: Priority")

			}

		},

@amdonov https://github.com/amdonov Hi! Can I just revert these
removals of test cases, and move forward to merge this?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes-incubator/kube-aws/pull/1124#discussion_r174771216,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AArhFFQX71cci_HcQ_WxcTYumFj303zVks5temS5gaJpZM4R4rrK
.


[TACHYON-1090] Replace type of counter of completed logs from int to long

A follow up PR for https://github.com/amplab/tachyon/pull/1706, without this PR, when ufs is S3, counter for completed logs may overflow.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins/job/Tachyon-Pull-Request-Builder/5816/
Test PASSed.

LGTM

LGTM


Easy way to check what account I am logged into

I would like to able to check easily what Azure account I am logged into without having to do a deployment to see the list of subscriptions.
azd login --check-status only says if you are logged in or not.
I can't find info that says whether I can assume that az and azd login statuses are one and the same, so I don't know if I can trust the output from az account list to be is what azd is using.

Thank you for using azd!! :)
azd currently uses AzureCLICredential.  So, it depends on whatever the az cli is logged in to.
The final experience around log in for azd is still WIP

@irinasmoke new azd config command for the default account/subscription #955

@irinasmoke new azd config command for the default account/subscription #955

After reviewing this feature, my understanding is that it takes care of the case where you may have one account with many subscriptions and don't want to scroll/pick each time.
However, I am also looking to cover the case where I have multiple Azure accounts (e.g. personal and enterprise) and need to know which I am logged into.

Thank you for using azd!! :)
azd currently uses AzureCLICredential. So, it depends on whatever the az cli is logged in to.
The final experience around log in for azd is still WIP

Do we make this explicit anywhere? My suggestion is to, for now, make it clear in docs/azd login --help that az cli login = azd login, and in the future azd login experience to make sure this scenario (I need to check what account I am logged into) is covered.

This has evolved a bit since this was filed but IMO, we should at the very least show what account(s) are authenticated

This is related:
https://github.com/Azure/azure-dev/issues/1745
I'm working on writing a script that needs to check if a user is logged into azd.  If we go with the current design of showing "Logged into Azure", then my script would have to parse that text.  It would be create if we could have a flag that was something like --is-logged-in that returns a bool.  Or something more structured so automation with azd is that much easier.  Thoughts @weikanglim ?

Looks like azd auth token --output json gives me what I need.

@jongio
This functionality exists as:
~ azd auth login --check-status --output json
{
  "status": "success",
  "expiresOn": "2023-10-24T17:35:40.934596732Z"
}

Closing based on https://github.com/Azure/azure-dev/issues/986#issuecomment-1777608905

@rajeshkamal5050 the issue is asking about showing the logged-in account not whether you are logged in or not.
Also, the related issue #2976 was asking for the same thing which is a way to show the logged-in email or principal id.
The comment mentioned a way to show whether you are logged in or not which doesn't solve the issue here or in #2976

Yes, you are right @john0isaac. Adding some notes.
Initial ask for showing the current logged-in user details is similar to #1745. Marking this as duplicate of #1745.
In the middle it got hijacked for need to check if a user is logged into azd which can be achieved by azd auth login --check-status --output json


Unfortunately the CSS does not work for me

https://user-images.githubusercontent.com/94720916/168450601-6a811827-0200-4385-a36f-ff214c419f81.png
https://user-images.githubusercontent.com/94720916/168450611-b650cc7b-b920-44e2-920f-978c00d938ed.png

You can open the index.html in the dist folder


Cython 3 compilation

Describe the bug
Error compiling Cython file
To Reproduce
Compile on macOS with cython 3.0 to get a lot of error messages:
Error compiling Cython file:
------------------------------------------------------------
...
                    raise TypeError("attempting to use real type for complex elements.")

                with nogil:
                    for i in range(Ns):
                        c[i] *= sign[i]
                        indices[i] = <npy_intp>rep_position(Ns_full,basis_pcon,basis[i])
                                                           ^
------------------------------------------------------------

quspin/basis/basis_general/_basis_general_core/source/general_basis_core.pyx:128:59: Unable to deduce type parameters for K (const K, I *, const I) noexcept nogil given (npy_intp, uint256_t *, uint256_t &)

Desktop (please complete the following information):

OS: macOS 13.5.2
Python 3.11.5
Cython 3.0.0

downgrade cython to 0.29 (see version prereqs online) and it should be fine.
Marin
On Tue, Sep 19, 2023, 1:15 PM Denis Vasilyev @.***>
wrote:

Describe the bug
Error compiling Cython file
To Reproduce
Compile on macOS with cython 3.0 to get a lot of error messages:
Error compiling Cython file:
...
raise TypeError("attempting to use real type for complex elements.")
            with nogil:
                for i in range(Ns):
                    c[i] *= sign[i]
                    indices[i] = <npy_intp>rep_position(Ns_full,basis_pcon,basis[i])
                                                       ^

quspin/basis/basis_general/_basis_general_core/source/general_basis_core.pyx:128:59: Unable to deduce type parameters for K (const K, I *, const I) noexcept nogil given (npy_intp, uint256_t *, uint256_t &)
Desktop (please complete the following information):

OS: macOS 13.5.2
Python 3.11.5
Python 3.0.0

—
Reply to this email directly, view it on GitHub
https://github.com/QuSpin/QuSpin/issues/642, or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADHSUBVKZNYYKNBGO6NHXGTX3F5GFANCNFSM6AAAAAA46EIOMI
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

There are many plans but very little developer time on our side, so if you
wanna go ahead and fix it we'd be happy to consider a commit into the most
recent development branch.
For some reason cython decided to break backward compatibility...
Marin
On Tue, Sep 19, 2023, 3:44 PM Denis Vasilyev @.***>
wrote:

@mgbukov https://github.com/mgbukov
downgrade cython to 0.29 (see version prereqs online) and it should be
fine.
Thank you, I'll do it.
Are there any plans to support the latest Cython version?
—
Reply to this email directly, view it on GitHub
https://github.com/QuSpin/QuSpin/issues/642#issuecomment-1725574479, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ADHSUBSHALXGUNWB6K4FKVTX3GOT5ANCNFSM6AAAAAA46EIOMI
.
You are receiving this because you were mentioned.Message ID:
@.***>

this should be fixed with quspin 1.0.0


Add temperature support for MH-Z19 CO2 sensor.

Description:
Add temperature support for MH-Z19 CO2 sensor.
Pull request in home-assistant.github.io with documentation (if applicable): home-assistant/home-assistant.github.io#<home-assistant.github.io PR number goes here>
Example entry for configuration.yaml (if applicable):
sensor:
  - platform: mhz19
    serial_device: /dev/ttyAAM0
    monitored_conditions:
    - temperature
    - co2

Checklist:
If user exposed functionality or configuration variables are added/changed:

[ ] Documentation added/updated in home-assistant.github.io

If the code communicates with devices, web services, or third-party tools:

[x] Local tests with tox run successfully. Your PR cannot be merged unless tests pass
[x] New dependencies have been added to the REQUIREMENTS variable
[x] New dependencies are only imported inside functions that use them
[x] New dependencies have been added to requirements_all.txt by running script/gen_requirements_all.py.
[x] New files were added to .coveragerc.

More tests will be added.


NC | CI | Add Versioning tests to nc coretest

Explain the changes

Add test_bucketspace_versioning.js and test_nsfs_versioning.js to nc_index.js.
Add NC_CORETEST changes for test_bucketspace_versioning.js.

Issues: Fixed #xxx / Gap #xxx

Testing Instructions:

Run sudo NC_CORETEST=true node ./node_modules/mocha/bin/mocha src/test/unit_tests/test_bucketspace_versioning.js
sudo ./node_modules/mocha/bin/mocha src/test/unit_tests/test_nsfs_versioning.js

[ ] Doc added/updated
[ ] Tests added

@romayalon In the PR description in the "Testing Instructions" part I think you need to change the command:
sudo ./node_modules/mocha/bin/mocha src/test/unit_tests/test_nsfs_versioning.js
to
sudo NC_CORETEST=true node ./node_modules/mocha/bin/mocha src/test/unit_tests/test_nsfs_versioning.js
(missing env variable of NC_CORETEST and the node command).

@romayalon In the PR description in the "Testing Instructions" part I think you need to change the command: sudo ./node_modules/mocha/bin/mocha src/test/unit_tests/test_nsfs_versioning.js to sudo NC_CORETEST=true node ./node_modules/mocha/bin/mocha src/test/unit_tests/test_nsfs_versioning.js (missing env variable of NC_CORETEST and the node command).

@shirady test_nsfs_versioning.js does not require NC_CORETEST=true, this tests works the same on all environments because it's calling directly to NamespaceFS, it's not doing rpc calls, db interaction etc.

@romayalon does this PR enable the versioning test-cases of ceph s3-tests on nsfs?

@shirady test_nsfs_versioning.js does not require NC_CORETEST=true, this test works the same on all environments because it's calling directly to NamespaceFS, it's not doing rpc calls, db interaction etc.

@romayalon I thought we needed it as long as in the test there is the condition if (is_nc_coretest), because some tests behave differently.

@shirady That's a correct assumption, but there is no if(is_nc_coretest) condition in test_nsfs_versioning.js...


Update zio-streams, zio-test, zio-test-sbt to 1.0.14

Updates

dev.zio:zio-streams
dev.zio:zio-test
dev.zio:zio-test-sbt

from 1.0.13 to 1.0.14.
GitHub Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "dev.zio" } ]

labels: library-update, early-semver-patch, semver-spec-patch, commit-count:1

Superseded by #80.


Add support for SSPI on Windows

This is a great library, we use it for testing client authentication against Kerberized hosts.
It's relatively straightforward to add support for SSPI on windows, I have a proof-of-concept that I've been working on. Would you be interested in a PR to that effect?

Sorry for the late reply. Yeah, absolutely, would love to see a PR with SSPI support.


activate pages to deploy site

maybe this is still needed https://docs.github.com/en/pages/quickstart (bullet 6) so that we can see the site live.

Fixed, thanks!


Docs - Added UI/UX youtube channel link in readme file

Fixes Issue
Closes #16
Description:
Added UI/UX youtube channel link in readme file
Resource URL:
https://www.youtube.com/@Figma/featured
Checklist:
Before submitting your pull request, ensure that you have completed the following tasks:

[x] I have carefully reviewed and adhered to the contributing guidelines before creating this pull request.
[x] I followed the prescribed PR title template. (Check this if you're adding a resource)

Hello @jfmartinz, I've updated it, Please review it.


Prescription.ProductIds is redundant to RxProductLookups

I have preliminarily made RxProductLookup.ProductID required as I do not understand the purpose of an RxProductLookup without a defined Product.   With that change Prescription.ProductIds is redundant information that invites both confusion and mismatch with the the RxProductLookups.
I recommend we remove Prescription.ProductIds or if not, require that implementations must keep these collections in sync.

24 August committee agreement to remove ProductIDs

We removed the concept of Prescriptions when we standardized Operation across document types. See https://github.com/ADAPT/Standard/issues/122.   The concept of RxProductLookup is replaced by ProductId on a Variable within an Operation.


⚠ Bofrost.de has degraded performance

In 7d9cb16, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 1349 ms

Resolved: Bofrost.de performance has improved in a2a437c after 6 minutes.


feature: Load persisted entities

Adds in the ability to load a model from a plugin and create entities from just a persistent id.
Refactored a lot of things in splitting the data models from the entity classes. Tests have been heavily revisited.
BREAKING CHANGES:

All previous usage of coalaip.models is now broken. You shouldn't have been doing stuff directly with it anyways, but the old models are now coalaip.entities instead.
EntityDataError has been renamed to ModelDataError to better reflect the cause of the error

Current coverage is 89.22% (diff: 90.71%)

Merging #31 into master will decrease coverage by 2.35%

@@             master        #31   diff @@
==========================================
  Files             8         11     +3
  Lines           202        362   +160
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
+ Hits            185        323   +138
- Misses           17         39    +22
  Partials          0          0

Powered by Codecov. Last update da0a566...9a6ece5


Add tmpdir_stagger_phase_limit to overrides

This PR adds tmpdir_stagger_phase_limit to TmpOverrides and updates phases_permit_new_job as needed. This allows setting different phase limits for different size/speed drives.
Have been testing this and it works as expected.

Hello, sorry, i'm just trying to understand. at the moment, tmpdir_stagger_phase_limit limits running plots  in all temp dirs not individually.
is that implementation for to use tmpdir_stagger_phase_limit parameter for each tmp directory.?
thanks.

@erdincsk - Yes. The concept is that if you have different drives that are capable of different number of parallel plots, you may want to have a different number in tmpdir_stagger_phase_limit (ideally, all fields would be overridable including the major and minor phases, but this is a start)

commit please

@ericaltendorf - I noticed that I neglected to update the documentation (config template) to reflect this update. Do you want me to update that or are you planning to?

It looks like https://github.com/ericaltendorf/plotman/pull/758 and https://github.com/ericaltendorf/plotman/pull/427 both provide this as well as the other pieces of the phase override so I expect to go with one of them.  I apologize that I have failed to keep up with the community contributions and I do appreciate your effort to make the changes and submit them here.


Component uses _.compose instead of compose-function which is defined in package.json

This is for all 1.x versions;

Fixed in #4


Fixed issue with verification methods

Overview
This fixes https://github.com/TBD54566975/ssi-service/issues/190
Description
Bug fix
How Has This Been Tested?
See added unit tests.
Checklist
Before submitting this PR, please make sure:

[x] I have read the CONTRIBUTING document.
[x] My code is consistent with the rest of the project
[x] I have tagged the relevant reviewers and/or interested parties
[x] I have updated the READMEs and other documentation of affected packages

References
n/a

Codecov Report

Merging #192 (c0e90f7) into main (b2f81b9) will increase coverage by 1.05%.
The diff coverage is 100.00%.

:exclamation: Current head c0e90f7 differs from pull request most recent head dd7f0dc. Consider uploading reports for the commit dd7f0dc to get more accurate results

@@            Coverage Diff             @@
##             main     #192      +/-   ##
==========================================
+ Coverage   24.98%   26.03%   +1.05%
==========================================
  Files          21       21
  Lines        1781     1782       +1
==========================================
+ Hits          445      464      +19
+ Misses       1264     1242      -22
- Partials       72       76       +4

Impacted Files
Coverage Δ

internal/did/access.go
20.21% <100.00%> (+20.21%)
:arrow_up:

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


Use --space with RCC for safe parallellization

Every concurrent execution should use distinct space.
We should have to options:

roundrobin; use spaces carrot-rcc-NN where NN where NN is between 01 and max concurrent executions

robot; use space per robot, use generic names carrot-rcc-NN where NN is the index of the order when the particular robot was loaded; spaces might change on restart, but removal of robots might not always leave unused spaces

  -s, --space string         Client specific name to identify this environment. (default "user")
``

Fixed in https://github.com/datakurre/carrot-rcc/pull/7


signal-desktop: add libappindicator-gtk3

Motivation for this change
electron needs libappindicator-gtk3 library so that it can draw indicators in gnome.
Things done
added indicator and verified it worked on my machine. im also interested in backporting this to 19.09

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[ ] Fits CONTRIBUTING.md.

Notify maintainers
cc @

@GrahamcOfBorg build signal-desktop


A question in request.go

Line 98
func (req *request) RemoteIP() string {
	return strings.Split(req.RemoteAddr(), ":")[1]
}

The RemoteAddr is

<IP_ADDRESS>:61119

and the result RemoteIP() is 61119
is it ture?
or should the mothod be named with RemotePort?

Sorry, it's my mistake.

It should be strings.Split(req.RemoteAddr(), ":")[0]

yep


Allow setting custom values for SpanId, TraceId and ParentId

Currently the enricher sets properties of SpanId TraceId and ParentId but it'd be great if we can override it to what we want to comply with OTEL and OTLP, e.g. trace.span_id trace.trace_id trace.parent_id

Hey @evilpilaf, do you have more info/links about these names that you'd like to rename them to? Are these part of a standard? Should these be the default?
I get that you want to be able to set the names yourself, just wondering if there is some Open Telemetry standard that we should be conforming to.

After a lot of digging because I could not find this info in the official documentation and semantic conventions, I could find that in the .proto file for traces we can see these fields https://github.com/open-telemetry/opentelemetry-proto/blob/main/opentelemetry/proto/trace/v1/trace.proto

Alternatively just the ability to rename them would also be nice. We're using this enricher but it doesn't really place nicely with datadog and it's correlation. Ideally we'd be able to do it on the dd ingest but that doesn't seem to be working so it'd be nice to override the keys used.

Seems reasonable, would take a PR for it.

@RehanSaeed sounds good I'll see if I can work it into our next sprint.

The current names already follow the OpenTelemetry Log Data Model, at least for TraceId and SpanId (ParentId is not specified).

This was released in https://github.com/RehanSaeed/Serilog.Enrichers.Span/releases/tag/2.1.0.


[BugFix][Habana_main][Multistep]Fix multistep deepcopy overhead

Objective:

Observe big performance regression with multi step as 2 or 4 or 8

How:

remove the seq_group_metadata_list deepcopy in first token of the multi-step-batch . Replace with the only necessary copy of output_token_ids. And replay at the last token of multi-step-batch.

Result:

Tested with bs=128, input_token=1024.
The previous 80ms overhead caused by the deepcopy is gone.
1.71x speedup when setting  --num_scheduler_steps 4

BEFORE SUBMITTING, PLEASE READ THE CHECKLIST BELOW AND FILL IN THE DESCRIPTION ABOVE

 PR Checklist (Click to Expand)
Thank you for your contribution to vLLM! Before submitting the pull request, please ensure the PR meets the following criteria. This helps vLLM maintain the code quality and improve the efficiency of the review process.
PR Title and Classification
Only specific types of PRs will be reviewed. The PR title is prefixed appropriately to indicate the type of change. Please use one of the following:

[Bugfix] for bug fixes.
[CI/Build] for build or continuous integration improvements.
[Doc] for documentation fixes and improvements.
[Model] for adding a new model or improving an existing model. Model name should appear in the title.
[Frontend] For changes on the vLLM frontend (e.g., OpenAI API server, LLM class, etc.)
[Kernel] for changes affecting CUDA kernels or other compute kernels.
[Core] for changes in the core vLLM logic (e.g., LLMEngine, AsyncLLMEngine, Scheduler, etc.)
[Hardware][Vendor] for hardware-specific changes. Vendor name should appear in the prefix (e.g., [Hardware][AMD]).
[Misc] for PRs that do not fit the above categories. Please use this sparingly.

Note: If the PR spans more than one category, please include all relevant prefixes.
Code Quality
The PR need to meet the following code quality standards:

We adhere to Google Python style guide and Google C++ style guide.
Pass all linter checks. Please use format.sh to format your code.
The code need to be well-documented to ensure future contributors can easily understand the code.
Include sufficient tests to ensure the project to stay correct and robust. This includes both unit tests and integration tests.
Please add documentation to docs/source/ if the PR modifies the user-facing behaviors of vLLM. It helps vLLM user understand and utilize the new features or changes.

Adding or changing kernels
Each custom kernel needs a schema and one or more implementations to be registered with PyTorch.

Make sure custom ops are registered following PyTorch guidelines: Custom C++ and CUDA Operators and The Custom Operators Manual
Custom operations that return Tensors require meta-functions. Meta-functions should be implemented and registered in python so that dynamic dims can be handled automatically. See above documents for a description of meta-functions.
Use torch.libary.opcheck() to test the function registration and meta-function for any registered ops.  See tests/kernels for examples.
When changing the C++ signature of an existing op, the schema must be updated to reflect the changes.
If a new custom type is needed, see the following document: Custom Class Support in PT2.

Notes for Large Changes
Please keep the changes as concise as possible. For major architectural changes (>500 LOC excluding kernel/data/config/test), we would expect a GitHub issue (RFC) discussing the technical design and justification. Otherwise, we will tag it with rfc-required and might not go through the PR.
What to Expect for the Reviews
The goal of the vLLM team is to be a transparent reviewing machine. We would like to make the review process transparent and efficient and make sure no contributor feel confused or frustrated. However, the vLLM team is small, so we need to prioritize some PRs over others. Here is what you can expect from the review process:

 After the PR is submitted, the PR will be assigned to a reviewer. Every reviewer will pick up the PRs based on their expertise and availability.
 After the PR is assigned, the reviewer will provide status update every 2-3 days. If the PR is not reviewed within 7 days, please feel free to ping the reviewer or the vLLM team.
 After the review, the reviewer will put an  action-required label on the PR if there are changes required. The contributor should address the comments and ping the reviewer to re-review the PR.
 Please respond to all comments within a reasonable time frame. If a comment isn't clear or you disagree with a suggestion, feel free to ask for clarification or discuss the suggestion.

Thank You
 Finally, thank you for taking the time to read these guidelines and for your interest in contributing to vLLM. Your contributions make vLLM a great tool for everyone!

@michalkuligowski @tzielinski-habana, please help to review this PR
Our test scenario is bs=128, input_len=1024, output_len=1024

Previously, with --num_scheduler_steps 4 => we saw performance regression comparing to num_scheduler_steps==1, only gets 64% of throughput.
Apply this fix => we saw no regression and 10% throughput improvement on num_scheduler_steps == 4

BTW, with bigger num_scheduler_steps==64, the original codes are working OK.

PR checked, performance boost is visible. @xuechendi , please rebase the branch and we'll merge it.

@jkaniecki, I have rebased the PR


Travis CI: Add Python 3.7 to the testing

Adds the missing piece from #32
https://docs.travis-ci.com/user/languages/python/#development-releases-support says that Python 3.7 can not be run on Trusty.  Travis support is confirming that the recommended solution.  It is not much of a hack if ipython, jupyter, numpy, matplotlib are all relying on it.
Travis are now recommending removing sudo

Came here to open a PR with the same thing.
If this had been merged, it would have saved me 1 hour of my life :)

Thank you for your PR @cclauss! 🙇


Added "Copy to Clipboard" button to code blocks

@ilopmar could you try on another machine? I did the work on Linux and tested in Firefox, but it works fine in Chrome and also in Chrome and Firefox on Mac. The code is from the user guide (multi-language-sample.js and guide.js) - the only change was the element where the button is added, listingblock instead of multi-language-sample since we only show one language per guide

@ilopmar I see the problem - the page runs differently when you load it with a file:// url than when it's served from a web server. I use livereload (cd build/dist && livereload -p 3000) but any server will work

It should work now, I was using <script /> but it needs to be <script></script>

Yes, now it works. I've tried serving the content with python (sudo python3 -m http.server 80 --directory build/dist) and it didn't work either.


Update camel-atlasmap to use 1.16.0 or newer version

camel-atlasmap needs to be updated to use a more recent version

I tried to update but it seems that the API changed and the method for creating  context with a given mapping has vanished: https://github.com/atlasmap/camel-atlasmap/blob/master/src/main/java/org/apache/camel/component/atlasmap/AtlasEndpoint.java#L185
@mattrpav : Is there any easy workaround this or is now only possible to create the context with an URI or an File ?

I see the following steps to do:

Extend AtlasMappingService to work with JSON (in addition to JAXB) --> https://github.com/atlasmap/atlasmap/issues/146
Extend AtlasContextFactory to take an AltasMapping in its createContext() method
Change every reference from com.mediadriver to io.atlasmap (but there can be changes in other names, too). This also affects the test.

So we need a new version of atlasmap/atlasmap, too (1.18)

merged


test_resolve.cpp fails

I have compiled inside a docker container with G++11. After running the tests, all but a single fail is observed. The test output below:
root@a100cse:/localscratch/senders-io/build/tests# ./test_sio

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
test_sio is a Catch v2.13.6 host application.
Run with -? for options

-------------------------------------------------------------------------------
async::resolve - Resolve ipv4 localhost
-------------------------------------------------------------------------------
/localscratch/senders-io/tests/net/test_resolve.cpp:22
...............................................................................

/localscratch/senders-io/tests/net/test_resolve.cpp:22: FAILED:
due to unexpected exception with message:
  Servname not supported for ai_socktype

===============================================================================
test cases:  87 |  86 passed | 1 failed
assertions: 306 | 305 passed | 1 failed

Interesting. I will look into that.

It might be due to a minimal /etc/services file. Can you post its content here, please? It might be better to change the test from using service "http" to some numerical string such as "80" (or anything else). In fact it might show that an overload is needed without a specified service, since that is a optional for the underlying calls.

/etc/services was missing. apt install netbase fixed the issue. Thanks. I guess docker environments can be really different compared to bare metal Linux installations.

The test just assumed /etc/services to exists which might be bad. I will fix that.


Clicking on a modal window sets height/width to carousel and not to parent component

Deleting this issue as I believe I've found the problem.

Hi @bdesilva-appneta
Can you provide here the solution to your problem.
It seems I have the same issue :(
Thanks


Broken Z2M link for devices with slash / in model name

See the SOHAN Electric RDCBC/Z page for example.
The model name (RDCBC/Z) contains a slash (/), but the Z2M website uses underscore (_) for the sake of not breaking the URL.
This causes the Z2M link to be broken on the Blakadder website:

Current broken URL: https://www.zigbee2mqtt.io/devices/RDCBC/Z.html
Actual Z2M URL: https://www.zigbee2mqtt.io/devices/RDCBC_Z.html

To fix this, I think this website should substitute slashes for underscores on the fly when generating the Z2M URLs.

fixed

Man that was fast.
Kudos for the website!

@blakadder ooops I think it's now broken for a different reason: an extra whitespace before .html

was too fast :D removed the space now

It's working now. Thanks!


Update pysb.integrate.Solver to select odeint if intergrator='lsoda'

Currently we use scipy. integrate.ode , which is a generic wrapper allowing multiple solvers (vode, zvode, lsoda, dopri5, dop853).   It solves the ODEs using
while self.integrator.successful() and self.integrator.t < self.tspan[-1]:
self.y[i] = self.integrator.integrate(self.tspan[i]) # integration
i += 1
There is some overhead in this that can be prevented between calling the fortran code and python. For lsoda, scipy has an lsoda specific solver. (http://docs.scipy.org/doc/scipy-0.15.1/reference/generated/scipy.integrate.odeint.html ). Using this method saves between 10~20%.
I wrote a class to use this. However, if we choose another solver then we cannot use it. Basically I just need to merge them together and check. If integrator == 'lsoda': use this type.
We may want to just use the new simulator class?

Should we close this, or were we still going to look into a cleaner solution. I think Jeremy had an idea about using an inline lambda function which would clean up the two extra wrap functions.

Rewritten using lambda functions in ee20151. Closing the issue.