DeprecationWarning: 'cgi' is deprecated and slated for removal in Python 3.13

DeprecationWarning: 'cgi' is deprecated and slated for removal in Python 3.13

Will fix asap

test, please
pip install ombott==2.0rc1
Some improvements/caveats:
earlier workflow:

whole request body is saved to a tmp-file
then file-fields are read from body-tmp-file and saved to separate tmp-files

now:

request body is parsed while saving to a tmp-file to make a markup
file-fields file-prop is BytesIOProxy, i.e. file-like object which is proxied to some part of the request body-tmp-file

Hello, Val !
Please, if possible, add a small change to the line 73 file ombott.py
  -     _stderr(f"Listening on http{'s' if kwargs.get('certfile', None) else ''}://{server.host}:{server.port}/\n")

  +      if not server.host.startswith('unix:/') :
  +          _stderr(f"Listening on http{'s' if kwargs.get('certfile', None) else ''}://{server.host}:{server.port}/\n")


Refactor pixel snapping.

-Rename pixel_snap to snap_2d_to_vertices
-Added snap_2d_to_transforms which is more useful
Fixes #41814
Solves proposal https://github.com/godotengine/godot-proposals/issues/1666
Supersedes #35606, supersedes #41535, supersedes #41534

I have done testing this Pull Request.
Using :
Godot 3.2.3,
Godot 4.0calinou.6c173e2f7 (Aka older version of Godot 4.0) ,
Godot 4.0 Pixel snap refactor
Here is what I came up with :
First I notices this Shaking effect in the new pixel snap refactor, its very noticeable.
I thinks its due to the snapping that happens in Realtime.
Godot 4.0 Refactor :

Old Godot 4,0:

Godot 3.2.3 :

Also the smoothness of movement in the Refactor Godot is very blocky.
Old pixel snap didn't have this "blackness" as shown in the GIFs
note: its stated by Calinou in #35635 That by snapping the camera you lose smoothness of motion.
Could be the reason, and I don't think there is a workaround for it.
Also when doing my tests I find that Godot 3.2.3 and Godot 4.0 are different in how they render the sprites.

Could be because of changes in Vulkan and HDR but that's not our talk, i just stated it because it give me a problem comparing the changes.(and also that I think Godot 3.2.3 sprites looks sharper then Godot 4.0)
Another problem I find is a wave like seam that appears in the sprite while moving,
I couldn't able to capture it using Gifs, but if you stop just in the right time, your sprite will get distorted.
This problem happens in both Godot 4.0 and doesn't happen in Godot 3.2.3:

As you can see the eye of my sprite got extra pixel on the left eye.
the sprite get distorted: unlike Godot 3.2.3 the sprite remain the same no matter how you move.
(could be because the sprites are not getting snapped as a whole, but some pixels get?)
Same for all sprites.
So it doesn't really pixel snap anything but just shake up the camera or something.
What I think is this Refactor pixel snapping was based on Godot 4.0 pixel snapping which my tests show is broken.
So if you did Refactor this tool based on Godot 4.0 then its broken. and should be refactored based on Godot 3.2
as I see in the code, a lot of changes in the sprite code between Godot 3.2 and Godot 4.0.
So I can't really tell what did go wrong.
Hope this help address the problems of pixel snapping in Godot 4.0, and improves pixel snapping of Godot 3.2.

