Cannot Install Package

This definitely is a great package. But cannot install it, can you resolve this
Error:
Updating dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - Installation request for rinvex/categorizable * -> satisfiable by rinvex/categorizable[v0.0.1].
    - rinvex/categorizable v0.0.1 requires rinvex/cacheable dev-develop -> satisfiable by rinvex/cacheable[dev-develop] but these conflict with your requirements or minimum-stability.

@abishekrsrikaanth
Got the same problem.
You'll need to add "minimum-stability": "dev" to your composer.json file before you install the package.

@abishekrsrikaanth
meanwhile, u should also add this line there:
"prefer-stable": true,
which prevent installing a bounch of other dev packages

Yes, it's exactly as @pilishen said.
This package still considered beta and until it's tagged as stable you've to change your minimum stability level, hopefully stable release will be out once Laravel 5.5 officially released 🙂

@abishekrsrikaanth

You'll need to add "minimum-stability": "dev" to your composer.json file before you install the package.

meanwhile, u should also add this line there:
"prefer-stable": true,

added these to composer.json, still cannot install

@besrabasant what's the error message you get?

Problem 1
    - rinvex/categories v0.0.4 requires rinvex/support dev-develop -> satisfiable by rinvex/support[dev-develop].
    - Installation request for rinvex/categories ^0.0.4 -> satisfiable by rinvex/categories[v0.0.4].
    - Conclusion: remove laravel/framework v5.5.40
    - Conclusion: don't install laravel/framework v5.5.40
    - rinvex/support dev-develop requires illuminate/bus ~5.6.0 -> satisfiable by laravel/framework[5.6.x-dev], illuminate/bus[5.6.x-dev, v5.6.0, v5.6.1, v5.6.10, v5.6.11, v5.6.12, v5.6.13, v5.6.14, v5.6.15, v5.6.16, v5.6.17, v5.6.19, v5.6.2, v5.6.20, v5.6.21, v5.6.22, v5.6.23, v5.6.24, v5.6.25, v5.6.26, v5.6.27, v5.6.28, v5.6.3, v5.6.4, v5.6.5, v5.6.6, v5.6.7, v5.6.8, v5.6.9].
    - laravel/framework 5.6.x-dev conflicts with laravel/framework[v5.5.40].
    - don't install illuminate/bus 5.6.x-dev|don't install laravel/framework v5.5.40
    - don't install illuminate/bus v5.6.0|don't install laravel/framework v5.5.40
    - don't install illuminate/bus v5.6.1|don't install laravel/framework v5.5.40
    - don't install illuminate/bus v5.6.10|don't install laravel/framework v5.5.40
    - don't install illuminate/bus v5.6.11|don't install laravel/framework v5.5.40
    - don't install illuminate/bus v5.6.12|don't install laravel/framework v5.5.40
    - don't install illuminate/bus v5.6.13|don't install laravel/framework v5.5.40
    - don't install illuminate/bus v5.6.14|don't install laravel/framework v5.5.40
    - don't install illuminate/bus v5.6.15|don't install laravel/framework v5.5.40
    - don't install illuminate/bus v5.6.16|don't install laravel/framework v5.5.40
    - don't install illuminate/bus v5.6.17|don't install laravel/framework v5.5.40
    - don't install illuminate/bus v5.6.19|don't install laravel/framework v5.5.40
    - don't install illuminate/bus v5.6.2|don't install laravel/framework v5.5.40
    - don't install illuminate/bus v5.6.20|don't install laravel/framework v5.5.40
    - don't install illuminate/bus v5.6.21|don't install laravel/framework v5.5.40
    - don't install illuminate/bus v5.6.22|don't install laravel/framework v5.5.40
    - don't install illuminate/bus v5.6.23|don't install laravel/framework v5.5.40
    - don't install illuminate/bus v5.6.24|don't install laravel/framework v5.5.40
    - don't install illuminate/bus v5.6.25|don't install laravel/framework v5.5.40
    - don't install illuminate/bus v5.6.26|don't install laravel/framework v5.5.40
    - don't install illuminate/bus v5.6.27|don't install laravel/framework v5.5.40
    - don't install illuminate/bus v5.6.28|don't install laravel/framework v5.5.40
    - don't install illuminate/bus v5.6.3|don't install laravel/framework v5.5.40
    - don't install illuminate/bus v5.6.4|don't install laravel/framework v5.5.40
    - don't install illuminate/bus v5.6.5|don't install laravel/framework v5.5.40
    - don't install illuminate/bus v5.6.6|don't install laravel/framework v5.5.40
    - don't install illuminate/bus v5.6.7|don't install laravel/framework v5.5.40
    - don't install illuminate/bus v5.6.8|don't install laravel/framework v5.5.40
    - don't install illuminate/bus v5.6.9|don't install laravel/framework v5.5.40
    - Installation request for laravel/framework (locked at v5.5.40, required as 5.5.*) -> satisfiable by laravel/framework[v5.5.40].

OK, now it's clear. This package requires Laravel v5.6.0 but you're trying to install it on v5.5.0, that's why you're getting this error message.

I tried this even with 0.0.3 and i get the same error

I'm sure you got a different error, but anyway since we don't support old releases and this package still considered in development, you can fork it and change composer.json to whatever suites your needs, and install it from your own custom repo. Hope this helps..


pushing v.0.0.19

Codecov Report

:exclamation: No coverage uploaded for pull request base (main@4f6c920). Click here to learn what that means.
Patch has no changes to coverable lines.

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #561   +/-   ##
=======================================
  Coverage        ?   60.02%
=======================================
  Files           ?       26
  Lines           ?     2809
  Branches        ?        0
=======================================
  Hits            ?     1686
  Misses          ?     1123
  Partials        ?        0

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

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


Enhancement: Out-of-box support for creating host L2 bridge network adapter

Enhancement description
In my use of LXD, I want virtual machines connected directly to my physical network, rather than a separate NAT'd network that only the LXD host is bound to. I need to self-host services running on LXD VMs so that other devices on my network have immediate access to them.
Current State
Right now, when I set up LXD on a new host, I have to manually:

Create a L2 bridge interface with Network Manager
Associate the L2 bridge adapter with the host's physical network interface
Create a separate LXD profile that connects VMs to the host bridge interface

Create host bridge interface: https://www.ubuntupit.com/how-to-configure-and-use-network-bridge-in-ubuntu-linux/
Create LXD profile: https://blog.simos.info/how-to-make-your-lxd-containers-get-ip-addresses-from-your-lan-using-a-bridge/
Proposal
During the lxd init phase, provide an option to the user to automatically create a virtual L2 bridge network adapter on the host, instead of creating the internal bridge network. The default LXD profile should connect new VMs to the host's L2 bridge.
 Physical Network (<IP_ADDRESS>/16)
┌───────────────────────────┐
│                           │
│                           │
│                           │
└───────────────────────────┘
             ▲            ▲
             │            │
             │            │
 LXD Host    │            │
┌────────────┼────────────┼────┐
│            │            │    │
│  ┌───────┐ │  ┌───────┐ │    │
│  │       │ │  │       │ │    │
│  │ VM01  ├─┘  │  VM02 ├─┘    │
│  │       │    │       │      │
│  └───────┘    └───────┘      │
│  <IP_ADDRESS>   <IP_ADDRESS>      │
└──────────────────────────────┘
 <IP_ADDRESS>

If you already have a working bridge in your host then you can tell lxd init to use it instead of creating the typical lxdbr0 that isn't connected to any external device.
# lxd init
...
Would you like to create a new local network bridge? (yes/no) [default=yes]: no
Would you like to configure LXD to use an existing bridge or host interface? (yes/no) [default=no]: yes
Name of the existing bridge or host interface: <my-own-bridge>
...

That way, your default profile should already have the right bridge configured. Please let us know if the above doesn't work for you.

Yeah, I was thinking it would be nice to automate the setup of the bridge interface on the host as well though. I always have to go lookup the Netplan documentation to figure it out as a separate step, figure out the correct YAML syntax, etc. @simondeziel
Maybe it's outside the scope of LXD, but since the init process is already well streamlined, I thought this would be a nice addition.

LXD already allows you to create a bridge, the part that it doesn't deal with is the NIC to use as external interface. That last part is indeed outside the scope for LXD.

You can set bridge.external_interfaces on the bridge, although its important that you disable DHCP on the managed network so it doesn't start providing DHCP to the external network.
Also worth keeping in mind that any IP addresses on the external interface will need to be removed and will become inoperable.
This can cause network disconnects if logged in remotely, so is why we are somewhat cautious in automating that too much.
https://linuxcontainers.org/lxd/docs/master/reference/network_bridge/
Also, if you dont need the instances to communicate with the LXD host, then you can use macvlan NIC directly connected to the external interface without the need for a bridge.
See https://linuxcontainers.org/lxd/docs/master/reference/devices_nic/#nic-macvlan

To expand on what Tom said, you can have your lxdbr0 network hooked to your physical network by doing:
# Use the physical network and the DHCP/DNS server that come with it
lxc network set lxdbr0 bridge.external_interfaces=<available NIC>  # hook it to the physical network
lxc network set lxdbr0 ipv4.address=none ipv6.address=none  # remove IPs
lxc network set lxdbr0 ipv4.firewall=false ipv6.firewall=false  # disable firewalling
lxc network set lxdbr0 dns.mode=none  # disable DNS

That would cause the host to drop off the network though as the IPs on the external interface would become inoperable.
I guess the IP settings would need to be populated with the values from the external interface, and then setting ipv4.dhcp=false.


[SDL2]: iconification bug #1: missing iconify gadget after we switch from fullscreen to window mode via alt+enter / SDL_SetWindowFullscreen()

When you run sdl2 app in window mode it have iconification gadget all fine. But then, when you switch to fullscreen (via SDL_SetWindowFullscreen() ), and then back to the window via the same SDL_SetWindowFullscreen(), then iconify gadget disappear. Like code which re-create window forgot to add iconification gadget as it done when window firstly created.
Just running as default in fullscreen and then switch back to window cause same effect.