@RamaStudio I am not exactly sure what I should be looking at. 4.0 prior to this PR did not have pixel snap implemented, so even if you turn on the setting it was the same as just disabling it (made no difference).
If you are using filtered textures, you should probably not enable snapping. Snapping will be mostly useful for pixel art. This PR aims to solve the problems with motion (see the referenced issues/PRS0, not with scaling.
Pixel (no filter) scaling will always be wobbly, not sure if anything can be done about that.

Also you should most definitely not be using vertex to pixel snap for pixel art. Use the new transforms to pixel snap instead.

@RamaStudio I am not exactly sure what I should be looking at. 4.0 prior to this PR did not have pixel snap implemented, so even if you turn on the setting it was the same as just disabling it (made no difference).

That's explain why its broken.

If you are using filtered textures, you should probably not enable snapping. Snapping will be mostly useful for pixel art. This PR aims to solve the problems with motion (see the referenced issues/PRS0, not with scaling.

I didn't. but some how in Godot 4.0 the sprites look more linear even with filtering set to nearest.
that could be why you thought I didn't use it.

Pixel (no filter) scaling will always be wobbly, not sure if anything can be done about that.

As for the motion problem I already said that it has the problem of "not snapping anything, and causing wobbly"
Here is what I meant:

The the sprites changes every time I stops :

Now look Godot 3.2.3 :

The sprite never changes with pixel snap on. (It may get distorted at some scale conditions but its way fewer wobbly effect then 4.0)
that's the only bug I can report here.

Pixel (no filter) scaling will always be wobbly, not sure if anything can be done about that.

I didn't say it was wobbly, I said it was shaking. compare it with the Gifs I sent. there is up down left right movement to the camera or to all the sprites.
maybe the pixels are getting snapped aggressively or something.

Also you should most definitely not be using vertex to pixel snap for pixel art. Use the new transforms to pixel snap instead.

I checked your code to see what that option does, couldn't find anything. but I kept it disabled anyway.

Ok just so we are on the same page, there are two options here:

The first one is meant to solve #41535. With it, the demos run ok, no jitter between objects reaching the next pixel at different times. When you turn it on, all reach the next pixel at the same time. This is definitely meant for pixel art, if your texture has filtering enabled you may not want to use this.
The second is the same as the old "pixel snap" in Godot 3.x and should work the same. It wasn't being enabled but it should use the same code as 3.2 so I assume it works. If it does not, it's most likely a bug and it needs to be fixed.

I would love to test this. It's a huge problem in my game.
Unfortunately I still did not understand how to make custom builds including certain PRs.
If someone has a Win build on 3.2 "lying around" with this change, I would love to test it and give feedback how it behaves with my project.

@RPicster builds artifacts are available for this PR to test:
Windows: https://github.com/godotengine/godot/actions/runs/336674241
Go into "Show all checks" → "Details" for each platform of interest → "Artifacts".

@RPicster This pull request is based on the master branch (with the Vulkan renderer), not the 3.2 branch. It's not compatible with 3.2.x projects.

@reduz
With that idea in mine I guess everything works fine,
I did further tests with bigger viewport size. and it shows no pixel artifact at all. (the wobbly movement is removed, if you set the viewport size the same as the window size.)
However the shaking problem I talked about is confirmed.
and happens when you enable "snap 2d transformation to pixel"
and that's it. 👍
Thank you.

Can the "viewport size = window size" requirement for pixel perfect get documented?

@reduz I've pointed out small typo which may be needed for this to work in master branch. I can't currently run 4.0 so anyone on 4.0 (@akien-mga ?) can make a small PR to fix this.

@reduz Should those issues you linked be closed?

@reduz Should those issues/PRs you linked be closed?

For the issues at least an equivalent PR still has to be finalized / merged for 3.2 first I think (this one can't be cherry picked super easily because there are some differences).


[soku] Make the ending font bigger.

Or did I already do that? I don't remember. I'll have to ask Splash.

I don't remember either. It's not too small to read, but sure enough the text looks odd. See how s and o melt together and the hooked d's. Might be related to issue #91 and #86.


[Roadmap][Network] QoS

Goals:

Easy creation of LibraNet clients outside p2p use-case (e.g. client → full node, validator → CTCB)
Separate network queues per peer for isolating back-pressure
Remove leakage of application layer notions into LibraNet (e.g. add_consensus like functions)

Related Issues:
#1670 Refactor LibraNet for end-to-end QoS fairness and backpressure isolation

Closed by #2130


Drop support of GHC 7.6

After release of arithmoi-<IP_ADDRESS> with stability fixes, IMHO it is time to stop supporting GHC 7.6 and base-4.6. It is really outdated and the maintenance is extremely tedious: we need to insert CPP macros here and there to make GHC 7.6 happy. The changelog is a solid evidence: ~100 lines of #if..#endif hell were required.
GHC 7.6 also blocks us from using some dependencies. For example, the upcoming branch with Riemann zeta function inevitably requires exact-pi >= <IP_ADDRESS>, which requires GHC 7.8 at least.

Dooooo it
Kill it all.
Honestly I'd go as far as to support only 7.10.3 or newer.  Alll other ghc
versions in 7.8 and 7.10 major versions have a bug in the register
allocator for any codes working on doubles and floats st the same time, and
I'm sure there's algorithmic accelerator Tricks we could use to better
approximate or get to the right answer that could benefit from float /
double tricks ?  Idk.
But 7.10.3 is the only one that doesn't have that register allocator bug.
On Thursday, November 3, 2016, Bodigrim<EMAIL_ADDRESS>wrote:

After release of arithmoi-<IP_ADDRESS> with stability fixes, IMHO it is time
to stop supporting GHC 7.6 and base-4.6. It is really outdated and the
maintenance is extremely tedious: we need to insert CPP macros here and
there to make GHC 7.6 happy. The changelog is a solid evidence: ~100 lines
of #if..#endif hell were required.
GHC 7.6 also blocks us from using some dependencies. For example, the
upcoming branch with Riemann zeta function inevitably requires exact-pi

= <IP_ADDRESS>, which requires GHC 7.8 at least.

You can view, comment on, or merge this pull request online at:
https://github.com/cartazio/arithmoi/pull/43
Commit Summary

Drop support of GHC 7.6
Simplify class constraints for GHC HEAD

File Changes

M .travis.yml
https://github.com/cartazio/arithmoi/pull/43/files#diff-0 (3)
M Math/NumberTheory/ArithmeticFunctions/Standard.hs
https://github.com/cartazio/arithmoi/pull/43/files#diff-1 (10)
M Math/NumberTheory/Logarithms.hs
https://github.com/cartazio/arithmoi/pull/43/files#diff-2 (5)
M Math/NumberTheory/Powers/Cubes.hs
https://github.com/cartazio/arithmoi/pull/43/files#diff-3 (3)
M Math/NumberTheory/Powers/Fourth.hs
https://github.com/cartazio/arithmoi/pull/43/files#diff-4 (3)
M Math/NumberTheory/Powers/General.hs
https://github.com/cartazio/arithmoi/pull/43/files#diff-5 (3)
M Math/NumberTheory/Powers/Integer.hs
https://github.com/cartazio/arithmoi/pull/43/files#diff-6 (7)
M Math/NumberTheory/Powers/Squares/Internal.hs
https://github.com/cartazio/arithmoi/pull/43/files#diff-7 (3)
M Math/NumberTheory/UniqueFactorisation.hs
https://github.com/cartazio/arithmoi/pull/43/files#diff-8 (10)
M Math/NumberTheory/Utils.hs
https://github.com/cartazio/arithmoi/pull/43/files#diff-9 (9)
M arithmoi.cabal
https://github.com/cartazio/arithmoi/pull/43/files#diff-10 (7)
M test-suite/Math/NumberTheory/TestUtils.hs
https://github.com/cartazio/arithmoi/pull/43/files#diff-11 (10)
M test-suite/Math/NumberTheory/TestUtils/Compose.hs
https://github.com/cartazio/arithmoi/pull/43/files#diff-12 (14)
M test-suite/Math/NumberTheory/TestUtils/Wrappers.hs
https://github.com/cartazio/arithmoi/pull/43/files#diff-13 (72)

Patch Links:

https://github.com/cartazio/arithmoi/pull/43.patch
https://github.com/cartazio/arithmoi/pull/43.diff

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/cartazio/arithmoi/pull/43, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAQwtg-taGuQpXBD4_b8FGxI1V2ZYcDks5q6mkugaJpZM4KpBQB
.

My vote is to drop ghc 7.8 support once ghc 8.2 will be released.


[Bug]: Using Lucia in Sveltekit Throwing 500 Code Error on Redirect from Callback

Package
@lucia-auth/oauth
Describe the bug
'Cannot use `cookies.set(...)` after the response has been generated'
'Cannot use `setHeaders(...)` after the response has been generated'

Above two are the root reason, that I find myself after exploring little bit!
The entry point of error is in hook.server.ts
import { auth } from '$lib/server/lucia';
import type { Handle } from '@sveltejs/kit';

export const handle: Handle = async ({ event, resolve }) => {
  // Below Somewhere error Happens
  event.locals.auth = auth.handleRequest(event);
  return await resolve(event);
};

So, also mentioning that, myself currently using sveltekit, drizzle, upstash for the project

Error: {"status":500}
    at coalesce_to_error (file:///Users/sukhpreetsingh/apps/clinic-app/.svelte-kit/output/server/index.js:107:7)
    at handle_fatal_error (file:///Users/sukhpreetsingh/apps/clinic-app/.svelte-kit/output/server/index.js:139:51)
    at resolve (file:///Users/sukhpreetsingh/apps/clinic-app/.svelte-kit/output/server/index.js:2767:20)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async Object.handle (file:///Users/sukhpreetsingh/apps/clinic-app/.svelte-kit/output/server/chunks/hooks.server.js:4:10)
    at async respond (file:///Users/sukhpreetsingh/apps/clinic-app/.svelte-kit/output/server/index.js:2590:22)
    at async file:///Users/sukhpreetsingh/apps/clinic-app/node_modules/@sveltejs/kit/src/exports/vite/preview/index.js:173:5

Above is full Error log

Closing this issue as, I thought that redirect & fail can replace, totally before written code,
    return new Response(null, {
      status: 302,
      headers: {
        Location: '/'
      }
    });

Yet, I needed to revert the changes to fix this!


Event sort options outdated in schema

https://developer.predicthq.com/resources/events/#param-sort
Missing some options from documentation.

"relevance" missing


ignoreMissingMigrations default not specified

What version of Flyway are you using?
4.2.0
What did you do?
Opened flyway.conf to set it up for the first time.
What did you expect to see?
A default mentioned.
What did you see instead?
# Ignore missing migrations when reading the metadata table. These are migrations that were performed by an
# older deployment of the application that are no longer available in this version. For example: we have migrations
# available on the classpath with versions 1.0 and 3.0. The metadata table indicates that a migration with version 2.0
# (unknown to us) has also been applied. Instead of bombing out (fail fast) with an exception, a
# warning is logged and Flyway continues normally. This is useful for situations where one must be able to deploy
# a newer version of the application even though it doesn't contain migrations included with an older one anymore.
# true to continue normally and log a warning, false to fail fast with an exception.
# flyway.ignoreMissingMigrations=

Good catch! Fixed.


First close bracket moved to end when has ansi colors

Expected behavior
My App v1.0.0
Usage: command argument [option] [parameter]
Actual behavior
My App v1.0.0
Usage: command argument [option [parameter]]
Steps to reproduce
term.echo('My App 1.0.0\nUsage: command argument [option] [parameter]');
Browser and OS
Chrome 73.0.3683.75 - Ubuntu 18.04.2 LTS
https://codepen.io/fval/pen/aMRPwK

The problem is that unix formatting don't know how to handle brackets. The output is correct but by default you can mix both ansi escapes and unix formatting so you need to escape formatting.
$.terminal.from_ansi('My App �[32m1.0.0�[39m\nUsage: command <argument> [<option>] [<parameter>]')
"My App [[;#008400;]1.0.0][[;inherit;]\nUsage: command <argument> [<option>] [<parameter>]]"

so first closing bracket is not disappearing but it close [39m formatting prematurely, so everything that after is outside of formatting even real closing formatting that at the end. This is correct behavior. It would be really hard to figure out what user want if he want brackets or mix formatting with ansi escapes so there is option, unixFormattingEscapeBrackets added by Marcel Link in PR.
var term = $('body').terminal(function(command, term) {
    term.echo('My App 1.0.0\nUsage: command <argument> [<option>] [<parameter>]');
}, {
    unixFormattingEscapeBrackets: true
});

this is global option but I can make it work in echo if needed.

Sorry I didn't see this option in documentation.
Works great for me.


Tensor API Refactoring

I've gone through it with some initial comments. Do you have any of this refactoring implemented? I think it might be useful to look at some examples of the changes it implies in user code.

I partially do in the tensor-refactoringof that repository, which is incomplete at this moment. I'll try to do a full conversion of a whole example instead and let you know.

It strikes me that Tensor<T> behaves somewhat like a Scala type class, when we think of it as representing behavior (e.g. math ops) applied to NDArray. Might be worth adopting such idea explicitly, and/or looking at how "type classes" are typically modeled in Java.   (random thought)

It strikes me that Tensor<T> behaves somewhat like a Scala type class, when we think of it as representing behavior (e.g. math ops) applied to NDArray. Might be worth adopting such idea explicitly, and/or looking at how "type classes" are typically modeled in Java. (random thought)

In the current proposal, a Tensor is simply a NdArray that has been allocated by TensorFlow, so they are quite interchangeable. Just to illustrate it, ˋNdArray could have been renamed to ˋTensor while ˋTensor could have been renamed ˋTFTensor.

Thinking of it, with that new proposal, if we opt for concrete classes per type (TInt32, ˋTString, ...), we could probably just rename ˋNdArray to ˋTensor (a name that I prefer) and simply drop the actual ˋTensor<> class.

@Craigacp : here is a little sample of what the migration would be from actual Tensor API to the new one. Note that this code does not compile yet and also assume that will find a way to avoid those try-with-resources everywhere, like we are discussing.
It's not the best example though as there is not much happening here but well, at least there is one.

WRT Scala type classes there was some discussion of typing tensors in Java Scala and kotlin at the jvmls after Erik Meijer's talk and I think the consensus was that the Java type system isn't powerful enough. That said my type theory isn't too strong and John Rose was taking about something like that on Twitter during it (https://twitter.com/JohnRose00/status/1156308406585532416?s=19).

@jxtps, do you have some opinion/suggestions on this topic?
I think it’s pretty to close to what you were discussing before in the SIG mailing list.

Hey, sorry I have been neck-deep in some other projects, will try to take a look later this week.

I think that @Craigacp has a good point that the Java type system isn't powerful enough (and in some cases may even be counter-productive).
To @karllessard's point about NDArray vs Tensor, I prefer to separate the tensor (view) vs buffer (storage) separation.  2 cents.
May I suggest you take a look at tensorflow-scala, which has a fairly well-developed set of types.   At least for comparison sake.

Nice work on the RFCs @karllessard et al! I have a couple of somewhat open-ended questions / comments (sorry I'm a little all over the place):

The creation of "small" tensors could use a fluency boost. Tensors.ofDouble(new long[]{2,2}) could instead be Tensors.ofDouble(2, 2), i.e. using long... dims, right? (This was from https://github.com/karllessard/community/blob/master/sigs/jvm/rfcs/20190606-java-tensor-io.md )

Since everything needs to start from a Shape (or long[]), maybe add convenience methods on there to easily create constants, variables & tensors?
Or is that too many ways to do the same thing? There already seems to be quite a few...

Feels like we should enumerate a couple of use-cases and make sure the APIs work smoothly for them.

Do people really construct "small-to-medium" sized tensors as constants in their code? I.e. is TInt32.ofShape(3, 2, 2).row(... likely to see significant use?
So far I've been working mostly with images, and I get them into tensorflow by creating a large, flat float[] that I have carefully populated, then attach a size and create a tensor. That works reasonably well, but obviously has some memcopy overhead.
Could obviously switch to using the NdArray write primitives.

I'd be a little wary of calling a set(float value, long... indices) type method since then you'd have to recompute the flat array index on every call.
The Iterator<> is probably fine, but then there's no "indexing help" (not super-needed, so this may be fine - probably better to start with a slim interface and then we can add conveniences as we discover the real need?)

I'm not 100% clear on what the best way to handle the various <Type> tags.

For starters, I still doubt the usefulness of making the dtype part of the type signature.
If we're going to keep it, your proposal sounds broadly feasible, though there's something that nags at me but I can't quite put my finger on it. I think I'd prefer to have a class DataType<T_ForNdArray, T_ForTfInternals> but I don't think that would really work since the corresponding Tensor type would still need to independently specify the T_ForNdArray and we'd want to avoid that duplication.

Note that users would be able to create new DataTypes if there's a non-private DataType.create method, though that's probably not a big deal in reality.

Avoid boxing like the plague. Use int instead of Integer wherever possible - there's boxing overhead, there are some java <-> scala interop issues (weird corner cases), and you never actually want an Integer, you always want an int.

If we're going to create all the separate primitive-type-specific classes, then there's really no need to use Integer et al basically anywhere.

With tf.math.add(c, c) returning a specific tensor type (TInt32), you'll have to overload the implementation of tf.math.add at least once per tensor type.

That's going to add up fast - if there are N ops and M data types, then you'll end up with O(N*M) implementations. Sure, that's in generated code, but still - you're putting a big burden on the framework code / devs for marginal user benefit, and e.g. IntelliJ auto-complete will offer dropdowns that repeat the same function M times, cluttering it up and greatly reducing its value.

With public abstract class Tensor<T> implements NdArray<T> { ... } and public final class TInt32 extends Tensor<Integer> implements Numeric { ... }, how will TInt32 offer direct IntNdArray functionality?

What is the full mapping between T_ForNdArray and dtype?

The Tensor type-safety features you're looking to create could maybe work in Scala where there are typedefs, primitive specialization of generic classes, and multiple inheritance via traits.
In Java, which is a great language in so many ways, you will be banging your head against the type system at every turn.
Framework developer time and effort is a very limited resource. Tensor dtype safety is not that big of a deal in practice. Let's not create an enormous type edifice that we will be struggling to design and maintain when doing:
public class Tensor {
   final public DataType dtype;
   ...
   public IntNdArray asInts() {...} // Throws exception if dtype isn't compatible
   ...
}

would get the job done in a fraction of the time/effort and be easy to use.
The only substantive loss I see in shedding the <T> from Tensor is that some operations change the datatype, e.g myFloats > 0.5f produces a boolean tensor. Similarly tf.image.decode_png produces a uint8 tensor. The first time around those can come as surprises.
A potential workaround for that is to default to auto-casting and issuing a warning. The user can then choose to either turn off auto-cast (making it an error that throws an exception), or accept auto-cast (silencing the warning).

Thanks @jxtps, there is a lot to reply to right now but let me start with your latest post:

With tf.math.add(c, c) returning a specific tensor type (TInt32), you'll have to overload the implementation of tf.math.add at least once per tensor type.

There is no need to overload the operation per tensor type. The type of the operation (and in the case of math.add, the type of its output) are still inferred by the input operands. So the signature remains Add<T> add(Operand<T> x, Operand<T> y), the only thing that changes is that T instead of being Integer will be a TInt32, that you can access in eager mode via something like Operand.data(), i.e.

tf.math.add(x, y) returns Add<T>, which implements Operand<T>.
tf.math.add(x, y).data() returns a TInt32

With public abstract class Tensor implements NdArray { ... } and public final class TInt32 extends Tensor implements Numeric { ... }, how will TInt32 offer direct IntNdArray functionality?

That's because in this new RFC, I dropped the primitive-based NdArray interfaces, which ends up to be a bad decision. I restored them in a new prototype I'm working on right now to prevent the problem you reported.
In this new prototype, tensor types like TInt32 does not extend Tensor anymore. Instead, Tensor<T> remains a reference to a native TF tensor, like now. But T is a tensor type instead of a java type. And it is the tensor type T that extends from NdArray, which you can access by calling Tensor.data(). For example,  something like
Tensor<TInt32> t = TInt32.tensorOfShape(2, 2);  // TInt32 extends from IntNdArray
t.data().at(0).write(new int[] { 100, 101 })  // possible because IntNdArray accepts to write a int[]
            .at(1).write(new int[] { 102, 103 });

What is the full mapping between T_ForNdArray and dtype

In this new prototype, then it is up to dtype to decide how it can map tensor data to NdArray. So in case of TInt32, it is pretty simple and can simply work with integers, because both are 32-bits. But, for example, TFloat16 could still implement the FloatNdArray interface, while working on a ByteNdArray, mapping each float value to only 16-bits. I added support for this as well in the code (to be discussed, of course).

The Tensor type-safety features you're looking to create could maybe work in Scala where there are typedefs, primitive specialization of generic classes, and multiple inheritance via traits.

If the trend is to remove the type-safety feature completely, we sure can do but we need to ask more broadly first because I think some users enjoy this aspect of TF Java. Nonetheless, the snippet you provided as a alternative is pretty close to what my new prototype is exposing, except that by keeping type-safety present, only one method is required (data())  which already returns the right type of NdArray.
To be continued...

The creation of "small" tensors could use a fluency boost. Tensors.ofDouble(new long[]{2,2}) could instead be Tensors.ofDouble(2, 2), i.e. using long... dims, right?

I tried to simplify it too by moving the factory methods to the datatype class instead of Tensors (so you don't need to specify it). In the RFC, it is TInt32.ofShape(2, 2) but now I would change it to TInt32.tensorOfShape(2, 2), since the return value would be a Tensorand not a TInt32.
Also, we could have some shortcuts for rank-0 and rank-2 tensors, such as TInt32.scalar(1) and TInt32.vector(1, 2, 3, 4).

Or is that too many ways to do the same thing? There already seems to be quite a few...

That is a very valid point, there is also the Constant class that builds up tensors... ideally, it should be clear for the user which one to use in which and not give him too many options...

Suggestion that you close this PR if it is obsolete.

Thanks @EronWright for raising this up, while a lot of stuff is still accurate with what has been merged lately, some of it must be updated. Instead of just closing it, it could also be interesting to make changes and merge it in TF community repo so it gains some visibility to all TF developers. I can take a look at it.


V2 minor async status changes

Related to https://github.com/bluesky/ophyd/pull/1096
This just adds a __repr__ and __str__ method (the latter pointing to the former) to AsyncStatus for ophyd v2. It also changes the return type of AsyncStatus.exception().

Please can you fix the merge conflicts now I merged the other one...

Docs warning is fixed in #1096

@coretl do you happen to know why the docs job is failing? I know for now the segfault can be ignored in the test job. But unsure about docs.

WARNING: failed to reach any of the inventories with the following issues:
intersphinx inventory 'https://blueskyproject.io/event-model/objects.inv' not fetchable due to <class 'requests.exceptions.HTTPError'>: 404 Client Error: Not Found for url: https://blueskyproject.io/event-model/objects.inv

I've fixed this on master


Add-on styling seems to be outdated (Call Request)

Boilerplate:
{** block-description:tmpl_call_request **}

        {$phone_number.prefix}
         {$phone_number.postfix}

        {include file="addons/call_requests/views/call_requests/components/popup.tpl" product=false link_text=__("call_requests.request_call")}

CS-Cart 4.3.5 Addon:
{** block-description:tmpl_call_request **}

{$phone_number.prefix}{$phone_number.postfix}

{include file="addons/call_requests/views/call_requests/components/popup.tpl" product=false link_text=__("call_requests.request_call")}

-- Others might have a similar issue.
[first issue on git!]

Hi! Actually, we decided to abandon from CSS prefix "ty-" in boilerplate to the side of clean bootstrap HTML and CSS as more as we can. That's why styling might seems to be outdated.
P.S. Congratz with your first issue :)

Hi, thanks for the response.
That makes sense. You're trying to keep the code as minimal as possible.
Quick pointer;
What I assume I should do is customize the module with ty- if I need to yes?
Thanks again,
Nipun Senadheera

On Mar 1, 2016, at 1:06 PM, Evgenii Ermolaev<EMAIL_ADDRESS>wrote:
Hi! Actually, we decided to abandon from CSS prefix "ty-" in boilerplate to the side of clean bootstrap HTML and CSS as more as we can. That's why styling might seems to be outdated.
P.S. Congratz with your first issue :)
—
Reply to this email directly or view it on GitHub.

Actually you can customize it as you want :) .But I'm think default classes will be quite enough to do that. If you want to use some custom classes for block I offer you add them from admin panel in block manager and build your CSS starting from your custom class.

Great, that's the approach I took. thanks for the pointers! :)
Regards,
Nipun Senadheera

On Mar 1, 2016, at 4:47 PM, Evgenii Ermolaev<EMAIL_ADDRESS>wrote:
Actually you can customize it as you want :) .But I'm think default classes will be quite enough to do that. If you want to use some custom classes for block I offer you add them from admin panel in block manager and build your CSS starting from your custom class.
—
Reply to this email directly or view it on GitHub.


Bootstrap quick refresh on startup ignored

When receiving a bootstrap message on startup, the BSM is always dropped because the cand_rp_list is not empty.
The cand_rp_list is always populated with at lease a static entry for SSM <IP_ADDRESS>/8
https://github.com/troglobit/pimd/blob/25608aa840b5d12bdfecf8bf9852277cf01d44d5/src/pim_proto.c#L3246-L3252
Maybe add a check to see if there are any dynamic entries in cand_rp_list?
Or use a timer on startup to allow during first 60 seconds or so?

Good catch!  What do you think about this patch?
diff --git a/src/pim_proto.c b/src/pim_proto.c
index 9d63557..1168247 100644
--- a/src/pim_proto.c
+++ b/src/pim_proto.c
@@ -3243,12 +3243,31 @@ int receive_pim_bootstrap(uint32_t src, uint32_t dst, char *msg, size_t len)
 	    return FALSE;
 	}

-	/* Probably unicasted from the current DR */
+
+	/* We have a Cand-RP-list already, check for static ones ... */
 	if (cand_rp_list) {
-	    /* Hmmm, I do have a Cand-RP-list, but some neighbor has a
-	     * different opinion and is unicasting it to me. Ignore this guy.
-	     */
-	    return FALSE;
+	    struct cand_rp *rp;
+	    int any = 0;
+
+	    for (rp = cand_rp_list; rp; rp = rp->next) {
+		struct rp_grp_entry *rp_grp = rp->rp_grp_next;
+		struct grp_mask *grp = rp_grp->group;
+		rpentry_t *entry = rp->rpentry;
+
+		if (entry->adv_holdtime == (uint16_t)0xffffff)
+			continue; /* Skip configured entries */
+
+		if (!IN_PIM_SSM_RANGE(grp->group_addr)) {
+		    logit(LOG_INFO, 0, "Ignoring PIM Bootstrap candidate, CRP %s for %s exists.",
+			  inet_fmt(entry->address, s1, sizeof(s1)),
+			  netname(grp->group_addr, grp->group_mask));
+		    any = 1;
+		    break;
+		}
+	    }
+
+	    if (any)
+		return FALSE;
 	}

 	for (vifi = 0; vifi < numvifs; vifi++) {

@josvarix Yeah, I'm still not sure if we should ignore all static/configured entries or just the hard-coded one for SSM, so I put all the code in just as a POC.  If we just skip all static ones the second if()-statement, including the log messages, could be removed entirely and the code be much simpler.

I think is better to ignore all static/configured entries. The purpose is only allow unicast bootstrap message if we do not already have received any previous bootstrap message on startup.

@josvarix Agreed, thank you for the input (and the bug report)! :smiley:


Wrong year if currentCalendar is NOT gregorian

Please check this situation since this returns invalid dates.
Expiration dates in credit card is in gregorian calendar.
To replicate just change the calendar in the settings to Japanese for example.

Here is the change I made to the code in order to get it right
+ (NSInteger)currentYear
{
    static NSCalendar *__calendarToUse = nil;
    if (__calendarToUse == nil) {
        __calendarToUse = [NSCalendar calendarWithIdentifier:NSCalendarIdentifierGregorian];
    }
    NSDateComponents *currentDateComponents = [__calendarToUse components:NSYearCalendarUnit fromDate:[NSDate date]];
    return currentDateComponents.year;
}


Cluster GPR176, TSC22D1, DPAGT1, CHRM4: exploration for MorphMap paper (ORF+CRISPR)

This cluster was found in #7 as strong (+/-) correlation in both ORF and CRISPR but not (completely) strongly connected in the KG.
Looking across ORF and CRISPR plots there, there are a few other adjacent genes we should consider adding to this and then figure out a story for them (if needed, contacting a biologist who studies some subset of these genes).

Notebook 1
LZTS2 is not present in the CRISPR dataset. Here are the remaining genes
ORF

CRISPR

We will discuss the exploration of the story in this doc (private link)

Knock-down of Musashi-1 (MSI1) in SU_MB002 medulloblastoma cells has been reported to lead to down-regulation of GPR176, CHRM4, and TSC22D1 and up-regulation of MYT1 by RNA seq analysis, mirroring our observed correlations (Kameda-Smith et al). MSI1 may play an essential role in nervous system development (Kameda-Smith et al). Additionally, GPR176, CHRM4, and TSC22D1 are reported to be down-regulated in Alzheimer's Disease (AD) associated TREM2 variants (Liu et al JExpMed2020).

https://plexsearch.com/search?ids=entrezgene%3A11245&ids=entrezgene%3A1132&ids=entrezgene%3A117257&ids=entrezgene%3A12672&ids=entrezgene%3A17932&ids=entrezgene%3A21807&ids=entrezgene%3A226154&ids=entrezgene%3A25111&ids=entrezgene%3A362291&ids=entrezgene%3A365468&ids=entrezgene%3A381413&ids=entrezgene%3A4661&ids=entrezgene%3A498545&ids=entrezgene%3A84445&ids=entrezgene%3A8848#tab=gds

Great, this paragraph has been finished and put in the main text. Presumably @niranjchandrasekaran needs to assemble the final figures into the main paper, so leaving it to him to close this issue when ready.

This story was included in the morphmap paper


Modifications required to make the flight stack work with new drivers.

This pull request will be updated periodically.  No changes are currently pushed.  I will inform you via email when the pull request is ready to be processed.

Is this ready for code review?

@jywilson @mcharleb Could you indicate if this ready for review and incorporation? Are you in sync with Julian's latest state?

My apologies.  This pull request was submitted by mistake.  It will be resubmitted by Mark Charlebois in a combined pull request with other changes.


merge from arlac77/template-github-action,arlac77/template-kronos-component

package.json

fix(engines): add >=14.10.1 remove >=14.9.0 (engines.node)

Codecov Report

Merging #821 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #821   +/-   ##
=======================================
  Coverage   28.94%   28.94%
=======================================
  Files           1        1
  Lines          76       76
  Branches        1        1
=======================================
  Hits           22       22
  Misses         54       54

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 43db2ee...02e6d2c. Read the comment docs.


Allow setting SecretType in writeConntectionSecretToRef

What problem are you facing?

Currently, all managed resources with connection information write secrets of type connection.crosspane.io/v1alpha1.
https://github.com/crossplane/crossplane-runtime/blob/378a57303ea0a2d13ae21668044364ad8d1035d9/pkg/resource/resource.go#L37
How could Crossplane help solve your problem?

Allowing a user to set alternate secret types (with a default of connection.crosspane.io/v1alpha1) could enable the case where controllers for external secret stores (such as Vault or SecretManager), could watch for secrets of a given type in the cluster and sync them to the external store.

@hasheddan Is the idea that we would want to make this configurable because controllers for secret stores like Vault expect a fixed secret type? i.e. They won't accept ours? One downside of making this configurable is that we won't easily be able to classify secrets as a Crossplane connection secret or not. I wonder if we could address this by supporting different secret types, but logically not considering them a 'connection secret'. e.g. As part of rethinking writeConnectionSecretToRef perhaps we support something like writeCustomSecretToRef? 🤔

For a tekton ssh key, we would have to set the type and annotatations:
apiVersion: v1
kind: Secret
metadata:
  annotations:
    tekton.dev/git-0: github.com
type: kubernetes.io/ssh-auth
stringData:
  ssh-privatekey: <private-key>

@turkenh this is fixed by https://github.com/crossplane/crossplane/pull/3029 ? Both annotations and type?

@chlunde correct, example https://marketplace.upbound.io/providers/upbound/provider-aws/v0.15.0/resources/rds.aws.upbound.io/Instance/v1beta1#doc:spec-publishConnectionDetailsTo-metadata


Can not pass multiple query parameters with same key name

Describe the bug/problem
On passing multiple query parameters with the same key name but different values, only one persists in the final query parameter map. The value of this key is the last pair of key and value added in the Request section.
Bug Preview

Steps to Reproduce the bug/problem

Go to the 'URL Params' tab of the 'Request' section.
Add two or more than two URL Parameters with same key name and different values.

Expected behavior
All the URL Parameters should be passed to the URL.
Device Info (The device where you encountered this issue):

OS: Windows
Version: Windows 11

Not a bug. Query parameters keys are supposed to be unique.

Hello @animator !!!!
With reference to some resources I would like to clarify what I was trying to point out:

MDN docs
*Here with proper code snippet examples it is shown that how 'getAll()' method returns all the values associated with a given
search parameter as an array. (JS)

Stackoverflow
*Correct way to pass multiple values for the same parameter name.

In the following example(JAVA) for same named input, while selecting all the checkbox, console shows 'stocks=google&stocks=meta&stocks=microsoft'

Since both the server can read it and browser can produce it so to test the server side script, we need to have the functionality in API Dash too.

Thanks @royshruti for the explanation & the relevant links.
I am reopening this issue.

@animator For this to work we will need to update the expectation for codegen request models which are explicitly set to override here.
/// GET request model with override query params
const requestModelGet3 = RequestModel(
  id: 'get3',
  url: 'https://api.apidash.dev/country/data?code=US',
  method: HTTPVerb.get,
  requestParams: [
    NameValueModel(name: 'code', value: 'IND'),
  ],
);


ENHANCEMENT: Update all task elements to standardized syntax

What this PR does / why we need it:
Updates all task elements to standardized syntax. This is a beautification enhancement and nothing more.
name: xxxxxxxxxx inside (app) tasks now has uniform syntax as Create < app > Docker Container and Create < app > Directories with consistent spelling, capitalization, proper app name, etc. where before there was multiple styles of syntax.
Which issue (if any) this PR fixes:
Fixes #
Any other useful info:
Output of the playbook is now more consistent and professional looking

I like changes like this - but it's a waste of time unless it can be enforced with build conditions (as we do with markdown linting for example) otherwise it drifts over time.
Any thoughts how we could do that?
Also, please squash down to one commit.

Sorry but I now nothing of GH CI.
I also don't know how to "squash down to one commit" - I just edited files and saved them to the same clone/patch. I don't know any other way.
As for how to get possibly get this type of thing "under control" for the future, two things:

I'm of the belief that most people copy, paste, then edit. If my theory is correct, after this PR is pulled, the source used to copy, paste, then edit will be standardized and we can hope for more standardized results in new apps added to AN.
I've been considering submitting a commented templet role  that contributors can use as a base to copy, paste, then edit. I'm very happy to do this, and with a lot of comments, but I want to know you're likely to pull it in first.

I like changes like this - but it's a waste of time unless it can be enforced with build conditions (as we do with markdown linting for example) otherwise it drifts over time.

p.s. Um, the submissions get reviewed by a human who catches other minutiae. :-)

Sorry but I now nothing of GH CI.

I also don't know how to "squash down to one commit"

A Google search will help you for both of these.

p.s. Um, the submissions get reviewed by a human who catches other minutiae. :-)

Yes, but I don't/won't catch everything. CI will mean I don't have to.

This is complicated for me as I don't use GH Desktop and GH won't allow me to pull down only this patch for me to play with temporarily and push back. Sorry but I'm only an amateur "developer."
The changes are really simple and easy to view. I'm guessing the review display would look the 99% the same if it's squashed or not. Would you be a dear and review the changes and then choose the squash and merge choice if everything is kosher please?
REF: https://stackoverflow.com/questions/35948131/github-squash-commits-from-web-interface-on-pull-request-after-review-comments


fix: fix wait-for-jobs boolean params

Your development orb has been published. It will expire in 30 days.
You can preview what this will look like on the CircleCI Orb Registry at the following link:
https://circleci.com/developer/orbs/orb/ankorstore/toolbelt?version=dev:d633708403c54a31338b4df0aed5db2f743b16eb

Your development orb has been published. It will expire in 30 days.
You can preview what this will look like on the CircleCI Orb Registry at the following link:
https://circleci.com/developer/orbs/orb/ankorstore/toolbelt?version=dev:d633708403c54a31338b4df0aed5db2f743b16eb

Your development orb has been published. It will expire in 30 days.
You can preview what this will look like on the CircleCI Orb Registry at the following link:
https://circleci.com/developer/orbs/orb/ankorstore/toolbelt?version=dev:0af54f5f17d0c219c4da70b7a3b664a9813bcf0d

Your orb has been published to the CircleCI Orb Registry.
You can view your published orb on the CircleCI Orb Registry at the following link:
https://circleci.com/developer/orbs/orb/ankorstore/toolbelt?version=0.5.2


maybe renamed

https://github.com/rickhonda/upfpy/blob/3badc49e8eb0c0baa48bfbdac16e703f07165b9b/upfpy/__init__.py#L2
Did you rename the package at some point?

Yes I did

I had a first attempt that was too disorganized to show


Ix-Blind allows action elemente similar to mdsp css container

Prerequisites

[X] I have read the Contributing Guidelines.
[X] I have not leaked any internal/restricted information like screenshots, videos, code snippets, links etc.

Suggestion / feature request
TLDR
feature request:
I want to be able to place action elements at the top right corner of an ix-blind.
i want to be able to place any element there
i want to provide these elements via a slot

I think this feature is useful if you have the need to allow a user to trigger actions for a group/collection of things at once. E.g.
Deleting available items within the component or editing content of one specific container but not the other one without the need to visually divide the action from the component.
Background
I'm working on a project view list, and I want to present each available project as a tile-like element. However, the standard tiles provided by the ix framework don't quite fit my use case.
I had considered using ix-cards or ix-push-cards, but those don't allow me to properly format the content the way I need. So, I've decided to build a custom component from scratch, trying to leverage as many ix components as possible. The component I've come up with looks a bit basic, but it should do the job. I'm still working on refining the design and functionality but here it is:

As you can see i am utilizing an ix-blind and here starts my feature request:

I want to be able to place action elements at the top right corner of an ix-blind.
i want to be able to place any element there
i want to provide these elements via a slot

at the end i wish that i have something similar to the container in mdsp css

https://design.mindsphere.io/patterns/container.html#tab3anchor6
here a little mockup:

Hello @Johanneslueke, something like in your mockup should already be possible with the slots that are provided via the ix-blind. I have prepared a little example here:
https://stackblitz.com/edit/cicesl3v?file=src%2Fblind-header-actions.tsx
If you have further question don't hestitate to ask!

Hi, @matthiashader that is awesome. But this information is missing from the documentation. perhaps this information should included there 😄


Spicify a VRF in settings.py

Is your feature request related to a problem? Please describe.
I cannot spicify a VRF to which ip-addresses will belong.
Describe the solution you'd like
I have a lot of tenants with overlap ip-space.

Yes we have the same problem.
Fortunately everything in our vCenter belongs to the same VRF. So my solution at the moment is to declare a default VRF and make sure it is used for every ipam post/get request.
I still have some Problems when looking for existing addresses in Netbox but I can share my code after I fixed those.

Hello @inetman28 and @Haeki!
I too have this need for one of my instances and wrote a function which lookups up the VRF based on the most specific matching parent prefix. As @inetman28 mentioned though, this does not solve the use case of having overlapping IPs thus I've left it out of the main project so far.
Would it be preferable to have an additional key in the vCenter hosts list that allows you to specify the VRF all IPs detected in that vCenter instance should go in to?

Would it be preferable to have an additional key in the vCenter hosts list that allows you to specify the VRF all IPs detected in that vCenter instance should go in to?

exactly. This option must specify in vcenter hosts list because automatically ip-lookup will not work correctly.

Sounds good. I'll test that out and report back.

Yes an additional key in the vCenter hosts list would be perfect.
From my testing I can tell that the search_prefix() function needs to be changed.
Also when checking in Netbox for existing IPs or prefixes the vrf has to be filtered or else there will be a Problem with multiple objects found.

Got it. Those are all great points. Let me see what I can do.

I created a Pull Request with my Implementation: Specify a VRF in settings.py Implementation
We have been using this for the last few weeks without Problems.
But I am not sure if this will be enough to deal with Identifying and assigning VRF and tenants problem #114 so maybe you will have to improve this further.


create: hex() argument can't be converted to hex

$ ./cli.py create
Traceback (most recent call last):
  File "./cli.py", line 6, in <module>
    sleth.cli.main()
  File "/Users/mids/Projects/Foundry/sleth/sleth/cli.py", line 65, in main
    args.func(args)
  File "/Users/mids/Projects/Foundry/sleth/sleth/cli.py", line 16, in cmd_create
    contract_address = instance.create(contract)
  File "/Users/mids/.virtualenvs/sleth/lib/python2.7/site-packages/pyepm/api.py", line 92, in create
    'gas': hex(gas),
TypeError: hex() argument can't be converted to hex

api.py should probably be modified to use str instead of hex; or config.getint should be used to cast the gas and gasprice variables to integer.

Had already done so for transact and call using str, will apply to create also.

Done in 0.8.1


creation of task with title that contains a url

Tried to run:
agen newTask -title "td7 opti http://fabien.viger.free.fr/oc/td7/"
and got the following:
agen:2024/02/13 18:20:19 open /home/megui/.agen/tasks/td7 opti http:/fabien.viger.free.fr/oc/td7: no such file or directory

same as #37


Add documentation about nif converter filter

Basic Service Reference
API Doc. A short sentence to the nif-converter API endpoint, another one to "informat"
API Users getting started

This is done.

Api Users Getting started

NIf-Converter api doc

Basic services reference

looks good.


model.predict(adata) behavior, what is exactly obsm['CPA_pred'] ?

Hi,
Regarding the tutorial on OOD perturbation prediction on Kang: https://colab.research.google.com/github/theislab/cpa/blob/master/docs/tutorials/Kang.ipynb
I don't get model.predict(adata) behavior, what is exactly saved in obsm['CPA_pred'] ? because afterwards R2 is computed between obsm["CPA_pred"] and layers["counts"]:
x_true = cat_adata.layers['counts']
x_pred = cat_adata.obsm['CPA_pred']
In the notebook tutorial x_true and x_pred have the same shape. Shouldn't the expected behavior be to take control cells and stimulate them ? In that case x_pred should have same number of samples as control cells for a particular cell_type, not the same number as stimulated cells. What am I missing ?
Thanks.

Hi, I have the same question. After some brainstorming, I understood that CPA_pred contains the predictions for all cells. Therefore, the prediction for control cells would represent "predicted stimulated cells," while the prediction for real stimulated cells would correspond to "reconstructed stimulated cells."
I'm not entirely sure if this interpretation is correct, so I would also appreciate confirmation from the authors.
Thanks.


bug

hi please fix this bug for new version
/G:/flutter/.pub-cache/hosted/pub.dartlang.org/pull_to_refresh-1.6.4/lib/src/smart_refresher.dart:434:9: Error: No named parameter with the name 'keyboardDismissBehavior'.
keyboardDismissBehavior:
^^^^^^^^^^^^^^^^^^^^^^^

Same here

Same here

So what do you say we do now?
The developer is not responsive !?

https://github.com/peng8350/flutter_pulltorefresh/pull/442

use version 1.6.3

what is happenning

+1

Duplicate #424,If your flutter version is >=2.0.0,use >= 1.6.4.Otherwise use 1.6.3


Define plant relations in the database

So the main idea behind this PR is to define relationships between different plants/genus/subfamily/family (please note that the difference between varieties and species is not well-defined yet, I will aggregate them into a single term plants for now, but will adapt the code accordingly in the future).
Important notes:

the genus, family, and subfamily information is distributed across different tables for better structuring reasons.
Why do we use an additional column <entity_name>_id e.g. genus_id in the plants table instead of referencing directly by the name, which is available directly in the CSV file?

Based on the current development state, in order to insert plants due to the foreign key constraints(one cannot reference to empty fields) we have to have genus/subfamily and families in our database first. This information will be available through their independent files e.g. data/distinctGenus.csv, which are not fixed yet. So this may change in the future

Why we don't use any foreign keys in the relations table?

The relations should provide cross-table relationships e.g. a genus doesn't like a family. Unfortunately, PSQL does not allow to reference a single foreign key to multiple tables.
[x] The buildserver is happy.
[x] The PR is rebased with current master.

Checklist

[x] I added unit tests for my code
[x] I fully described what my PR does in the documentation
(not in the PR description)
[x] I fixed all affected documentation
[x] I fixed all affected decisions
[x] I added code comments, logging, and assertions as appropriate
[x] I mentioned every code not directly written by me in reuse syntax
[ ] remove commented code from the migration

Review

[ ] Documentation is conforming to our Documentation Guidelines
[ ] Examples are well chosen and understandable
[ ] Code is conforming to our Coding Guidelines
[ ] Code is consistent to our Design Decisions

Important notes:

Please always add such notes within the documentation itself (in this case the decision). Nobody reads text in the PRs afterwards, but people read the documentation we have in the repository.

the genus, family, and subfamily information is distributed across different tables for better structuring reasons.

This is also basically what the decision decides :+1:

Why do we use an additional column <entity_name>_id e.g. genus_id in the plants table instead of referencing directly by the name, which is available directly in the CSV file?
Based on the current development state, in order to insert plants due to the foreign key constraints(one cannot reference to empty fields) we have to have genus/subfamily and families in our database first. This information will be available through their independent files e.g. data/distinctGenus.csv, which are not fixed yet. So this may change in the future

What exactly may change in the future? The decision should capture how we finally want it.

Why we don't use any foreign keys in the relations table?
The relations should provide cross-table relationships e.g. a genus doesn't like a family. Unfortunately, PSQL does not allow to reference a single foreign key to multiple tables. So we have to tradeoff here

Please describe advantages/disadvantages of the trade-off in the decision.

I accidentally pushed wrong commits here, I removed them with a force push.

Hey @markus2330,
thank you for your feedback!

Please always add such notes within the documentation itself (in this case the decision). Nobody reads text in the PRs afterwards, but people read the documentation we have in the repository.

Let me kindly disagree with you here on the completeness of this PR. First, I would like to mention that the notes were added here to point the reviewer's attention to the details mentioned in the description once again before touching on the actual documentation. I do know from my personal experience how overwhelming is the reviewing process in big teams and how easy it is to oversee changes in the documentation. The PR is well-documented though:

the genus, family, and subfamily information is distributed across different tables for better structuring reasons.

This is also basically what the decision decides 👍

exactly, however, worth mentioning

Why do we use an additional column <entity_name>_id e.g. genus_id in the plants table instead of referencing directly by the name, which is available directly in the CSV file?

Based on the current development state, in order to insert plants due to the foreign key constraints(one cannot reference to empty fields) we have to have genus/subfamily and families in our database first. This information will be available through their independent files e.g. data/distinctGenus.csv, which are not fixed yet. So this may change in the future

What exactly may change in the future? The decision should capture how we finally want it.

Sorry, if this may sound unclear to you. As you may have noticed, my writings are very extensive, but I should probably add more details and explanations in the future, so we don't lose much time on such clarifications. Ok, let's go through this one:
- this is a temporary solution since there is still no ETA on when we will get more information on the structure of genus/subfamily/family and how these tables are going to be populated. I clearly understand that not all knowledge could be gained at once
- hence, genus/subfamily/family CSV files are not fixed yet
- hence, their tables are empty yet
- nevertheless, plants table should somehow refer to the genus/subfamily/family tables
- each plant has genus/subfamily/family names as string values in the plant_detail CSV file
- when we insert plants from the plant_detail CSV file, we are not allowed to refer to empty tables
- hence, I update tables with foreign keys manually after insertion (link)
- As you can see these details are worth mentioning in the PR description but in the documentation itself. However, more important information like the structure of the tables or foreign keys is well documented.
So, answering your questions:

Reference by id can be easily replaced with reference by name for foreign key relationships described above. This may change in the future, back to the direct reference by the name during the insertion
The decision has already its final state

Why we don't use any foreign keys in the relations table?

refer to Relations between plants in the decision and in the database documentation
However, I do agree here that for a person without any prior knowledge could get confused. The following statement about PSQL PSQL does not allow to reference a single foreign key to multiple tables. could be added to the decision to make it even more clear.

Hopefully, now it is more clear and makes sense to you

jenkins build please

Would be great to have some other review here!

I have a few notes to add here.

It's a minor note but we should have consistency in the naming of database tables. Personally I don't care if table names are in plural or singular but we definitely shouldn't mix. Here we have singular e.g. plant_detail  and plural e.g. relations.
If we are using a relational database we should make sure we are utilizing its strengths. If a foreign key can't point to multiple tables and the tables are so similar we should maybe choose a different approach.
Here is a quick sketch of what I have in mind.

erDiagram

enum_taxonomic_rank {
  VARCHAR family
  VARCHAR subfamily
  VARCHAR genus
  VARCHAR species
}

enum_relationship_type {
  VARCHAR companion
  VARCHAR neutral
  VARCHAR antagonist
}

taxon }|--|o taxon: "parent"
taxon {
    enum enum_taxonomic_rank
}

plant_detail }|--|| taxon: ""

relationship }|--|| taxon: "left"
relationship }|--|| taxon: "right"
relationship {
  int strength
  enum enum_relationship_type
}

CREATE TYPE TAXONOMIC_RANK AS ENUM ('plant', 'genus', 'subfamily', 'family');
CREATE TABLE taxon (
  id SERIAL NOT NULL PRIMARY KEY,
  rank TAXONOMIC_RANK NOT NULL,
  parent_id integer NULL
);
ALTER TABLE taxon
ADD CONSTRAINT taxon_parent_fkey FOREIGN KEY (parent_id) REFERENCES taxon (id);

CREATE TYPE RELATIONSHIP_TYPE AS ENUM ('companion', 'antagonist', 'neutral');
CREATE TABLE relationship (
  id SERIAL NOT NULL PRIMARY KEY,
  strength integer NOT NULL CHECK (strength >= 0),
  type RELATIONSHIP_TYPE NOT NULL,
  left_taxon_id integer NOT NULL,
  right_taxon_id integer NOT NULL
);
ALTER TABLE relationship
ADD CONSTRAINT relationship_left_taxon_fkey FOREIGN KEY (left_taxon_id) REFERENCES taxon (id);
ALTER TABLE relationship
ADD CONSTRAINT relationship_right_taxon_fkey FOREIGN KEY (right_taxon_id) REFERENCES taxon (id);

CREATE TABLE plant_detail (
  id SERIAL NOT NULL PRIMARY KEY,
  taxon_id integer NOT NULL
);
ALTER TABLE plant_detail
ADD CONSTRAINT plant_detail_taxon_id_fkey FOREIGN KEY (taxon_id) REFERENCES taxon (id);

Sure, I'll provide a more specific example towards the end of the week.

I'm not sure where I would be using metatables in the example here.
The idea builds upon your approach but squashes the tables for different taxonomic levels into one, the taxons table.
A taxon refers to its parent by its parent_id and you can see whether it's a genus, family, subfamily, or species through the type.
As you mentioned the hierarchical structure we use is not fixed yet so this enum could be extended.
I have worked on a more specific example.
It's based on the schema of this commit according to the migrations.
Some notes:

It might make sense to normalize plant_detail and taxon as it doesn't seem like the relation between them will ever be anything but one-to-one.
I don't understand why plant_detail.common_name is an array.
A lot of things in plant_detail could be removed, e.g. the names of the taxons (genus, family, ...)
I have not made use of relationships.strength here but it could be used for ordering or filtering.

CREATE TYPE taxonomic_rank AS ENUM ('species', 'genus', 'subfamily', 'family');
CREATE TABLE
    taxons (
        id SERIAL PRIMARY KEY NOT NULL,
        rank taxonomic_rank NOT NULL,
        name VARCHAR NOT NULL,
        parent_id INTEGER REFERENCES taxons (id) NULL
    );

CREATE TYPE relationship_type AS ENUM ('companion', 'antagonist');
CREATE TABLE
    relationships (
        id SERIAL PRIMARY KEY NOT NULL,
        strength INTEGER CHECK (strength >= 0) NOT NULL,
        type relationship_type NOT NULL,
        left_taxon_id INTEGER REFERENCES taxons (id) NOT NULL,
        right_taxon_id INTEGER REFERENCES taxons (id) NOT NULL
    );

ALTER TABLE
    plant_detail
ADD
    COLUMN taxon_id INTEGER REFERENCES taxons (id) NOT NULL;

-- Example
--
-- For this example we use the following notation for companion "<->" and antagonist ">-<"
-- Consider the following relationships between plants:
-- Radish <-> carrot
-- Radish <-> potato
-- Carrot >-< potato
-- Marigold <-> carrot
-- Marigold <-> radish
--
-- We want to plant carrots and radish and get suggestions for it.
-- When looking for companions we would expect the result just to be marigold.
-- Potato wouldn't be in the result due to it's antagonist relationship with carrot.
--
-- Let's insert the plants.

         LEFT JOIN taxons family ON (family.rank = 'family' AND (family.id = subfamily.parent_id OR family.id = genus.parent_id));

@aidnurs
@markus2330
Can we please push this issue forward?
It's quite the blocker for almost all my further work.

Can we please push this issue forward?

Absolutely. I think it is fastest if you take over this PR and update your proposal directly in the decision. Maybe simple move the migration files to some subfolder where they are used, let us merge this and then continue with a new PR? Currently there are actually several decisions intermixed:

how the hierarchy information is stored
if there are metatables, how they would look like
how the relations between plant table should look like

As far as I understood only "1." is really a decision, the other follow from it. For "1." there are 3 approaches:

one table per taxonomy rank (as proposed by @aidnurs) (problem: species is both meta and actual)
two tables: one for abstract taxonomy rank and one for concrete plants (again has some overlap)
every plant and ranks in one table (with columns to decide about rank, if concrete etc.)

The decision should clearly capture the pros/cons of these 3 approaches, and write non-decision parts (what follows) to implications. As it is your topic anyways, you could do a (preliminary) benchmark, as speed is probably the main concern (there might be quite many lookups involved when traversing the hierarchy).
Thanks for your SQL code, it worked for me. The SQL should better be in a separate file within the pull request, so that I can comment on the specific lines (some things like enum for relationship we already discussed, so best if you bring everything up-to-date before creating the PR).

It might make sense to normalize plant_detail and

Please use the new table name "plants", everywhere. plant_detail was just a misunderstanding and is now renamed to plants.

taxon as it doesn't seem like the relation between them will ever be anything but one-to-one.

Depends on the design, biologically a plant is part of all the ranks except for species, which are not part of variety.

A lot of things in plant_detail could be removed, e.g. the names of the taxons (genus, family, ...)

Depends on the design, we should first decide on it, and then clean up.
Unaddressed problems I see:

how to deal with varieties (they basically inherit all the data from the species, with a few exceptions). We unfortunately currently don't know  how (incomplete) the database from permapeople is and which effects it has on our plants table. We already know that they don't have taxonomy levels right now.
ranks should inherit from each other. E.g. if we create an icon for a family, this icon should be used for all varieties of tomatoes. This should work on any taxonomy rank.

Rebased on master.

@markus2330
Subfolders created.
Ready to be merged!


[WIP]: Add Blog Post for KEP-3202-beta release (PLACEHOLDER)

This is a placeholder PR for the blog post explaining the updates to the Auto-refreshing Official CVE feed.

Thank you so much for getting on this and creating a wonderful draft @cailynse :)
/sig security

Thanks a lot for the draft and placeholder work! Now, most of the changes are merged, let's write the blog :)

Hey cailyne, I cannot push to this PR (of course), so could you do a rebase of this branch on main? This branch is pre-cve feed fix and other fixes which prevent it to build locally. I can fix my local copy of your branch but not the remote. If you use gh and git it looks like this:
gh repo sync caylinse/website
git checkout main && git fetch && git pull origin main
git checkout KEP-3202-blog && git rebase main
git push origin KEP-3202-blog --force-with-lease

If you prefer applying a git patch instead of clicking all these buttons you can git apply this thing. mahe_review.txt

Thanks for this @mtardy! I've not used git apply before - very neat, and handy!

I'm going to assume this is ready for review, and:
/retitle Add Blog Post for KEP-3202 beta (CVE feed)

I'm going to assume this is ready for review, and: /retitle Add Blog Post for KEP-3202 beta (CVE feed)

I was literally writing this ahah

Hello, Comms Lead for the 1.27 release here. This feature blog is tracked for release, the deadline for submitting the draft is on 4th of April
Thank you!

@cailynse please tag me when you are able to make updates to dates as suggested by @harshitasao on the file name and metadata.
Happy to /lgtm after that!

@PushkarJ  - should the date be set to the deadline, April 4th? Or before?

Oops @cailynse you maybe right and I guess I misunderstood.
@harshitasao can you clarify which of the following is true:
do we want the blog to be "ready to merge" with /approve and /lgtm by April 4 ?
OR
Do we want just a PR open without need for any approvals or reviews by April 4? (Which is already what the blog's current state is)
OR
Is the publication date for this blog set to April 4?

Hey @PushkarJ Sorry for the delayed response. We want just a PR open with a complete blog drafted by April 4th, which is the hard deadline, to better plan the release dates and avoid missing out. The feature blogs publication will start after the release (i.e., after April 11th). We're finalizing the publishing schedules, and I'll let you know the publication date.

Hello, Comms Lead for v1.27 here. The publication order and date for the Feature Blog series has been finalized and the tracking board is updated.
The publication date for this article is 25-04-2023 (April 25).
Thank you!

/lgtm

/assign @sftim

/hold cancel


Is there a way to install Mcrypt extension for php5.6?

I am trying to configure an old project via devenv.sh and I see that they use this package for older php versions.
But I've tried to add Mcrypt extension and it says it's missing.
I am new to Nix and don't know how to handle this better but my assumption would be to create my own derivation for Mcrypt extension, build it and provide result to nix-phps so it can pass it further to php interpreter into withExtensions function? And then withExtensions function should handle adding the Mcrypt ext to php.ini file?

Hello,
I made a couple of PRs to add some missing extensions for PHP 5.6, maybe you can get some inspiration from them?
Here's a page listing a couple of commits where you can see them: https://github.com/fossar/nix-phps/pulls?page=3&q=is%3Apr+is%3Aclosed
Hope it helps.

I would suggest to use buildPecl to build that new extension you're trying to introduce.
I wish I could give more support, but I tend to limit the support I give to open-source these days because of some everyday life stuff.
Consider sponsoring this project or its maintainers to get a quicker personal support.

In the and I resolved it via this code:
{
  buildPecl,
  lib,
  fetchFromGitHub,
  libmcrypt,
  pkg-config,
}:

let
   version = "0.0.0";
   revision = "c37265eacdd0186cb3b0bfeb0e0104c8563807ef";
in
buildPecl {
  inherit version;

  pname = "mcrypt";

  src = fetchFromGitHub {
    owner = "php";
    repo = "php-src";
    rev = revision;
    sha256 = "sha256-aDiGbOqy2L8Qqd6IliEN19Oa8JO1uDSEju6uUN4b0XI=";
  } + "/ext/mcrypt";

  nativeBuildInputs = [ pkg-config ];
  buildInputs = [ libmcrypt ];

  configureFlags = [ "--with-mcrypt=${libmcrypt.outPath}" ];

  doCheck = true;
  checkTarget = "test";

  meta = {
    changelog = "https://github.com/php/php-src/commit/${revision}";
    description = "Mcrypt from 5.6.4";
  };
}

It gets PHP 5.6.4 and its mcrypt code and it works well together.

Good! You could also submit a PR against this project so it's available for everyone!

I've done it separately in the file but would definitely be cooler to get it from this project!
I'll try to do that tomorrow

Looks like it was moved to PECL https://www.php.net/manual/en/intro.mcrypt.php, https://pecl.php.net/package/mcrypt

@jtojnar I couldn't use anything from Pecl because their API version is different than PHP5.6 so I build the one being released together with PHP5.6 https://github.com/php/php-src/commit/c37265eacdd0186cb3b0bfeb0e0104c8563807ef

Added a pr for this https://github.com/fossar/nix-phps/pull/340


Code Refactoring

Aim of the PR
This Pull Request follows up on and closes #12: it aims at refactoring the code we have written so far, mainly to avoid instantiating objects outside of the functions that then call them. Some changes in the comments are also proposed, especially in the alerts.py file, where code blocks have been slightly reorganised.
Changes Made

The main goal of the edits is to eliminate the instantiations we are currently making and could avoid in files like alerts.py, risks.py and homepage.py.

To better describe the goal of the modifications, here is the example that was provided in the issue:

# ------------------------------------------------------------------------------
# App layout (finally!)

# Instantiating the navigation bar
nav = Navbar()

# Adding a first separator between the navigation bar and the button
space = dcc.Markdown('---')

# Instantiating the button to change the map layer style
layer_style_button = build_layer_style_button()

# Adding a second separator between the button and the map
separator = dcc.Markdown('---')

# Finally instantiating the map object
map_object = build_alerts_map()

# Gathering all these elements in a HTML Div and having it returned by the AlertsApp function
def AlertsApp():
    layout = [nav,
              space,
              layer_style_button,
              separator,
              map_object]

    return html.Div(layout)

It gives, after the refactoring:

# ------------------------------------------------------------------------------
# App layout (finally!)

def AlertsApp():
    layout = [Navbar(),                             # Instantiating the navigation bar
              dcc.Markdown('---'),               # Adding a first separator between the navigation bar and the button
              build_layer_style_button(),       # Instantiating the button to change the map layer style
              dcc.Markdown('---'),               # Adding a second separator between the button and the map
              build_alerts_map()]                  # Finally instantiating the map object

    return html.Div(layout)

Second Commit
As noticed by @abdi-adel, there was no way to come back to the home page from "specialised" dashboards via the navigation bar. The goal of the second commit is to correct this impossibility by adding the home page to the dropdown menu of the navigation bar (and to correct a typo).

Thanks a lot for your review, comment and approval @VincGargasson!

This part of the code has been changed too in my PR. I guess the first PR that will be merged won't have to deal with conflicts 😅

I guess I was going to merge this one now but do let me know if you prefer that we first move forward with yours! I haven't had the time to review it yet but I could definitely make it a priority. And in any case, if we merge mine beforehand, don't hesitate to ping me could I be of any help to manage the conflicts that will appear 😊

As the number of function we have in this script is growing fast, I'm wondering if we should to put set standard in our function's docstrings. Maybe this would require a specific PR to update it in the whole app.

I couldn't agree more! And I am also aligned with the need for a specific PR to update it in the whole app.
Once this is done, I think that there are tools that can help us generate a clean documentation out of the docstrings in the code, which could be useful as well while scripts become more and more complex.

Merged following the discussion above and after oral exchange with @VincGargasson and @Akilditu 😊


Pixel perfect box-drawing characters in GVim

Is your feature request about something that is currently impossible or hard to do? Please describe the problem.
GVim delegates drawing box-drawing characters to a font-rendering engine. This makes the characters overlap, blurry and never align property. Most terminals draw those characters by themself.

Describe alternatives you've considered
Borrow the code from libvte.

There's also another issue that occurs when drawing popup borders, see https://github.com/vim/vim/issues/6043. Can you reproduce this?

The images are good, but it would be helpful to get the text to put into vim.

There's also another issue that occurs when drawing popup borders, see #6043. Can you reproduce this?

Yes, it is the same problem.

Is this always desired? I was curious and looked around, and seems like on iTerm at least there was an issue complaining about the native box drawing (iTerm does do custom box drawing) taking control away from the font which may have the box drawing glyphs fit their style more. The solution there was they added an advanced option to revert back to the font's glyphs: https://gitlab.com/gnachman/iterm2/-/issues/6151
I wonder if another solution would be to stretch the glyph to line up better, but it depends on the font rendering engine, and for the grayscale boxes (e.g. U+2591 "░") that wouldn't work.

FWIW, the kate editor in KDE plasma 5.24, and geany, look like gvim.

Is this always desired?

Probably not. I guess it is not too big of an issue on HiDPI displays.

I wasn't trying to say this is not useful btw, as the gaps do seem annoying. Just trying to understand if there will be some users who may prefer to use the font's rendering instead (probably applies more to the borders and lines than the blocks).

The alacritty terminal also has an option font.builtin_box_drawing that can be set to either true or false. Wouldn't something like this be the best approach so that users can decide themselves?

I suppose you may also want to configure anit-aliasing settings? E.g. on Windows enable ClearType and set the the 'renderoptions' setting.

Configuring anti-alialiasing will affect the look of all the glyphs, not only box-drawing characters. I like how anti-aliasing is applied to my font overall.

Isn't this just a GTK3 bug?
The GUI libraries we use must be able to draw characters properly.
Working around bugs in those by adding code in Vim sounds like a really bad idea.
Only if there are some rendering parameters we could use those perhaps.
But then why would we need to inspect characters to decide how to best draw them?
That's also a task of the rendering engine, not of Vim.  Especially since we use fixed cell sizes, it should just work.

Both libvte and GTK projects are under Gnome umbrella, however they decided to address this issue inside libvte.
I haven't looked how GVim draws the characters, but if Vim already depends on libvte I wonder if it would be feasible to reuse its drawing routine.

Both libvte and GTK projects are under Gnome umbrella, however they
decided to address this issue inside libvte.
I haven't looked how GVim draws the characters, but if Vim already
depends on libvte I wonder if it would be feasible to reuse its
drawing routine.

It is a bit disappointing that you report an issue without even looking
around for more information....
Vim intentionally miminizes dependencies on libraries.  It appears
libvte is a terminal widget, not something you would use inside an
editor.  Well, we have libvterm, which is included as source code to
avoid dragging in a dependency (where versioning is very difficult to
handle, and the code actually required fixing).  I don't know how libvte
and libvterm are related, if at all.
Anyway, if libvte has some example code, that could perhaps be used
inside Vim.  But I very much doubt it actually is something we want to
do.  If someone wants to spend time on making this work perfectly, and
after review it is considered a good improvement, without introducing a
new maintenance burden, there is a chance for it.  I can't estimate how
big that chance is.
--
Apparently, 1 in 5 people in the world are Chinese.  And there are 5
people in my family, so it must be one of them.  It's either my mum
or my dad.  Or my older brother Colin.  Or my younger brother
Ho-Cha-Chu.  But I think it's Colin.
/// Bram Moolenaar -- @.*** -- http://www.Moolenaar.net   \
///                                                                      \
\\        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

I'm sorry. I saw many mentions of libvterm in Vim discussions and I confused it with libvte. Those are totally separate projects, with similar goals however.
As for example code, this is how libvte is doing it https://github.com/GNOME/vte/blob/master/src/minifont.cc

Isn't this just a GTK3 bug?
The GUI libraries we use must be able to draw characters properly. Working around bugs in those by adding code in Vim sounds like a really bad idea. Only if there are some rendering parameters we could use those perhaps. But then why would we need to inspect characters to decide how to best draw them? That's also a task of the rendering engine, not of Vim. Especially since we use fixed cell sizes, it should just work.

I think part of the issue here is that some fonts don't have perfectly stitched border, and also if you have non-standard line-heights, it would be impossible for the fonts to match up perfectly at the border. You also can't get perfectly grayscaled boxes and instead get a dithered shading instead. So not a bug in GTK3 per se, but it does seem like some fonts could have addressed this by fixing their glyphs better. But it's ultimately a nice-to-have but optional feature. Looking at Alacritty's threads seems like there were quite a bit of back and forth:
Original issue proposal which was shot down (filed by the same author as this issue): https://github.com/alacritty/alacritty/issues/3262
Another issue to propose the same thing, where the maintainers eventually decided to implement this reluctantly: https://github.com/alacritty/alacritty/issues/5485
More issues that came out after it was implemented since Alacritty now didn't respect the original font's glyphs: https://github.com/alacritty/alacritty/issues/5809
From the last one, it does seem like this is the kind of thing that will lead to more people complaining about why things work certain ways and not drawn another way, so it's definitely the kind of feature that would require a little bit of upkeep post-commit to keep people happy (since people who want this usually have very particular way they want their boxes drawn).

Also, I would imagine if this is implemented we should do this at least for GTK and Windows so Vim isn't so platform dependent (and for MacVim as well). I think the implementation part is not hard anyway (therefore we shouldn't use a library to do it), but rather it's the deciding what to do and what options to expose etc (all of which would be Vim specific) that's the annoying part.

This sounds like it's not worth the effort and we may get complaints for whatever behaviour we will settle on. So I vote for closing it. It's not like there are not enough issues to spend time on :)