Fixed, thanks


test(atomic): skip quickview cypress tests

https://coveord.atlassian.net/browse/KIT-3651
Did some manual tests and everything works fine..
cypress is randomly failing 1 to 3 tests in that suite. I think it is best to skip it and then rewrite in playwright another time.

It is still failing randomly. Might be some sort of throttling honestly.


3d text animation

To create an issue, edit this template to fill your details as well as describe your issue and then post it.
add 'x' to the relevant to define you

[ ] Hacktoberfest Participant
[ ] Contributor

I would like to add 3d text animations
Additional context
Add any other context or screenshots about the feature request here.

pls go ahead


[KOGITO-8401] Add a brief introduction to Kogito SW capabilities in the home page

Signed-off-by: Ricardo Zanini<EMAIL_ADDRESS>
JIRA: https://issues.redhat.com/browse/KOGITO-8401

Description: Brief introduction explaining the potential usage of Kogito SW in the cards.

Please make sure that your PR meets the following requirements:

[x] You have read the contributions doc
[x] Pull Request title is properly formatted: KOGITO-XYZ Subject
[x] Pull Request title contains the target branch if not targeting main: [0.9.x] KOGITO-XYZ Subject
[x] The nav.adoc file has a link to this guide in the proper category
[x] The index.adoc file has a card to this guide in the proper category, with a meaningful description

How to backport a pull request to a different branch?

In order to automatically create a backporting pull request please add one or more labels having the following format backport-<branch-name>, where <branch-name> is the name of the branch where the pull request must be backported to (e.g., backport-7.67.x to backport the original PR to the 7.67.x branch).

NOTE: backporting is an action aiming to move a change (usually a commit) from a branch (usually the main one) to another one, which is generally referring to a still maintained release branch. Keeping it simple: it is about to move a specific change or a set of them from one branch to another.

Once the original pull request is successfully merged, the automated action will create one backporting pull request per each label (with the previous format) that has been added.
If something goes wrong, the author will be notified and at this point a manual backporting is needed.

NOTE: this automated backporting is triggered whenever a pull request on main branch is labeled or closed, but both conditions must be satisfied to get the new PR created.

Don't we want {product_name} {context} instead of {product_name} we are using only a part of Kogito.

The problem is that product_name and context are "OpenShift Serverless Logic" downstream. @kaldesai wdyt? I believe we need to review those.

@MarianMacik @radtriste do you mind taking a final look? Can merge if it's fine.


Fix Permissions issue for spot instances

Pods are not getting scheduled due to permissions issues  below
controller.provisioner launching machine, creating cloud provider instance, with fleet error(s), AuthFailure.ServiceLinkedRoleCreationNotPermitted: The provided credentials do not have permission to create the service-linked role for EC2 Spot Instances.
Description

Motivation and Context

Pods not getting scheduled due to permissions issue

Breaking Changes

How Has This Been Tested?