This sounds like it's not worth the effort and we may get complaints
for whatever behaviour we will settle on. So I vote for closing it.
It's not like there are not enough issues to spend time on :)

Right, the problem stems from the idea that you can use a font to draw
boxes and lines, while that is not something a font renderer was really
made for (they are optimized to draw text very well, sharp and smooth,
to make it pleasant to read, which is what we do all the time thus it is
very important to optimize for it).  Then you get into an impossible choice
between making a font renderer that can draw things well that it wasn't
made for and working around it by not using a font renderer for some
selection of characters but hard coding what the glyph must look like
for them.  Basically drawing pixels directly instead of using a font,
and ignoring all information about the properties of the currently
selected font.
Of course there is more history, in the past when characters were used
to draw graphics because characters were the only things you could draw
anyway.  In MS-DOS times whole menu systems were made that way.  Some
installers still rely on that mechanism being available.  But I don't
see much use for it when editing text files with Vim.
So let's settle on it being possible to draw boxes and lines with
characters if you really want to, but accept that they won't look all
that pretty.  Not something that Vim needs to spend time on making
better.  Just using the existing font renderer should be good enough.
--
Q. What happens to programmers when they die?
A: MS-Windows programmers are reinstalled.   Java programmers reincarnate
after being garbage collected, unless they are in permgen, in which case
they become zombies.  Zimbu programmers leave a stack trace that tells us
exactly where they died and how they got there.
/// Bram Moolenaar -- @.*** -- http://www.Moolenaar.net   \
///                                                                      \
\\        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

closing then


[Bug Report] Some of docs links not working

Describe the bug
On https://gymnasium.farama.org/content/basic_usage/, some of the links (top 2) at the complete bottom don't work. The last link (3rd in the list) works.
The links not working:

Code example
No response
System info
No response
Additional context
No response
Checklist

[X] I have checked that there is no similar issue in the repo

Same as https://github.com/Farama-Foundation/Gymnasium/issues/419


functional AMQP broker & backend

All tests passing.

Coverage increased (+25.08%) to 78.157% when pulling 39ac4d8bf5bf3249be59267ac6834be561107e08 on amqp into d4c0e323bfbf5f1c39d1ca7fef024d044000bb35 on master.


Cannot Add a role to a user ( new or existing user )

Description
Orchid provides roles to group permissions and adds them to a certain user.
the issue is I cannot add a role to an existing user or create a new user with a role.
To Reproduce
Steps to reproduce the behavior:

got to the users list
select a user to edit ( or click new user )
add a role to it

Expected behavior
a role should be assigned to the user
Screenshots
Issue face when trying to update:

Issue faced when creating a new user with a role:

@HijenHEK looks like it more about mass assignment problem within your User model. You're basically allowing roles field to be filled. Edit your protected $fillable property so it didn't contain roles (or maybe you have empty $guarded)