[ X] I have updated at least one of the examples/* to demonstrate and validate my change(s)
[ ] I have tested and validated these changes using one or more of the provided examples/* projects

[ ] I have executed pre-commit run -a on my pull request

yes, this can be rather frustrating. however, we can't add this here because there are a number of users which will have this role already in their account and that would cause a conflict. Whenever a service linked role is involved, its best to refer to the documentation for that one time creation event


GD-271: C# - Add AssertSignal to verify on Godot signals

Description
Add missing support to verify on Godot signals
https://mikeschulze.github.io/gdUnit3/asserts/assert-signal/
Acceptance criteria

AssertSignal()

moved to https://github.com/MikeSchulze/gdUnit3Mono/issues/11


Update storage-network-security.md

@tamram : Thanks for your contribution! The author(s) have been notified to review your proposed change. @santoshc


Change login handling to make it easier to disable login for testing

tested on stage, login working correctly with oauth and for admins

trigger build

@mahendra I looked into the django auth middleware a little more and it seems like it serves a different use case than what we want (it adds a user attribute to http requests, but then you still have to require them to login separately).
I'm not too concerned about config mistakes causing the site to not require login because the default case (no additions to settings.py) requires users to log in everywhere, and we'd use this. So to disable login pages someone would have to add LOGIN_EXEMPT_URLS to settings.py, which couldn't really happen by accident like deleting/changing a config could.
Lmk if this is ok, I want to merge this before getting started on ES because it makes testing a lot less frustrating

@mahendra changed to use new decorator like we talked about yesterday


[macOS] invalid subscript '_ShadowCoord' at […] XSVert.cginc(23) (on glcore)

I get magenta for example material: /XSToon 2.0 _ Carbon Fiber.mat
I get what appears to be a working shader for example material: /XSToon 2.0.mat
Shader error in 'Xiexe/Toon2.0/XSToon2.0': invalid subscript '_ShadowCoord' at assets/Xiexes-Unity-Shaders-master/Main/CGIncludes/XSVert.cginc(23) (on glcore)

Compiling Vertex program with UNITY_PASS_FORWARDBASE DIRECTIONAL SHADOWS_SHADOWMASK LIGHTPROBE_SH
Platform defines: UNITY_ENABLE_REFLECTION_BUFFERS UNITY_USE_DITHER_MASK_FOR_ALPHABLENDED_SHADOWS UNITY_PBS_USE_BRDF1 UNITY_SPECCUBE_BOX_PROJECTION UNITY_SPECCUBE_BLENDING UNITY_ENABLE_DETAIL_NORMALMAP SHADER_API_DESKTOP UNITY_LIGHT_PROBE_PROXY_VOLUME UNITY_LIGHTMAP_RGBM_ENCODING

😀 If it's reasonable to fix, that would be nifty!

Updated to the development branch and things seem fine now.


Remove the rest of parts which use tryCatch

This is the list of them which we may be able to remove using tryCatch from:

[ ] BoundCallbackObservable
[ ] BoundNodeCallbackObservable
[ ] AjaxObservable
[ ] WebSocketSubject
[ ] DeferObservable (#1393, by #1484)
[ ] FromEventObservable
[ ] FromEventPatternObservable (#1397)
[ ] IteratorObservable
[ ] bufferToggle
[ ] bufferWhen
[ ] distinctUntilChanged
[ ] expand
[ ] inspect
[ ] mergeScan
[ ] retryWhen
[ ] windowToggle
[ ] windowWhen
[x] forEach (by #1434)
[ ] Subscription (#1389)

@saneyuki ... I'd like to hold off on these sorts of changes for the time being. We can make these non-breaking changes even after we've pushed out the production release. Right now, I'd like to focus everyone's effort on more critical, possibly breaking changes to RxJS before the 5.0.0 production release.
As such, I'm going to close this issue for now. We can revisit it as time allows. It's definitely something that is on my mind.
Of course, I'll never turn away a PR to improve the performance of the library, and everyone's time here is voluntary. So feel free to work on whatever makes you happy. I just need to prioritize PRs that are more critical to the production release.

Also, FWIW: There is some talk about possibly creating a more unified strategy for this that is still efficient. Something that we can use a Babel transform here at Netflix to remove the try/catching entirely for a Node/Panic-mode type build for Node.js server use. That means work around this might change again.

@blesh Okay. Rather, it was peace of mind that did not become a release blocker.


Potential bug with refresh in IE 8/9 at zoom level 10 or higher

User has CartoDB.JS map with 4 SQL sublayers
He writes "when zoom level is higher than 10 the map does not refresh after I set the sql using thelayer.getSubLayer(0).setSQL method."
He is not experiencing these issues in any other browsers, only IE.
He also has indicated that when he removes the 4th sublayer the map behaves perfectly.
Let me know if having his code would help and I can send it. I haven't IE so I can't reproduce the issue, and a screenshot from the user wouldn't really illustrate anything except the map staying the same.

It seems this is due to browsers like 8-10 blocking long get requests


fix API>=21 cookieManager not call flush()

fix API>=21 cookieManager not call flush()

@xialei92 is this still related? What is your solution different in behaviour than this commit? https://github.com/facebook/react-native/commit/b01ac3bffea0180002439a15e3ecf435e34dd0fe (connected PR https://github.com/facebook/react-native/pull/19770)


[Feature Request] Specify order of function argument evaluation

Is there support for evaluating function arguments in a developer-specified order?
Here's a quick example of a function I'm trying to write (the goal is to use the nice runtime shape checking of the jaxtyping library). This code currently breaks because a is typechecked before b - the symbolic expression T+1 cannot be evaluated before knowing T.
import jax.numpy as jnp
from jaxtyping import Float, Array, jaxtyped
from beartype import beartype as typechecked

@jaxtyped
@typechecked
def ideal_fn(a: Float[Array, "T+1"], b: Float[Array, "T"]) -> Float[Array, ""]:
    return jnp.sum(a**2) + jnp.sum(b**2)

a = jnp.ones(3)
b = jnp.ones(2)
ideal_fn(a, b)
>>> NameError: Cannot process symbolic dimension ...

Due to various constraints, I can't necessarily reverse the order of a and b, or redefine the symbolic expression in terms of Tp1. Based on the issue I raised in jaxtyping, it seems like the order arguments are evaluated is determined by beartype.
The proposed solution would look something like this:
from functools import partial
@jaxtyped
@partial(typechecked, eval_order=(1, 0))
def improved_fn(a: Float[Array, "T+1"], b: Float[Array, "T"]) -> Float[Array, ""]:
    return jnp.sum(a**2) + jnp.sum(b**2)

I understand this is probably a unique edge case, but it would be nice to have if this doesn't already exist. Thanks! 😀

Fascinating. Indeed, this is a unique (but valuable!) edge case. Since Python guarantees parameter names to be unique across callable signatures, allow me to counter-propose a slightly more readable, rigorous, and robust solution that remains semantically equivalent to your proposed @functools.partial(..., *, eval_order: Optional[Tuple[int]] = None) solution.
Behold! @beartype Presents: @beartype(..., *, args: Optional[Iterable[str]] = None):
import jax.numpy as jnp
from beartype import beartype
from jaxtyping import Float, Array, jaxtyped

@jaxtyped
@beartype(args=('b', 'a'))
def improved_fn(a: Float[Array, "T+1"], b: Float[Array, "T"]) -> Float[Array, ""]:
    return jnp.sum(a**2) + jnp.sum(b**2)

@beartype's new keyword-only optional args parameter then offers fine-grained control over parameter type-checking. This parameter is intentionally not named eval_order, arg_order, or something similar. Why? Because I am curmudgeonly. Also, because this parameter doesn't just control ordering. It does control ordering... and more! This parameter serves a dual purpose. Prepare for minds to be blown:

Explicit whitelisting. @beartype will only type-check parameters listed in this iterable. Equivalently, @beartype will avoid type-checking parameters not listed in this iterable. Currently, @beartype unconditionally type-checks all annotated parameters – whether you want it to or not.
Explicit ordering. @beartype will type-check parameters in the order listed in this iterable. Currently, @beartype unconditionally type-checks parameters in declaration order – whether you want it to or not. You don't. Thus, sadness.

Flex those QA biceps, JAX-fuelled bear bros. :muscle: :bear:

This is an awesome solution, I love it!
Much more elegant than what I proposed 🚀

@leycec hate to be negative, but I really think this kind of approaches are 'hacks' on top of what beartype currently supports...
In the long run, I would love plum (and therefore beartype) to have proper support for type parameters. Unfortunately this would be pretty massive because beartype currently processes arguments one by one, but for proper type checking one would have to process them in a single batch in the 'proper' manne (whatever that means).
I'm starting to think about what plum requires, but if beartype requires it as well we could have a chat about where to go from here in the future..

@PhilipVinc: ...heh. You're not wrong, of course. Beartype and Plum both would strongly benefit from full-blown TypeVar support – especially with Python 3.12 going all-in on implicit TypeVar instantiation, which now hides everything under a shiny layer of syntactic sugar: e.g.,
# I can't believe this is now a thing. But... this is now a thing.
def muh_func[T: str](muh_arg: list[T]) -> T: ....  # <--- woah

Relatedly, I just posted @beartype's official roadmap for the 2023–2024 season. In this roadmap, I've tentatively slated deep type-checking of TypeVar for Spring (or Summer at the latest), 2024. Admittedly, that's not great.
If you'd like to make that greater, I'd love to receive your amazing help with a series of PRs. I know how much you've already done for Plum and you seem dangerously keen for it. Wonderful! Simply wonderful!
I'd be delighted to brutally force gently guide you through exactly what would need to be done in the @beartype codebase – and where. If you're still dangerously keen, let's traipse over to open issue #236 (i.e., "Type-stable callable declarations").
We Now Return to Your Regularly Scheduled Issue
</ahem>
Apologies for the diversion, @alexoshin. I'm pretty sure (but not entirely sure) that @jaxtyping symbolic expressions are another beast entirely from your garden-variety typing.TypeVar type variables. They're not actually type variables. They only superficially resemble type variables: e.g.,
# I have no idea what is going on here. But I *like* it.
def ideal_fn(a: Float[Array, "T+1"], b: Float[Array, "T"]) -> Float[Array, ""]:  # <-- woah

For one, you can friggin add jaxtyping symbolic expressions. You also don't need to define them anywhere. You definitely cannot add typing.TypeVar objects together. You also need to define them somewhere. Like, what does T+1 even mean? I have no idea, because I am dumb.
What I'm trying to say, @PhilipVinc, is that this issue is (...probably) orthogonal to your justifiable interest in standard typing.TypeVar objects. Maybe. Possibly. Actually, I have no idea. This is so far above my pay grade that I'm no longer even in the conversation. To quote Trudy Chacon from Avatar:

"I didn't sign up for this [insert-adult-expletive-here]."

@patrick-kidger: I summon thee to do mighty battle with my ignorance. Is my proposed solution above something that jaxtyping might fine useful? If so, I promise to eventually think about eventually doing something. :smile_cat:

@patrick-kidger: I summon thee to do mighty battle with my ignorance

Fee fi fo fum, who disturbs my slumber?
So first of all, yup, what you've written is definitely something jaxtyping would find useful.
The only thing I might add is also handling the return type in the same unified way. In principle someone might have something like
def foo(x: Float[Array, "T+1"]) -> Float[Array, "T"]:

for which T+1 can only be evaluated after T is known. Of course using this would mean we don't run any argument type checking before the function is called. That's less than ideal, so we could also just declare that the above is weird and unsupported.

To explain what jaxtyping is doing under the hood here, by the way, just so that things seem less magical: if the string is valid as an identifier, e.g. T, and isn't yet bound to value, then we run e.g. (T,) = b.shape. This asserts both that len(b.shape) == 1 and sets T = b.shape[0]. Otherwise, we run e.g. assert (T+1,) == a.shape, i.e. require that there be a previously-bound value of T, and assert that len(a.shape) == 1 and a.shape[0] == T + 1.
Arbitrary Python is allowed in these symbolic expressions; we just eval it.
This is why jaxtyping doesn't need you to declare variables in advance, and why you can just do arbitrary symbolic things. It's basically an imperative API secretly masquerading as a declarative API. This is all just for ease-of-implementation reasons, so that I'm not trying to write general constraint-solving algorithms.

Fascinating question @alexoshin! This is awfully close to the problem of typechecking full-blown dependent types. You can imagine the typevar T as an "implicit" parameter of the function at the value-level.
I'm not sure who's implementing the support for non-atomic mathematical expressions in types (@leycec or @patrick-kidger or someone else entirely), but I would like to (A) congratulate them on their efforts 🎉 , and (B) warn them to be careful, lol.
I implemented this flavor of "algebraic" shape-checking for tensors (allowing arbitrary order of parameters) very poorly, long ago, using sympy. Note that the general problem is basically the problem of SMT, and is (possibly?) undecidable.
I would recommend building a working system for atomic typevars first, and then experimenting with expressions, it's a very hairy problem.
On the subject of allowing arbitrary parameter evaluation order: well I can only offer up the standard approach that is taken in the denotative world, which is to think carefully about the order in which parameters are defined. In python it doesn't matter so much what order your parameters are in, but in a language that supports currying it matters a ton, and you can often derive massive simplifications of code from swapping two arguments around. If the other parts of your program are designed so that you can't put the parameters in the order you want, perhaps that is just an indication that a refactor is needed to "line things up nicely".


Error: Cannot find module '@actions/core'

This is an issue when we try to publish our latest policy updates.
Our best guess is that it is related to last commit by @tauhid621. See more info in below image:

Can confirm, same issue here since this PR #56

Previous commit works as expected
uses: azure/manage-azure-policy@c693881e3b39a41eadc4b74de0ab032a73eeab3b

Latest commit
uses: azure/manage-azure-policy@v0
Fails with
Error: Cannot find module '@actions/core'

Updated the v0 tag.
No idea how my commit broke things as the tag was not updated.

@tauhid621
I receive Error while deploying policies on v0, works good on @c693881e3b39a41eadc4b74de0ab032a73eeab3b. Don't know if it is related.
Run azure/manage-azure-policy@v0
  with:
    paths: config-files/policy/policies/**
  config-files/policy/initiatives/**

  env:
    User: ***
    Password: ***
    TenantId: ***
----------------------------------------------------------------------------------------------------
Error : Error occurred while fetching policies from Azure.
----------------------------------------------------------------------------------------------------
Error: Error while deploying policies.

@sbugalski This can be related to https://github.com/Azure/manage-azure-policy/pull/56
Is there some error while fetching policies?

Fixed in #63


LD_LIBRARY_PATH not correctly set for executors

I am running mesos 0.24.0 with Marathon 0.10.1 on CoreOS 808.0.0.
Mesos is built with the prefix /opt/test/mesos/. On my CoreOS nodes, mesos is also deployed to /opt/test/mesos.
My mesos slaves are started using systemd and the systemd unit files sets the environment variable: LD_LIBRARY_PATH=/opt/test/mesos/lib.
In addition, I am also starting my mesos-slaves with the executor_environment_variable flag: --executor_environment_variables='{"LD_LIBRARY_PATH": "/opt/test/mesos/lib"}'.
When starting the scheduler using Marathon, I also set the LD_LIBRARY_PATH environment variable to /opt/test/mesos/lib.
The scheduler starts fine. However, when it attempts to start the executor (journal node in my case), it fails because it is unable to load a shared library.
If I inspect stdout, it is apparent that the LD_LIBRARY_PATH environment variables I have set is not used:
HADOOP_DATANODE_OPTS=-Xmx512m -Xms512m
MESOS_DIRECTORY=/tmp/mesos/slaves/20150920-091313-169978048-5050-1315-S1/frameworks/20150920-091313-169978048-5050-1315-0001/executors/executor.journalnode.NodeExecutor.1442742836789/runs/c2241168-e8de-472f-abad-3749262b99b5
LD_LIBRARY_PATH=/usr/local/lib
MESOS_EXECUTOR_ID=executor.journalnode.NodeExecutor.1442742836789
HADOOP_HEAPSIZE=512
PATH=/opt/test/java/bin:/usr/sbin:/usr/bin
PWD=/tmp/mesos/slaves/20150920-091313-169978048-5050-1315-S1/frameworks/20150920-091313-169978048-5050-1315-0001/executors/executor.journalnode.NodeExecutor.1442742836789/runs/c2241168-e8de-472f-abad-3749262b99b5
JAVA_HOME=/tmp/mesos/slaves/20150920-091313-169978048-5050-1315-S1/frameworks/20150920-091313-169978048-5050-1315-0001/executors/executor.journalnode.NodeExecutor.1442742836789/runs/c2241168-e8de-472f-abad-3749262b99b5/jre1.7.0_76
MESOS_NATIVE_LIBRARY=/opt/test/mesos/lib/libmesos-0.24.0.so
HADOOP_OPTS=-XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled -XX:+UseTLAB -XX:+AggressiveOpts -XX:+UseCompressedOops -XX:+UseFastEmptyMethods -XX:+UseFastAccessorMethods -Xss256k -XX:+AlwaysPreTouch -XX:+UseParNewGC -Djava.library.path=/usr/lib:/usr/local/lib:lib/native
MESOS_SLAVE_PID=slave(1)@<IP_ADDRESS>:5051
MESOS_FRAMEWORK_ID=20150920-091313-169978048-5050-1315-0001
MESOS_CHECKPOINT=1
EXECUTOR_OPTS=-Xmx256m -Xms256m
SHLVL=1
LIBPROCESS_PORT=0
HADOOP_NAMENODE_OPTS=-Xmx512m -Xms512m
MESOS_SLAVE_ID=20150920-091313-169978048-5050-1315-S1
MESOS_RECOVERY_TIMEOUT=15mins
_=/usr/bin/env
Warning: MESOS_NATIVE_LIBRARY is deprecated, use MESOS_NATIVE_JAVA_LIBRARY instead. Future releases will not support JNI bindings via MESOS_NATIVE_LIBRARY.

For some reason, the executor is still using /usr/local/lib as its LD_LIBRARY_PATH rather than /opt/test/mesos/lib.

This is a configuration value. Please set this up in your mesos-site.xml configuration before compiling, https://github.com/mesosphere/hdfs/blob/master/conf/mesos-site.xml#L83.

I do have mesos.native.library pointing to the right place: /opt/test/mesos/lib/libmesos.so, but the problem is that it's not reading the value I have assigned to LD_LIBRARY_PATH and is having trouble loading shared libraries like libsasl2.so.

Please set mesos-site.xml prior to compiling it so it is propagated to the executors. hdfs-site.xml is propagated to executors if you configure this at runtime, but not mesos-site.xml as described in the readme. We do plan on implementing this for meso-site.xml along with other configuration improvements as part of our roadmap.

Adding the following entry to mesos-site.xml and recompiling fixed it for me:
<property>
    <name>mesos.hdfs.ld-library-path</name>
    <value>/opt/test/mesos/lib</value>
  </property>


'Request Time Out' issue in Xamarin.iOS

Xamarin.Auth Issue
I have implemented Xamarin.Auth <IP_ADDRESS> version. It is working find in Android but Getting 'Request Time Out' issue with iOS.
IF BUG, INCLUDE THIS PART:
Version

[ ] nuget version = <IP_ADDRESS>85

Platform:

[] mono version = Mono <IP_ADDRESS> (2018-06/b63e5378e38) (64-bit)

Expected behaviour
This should redirect to Facebook login page
Actual behaviour
https://plus.google.com/u/0/photos/albums/puiqs2ovnc2dlev86q5ubse61gtridtj7?pid=6656735587731708178&oid=115348344533077084425

was this resolved? We're experiencing a similar issue.


File confusion

In the documentation both sip_custom.conf and pjsip_custom.conf are referred to. this is causing confusion when configuring.

There is a new central wiki/docs called SIP-HASS docs. Removed the old wiki and updated the links. So should be good now. :slightly_smiling_face:


Overplapping items

When I use data from a parent component or a photo without a precisely set height, the items overlap. If I change the width of the window, the height will be recalculated and everything will fall into place

@kanopa Thanks for reporting this issue! Any chance you could provide a minimal repo so I can reproduce the issue and see what needs to be fixed specifically? Thanks in advance 😊

@dennisameling thanks for answer
stackblitz - https://stackblitz.com/edit/angular-ivy-zjjy9b
Elements are overlaid if you do not set the exact height for them, in the example this is a description and a photos

@kanopa Thanks for reporting back, hope I'll have some time to check in the coming days. To be continued 😊

Though not 100% identical to your error - but I can confirm that there - have been changes to muuri > 0.8.0. that are affecting layout.
I have notices in "some instances" that the layout does not build nicely anymore in muuri 0.9.0...
@cwqt - if you revert muuri back to 0.8.0 => does this correct your issue..?

While Muuri 0.9.2 has some fixes for overlapping items, it's not perfect. I still noticed items overlapping after updating, but that fixes itself when I resize my browser window.
As a workaround for now, I added a force refresh using this.tileGrid.refresh() in the MuuriGridItemDirective. Just released a new version 0.0.6 with this fix. Could you check if that resolves your issue @kanopa?

yes refresh items fix this. thank you

Great, thanks for reporting back! I'll close this issue for now. If this issue comes up again, feel free to re-open or create a new issue 😊


Overriden methods not instrumented by JQF

When fuzzing an @Override method using JQF, the coverage reported by JQF does not include the code in the method - A.foo in the example below.
However, when fuzzing a non-overridden replica of the above method (i.e, everything else is exactly the same except that this method is not an @Override method) in the same class, the reported coverage does include all the code within the method - A.foo1 in the example below.
It looks like JQF does not instrument @Override methods.
public interface B {
    public int foo(int i);
}

public class A implements B {

    @Override
    public int foo(int i) {

	int j;

	if(i%2==0)
		j = i*2;
	else if(i%3==0)
		j = i/3;
	else
		j = i*4;
	return j;

    }

    public int foo1(int i) {

	int j;

	if(i%2==0)
		j = i*2;
	else if(i%3==0)
		j = i/3;
	else
		j = i*4;
	return j;

    }
}

Thanks for the report! This is interesting. I'll come back to this issue
after the year-end holidays.
On Tue, Dec 14, 2021, 6:00 PM Chaitra Niddodi @.***>
wrote:

When fuzzing an @.*** https://github.com/OverRide" method using
JQF, it was seen that the coverage reported by JQF does not include the
code in the method.
However, when fuzzing a non-overridden replica of the above method (i.e,
everything else is exactly the same except that this method is not an "
@OverRide https://github.com/OverRide" method) in the same class, the
reported coverage does include all the code within the method.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/rohanpadhye/JQF/issues/167, or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABAJQMRTVLI7YLDKBCK7FZTUQ7D7VANCNFSM5KCFFV3Q
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

I tried replicating your issue but was not successful. I'm using branch jqf-issue-167 in the jqf-zest-example repo.
Steps to set up:
git clone https://github.com/rohanpadhye/jqf-zest-example.git --branch jqf-issue-167
cd jqf-zest-example
mvn test-compile

Then fuzz both the test methods:
mvn jqf:fuzz -Dclass=examples.OverrideTest -Dmethod=testFoo -DrandomSeed=42 -Dtrials=1000
mvn jqf:fuzz -Dclass=examples.OverrideTest -Dmethod=testFoo1 -DrandomSeed=42 -Dtrials=1000

In both cases, I see 7 branches being covered, as expected. There is no difference between the overridden method and the non-overriden method.
Is there some additional context required to reproduce the issue? Feel free to file a PR on that branch to demonstrate the issue so that I can replicate it.

We ran into this issue while using JQF version 1.7 with a larger Gradle based java project that has SQLite database and other dependencies (not in the small example posted to explain the concept).
We were able to resolve the issue by making the method being fuzzed a non-overridden one. We did not make any other changes.
So, the issue looks to be related to the override feature.

Hmm. Without an example to reproduce it, there is no way for me to debug it. It could be related to something else (e.g. the superclass not being instrumented). Thanks for the report, though; I'll keep it in mind if it comes up again.


ServersList not working

After the latest update it seems that the theme is straight up ignored

seems to at least be working now but the images are not scaled:

is there anything planned to fix or just leaving it as is?

I can't seem to reproduce this result
Are you on discord stable?

I can't seem to reproduce this result Are you on discord stable?

yes, has been like this since the update before I created the issue

I don't know what to tell you, the snippet is working fine for me since I updated it 2 weeks ago

I don't know what to tell you, the snippet is working fine for me since I updated it 2 weeks ago

I've tried in web, discord client, new client, other browser, it's always like this:

the image is always cut out at half and the server button is pressable only on the image

I have no other themes, so yeah I don't know what to tell you I've reporduced this every time I tried using the snippet

it seems that the height propriety does not actually resize anything besides the container
--guild-list-height: 24px;

I see, I will take a look at it later. Tbh, this snippet is already held by hopes and dreams, so I might just cut it out completely


SINGA-100  Implement layers using CUDNN for GPU training

Support training with CUDNN on single or multiple GPU cards in one machine.
To test it,

cp Makefile.gpu Makefile
update the HOME_DIR, CUDA_DIR, CUDNN_DIR
make singa
./bin/singa-run.sh -conf example/cifar10/cudnn.conf

You can run with multiple cards, e.g.,
nworkers_per_group: 2
nworkers_per_procs: 2

@xiezl please help update the Makefile.am to enable compilation for cudnn related code.
e.g.,
./configure --enable-cudnn --with-cudnn=   --enable-cuda --with-cuda=
which would add -DUSE_CUDNN into the compilation flags.
The cudnn version we used is v3, and the cuda version is v7.5

[UPDATE] Test steps

./autogen.sh
./configure --enable-cuda --with-cuda=<path to cuda folder, e.g., /usr/local/cuda> --enable-cudnn --with-cudnn=<path to cudnn folder, e.g., /home/bob/cudnn>
make
make test
./bin/singa-run.sh -conf examples/cifar10/cudnn.conf

the accuracy should reach 0.81xx finally.

Configuring without cudnn and cuda, I got the following warning during make,
CXX      src/proto/libsinga_la-singa.pb.lo
:0:9: warning: ISO C99 requires whitespace after the macro name
CXX      src/proto/libsinga_la-job.pb.lo
:0:9: warning: ISO C99 requires whitespace after the macro name
CXX      src/proto/libsinga_la-common.pb.lo
:0:9: warning: ISO C99 requires whitespace after the macro name
CXX      src/libsinga_la-driver.lo
:0:9: warning: ISO C99 requires whitespace after the macro name
CXX      src/libsinga_la-server.lo
:0:9: warning: ISO C99 requires whitespace after the macro name
CXX      src/libsinga_la-worker.lo
:0:9: warning: ISO C99 requires whitespace after the macro name
CXX      src/libsinga_la-stub.lo
:0:9: warning: ISO C99 requires whitespace after the macro name
CXX      src/neuralnet/libsinga_la-layer.lo
:0:9: warning: ISO C99 requires whitespace after the macro name
CXX      src/neuralnet/connection_layer/libsinga_la-bridge.lo
:0:9: warning: ISO C99 requires whitespace after the macro name
CXX      src/neuralnet/connection_layer/libsinga_la-concate.lo
:0:9: warning: ISO C99 requires whitespace after the macro name
CXX      src/neuralnet/connection_layer/libsinga_la-slice.lo

@seaokcs pls help check the neuron_layer.h:291.
running the program with cudnn.conf (compiled using makefile.gpu or configure) gets stuck when creating cudnn handle.


V2

I believe this branch contains all the modifications we need to release v2. @rackt/routing please review in case I missed something.

The only thing I'm a bit hesitant about is that we didn't warn people we were going to remove createLocation as public API, but I think that's a relatively minor change because it was only ever really used for server-side rendering.
Also, should probably update docs before merging.

What do we want to do with the match API in React Router? Currently it calls into history.createLocation: https://github.com/rackt/react-router/blob/v1.0.1/modules/match.js#L37-L39.
I'm fine with deprecating createLocation - we just need to figure out how to write that function before we proceed, though.

I think we should keep it. You can go from LD to string with createHref or createPath, but not back? Since we seem to prefer LDs, that seems a bit backwards.

The point of createLocation is to go from location descriptor to location, so the router can match. Maybe we should update createLocation to also take a location descriptor? I don't know how to make match work otherwise.
Maybe we should be unconditionally calling history.createLocation on the input to match.

Okay, sorry, I think we're actually not ready for 2.x yet... I totally forgot about createLocation.
I think we should update createLocation to work with match and push that out as 1.16.x. Then we'll finally have fully forward-compatible APIs, and React Router 1.1.x can depend on "history": "^1.16.0 || 2.x".
This way users will actually not be broken, and they'll have the full set of deprecations.

Users shouldn't ever actually need to use createLocation. It's private API.
Server-side match can just work like:
match(req.url, routes, ...)

That's the beautiful thing about us being able to accept either a path or an object as a "location descriptor". You can give us a plain URL if that's all you have. In a lot of ways it's actually simpler.

But how does match convert that string to a location descriptor? Via private API usage?

Nope, I figured out how to do it without using any private APIs, and without some of the hacks that I attempted on the way:
https://github.com/rackt/react-router/pull/2680

Per this discussion on https://github.com/rackt/react-router/pull/2680, we're still going to have to update createLocation to accept a location descriptor, and warn when called with multiple arguments.

@taion @timdorr I've added back the history.createLocation instance method, but no warnings about multiple arguments. At this point I'd rather just ship v2.

I can try to put together a PR for createLocation later today or maybe tomorrow. At this point, until we update React Router, nobody will be able to use history v2 anyway, so there's not much immediate benefit from releasing right now.

The only real immediate benefit to me is that I get to cross something off my TODO list.

That's a pretty good benefit (:
This sounds a little byzantine, but what do you think of releasing a 1.16.0 with the deprecation warnings removed (maybe after we fix createLocation)?
I'm a little uncomfortable that all the code we've pushed since 1.13.1 isn't getting used (even through the backward compat shims). It means that we aren't getting e.g. bug reports, so if there are problems, we won't know until (much) later.
I'm thinking something like:

Fix createLocation API
Release a 1.16.0 without deprecation warnings that users can upgrade to for the moment until we're done with React Router 1.1.x
Release 2.0.0
Release a 1.17.0 that adds back the deprecations

It sounds weird written out like this, but it means that we can start exercising the new/modified code paths, and get more confidence around the new code working, which means we have more time to fix bugs as they come up.

ok, let's do it.

:+1:

I noticed this diverged quite a bit from master. Doing a rebase now to get everything back in line.

BTW, this looks all good to me too. :shipit:

Instead of removing deprecated code in 2.0, we'll remove it in 3.0.


Implemented binary for extracting repo, also tweaked mvn config resulting from testing with actual mvn repo.
(Tested successfully with basic mvn repos) [phab:D2262]

Created by craigbarber at 2018-04-23 22:55:13:
Added java extractor artifacts Dockerfile, integrated it with the test extraction config for mvn
moved the logic from parseconfig into the library function: GenerateExtractionImageFile
finished implementing GenerateExtractionImage lib function
implemented binary for extracting repo, also tweaked mvn config from testing with actual repo
incorporated linter feedback
cleaned up json formatting

craigbarber commented inline (context lost during migration) at 2018-04-23 22:59:16:
Tried to incorporated these as args, but the redirect got fouled up. I wasn't convinced that it merited further logic to disable arg escaping, however if someone feels strongly about it I can add it in.

craigbarber commented inline (context lost during migration) at 2018-04-23 22:59:16:
This script originated from juanch's script: https://pantheon.corp.google.com/code/develop/browse/default/master/docker-containers/dkythe-java/scripts/maven-build.sh

craigbarber wrote at 2018-04-23 23:56:02:

added README doc for extractrepo

Updating (earlier comment): Implemented binary for extracting repo, also tweaked mvn config resulting from testing with actual mvn repo.
(Tested successfully with basic mvn repos)

danielmoy-google commented inline (context lost during migration) at 2018-04-24 00:18:29:
I dunno go style, is it worth grouping the publicly visible consts separately, or no?

danielmoy-google commented inline (context lost during migration) at 2018-04-24 00:18:29:
does it need to be writable (maybe 444?)

danielmoy-google commented inline (context lost during migration) at 2018-04-24 00:18:29:
why the surrounding \n here but not in other failures?

danielmoy-google commented inline (context lost during migration) at 2018-04-24 00:18:29:
Is this necessary with the above RemoveAll? (or does RemoveAll fail if there's still stuff inside it? I dunno)

danielmoy-google commented inline (context lost during migration) at 2018-04-24 00:18:29:
Hmm I wonder if the drift on that proto version will be enough to warrant just linking to the file (though then you'd lose the line).  I dunno.
No great option because (afaik) we can't do semantic linking into github.

danielmoy-google wrote at 2018-04-24 00:18:29:
most of the way done reading

danielmoy-google commented inline (context lost during migration) at 2018-04-24 00:41:10:
huh so maybe this is just my lack of understanding here, but this means that someone running this actually modifies their local env after all is done, correct? I.e. there's no undo on the installation there?
Or maybe I'm just completely missing the point here...

danielmoy-google commented inline (context lost during migration) at 2018-04-24 00:41:10:
maybe "the output of the extraction process is a [kindex file]
or are kindex files (I dunno)

danielmoy-google commented inline (context lost during migration) at 2018-04-24 00:41:10:
Ah do we need to explicitly state json format (possibly linking to some proto<->json format doc, if one exists)?

danielmoy-google commented inline (context lost during migration) at 2018-04-24 00:41:10:
worth including the build step ahead (for the binary itself), or no?

danielmoy-google commented inline (context lost during migration) at 2018-04-24 00:41:10:
oh right I forget we get spoiled by having libraries do this for us sometimes.
Speaking of, is there an open source library that would do this for us?  (Fine if not)

danielmoy-google commented inline (context lost during migration) at 2018-04-24 00:41:10:
getting really nitty here, but would it be worth checking both of these, and returning all the errors at the same time (or is there a way to concat errors cleanly?)
Just from the user standpoint, it would be a pain to do:
./binary --missing-both-flags
see the first error message, then specify
./binary --missing-one-flag --repo_uri=...
then see the second error message, which could have been specified on the first failure not the second failure

danielmoy-google commented inline (context lost during migration) at 2018-04-24 00:41:10:
My knowledge of how fatal works wrt. deferred handling.  Since this is inside a defer, does fatal (panic, or is that just os.Exit(1)?) cause problems with earlier defer statements?
This makes me vaguely uncomfortable from an embedded-C interrupt handling perspective, but maybe go just does the right thing here and I'm completely wrong.

danielmoy-google commented inline (context lost during migration) at 2018-04-24 00:41:10:
nit: \n

danielmoy-google commented inline (context lost during migration) at 2018-04-24 00:41:10:
might be worth some comment (maybe package-level up at line 1)
# this package provides docker config that ... blah blah ...

craigbarber commented inline (context lost during migration) at 2018-04-24 16:39:04:
If I'm understanding your question, you're asking whether these RUN commands will affect the host env, (please correct if I misinterpreted)? The modifications are local to the container. The host env is unaffected.

danielmoy-google commented inline (context lost during migration) at 2018-04-24 19:42:13:
ok cool my misunderstanding then

craigbarber wrote at 2018-04-24 20:14:35:

incorporated CL feedback

Updating (earlier comment): Implemented binary for extracting repo, also tweaked mvn config resulting from testing with actual mvn repo.
(Tested successfully with basic mvn repos)

craigbarber commented inline (context lost during migration) at 2018-04-24 20:14:50:
I've been modeling my approach based upon our other existing golang binaries. That said, I'll dig around and see if there something new which might eliminate the needs for this boilerplate code.

craigbarber commented inline (context lost during migration) at 2018-04-24 20:14:50:
That's a fair point, I'll consult with fromberger on this to  to see what is idiomatic for golang in this regard.

craigbarber commented inline (context lost during migration) at 2018-04-24 20:14:50:
I'll do some experimenting and follow up on this.

fromberger commented inline (context lost during migration) at 2018-04-25 14:20:30:
It doesn't matter, but it can't hurt. :)

fromberger commented inline (context lost during migration) at 2018-04-25 14:20:30:
Or equivalently: fmt.Fprintln(&buf)

fromberger commented inline (context lost during migration) at 2018-04-25 14:20:30:
I'd like to offer a suggestion for restructuring this API. While there's nothing wrong with combining these two steps, I think it'd be beneficial to separate the concern of "loading extraction config" from "generating image file".
Schematically, what I'd propose is something like:
func Load(path string) (*ecpb.ExtractionConfiguration, error) {…}

func CreateImage(path string, config *ecpb.ExtractionConfig) error {…}

Indeed, I might even go one step further here:
func Load(r io.Reader) (*ecpb.ExtractionConfiguration, error) {…}

f, err := os.Open(configPath)
…
defer f.Close()
cfg, err := config.Load(f)
…
if err := config.CreateImage(outputPath, cfg); err != nil {
   …
}

This makes it easier to write tests (no need to create any test data files; you can just pass in literals via strings.NewReader to Load, and pre-composed input configs to CreateImage), easier to handle input from sources other than the local filesystem (which can be tedious to retrofit later), and easier to distinguish where errors happened when something goes wrong.

fromberger commented inline (context lost during migration) at 2018-04-25 14:20:30:
https://github.com/golang/go/wiki/CodeReviewComments#error-strings
viz., Error → error here and below. Though that said, I don't think it's necessary to include the word "error" in most errors:
`fmt.Errorf("parsing config: %v", err`

would work just as well (keep in mind that if someone logs this upstream, They'll probably include the word "error" anyway)

fromberger commented inline (context lost during migration) at 2018-04-25 14:20:30:
I don't think the "tmp" prefixes really add much here; there's not a non-temporary repo dir. :)
I suggest simplifying a bit: repoDir, outputDir, dockerFile, imageTag, etc.

fromberger commented inline (context lost during migration) at 2018-04-25 14:20:30:
Maybe log what you settled on for the config path?
log.Printf("Using configuration file: %q", *configPath)

fromberger commented inline (context lost during migration) at 2018-04-25 14:20:30:
output, err := exec.Command("docker", "build", "-f", dockerFile.Name(), "-t", imageTag, outputDir).CombinedOutput()

fromberger commented inline (context lost during migration) at 2018-04-25 14:20:30:
I suggest either fmt.Printf + os.Exit(1) or log.Fatal but not a mix of the two.
Maybe:
log.Fatalf("Failed to build docker image: %v\nCommand output:\n%s", err, string(output))

or words to that effect.

fromberger commented inline (context lost during migration) at 2018-04-25 14:20:30:
143, ibid.

fromberger commented inline (context lost during migration) at 2018-04-25 14:28:17:
t.Helper() at the top of this function.

fromberger commented inline (context lost during migration) at 2018-04-25 14:28:17:
In Go, the conventional words for "actual" and "expected" are "got" and "want". When there's only one kind, it's fine—indeed encouraged—to just use those names directly:
got, err := ioutil.ReadAll(imageFile)
…
want := mustLoadFile(t, testConfig)

craigbarber wrote at 2018-04-26 22:37:41:

incorporated CL feedback

Updating (earlier comment): Implemented binary for extracting repo, also tweaked mvn config resulting from testing with actual mvn repo.
(Tested successfully with basic mvn repos)

craigbarber commented inline (context lost during migration) at 2018-04-26 22:38:15:
Changed all except for tmpOutputDir, which in this case is a tmp dir which is separate from the parameter output dir.

craigbarber commented inline (context lost during migration) at 2018-04-26 22:38:15:
Done. The testdata file pattern is one we use for the verifiers for the indexers which I find helpful, as it allows for each file to represent a self-contained test. Adding a new test is easy as you just add a new test data file with corresponding expected data file.

craigbarber commented inline (context lost during migration) at 2018-04-26 22:38:15:
I think that this function, (which is called in multiple test cases), eliminates redundant boilerplate code for reading expected test data files. If you feel strongly about it let me know, but otherwise I'd prefer to keep it in its current form as it allows the test case code to be cleaner.

craigbarber commented inline (context lost during migration) at 2018-04-26 22:38:15:
This code got re-factored to using testData. PTAL

fromberger commented inline (context lost during migration) at 2018-04-27 18:32:53:
Both "extractors" and "config" are already implicit in the package name—can we simplify the names here by removing those redundant parts?
At the call site, this will be
import "kythe.io/kythe/go/extractors/config"

cfg, err := config.LoadExtractionConfig(…)

but it could more simply be:
cfg, err := config.Load(…)

without loss of information.
(LoadExtraction would probably not be too bad either)

fromberger commented inline (context lost during migration) at 2018-04-27 18:32:53:
As above. I'd suggest maybe: CreateImage here, since "extraction" is already implied.

fromberger commented inline (context lost during migration) at 2018-04-27 18:32:53:
Sure, having the function makes sense. But it can still be simplified quite a bit:
func mustLoadDockerFile(t *testing.T, configFile string) []byte {
   t.Helper()
   fileName := fmt.Sprintf(…)
   content, err := ioutil.ReadFile(os.ExpandEnv(filepath.Join(testDataDir, fileName))
   if err != nil {
      t.Fatalf("Failed to open test docker file: %v", err)
   }
   return content
}

fromberger commented inline (context lost during migration) at 2018-04-27 18:32:53:
Nothing is closing the files returned by this function. That should be arranged for, since even in a short-lived test a lot of test data files could potentially cause descriptor exhaustion.
There's a couple approaches you could take: One might be to define a type for this,
type testFiles []*os.File

func (t testFiles) Close() error {
   var err error
   for _, f := range t {
      if cerr := f.Close(); err == nil {
         err = cerr
      }
   }
   return err
}

and document that the caller should close them:
testFiles := mustOpenTestData(t)
defer testFiles.Close()

Alternatively, you could have this function return a cleanup:
func mustOpenTestFiles(t *testing.T) (files []*os.File, cleanup func()) {

which similarly gets called. (The two are essentially equivalent in effect, modulo where the code goes)

fromberger commented inline (context lost during migration) at 2018-04-27 18:32:53:
nit: the name doesn't reflect what it does—it doesn't load any data, it only opens the files.

fromberger commented inline (context lost during migration) at 2018-04-27 18:32:53:
var files []*os.File

fromberger commented inline (context lost during migration) at 2018-04-27 18:32:53:
I suggest (throughout):
testDataList → testData
testData → file

fromberger commented inline (context lost during migration) at 2018-04-27 18:32:53:
Not sure why this is necessary—a newly-opened file should already be at offset 0 unless it was opened for append.

fromberger commented inline (context lost during migration) at 2018-04-27 18:32:53:
It's probably worth mentioning that this is expected to be in JSON, maybe something like

This tool extracts compilation records from a repository containing a
JSON extraction configuration encoding a kythe.proto.ExtractionConfiguration.
It makes a local clone of…

or words to that effect.
(Note that unlike the package comment, it's not strictly necessary to repeat the name at the beginning of the docstring here—though if you want to do that might as well use the same argument as in the usage, e.g., %[1]s)

fromberger commented inline (context lost during migration) at 2018-04-27 18:32:53:
if flag.NArg() > 0 {

fromberger commented inline (context lost during migration) at 2018-04-27 18:32:53:
I don't have a strong feeling about it. My experience has been that most of the time the benefits of combining checks are pretty minimal, and any tool that consistently requires multiple flags will get stuffed in a script anyway. So I think it's fine to fail-first here, but YMMV.

fromberger commented inline (context lost during migration) at 2018-04-27 18:32:53:
Do you really want to fatal for this? Failing to clean up the image is mostly harmless, no? I think we are running in a temp directory anyway, so best effort seems sufficient. (Of course it still makes sense to log it)

fromberger commented inline (context lost during migration) at 2018-04-27 18:32:53:
Is this implicitly in the home directory, or does it look in $PWD?

fromberger commented inline (context lost during migration) at 2018-04-27 18:32:53:
Sub in your constant?

fromberger commented inline (context lost during migration) at 2018-04-27 18:32:53:
It might be worth including a check for these in the flag-checking pass, e.g.,
if _, err := exec.LookPath("git"); err != nil {
    log.Fatalf("Unable to find a git executable: %v", err)
}

or words to that effect.

fromberger commented inline (context lost during migration) at 2018-04-27 18:32:53:
It may not matter, but note that this bypasses the deferred cleanup. What I'd probably do here is something like:
output, err := exec.Command("docker", "run", …)
cleanup()
if err != nil {

so that it always gets run even if the run fails.

craigbarber wrote at 2018-04-27 19:48:59:

incorporated CL feedback

Updating (earlier comment): Implemented binary for extracting repo, also tweaked mvn config resulting from testing with actual mvn repo.
(Tested successfully with basic mvn repos)

craigbarber commented inline (context lost during migration) at 2018-04-27 19:53:11:
Verified that there doesn't currently exist a lib for this.

craigbarber commented inline (context lost during migration) at 2018-04-27 19:53:11:
Followed up with some experimentation, panicking from within a defer seems to work fine.

craigbarber wrote at 2018-04-27 20:57:34:

incorporated CL feedback

Updating (earlier comment): Implemented binary for extracting repo, also tweaked mvn config resulting from testing with actual mvn repo.
(Tested successfully with basic mvn repos)

craigbarber commented inline (context lost during migration) at 2018-04-27 20:57:40:
This is necessary due to Load() reading the file.

craigbarber commented inline (context lost during migration) at 2018-04-27 20:57:40:
Not sure what you mean, are you referring to the tmp image?

danielmoy-google wrote at 2018-04-27 23:21:32:
mostly fine by me, dunno if fromberger still has comments

danielmoy-google accepted this revision at 2018-04-27 23:21:32

fromberger commented inline (context lost during migration) at 2018-04-30 15:00:17:
t.Fatal("No test config data found")
(no need for the -f variant when there are no substituents; the "\n" at the end is fine but unnecessary)

fromberger accepted this revision at 2018-04-30 15:00:17


Hotfix/grant empty permissions

This patch splits grant- and alter-role-actions into two functions and prevents execution of alter role with empty options.

LGTM


added fixed version of awesome-typescript-loader

version 2.2.3 causes errors

Why does 2.2.3 cause errors?

Fixed already! Check out the PR for my previous comment. https://github.com/angular/angular-cli/pull/1993

ah, sorry. I totally overlooked that PR.


Potential collaboration with Gnosis AI (Omen prediction market, predictor agents)

Hey, team, I'm working with Gnosis AI, and it seems like our work is highly correlated. We (along with other teams), take care of

Presagio (Omen 2.0) -- prediction market platform by Gnosis (fun fact, Polymarket uses smart contracts originally developed by Gnosis)
prediction market agents and library to create such agents from scratch -- most of the PMs are created and traded by LLM agents on Omen
Dune dashboard showing very detailed charts about the markets on Omen.
And many other projects

Would you be open to a discussion about whether we can somehow collaborate?
Some use cases I can imagine from the top of my head right now:

We could contribute support for betting on Omen
We could create customized market creators on Omen, if you have some niches agents
We could share LLM predictors' logic

Hey, sounds awesome. We like Gnosis AI a lot. We are currently super focused on scaling our event landscape but integrations with prediction markets are a priority, especially from a product point of view. I just dropped you an email.


Show contemporary trailers

Don't know how this would be possible but thought it would add to the cinema experience. Maybe it would need a tag like Release19770525 to make the idea work.
You sit down to watch a movie. It's from 1977, May 25. The plugin searches for trailers in your collection with tags within the next 12 months, so you are truly seeing contemporary trailers. So, you're watching Star Wars and see a trailer for The Spy Who Loved Me (if it's in your trailer collection). If there aren't any trailers in the next 12 months, the plugin logic just defaults to the regular selection method.

Something very close to this (but not exact) is already available without the use of tags. Jellyfin has "Release Date" in movie meta data already. See the Year selection rule here: https://github.com/CherryFloors/jellyfin-plugin-cinemamode?tab=readme-ov-file#selection-rules-1
In your example, with this selection active the plugin will find all movies you have that were released in 1977 (1977/1/1 - 1977/12/31), so it may play trailers for movies released prior to the features release date.
It would not be very difficult for me to change the plugins behavior to search for movies released 1 year from the feature. So in this example, the search range would be 1977/5/25 - 1978/5/25. I will leave this open as an enhancement while I think about ways to proceed. I appreciate your feedback!

Don't know how I missed that, but thanks for considering an upcoming contemporary option.


Column filter reset after changing field format

DD24 / OE 11.6.3
Changing the format in the table-info top-browser will reset query and column filters.
Steps to reproduce:

Enter a value in any column filter and execute
Change the format for any field in the table-info top-browser
Try to re-execute the filter already entered in step 1. by pressing enter in the filter-field (or clicking the execute query play-button)
Query and filter is reset.

Column filter fields and query should not reset after changing field format.

Hi kingOttmar, thanks for reporting, I'll see if I can fix this.

Hi KingOttmar,
I think I've got it fixed. And as a bonus, I found out that I can actually
change the format of the databrowse on the fly, so I do that as well. To
give reporters of a bug credit, I'd like to add you to the changelog. By
what name would you like to appear there?
gr
Patrick Tingen
Op vr 21 dec. 2018 om 11:38 schreef kingOttmar<EMAIL_ADDRESS>
DD24 / OE 11.6.3
Changing the format in the table-info top-browser will reset query and
column filters.
Steps to reproduce:

Enter a value in any column filter and execute
Change the format for any field in the table-info top-browser
Try to re-execute the filter already entered in step 1. by pressing
enter in the filter-field (or clicking the execute query play-button)
Query and filter is reset.

Column filter fields and query should not reset after changing field
format.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/patrickTingen/DataDigger/issues/46, or mute the
thread
https://github.com/notifications/unsubscribe-auth/AFuwHa5hC3WHZjpXKtP1pCVb9jLjoUwaks5u7LoZgaJpZM4ZdxX8
.

Fixed in develop branch, will ship with DD25


Colors for the STEREO FLAGS and STEREO MARKS

As a Ketcher collaborator I'd like to implement rendering colors of the stereochemistry flags and labels.
In the ‘Settings’ user is able to specify the preferences for the rendering of the stereochemistry flags and labels.
Colors:
• Color of Absolute Centers - Specifies the color in which the stereo bonds, stereogroup labels, or both are displayed at absolute stereogenic centers.
• Color of AND Centers - Specifies the color in which the stereo bonds, stereogroup labels, or both are displayed at AND stereogenic centers.
• Color of OR Centers - Specifies the color in which the stereo bonds, stereogroup labels, or both are displayed at OR stereogenic centers.
• Color stereogenic centers - Specifies how color is used with one of the following values:
a) Labels only

b) Bonds only

c) Labels and Bonds

d) Off

Draw the default colors for stereocenters are:
Absolute – Red;
AND – MediumBlue
OR – ForestGreen
The color for the next label (AND1, AND2, AND3 or OR1, OR2, OR3…) is a little lighter then for previous one.

Part 3 in Epic #56

Bonds are not rendered in color in both 'Bonds only' and 'Labels and Bonds' cases.
Steps to reproduce:

Create a structure on the canvas (e.g. chain)
Add several stereobonds to the structure
Select 'Bonds only' option in  'Settings' -> 'Color stereogenic centers'
Select 'Labels and Bonds' option in  'Settings' -> 'Color stereogenic centers'

Expected result:
3. The stereobonds are colored in accordance with the selected colors.
4. Labels and Stereobonds are colored in accordance with the selected colors.
Actual result:
3. The stereobonds remain black.
4. Labels are colored in accordance with the selected colors. The stereobonds remain black.

The possibility to specify the colors for stereogroup labels and stereo bonds at absolute/AND/OR  stereogenic centers was implemented. Release/2.3 The issue is verified and closed.


Update evdi to 1.8 for support 5.6.xxx 5.7.xxx 5.8.xxx and 5.9.xxx Kernel line

Update evdi to 1.8 for support latest Kernel.

EVDI already supports kernels up to 5.9. Not sure what is it about?

Sorry - page refresh and hook in to this issue list. This issue was target to this page
https://github.com/displaylink-rpm/displaylink-rpm

OK. Closing


Court was misspelled.

Fixed issue #2.https://github.com/pslmsngr/pwm-db/commit/39de5ef4f1b7d25c3061551405530a5db7757e81


Can the http-collector scale horizontally?

Hello Norconex-Team,
I am wondering whether the http-collector can scale horizontally, meaning if it is possible to start multiple crawlers with the same configuration working on the same data? I am looking into running the collector on k8s and would love the possibility to dynamically scale the crawler-process on demand.
Best regards
Tobias

The HTTP Collector focus is definitely more "vertical".  There has been very little demand for horizontal scalability but that is starting to change I think.   That being said, there are a few approaches that worked for different users.
Distributed crawl store
You can have your own implement of ICrawlDataStoreFactory (or use existing, like MongoDB) that can be scaled horizontally.  Then you should be able to have multiple crawlers sharing the same config.  Maybe you will hit a few concurrency issues but hopefully, those will not be of concern (like maybe processing the same URL .
Dynamic config generation.
Next release

I had closed this issue by accident.  Re-opening.

it's an interesting topic, so I'd like to participate :)
regarding Distributed crawl store:

Then you should be able to have multiple crawlers sharing the same config.

if I'm not mistaken, a distributed store (like Mongo, NFS) would not make crawling efficient, if all the collectors share the same configs, I mean, the same sites will be potentially crawled as many times as many collector instances you have, e.g.

instance-1 starts and picks up the site-1 and runs
instance-2 starts, tries to pick up the site-1, fails (as it's locked already), picks up the site-2 and runs
assuming, the site-2 is smaller than the site-1
instance-2 finishes the site-2 and picks up the site-3
instance-1 finishes the site-1 and picks up the site-2, as it has no "idea", that the site-2 has been just processed.

The next major release should make it easier to perform horizontal scaling.

could you please share some details on that? Thanks!

Hello @jetnet.  Nothing is cast in stone for V3 yet and we welcome suggestions.  One thing for sure, we would like to make it easier for developers to integrate it in other systems that can scale horizontally.  "Vertical" crawling and simplicity will remain a key focus of version 3, but we are considering a few ideas.  For example, having each important components (collector-importer-committer) runnable on their own as servers, to facilitate reuse/scalability.
The crawl store will be reworked as well, but in the end, it probably won't be used like you describe it.  I mean, it can be distributed, but for a large crawl "session".  Different crawler configurations/sessions should probably stick to their own crawl store "space" (distributed or not) for better results.  Implementors can have different crawlers crawling some of the same content, but extracting/filtering things differently for whatever reason, so they should not overlap.


Test status code in failed token validation

Addresses status codes part of #17 .
Depends on #19.

Tests pass for me hence I consider this PR ready to review and merge.

Merged.  Thanks for the contribution.


Turn the regex used for validation in models.py to a constant

Turn the regex below into a reusable constant for "a SPARQL variable from a controlled namespace"
https://github.com/neurobagel/api/blob/fc48a2c2b53bd1907b9825505024a93b9f6ec4f3/app/api/models.py#L19

@rmanaem I think this is a fairly straightforward refactoring that can probably be addressed for this release, so I've moved it to the Backlog on the Kanban board. :) Feel free to reshuffle the priority as you see fit!


Integrate software-ROR links from openaire_x_czi into consolidate_links.py

Once #24 is done. Would you be interested in taking this on @schatzopoulos ? Happy to help point you to the relevant parts of consolidate_links.py if needed!

Closed via https://github.com/jmelot/SoftwareImpactHackathon2023_InstitutionalOSS/pull/31


add fail test case for deleting activity

origin issue is https://github.com/spatie/laravel-activitylog/issues/47
delete activity not recorded

You're using  Spatie\Activitylog\Test\Models\Article which does not have the LogsActivity trait. So I expect this to fail.


More useful bug fixes + re-added identity crisis transition

almost forgot to fix this again

i fixed the title screen issue  with not being able to enter lol

HOLD I THINK I MAY HAVE FIGURED OUT THE DOUBLE KILL LAG

YESSSSSSSSSSSS
I FIXED IT
read the commit desc if you wanna know what was the problem lol

i think it's too late clowfoe already left the internet

i think it's too late clowfoe already left the internet

well just incase lol

9 minutes ago

9 minutes ago

lunarcleint

well well well a new commit just dropped so this might get merged

oooo


[BUG] VoIP permission in Configure.ps1

Describe the bug
VoIP permission is not existed in application "Azure Communication Service". There is only one permission with name "Teams.ManageCalls". Need to change L375 in Configure.ps1.
In addition, service principal for Azure Communication Service is not builtin by default. User needs to create service principal for communication service if it is not there. It is better you add this comment into README.md.
To Reproduce
Steps to reproduce the behavior:

You can check scope name in AAD portal
If you try to run this script, you can get error.
If you get error like  Invalid value specified for property 'resourceAppId' of resource 'RequiredResourceAccess'., you need to add service principal with New-AzureADServicePrincipal -AppId "1fd5118e-2576-4263-8130-9503064c837a".
After that you can get the error

Code: Request_BadRequest
Message: Property requiredResourceAccess.resourceAccess value is required but is empty or missing.

When you change 'VoIP' into 'Teams.ManageCalls', everything can work.

Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
Screenshot when service principal for Azure Communication Service is not existed

Screenshot for VoIP error

Additional context
Add any other context about the problem here.

Version - what version is affected (e.g. 0.1.2)
Motivation for or Use Case - explain what are you trying to do and why the current behavior is a bug for you
Browsers and Operating System - is this a problem with all browsers?
Related Issues - has a similar issue been reported before?

Suggest a Fix
If you can't fix the bug yourself, perhaps you can point to what might be causing the problem (line of code or commit)

Change VoIP into Teams.ManageCalls in Configure.ps1
Please add the following guide into README.md.
User need to add service principal for Azure Communication service manually when it is not existed.
How to check if service principal is existed: az ad sp show --id "1fd5118e-2576-4263-8130-9503064c837a"
How to add service principal: New-AzureADServicePrincipal -AppId "1fd5118e-2576-4263-8130-9503064c837a"

@wansanji  Thanks for raising this bug. Solved in this pr


Dart SDK throwing a weird error

Here's the error log:
E/flutter (30596): [ERROR:flutter/runtime/dart_vm_initializer.cc(41)] Unhandled Exception: ClientException: {url: https://ahrar.pockethost.io/api/realtime, isAbort: false, statusCode: 526, response: {}, originalError: null}
E/flutter (30596): #0      PocketBase.send (package:pocketbase/src/client.dart:236:9)
E/flutter (30596):
E/flutter (30596): #1      RealtimeService._connect. (package:pocketbase/src/services/realtime_service.dart:276:7)
E/flutter (30596):
Looking at the PocketHost repo, I noticed a commit about 1 hour ago, around the time I started having issues. Related?
EDIT
after some more troubleshooting, I tried accessing the database dashboard directly in my browser and it's telling me there's an invalid SSL certificate

From the PocketHost maintainer:

There was a security update to PocketHost. CloudFlare now uses "Full" SSL encryption, meaning traffic is encrypted not just between browser and Cloudflare, but also between Cloudflare and the PocketHost origin. We are running the Caddy HTTP server (golang) on the server now, and it provides automatic SSL and proxies things to the PocketHost nodejs server if it passes all the Caddy security checks. You may get some temporary "526 certificate invalid" errors from Cloudflare until all the caches change over, but it should be resolved within a few hours. If it is not, please let me know.

@Jadi255 Yes @brewhousedigital is correct, sorry about that. We are trying to do some security updates but something appears to be going wrong with Cloudflare. If you get this error intermittently over the next day, that is likely the cause. If it persists beyond that, please re-open this issue.
https://discord.com/channels/1128192380500193370/1179854182363173005/1189229738967961600


Make cache timeout for GCS configurable

Addresses Issue #488.
I also bumped the requirement for gcsfs, since an issue with disabled caching was fixed in version 2022.02.0.

This looks great to me. Thanks so much!

Looks like we have some problems with the mamba api -- completely unrelated to this PR. Will get to fix that soon!

@wolfv, would it be possible to release a new version, after this PR has been merged? we'd love to use this feature as soon as possible. 🙂

Hey, I just fixed the mamba tests (https://github.com/mamba-org/quetz/pull/496)
If they are green, I'll merge & re-run tests here.
Then we can release!


(PUP-3898) Fix writing content with checksum

Fixes writing a file from content for a non-default checksum type when
the content is initialized as part of creating a file resource.
Fix applies to both puppet apply and puppet agent runs.

@joshcooper: last set of checksum fixes.

CLA signed by all contributors.

@MikaelSmith looks like travis failed

No errors in acceptance tests on Windows or Linux with the 2nd commit.

@MikaelSmith changes look good, I just had a small nit on the commit message. Could you describe what the old behavior was and how this commit fixes it? I assume we used to compare the old "content" using the default checksum type, e.g. {md5}xxxx, against the non-default checksum type, e.g. {sha256}yyyy?


Update non-GCE Salt distros to 1.6.0, fallback to ContainerVM Docker version on GCE

This is neutral on the current version of ContainerVM, and saves us some cycles.

Wait, misread this Salt. Argh. We need this for GCE for the next ContainerVM, but I need special case the others.

I changed the PR title to "WIP". Please flip it back once it's ready for review.

Ready now. Tested the override path by flipping the the cloud provider equality to verify (I have a ContainerVM image with Docker 1.6 on it, so it resulted in a downgrade).

cc @vmarmol @dchen1107

LGTM, thanks @zmerlynn! Are we planning on updating the Docker version to 1.6 sometime?

It's in the ContainerVM update. Do you want me to just bonk it into here since we've already e2e'd it? It would basically update Azure and AWS but not us (yet).

Yeah I was thinking that for the non-GCE setups. I'm fine doing it here or in another PR.

I can do it here. One sec.

Upgrading non-GCE providers to 1.6.0. Tested by briefly flipped the equality again and doing an -up on a stock ContainerVM image, then verifying the versions.

PTAL (fixed the nit along the way)

LGTM, will merge on green. Thanks again @zmerlynn!


Update MPI Settings

This PR updates a few things:

For Intel MPI at NCCS, it sets a few settings that have proven useful by @wmputman and @sdrabenh
For Open MPI, it turns on WRITE_RESTART_BY_OSERVER: YES (the default NO is kept for all other MPI stacks). This is needed because there is some weird issue with Open MPI and GEOS where writing restarts at even, say, c90 can take hours without this. This needs a line added to AGCM.rc.tmpl
Set PARALLEL_READFORCING to 0. This is from @atrayano who says this should be the default period. No matter what.
Fix some spelling issues I saw when reading AGCM.rc.tmpl
Add in c12 and c24 to the "what resolution" print of the _setup scripts. I know of a few people I've told to try c24 and then they are confused since it's a "hidden" option.

Probably would be good for @yvikhlya and @mmanyin to test this in coupled and other-chemistry modes. I've added them as reviewers

The change for the default value of PARALLEL_FORCING makes sense to me. The code does not benefit much from enabling PARALLEL_FORCING for tile files - even if we read the data in parallel, we still need to re-shuffling And the 14-word header is never read in parallel. Moreover, if PARALLEL_FORCING is enabled, the file is opened with MPI_FileOpen, but the header is read with "read", which is not consistent


sql: remove interleaved join

PR: https://github.com/cockroachdb/cockroach/pull/54163
From release notes:

Interleaved joins have been removed; merge joins are now planned in all cases when interleaved joins would have been planned previously. [#54163][#54163] {% comment %}doc{% endcomment %}

I don't think we need to document this.


Twitter Bootstrap Theme?

Hi,
Is there any Twitter Bootstrap Theme for W2UI?
I know that the the standard w2ui theme is very compact, but having TW support would be of great help since many projects already use it.

w2ui should not overlap with bootstrap. So, you can include any bootstrap theme.

w2ui should not overlap with bootstrap.

But I need the W2UI components to also have the Bootstrap look and feel like the rest of the stuff that's in the page, hence my question for a "Bootstrap Theme for w2ui".
Just dropping new components in a page that has Bootstrap can't possibly make them look and behave like Bootstrap. That's why many libraries have some sort of theme or extension to make that happen:
e.g. DataTables has such a theme:
https://www.datatables.net/examples/styling/bootstrap.html
or KendoUI:
http://demos.telerik.com/kendo-ui/bootstrap/
or ExtJS:
http://bootstrap.newbridgegreen.com/view/

@hansgru do you have a solution to give a w2ui app a bootstrap look and feel?


Add sanctuary to libraries section.

https://github.com/sanctuary-js/sanctuary

hey tomkel, maybe add a pull request? should make it easier to get added, definitely a good library


Sharing a Backdate Post

Hi, Is it possible to share a backdate post or change the date of the existing post?

Hi, Is it possible to share a backdate post or change the date of the existing post?

I'm not aware of that functionality so it's not likely it's present in this library. If it's possible in the app, then it is possible to implement a request in this library here by making your own. If you do, I encourage you to open a pull request.
Here is guide to intercept requests from the app, and creating your own requests using this library as the framework.
We also have a discord for more questions like these.

Hi, Is it possible to share a backdate post or change the date of the existing post?

I'm not aware of that functionality so it's not likely it's present in this library. If it's possible in the app, then it is possible to implement a request in this library here by making your own. If you do, I encourage you to open a pull request.
Here is guide to intercept requests from the app, and creating your own requests using this library as the framework.
We also have a discord for more questions like these.


nixos/nebula: add CAP_NET_BIND_SERVICE when lighthouse node serves DNS

Serving DNS fails in the absence of CAP_NET_BIND_SERVICE.
Things done

Built on platform(s)

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

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[x] Tested, as applicable:

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

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

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

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

@numinit I would appreciate your review on this 🙏

May be worth updating the NixOS test too.

Hey, thanks for taking this btw! Let me know if you need any help getting it across the finish line.