Should work with guarded properties since version 12.4.4


Support for POWR3 (especially power monitoing!)

Please explain your feature request in a one or two sentences.
Support for new POWR3 device.
Higher power (25A) allows finally to monitor energy usage of typical household inverts/heaters/etc that require 20amp circuits

I suspect this will work by default (I actually dont have any POWR2 devices) ?

Is your feature request related to a problem? Please describe.

Nope! Just a shiny new device to add :-)

Any particular eWeLink devices that this relates to?

https://itead.cc/product/sonoff-powr3/
POWR3 device

Anything else?

I’d be able to add support for the device if i have one shared to my ewelink account!

Gonna close this issue and will track in #271


Minimal Syntax

In addition to LMQL's current style of clause-based syntax, we want to add a new "minimal" syntax mode, that allows to express programs in a more concise way.  More specifically, we want to provide simplified syntax with reasonable defaults, that reads more like standard Python.
Example
To illustrate consider the following snippet:
"A list of things not to forget when going to the sea (not travelling): \n"

things = []

for i in range(4):
   "-[THING]" where STOPS_AT(THING, "\n")
   things.append(THING)

"My favourite is[FAVORITE]" where FAVORITE in things

From this, we derive the following semantics:

As shown, prompts can start directly on the top-level of query. If this is the case, we assume argmax as the standard decoding method for the top-most prompt.

The model used to decode such prompts may either be defined by the surrounding context, e.g. by annotating the function with @lmql.query(model=<model>) or by setting a globally-applicable LMQL default model, e.g. lmql.set_default_model(<model>). In general, this allows users to omit the from clause, and, if needed, to switch to a different model across several queries, more easily.

where conditions can be specified inline, avoiding the need for a global where clause. At the same time, this enables constraints like FAVORITE in things, that refer to program variables like things, currently not possible.

Overall, this simplified syntax aligns LMQL fully with Python, where the only extra construct needed beyond top-level strings is the where keyword.
Other applications
Sub-Queries
In place of template variables like [THING], we should allow sub-queries. For instance in the above, instead of [THING], users can specify:
"[sample(temperature=0.7)  "-[THING]" where STOPS_AT(THING, "\n")]"

In this case, THING values are decoded using different decoding parameters, however the prompt should be inherited from the surrounding context.
One Line Syntax
With this simplified syntax mode, we can also express small programs more concisely. For instance the following would be a valid LMQL program:
"The country code of {country} is[CODE]"
In such one-line programs, it would also make sense to define the last template variable (e.g. CODE here), as the return value of the function. This is comparable to how lambda expressions work in Python.

<IP_ADDRESS> added inline constraints, one line syntax (lmql.F) and the simplified syntax.


[Testing phase, don't review] Migrate to new pool

Migrate to new pool

CI is currently failing on Windows due to #4152.

The fix is in. Now it is failing due to its own PR-specific reasons.


MSVC compiler warning

From the MSVC compiler:
D:\a\libcoro\libcoro\include\coro/when_all.hpp(447): warning C4033: 'coro::detail::make_when_all_task' must return a value
[D:\a\libcoro\libcoro\build-release-cl\examples\coro_thread_pool.vcxproj]
D:\a\libcoro\libcoro\include\coro/when_all.hpp(447): message : Flowing off the end of a coroutine results in undefined behavior when
promise type 'coro::detail::when_all_task_promise<return_type>' does not declare 'return_void' [D:\a\libcoro\libcoro\build-release-cl\examples\coro_thread_pool.vcxproj]
          with
          [
              return_type=unsigned __int64 &&
          ]
D:\a\libcoro\libcoro\include\coro/when_all.hpp(475): message : see reference to function template instantiation
 'coro::detail::when_all_task<unsigned __int64 &&> coro::detail::make_when_all_task<coro::task<uint64_t>,unsigned __int64&&>
(awaitable)' being compiled [D:\a\libcoro\libcoro\build-release-cl\examples\coro_thread_pool.vcxproj]
          with
          [
              awaitable=coro::task<uint64_t>
          ]
D:\a\libcoro\libcoro\examples\coro_thread_pool.cpp(74): message : see reference to function template instantiation
'coro::detail::when_all_ready_awaitable<std::vector<coro::detail::when_all_task<unsigned __int64
&&>,std::allocator<coro::detail::when_all_task<unsigned __int64 &&>>>>
coro::when_all<std::vector<coro::task<uint64_t>,std::allocator<coro::task<uint64_t>>>,coro::task<uint64_t>,unsigned __int64&&>
(range_type)' being compiled [D:\a\libcoro\libcoro\build-release-cl\examples\coro_thread_pool.vcxproj]
          with
          [
              range_type=std::vector<coro::task<uint64_t>,std::allocator<coro::task<uint64_t>>>
          ]

Unfortunately, I lack the C++ knowledge to fix this myself.

@a858438680. do you know how to fix this?

@a858438680. do you know how to fix this?

Yes, I know. Just don't use co_yield and change it to co_return and change some of the member functions in the promise type.
I tried to change this locally. But I can't tell why the author designed it this way. So I didn't create a pull request. You can ask him and if he thinks I'm right, I will create a PR.

@jbaldwin, are you open to a PR from @a858438680 which would fix this? Did you have any specific design goals in mind, or is s/he free to innovate?

Honestly I don't remember why I did it this way a few years ago, looking at the code using co yield shouldn't be necessary. I'm definitely open to a PR to clean this up.

Honestly I don't remember why I did it this way a few years ago, looking at the code using co yield shouldn't be necessary. I'm definitely open to a PR to clean this up.

Here is the thing, I'm also glad to create a PR but I also thinks that the api of when_all is not proper, co_await a when_all_task should return the value of all tasks rather than get a container of some handles.
But if you think that it is ok now and does not want a broken change, I will create a PR which just cleans the warning. Otherwise, if you think that adding a new api or changing the behavior of co_await when_all is acceptable, please tell me you your opinion.

The original intent behind the coro::when_all api is so that you can compose it with coro::sync_wait as well as co_await it within a coroutine.  I realize now typing this out there is no test for coro::when_all within the test_when_all.cpp file so I'm going to add one.
Can you propose an API that would return the values directly that would work in both situations? Or would it require two implementations, one coro::when_all to work outside a coroutine context and another to work inside coroutine contexts?  The former would mean all instances of coro::sync_wait(coro::when_all(...awaitables...)) would become coro::when_all(...awaitables...).  If you have a way to make it work both ways without duplicating it I'd love to see that.
How would you handle multiple exceptions being thrown?  Right now you get each one upon calling each output task's return_value() and can handle them individually, I think you'd need a std::variant<return_type, std::exception> type result to capture each one appropriately for the user.

I'm kind of thinking something new coro::when_all_values(awaitable...) -> coro::generator<result<T, E>>, perhaps two APIs isn't the worst.

I've implemented a temporary solution to address the build warning and have also raised a pull request for it. @jbaldwin , when you have a moment, could you please take a look and provide your feedback?

Thanks for taking the time to write this up to fix the warning.

#260


gen-guest-c: optional parameters with null pointers

In the C guest generator, functions which have optional parameters of the form:
x: func(a: option<a>, b: option<b>) -> _

Currently output signatures like:
void interface_x(interface_option_a_t *a, interface_option_b_t *b);

Where it would be nice to support the more C-like interface:
void interface_x(interface_a_t *a, interface_b_t *b);

where a null pointer could be used to imply the optional parameter value instead.

As far as I can tell, implementation here would require that OptionLift and OptionLower operations have additional information in core indicating if they are parameters that are being lifted or lowered, so the special casing can apply.

I think that may not be necessary since the context of a generator fixes that, e.g. for C when generating an imported call lifts only happen for results. So given the context of import or export, and C, I think that designates what's being lowered and what's being lifted.

I think this might still be necessary actually, as when defining an imported function one ends up with a wrapper looking like the following:
void fn (float *maybe_a, float *maybe_b) {
  interface_option_float_t a;
  a.is_some = maybe_a != NULL;
  if (maybe_a) {
    a.val = *maybe_a;
  }
  if (a.is_some) {
    //... logic...
    option = 1;
    option1 = *payload0;
  } else {
    option = 0;
    option1 = 0;
  }

where my concern is that we end up copying the data out of the pointers in this approach when perhaps we should be optimizing this?
For what it is worth, I hit up against similar issues in the JS generator.
Alternatively I can just implement the wrapper approach as described above for now, leaving the door open to further optimizations in future to remove the extra copy.

Ah this is something I think it safe to optimize for later. The set of data possibly being extraneously loaded per call would be a small enough fixed size that I doubt this'd ever be an issue. If it is an issue we could try adding restrict or w/e corresponding attributes C has for "this doesn't alias" or things like that.

Ok, I'll work to the above for now.

Landed in https://github.com/bytecodealliance/wit-bindgen/pull/453.


Support<EMAIL_ADDRESS>release

@acao @benjie Took a long long time than I initially anticipated but I finally released<EMAIL_ADDRESS>It includes a number of small breaking changes:
https://github.com/graphql/graphql-js/releases/tag/v15.0.0-alpha.1
https://github.com/graphql/graphql-js/releases/tag/v15.0.0-alpha.2
https://github.com/graphql/graphql-js/releases/tag/v15.0.0-rc.1
Can you please test it with packages in this repo so I can release 15.0.0 without worrying about breaking GraphiQL?
Note: It doesn't yet include two-stage introspection that I currently working on and will add in the next release since it's not a breaking change.

awesome work @IvanGoncharov ! i tested it with first alpha before, looking forward to giving it a spin!

@IvanGoncharov good news, only a few failing tests around error message formatting, and the minified build is looking solid with some manual and automated tests. I'll push a PR  tonight, and hopefully I can check in on some of the breaking changes in more depth, as well as test out the LSP server

yeah just that one failing test related to graphql-config for the dev server. everything else is looking great overall. I'll keep it open and bump to the next RC if/when that comes.

@acao @benjie Just release RC2 can you please test it?
https://github.com/graphql/graphql-js/releases/tag/v15.0.0-rc.2

yes, can do!

@IvanGoncharov as noted on the PR we merged, we need to remove peer resolutions up to graphql 14 across the board, correct?

@acao Yes, it would be great!

@IvanGoncharov i did a patch release where we merged the #1204 bump, and will follow up with peer resolutions!

then we can follow up with seperate issues for adopting each new feature, i can create a whole project on here for it

@IvanGoncharov going to close this, we pre-released with 15 support a while ago, and i'm going to open new issues to adopt new features, as we are likely about to rebuild the doc explorer from scratch


prevent duplicate filenames in METS files

This commit will prevent a METS file from being processed when filenames are duplicate. The filename is the identifier in the end.
Currently this makes that the file gets indexed to elastic search first and then updated because the document ID already exists. Resulting in a different set because the data in ES has no duplicates like the METS file has.

Closed this pull-request in favor of https://github.com/delving/hub3/pull/89. In that pull-request this functionality will be merged in.
We currently can't edit this remote branch.