gcc: only disable aligned_alloc for darwin build/host/target platforms

Before this change a Darwin gcc would output binaries that avoid
aligned_alloc, regardless of target platform. That's fine for Darwin
targets, but not for non-darwin targets such as pkgsCross.raspberryPi.
This change replaces the single configure flag with a flag for
each of build, host, target.
Idea by @trofi.
Things done

Built on platform(s)

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

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

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

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

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

[ ] Fits CONTRIBUTING.md.

Excuse my ignorance, but what is the next step in getting this merged? More approvals?

Getting review from @NixOS/darwin-maintainers would be nice. Otherwise I support merging it tostaging.

Time for staging, or wait a bit more?

I guess this can only take place after 2023-05-15?

Does the ban apply to darwin-only changes as well?

Well, perhaps we could say that gcc isn't a critical package on darwin (as clang is the default stdenv.cc), but any breaking changes have cutoff today (except desktop stuff).

@eliasnaur Since this only affects cross, do you think you could massage this into a zero rebuild change?

If it only affects cross, it should be enough to just do the inverse of this: https://github.com/NixOS/nixpkgs/blob/120dd6a8032fa2dcf9197b0d49614b07b20581fe/pkgs/development/compilers/gcc/12/default.nix#L72-L74

If I make the PR zero-rebuild as you describe, won't it break cross-building a darwin gcc from linux? If so, I'd rather wait 2 weeks for this PR to get into staging. I have other mass-rebuild reproducibility PRs that need to wait for staging anyway.

cross-building a darwin gcc from linux

macOS/Darwin is a special case, as not the whole OS is open-source. It’s only possible to cross compile between aarch64-darwin and x86_64-darwin. aarch64-darwin support was recently added, so cross compilation is barely tested.

https://nix.dev/tutorials/cross-compilation#determining-the-host-platform-config
So I would say it is fine

cross-building a darwin gcc from linux

macOS/Darwin is a special case, as not the whole OS is open-source. It’s only possible to cross compile between aarch64-darwin and x86_64-darwin. aarch64-darwin support was recently added, so cross compilation is barely tested.

https://nix.dev/tutorials/cross-compilation#determining-the-host-platform-config
So I would say it is fine

It may not work today, but won't we like to be able to cross-compile to darwin in the future?
If I seem overly caring about adding these special cases, it's because I've spent quite some time finding and fixing reproducibility ruining special cases already[0]. I'd rather not add more for future contributors to untangle.
[0] Apart from this PR, there are https://github.com/NixOS/nixpkgs/pull/226048, https://github.com/NixOS/nixpkgs/pull/223861, https://github.com/NixOS/nixpkgs/pull/225328, of which two trigger mass rebuilding.

The branch-off date has come and passed, so I assume this can be merged?

The staging unrestricting date has come and passed, so I assume this can be merged?

According to #232237, you are correct.
Let's do it.


html repr

My attempt at an arbitrarily-deeply nested html repr.

That's for the test datatree, whose string repr currently looks like this:
DataTree('root', parent=None)
│   Dimensions:  (y: 3, x: 2)
│   Dimensions without coordinates: y, x
│   Data variables:
│       a        (y) int64 6 7 8
│       set0     (x) int64 9 10
├── DataTree('set1')
│   │   Dimensions:  ()
│   │   Data variables:
│   │       a        int64 0
│   │       b        int64 1
│   ├── DataTree('set1')
│   └── DataTree('set2')
├── DataTree('set2')
│   │   Dimensions:  (x: 2)
│   │   Dimensions without coordinates: x
│   │   Data variables:
│   │       a        (x) int64 2 3
│   │       b        (x) float64 0.1 0.2
│   └── DataTree('set1')
└── DataTree('set3')

I'm pretty pleased with this, but open to feedback.
Some things I think could be improved are:

Making the group names stand out more
Maybe listing groups after data variables?
It should also show if the root node has a parent (i.e. it's not really the root).

Not really sure how to test it exactly either.

[x] Closes #75
[ ] Tests added
[x] Passes pre-commit run --all-files
[ ] New functions/methods are listed in api.rst

@jsignell you will probably be interested to see this - thanks for making the xarray html repr code so neat that I was able to easily extend it!
@rabernat @jbusecke opinions welcome too

Thanks for doing the ping @TomNicholas! Let me also ping @benbovy since he did the majority of the work on the xarray repr.

Is there a way to indent everything but groups? That might help clarify that groups is the 'top level' organizer and everything beneath it is just another leaf-dataset? Unless I totally did not understand that right, hehe.

Is there a way to indent everything but groups? That might help clarify that groups is the 'top level' organizer and everything beneath it is just another leaf-dataset? Unless I totally did not understand that right, hehe.

I don't think that makes sense - Variables and sub-Groups exist at the same level within a given Group. In the topmost (i.e. root) group you can select a Variable via dt[var_name] or a group via dt[group_name]. So I don't think it would make sense to do what you're suggesting?

You might be right, my main reason to say that is that the output is quite large (long scroll) and visually very homogenous to look at. This can make it hard to find the thing you are looking for.
But actually there might be an easier way: Do you think its possible/useful to fold the full groups by default? So for example if you unfold 'Groups', you could have a list of set1/set2/... that can each be unfolded to get the datasets repr. I think this would make handling many groups easier, since the current way seems to end up being a very long scroll for 3+ groups?
Additionally some visual elements like in the dask client repr could help the user grasp the high level structure of the tree more easily.

Do you think its possible/useful to fold the full groups by default?

This line should control how many items a group dropdown must have before it is folded by default. If we set it to 0 it should fold all groups be default.

Additionally some visual elements like in the dask client repr could help the user grasp the high level structure of the tree more easily. These rounded boxes (or something similar) could be color coded for e.g. (leaf, branch etc).

This is trickier, but I agree some kind of graphical representation would be nice. I do like the way the printable string repr shows you the structure. This is so much harder for me to implement though that I might leave it to a second PR.

This is trickier, but I agree some kind of graphical representation would be nice. I do like the way the printable string repr shows you the structure. This is so much harder for me to implement though that I might leave it to a second PR.

Yeah absolutely, this was a 'nice to have' from my end. Not required. Root level folding seems very beneficial for large sets of groups, so that would be nice to implement here (and it seems quite easy).

Thanks for the ping @jsignell, and also glad to see that it was easy to reuse the xarray repr code here (with the hope that the hacks used there won't have too much impact here).

This is trickier, but I agree some kind of graphical representation would be nice. I do like the way the printable string repr shows you the structure. This is so much harder for me to implement though that I might leave it to a second PR.

I think this could be already achieved - although a bit less fancy than the dask repr - with some basic UI design applied to the group names like font-weight or color variation(s), or by prepending repeated symbol(s) (dot, cross, etc.) to those names so that it informs about their hierarchical level.

I think this could be already achieved - although a bit less fancy than the dask repr - with some basic UI design applied to the group names like font-weight or color variation(s), or by prepending repeated symbol(s) (dot, cross, etc.) to those names so that it informs about their hierarchical level.

Makes sense @benbovy - that is basically how anytree achieves this:

DataTree('root', parent=None)
│   Dimensions:  (y: 3, x: 2)
│   Dimensions without coordinates: y, x
│   Data variables:
│       a        (y) int64 6 7 8
│       set0     (x) int64 9 10
├── DataTree('set1')
│   │   Dimensions:  ()
│   │   Data variables:
│   │       a        int64 0
│   │       b        int64 1
│   ├── DataTree('set1')
│   └── DataTree('set2')
├── DataTree('set2')
│   │   Dimensions:  (x: 2)
│   │   Dimensions without coordinates: x
│   │   Data variables:
│   │       a        (x) int64 2 3
│   │       b        (x) float64 0.1 0.2
│   └── DataTree('set1')
└── DataTree('set3')

I imagine I could use similar logic to how anytree's RenderTree just uses 3 different characters (vertical=│, continuation=├──, end=└──).

I'm going to merge this now and leave #87 up to discuss how to improve the html repr in the future.


Example of proper way to consume types in the callbacks?

So I am trying to add SCIM support using SCIMMY and SCIMMYRouters to my express API.  So far so good.  Everything is hooked up, and my placeholder ingress/egress functions are being hit by my postman tests.
However, I saw that you had type definitions but I can't seem to find a reasonable way to use them in my modules.  I was having trouble importing types from the module, possibly because the types aren't reexported at the top level of the module?  IDK, I was able to get around that by typing inputs using typeof, but the objects passed to my callbacks don't seem to match these classes members, so its not quite right and would welcome input.
For example, for ingress, it is documented with a js example at https://scimmyjs.github.io/SCIMMY.Types.Resource.html#~IngressHandler (thanks for that) with the arguments types listed as SCIMMY.Types.Resource and SCIMMY.Types.Schema
I tried converting that literally:
	// Register the User resource
	SCIMMY.Resources.declare(SCIMMY.Resources.User, {})
	// Add support for the optional EnterpriseUser extension
	SCIMMY.Resources.User.extend(SCIMMY.Schemas.EnterpriseUser, false)
	// Add handlers for retrieval and submission
	SCIMMY.Resources.User.ingress(async (resource: typeof SCIMMY.Types.Resource, data: typeof SCIMMY.Resources.User.schema, _ctx: unknown): Promise<typeof SCIMMY.Schemas.User> => {
		console.log(`Request to create/edit user ${JSON.stringify(resource)}, ${JSON.stringify(data)}`)

                // For now, return a raw Promise, eventually we'll await database operations
		return await new Promise((resolve) => resolve({ ...data, id: '456' }))
	})
	SCIMMY.Resources.User.egress((resource: Record<string, unknown>) => {
		console.log(`Request to read user ${JSON.stringify(resource)}`)
	})
	SCIMMY.Resources.User.degress((resource: Record<string, unknown>) => {
		console.log(`Request to delete user ${JSON.stringify(resource)}`)
	})

But those types' members don't seem to match the members of the object resource/data.  I also tried typing using SCIMMY.Resources.User and even SCIMMY.Resources.User.definition based on following steps through the constructors.
Anyway, I get that part of this is probably because the actual attributes on an object are defined by the schema, and can be optionally present, but it seemed like in schemas.js User.#definition did some magic, so I wasn't sure if there was a way for me to type the objects such that typescript would know what the possible (they could be missing on a given call I know) members supplied by the User or Group object would be?  I assume that is kinda the point of these resources?  To type them?
Maybe I'm missing something obvious, but I've been chasing my tail trying to use SCIMMY.Resources.User, SCIMMY.Schemas.User, SCIMMY.Types.User, etc but I can't seem to figure it out.  Maybe its not possible and everyone just types the incoming data as unknown or Record<string, unknown> and test everything manually.  Let me know if that is true, but it seems like this library validates the input before calling my handler, so it would suck to have to treat the object as an anonymous, untyped object when it has been verified to meet a, well, type.
Anyway, I'm liking the library so far, just hoping to add typing into my use case to add auto-complete and transpile-time error checking.
And if I am just missing something, I'd suggest changing the type of the handler argument to SCIMMY.Resources.User.ingress/etc.  Currently it explicitly seems to take any, and it'd at least be cool if it typed its input as a callback that took the three arguments and returns a promise of an object of the requested shape.  It'd take some of the guesswork out of making the handler implementation.  I think it'd even help non-TS developers since VSCode will show hints based on types even in pure JS these days.

In the end, I found this type magic to get me relatively close.  Its been harder than consuming types from some libraries, and for a bit I thought it was impossible without modifying the .d.ts to explicitly export some more types, but this seems to be getting close (implementation and product specific details removed for space).
import type { Express } from 'express'
import SCIMMY from 'scimmy'
import SCIMMYRouters from 'scimmy-routers'
import { parse as SCIMParse, filter as SCIMFilter } from 'scim2-parse-filter'

type SCIMMYUserSchema = InstanceType<typeof SCIMMY.Schemas.User>
// An arbitrary object.  Technically its constrainted at runtime, but there doesn't seem to be a type for that?
type SCIMMYData = Record<string, any>
// The way the constructor of the User object works, it copies all the input data on to extend it
type SCIMMYUserInput = SCIMMYUserSchema | SCIMMYData

type SCIMMYResource = InstanceType<typeof SCIMMY.Types.Resource>
type SCIMMYConstraints = SCIMMYResource['constraints']
type SCIMMYFilter = SCIMMYResource['filter']

// As part of the RFC, the multi-objects have some basic properties
type SCIMMulti = {
	type: /*'home' | 'work' | 'other' |*/ string
	primary: boolean
	display: string
	value: string
}

type SCIMEmail = SCIMMulti
type Context = {
	// My product context
}
// Manages state, registers routes, contains the controller that performs product specific operations
class SCIMHandler<UserEntity, Controller extends SCIMController<UserEntity>> {
	controller: Controller

	applyFilter(data: Array<SCIMMYData>, filter: SCIMMYFilter) {
		return data.filter(SCIMFilter(SCIMParse(filter.expression)))
	}

	ingress = async (resource: SCIMMYResource, data: SCIMMYUserInput, ctx: Context): Promise<SCIMMYData> => {
		// Implementation removed for space
	}

	egress = async (resource: SCIMMYResource, ctx: Context) => {
		// Implementation removed for space
	}

	degress = (resource: SCIMMYResource, ctx: Context) => {
		// Implementation removed for space
	}

	// Main entrypoint for adding SCIM functionality to an Express server
	registerSCIMRoutes(app: Express) {
		const scimConfig = SCIMMY.Config.get() as Record<string, unknown>
		console.log(scimConfig)

		// Register the User resource
		SCIMMY.Resources.declare(SCIMMY.Resources.User, {})
		// Add support for the optional EnterpriseUser extension
		SCIMMY.Resources.User.extend(SCIMMY.Schemas.EnterpriseUser, false)
		// Add handlers for retrieval and submission
		SCIMMY.Resources.User.ingress(this.ingress)
		SCIMMY.Resources.User.egress(this.egress)
		SCIMMY.Resources.User.degress(this.degress)
	}
}

Hi @DillonSadofsky, apologies for the delay in addressing this.
Since the SCIMMY source code is written in vanilla JavaScript, the type declarations are generated at build time from the JSDoc comments using the process documented in the TypeScript handbook. Unfortunately, the TypeScript compiler is seemingly quite bad at this, and when it doesn't just go with the "any" type, the generated declaration file is littered with broken or incorrect types.
I'm working on modifying the build process to solve this issue by directly using the TypeScript compiler API to parse the source files and generate an accurate declaration file, which should eliminate the abundant "any" types and provide access to the correct types, however that still leaves the issue of typing the objects passed through to handlers.
As you correctly noted, SCIMMY does have various pieces of magic to validate schema conformance throughout the process. These schemas are defined at runtime - almost any attribute can be added or removed - making it very difficult if not impossible to accurately type the properties of each schema instance. In theory I could include types for the default shape of the schemas, but since almost all attributes are optional, they might end up looking more like the Record<string, unknown> type you originally mentioned. If you've had any further success in typing when moving between SCIM object shapes and your domain's object shapes without having to do so manually I'd love to know how, as it would be great to include this in a future version?
Thanks,
Sam

As my integration has progressed, my type declarations have stuck pretty closely to the trimmed down prototype I posted above, so I can't say I've gotten any further.
I agree that process wise, everything is done at runtime, but technically the user does encode their opinions into the code by calling various .declare and .extend calls, which return the object.  Theoretically, if the various objects were generics (https://www.typescriptlang.org/docs/handbook/2/generics.html), that information could 'follow' through those calls into the generic type argument of the return of those various objects, which could prime the object with an 'argument' that would tell it a bit about (at code time) what the valid objects will be at runtime.  Maybe it could be solved somehow at the higher level of the namespaces that contain the various workhorse entities?  The caller could keep an opinionated type they pass into a generic argument at a higher level, then when they do .Schema or whatever, it'd be part of that context.  I'm not sure if that is even possible, I don't have much experience with that.
That said, this is, at its heart a wrapper around an HTTP API, and almost everything is optional, so ignoring the above which is probably a very advanced solution (could require a rethink of the structure of the project or rewriting it in TS to make it easy to manage), it would've helped me if the type could at least explicitly mention and type all optional inputs (some of which are defined by the RFC [attributes, filter, etc], and some of which would just be optional based on the common schemas).  I know it wouldn't be perfect if someone customizes the schema, but if all the attributes are marked optional, then its not technically wrong if they're omitted/impossible.  As for additional fields, if the type listed all explicit optional (expected) attributes, then unioned on a general one like Record, it wouldn't provide much error checking against misspellings (since any attribute is 'valid' at that point), but it'd give some auto-complete and explicit type information to modern IDEs.  If the user does go with a custom schema, I guess that would be a benefit of the Generic type, as the generic arguments can have a default, so the User/Group could have defaults for the common case and the user could override if they wished.  I honestly have no idea what is the most common, but I didn't plan to extend the schema, and I assume most users are just trying to add support for the base technology.
I apologize I don't have better suggestions.  This request started out as confusion regarding to importing types nested within the namespaces (which as you mention may just be due to issues in the hand written type hints) and morphed into a bigger discussion on what is possible.  I mostly just assumed I was doing something wrong/was confused since the same 'object' name is reused in several namespaces, and I was somewhat confused between the entity types (runtime objects) and the Types of the entities if that makes sense.  I didn't know if that was throwing of VS code or if it was something else.
At this point, I've mostly figured things out by getting the basic stuff connected and setting breakpoints and just seeing what objects contained, but I guess my core complaint was that (as a new user who isn't yet super familiar with SCIM tech), I identified that overriding ingress/egress/degress with custom transforms was the thing todo, but the examples don't get much into what the arguments 'contain' and it took a bit of guess and check.  I saw that your project shipped types, and even in non-TS projects, VS code and (presumably  other IDEs) can read that to give hints, which are a kind of living documentation that ships with the code, so IMO, although you could improve the docs like https://scimmyjs.github.io/SCIMMY.Types.Resource.html#~IngressHandler I think more explicit shipped types help provide a bit of documentation to the consumer.  Above, we were discussing how to make the types runtime-accurate, which is useful if you want types to constrain the code and detect bugs (automatically detect that .Id is bad while .id is good or whatever) and that is nice, but even if the types had those suggested properties and unioned Record, it could still serve the purpose of discoverability.  That's my 2 cents at least.

Hello here ! 👋
I was learning how to use the library, and I struggled with the typing of ingress/egress callback. I created a PR just to show a proposal to augment typing for the SCIMMY.Resources.User.ingress.
Since the User class extends Types.Resource but bring override, I notice that typescript handle it better if we declare the new type directly in the User class.
Do you think it's something that can work for the default types ? Or am I missing something ?
Great day to everyone !
Yann.

Hi @DillonSadofsky and @ymoriaud,
Apologies for the delay in getting this fix over the line, I've just released v1.3.0 which should include a scimmy.d.ts file that isn't functionally useless! The types in the handler methods should now be correctly inferred, and I was even able to get partial type checking on the expected return values of the handlers. If possible, would you mind updating to this version and reporting back as to whether the types are now working as expected?
Thanks,
Sam

Congrats again @sleelin for the release !
I can confirm that upgrading to v1.3.0 fix and improve a lots the typing. 👏

[...] I was even able to get partial type checking on the expected return values of the handlers [...]

When you say you were able to get partial type checking on the return values, is it the same partial type checking that in the example below ?
Example

[!note]
This example is only here to demonstrate typing check, it's not a "working" code.

You can see in the egress handler the three comments (1., 2., 3.). The comment 1. will raise a typing error, rather than the comments 2. and 3. won't. It looks like typescript having hard time with the union check with the EgressHandler define in the scimmy.d.ts file ? If I'm missing something, please let me know.

import SCIMMY from<EMAIL_ADDRESS>
// Define the type for a User retrieved from the database
interface UserFromDatabase {
    id: string
    active: boolean
    userName: string,
    displayName: string,
    emails:{
        value: string,
        primary: boolean
    }[]
    meta: {
        created: Date,
        lastModified: Date,
        version: string
    }
}

// Fake function to retrieve a user from a database
function userFromDatabase(id: string, _ctx: unknown): Promise<UserFromDatabase> {
    return new Promise((resolve) => {
        resolve({
            id,
            active: true,
            userName<EMAIL_ADDRESS>            displayName: "Nice user name",
            emails: [{
                value<EMAIL_ADDRESS>                primary: true
            }],
            meta: {
                created: new Date("2024-12-09"),
                lastModified: new Date("2024-12-09"),
                version: "0001"
            }
        })
    })
}
// Fake function to retrieve multiple users from a database
function usersFromDatabase(_filter?: SCIMMY.Types.Filter, _constraints?: SCIMMY.Types.Resource<SCIMMY.Schemas.User>["constraints"], _ctx?: unknown): Promise<UserFromDatabase[]> {
    return new Promise((resolve) => {
        resolve([{
            id: "1234",
            active: true,
            userName<EMAIL_ADDRESS>            displayName: "Nice user name",
            emails: [{
                value<EMAIL_ADDRESS>                primary: true
            }],
            meta: {
                created: new Date("2024-12-09"),
                lastModified: new Date("2024-12-09"),
                version: "0001"
            }
        }])
    })
}

class ResourceController {
    static async findOne(id: string, ctx: unknown) {
        // Retrieve a specific user from the database
        return await userFromDatabase(id, ctx)
    }

    static async findMany(filter?: SCIMMY.Types.Filter, constraints?: SCIMMY.Types.Resource<SCIMMY.Schemas.User>["constraints"], ctx?: unknown) {
        // Faking retriving a list of users from the database
        return await usersFromDatabase(filter, constraints, ctx)
    }
}

SCIMMY.Resources.declare(SCIMMY.Resources.User)
    // Uncomment the lines below to see the typing error on the handler
    .egress(async (resource, ctx) => {
        // 1. This will raise a typing error on the handler
        if (resource.id) return await ResourceController.findOne(resource.id, ctx);
        else return await ResourceController.findMany(resource.filter, resource.constraints, ctx);

        // // 2. But if the handler return twice the same type, no typing error
        // if (resource.id) return await ResourceController.findOne(resource.id, ctx);
        // else return await ResourceController.findOne("1234", ctx);

        // // 3. But if the handler return twice the same type, no typing error
        // if (resource.id) return await ResourceController.findMany(resource.filter, resource.constraints, ctx);
        // else return await ResourceController.findMany(resource.filter, resource.constraints, ctx);
    })

Hi @ymoriaud, thanks for testing this for me!
I can confirm that the partial type checking is on the return values of the ingress/egress handlers as in your examples.
I believe the issue in example 1 is because for some reason TypeScript seems to think that:
Promise<UserFromDatabase>|Promise<UserFromDatabase[]>

is somehow different to:
Promise<UserFromDatabase|UserFromDatabase[]>

I've updated the expected type in the JSDoc annotation for the EgressHandler callback to the latter format with the type union wrapped in a single Promise, and testing with your example code seems to show example 1 working as expected (allowing return of one or multiple users in the handler, instead of complaining about incompatible types).
In examples 2 and 3 the returned types are the same, so I suspect TypeScript was able to infer the return type matched one of the expected values (e.g. either the Promise<UserFromDatabase> or the Promise<UserFromDatabase[]> type, as opposed to in example 1 where it misunderstood the union).
I've now released v1.3.1 which should include the correct type, would you mind updating again and reporting whether it now behaves as expected?
Thanks,
Sam


Kill Switch option on new monolithic PCB

Per a DM I just received on the forum from @jhphelan:
Place a 4-position screw terminal strip on the board between main power output and the RoboClaw power inputs with heavy gauge jumper wires from + to + and gnd to gnd.  That way a kill switch cold be wired in replacing the jumper wires.  This would also allow a take-off for a "robot safety module" of flashing light & beeper to run only when the RoboClaws are powered.  This would permit power to the Raspberry Pi and Display for program testing while paralyzing the robot for safety.
Thanks for making this GREAT project!
Jim Phelan
Mars rover project lead
Houston Robotics

@ericjunkins I'll assign this to you for now.  If you've already implemented something like this, feel free to close.  If not, it seems like a good addition.
Let me know what you think.

@JHPHELAN There is an ESTOP pin on the Roboclaws that disables the H-bridges on the motor controllers, disabling movement of the robot. In the current PCB Design I have that connected to a GPIO pin on the RPi, such that the PI must let the motor controllers know things are in a safe state. Are you specifically wanting an additional hardware E-STOP switch/button?

Yes, using a keychain remote & a receiver relay an interrupt could be placed in the power train.  The ESTOP requires the RPi to be functioning perfectly.  The risk is that a program glitch could make the RPi "go off into the weeds" taking the rover with it.
Jim Phelan
Mars rover project lead
Houston Robotics

@JHPHELAN Okay I understand now what are you asking for. I have to look at a few things.
The Roboclaw might support multiple E-STOP inputs. I know you can configure S3 to be an E-STOP input, you might be able to also configure S4/S5. If you cannot then I think I will add the following AND logic gate comparitor to the system.
https://www.digikey.com/product-detail/en/texas-instruments/SN74HC11N/296-8217-5-ND/376871
As a few notes:
The signal from the RPi for the kill switch is set such that initially the motor controllers will be in an E-STOP mode, and require the logic line driven HIGH in order to clear that, which must be held HIGH at all times in order for the E-STOP error flag to be cleared and the H-bridges enabled. I was going to write a separate watcher on the Pi that would continually monitor the system and if anything happens it will drive that to LOW.
This does mean that if there is a malfunction on the Pi catastrophically that you could get into the scenario you are describing. However I would suggest not putting the "kill switch" on the power line to the RoboClaws, and additionally definitely do not make it disconnect both power and GND. When the E-STOP flag is called on the motor controllers they will disable the H-bridge and it will safely handle all of the energy currently in the system. However if you cut power abruptly there is a chance there is still energy in that system, which then has potentially no safe outlet to go to. Also if you remove the GND connection you allow the voltage at the device to be floating, which could lead to some large voltage differential between the power terminals and battery upon connecting (especially if the system is just hot-plugged off). There should be no reason to ever disconnect the GND of the devices, only every the (+) side voltages.
All of the above mentioned are of course low chances of things that could go wrong, but especially in an educational project it is better to err of the side of caution

Eric,
The kill switch should not, for the reasons you say, interrupt the
ground.  But it does need to tap into it for the receiver circuit to
operate.
The power interrupt seems simpler and has the advantage of the "robot
safety module" takeoff option.
However, using the E-STOP, the kill switch relay could simply ground the
E-STOP line from the RPi preventing it from activating the RCs without
the need for a comparitor.
Can you make the RPi drop the E-STOP enable if it looses radio contact?
I don't know the details, but Bluetooth does seem to be aware when it
looses contact.
As far as an onboard switch, a big red "bop to stop" switch on top
wouldn't be a bad idea!  I looked at several emergency stop switches but
they were all expensive.
We did change our power toggle to a lighted push-button so that it would
be very clear when the power was on.  We're also thinking of LED
lighting for the inside to show it off through the acrylic back, and
additionally front, panels (thickened to 1/4" for strength).
Jim
James H Phelan
"Nihil est sine ratione cur potius sit quam non sit"
Liebniz
On 3/20/2019 11:53 PM, ericjunkins wrote:

@JHPHELAN https://github.com/JHPHELAN Okay I understand now what are
you asking for. I have to look at a few things.
The Roboclaw might support multiple E-STOP inputs. I know you can
configure S3 to be an E-STOP input, you might be able to also
configure S4/S5. If you cannot then I think I will add the following
AND logic gate comparitor to the system.
https://www.digikey.com/product-detail/en/texas-instruments/SN74HC11N/296-8217-5-ND/376871
As a few notes:
The signal from the RPi for the kill switch is set such that initially
the motor controllers will be in an E-STOP mode, and require the logic
line driven HIGH in order to clear that, which must be held HIGH at
all times in order for the E-STOP error flag to be cleared and the
H-bridges enabled. I was going to write a separate watcher on the Pi
that would continually monitor the system and if anything happens it
will drive that to LOW.
This does mean that if there is a malfunction on the Pi
catastrophically that you could get into the scenario you are
describing. However I would suggest not putting the "kill switch" on
the power line to the RoboClaws, and additionally definitely do not
make it disconnect both power and GND. When the E-STOP flag is called
on the motor controllers they will disable the H-bridge and it will
safely handle all of the energy currently in the system. However if
you cut power abruptly there is a chance there is still energy in that
system, which then has potentially no safe outlet to go to. Also if
you remove the GND connection you allow the voltage at the device to
be floating, which could lead to some large voltage differential
between the power terminals and battery upon connecting (especially if
the system is just hot-plugged off). There should be no reason to ever
disconnect the GND of the devices, only every the (+) side voltages.
All of the above mentioned are of course low chances of things that
could go wrong, but especially in an educational project it is better
to err of the side of caution
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/nasa-jpl/open-source-rover/issues/103#issuecomment-475112946,
or mute the thread
https://github.com/notifications/unsubscribe-auth/Ahyuo-tu_ZtNRs-eeTS0bnU4AqVHT3Tlks5vYxBfgaJpZM4b_pHl.

@JHPHELAN  can you send me a link to the receiver you are using so I know how it works?

The RPi can monitor if there is connection from a wireless device yes, there are a few ways to do this and make that descision
I had thought about installing power LEDs as well, I didn't because the voltage monitor will turn on and give indication of what is happening. In addition with the new PCB rework and adding an Arduino you can get some LED indication from the face that things are running instantly. I have a lot of code changes to upload when i get minute on that still.

@JHPHELAN I want to reference you to a comment I just made in #94 for future PCB design requests. Would you mind reading that and let me know if that path forward is something that works for you, and also let me know if you are able to make board edits yourself or if you are looking for assistance in designing them.

@JHPHELAN I verified today that you can configure the RoboClaws to accept multiple E-STOP signals onto different control pins. My suggestion to the remote kill-switch edit you are wanting to add is to add that to S4 or S5 of each of your Roboclaws on the PCB

JPL is focusing on issues other than this one, so we're choosing not to implement it on our end.
If it's a valuable enough feature for other folks, you're encouraged to try your hand at adding it based on the discussion above.


centered text, added definition, changed styling for What? and Really? to differenti…

…ate from white text
Came across an issue that you would need to click "What?" twice for the definition to be visible. Still trying to figure out how to fix it.

#1
Looks great. Can you make a new html file under /pages/ for this? Thanks!

@choyiny on it!


fix #762

Description

Relevant issues/tickets

Type of change

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist

[ ] This change requires a documentation update
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] I have added a test case that will be used to verify my changes
[ ] Verified independently on a cluster by reviewer

Verification steps

@NissesSenap You mentioned this you used the proper flag, right? It should be --zap-log-level as with this change right?


added user instructions to docs

there is no point in having this in email attachments

Since the client side tool is integrated with the unified cluster tool command replacing the current cluster-xxx scripts, and the functionality is related to the HPC, I think the final complete instruction should be part of the HPC wiki.

I think that the HPC wiki should be merged (one way or another) with the intranet. Storage, project quota, installed software, archiving, etc., are also all part of the same research compute environment.


Add tests

Checklist

[x] Used a personal fork of the feedstock to propose changes
[ ] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[x] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x] Ensured the license file is being packaged.

@conda-forge-admin, please rerender

Failures are due to broken tests upstream. They've been fixed on https://github.com/django-guardian/django-guardian/commit/5ac8be19d484e389ee43a72759e3308771b19660, but that hasn't made it into a released version yet. Leaving this in draft until then.

@conda-forge-admin, please rerender


Growl Notification when I Send Message

Whenever I send a message to someone, I see a growl notification that shows the message that I just typed.  I think this just started happening in the last month or so. Anyone know why this is happening?

Same here!

Just wondering, but why are you using Growl, instead of the native notification service of macOS, assuming you aren't using Windows of course. That would explain itself already..

Perhaps he was mistaken in calling it a growl notification. I have this issue with the default notification system.

I have the same issue with the default notification system.

same !

Same issue

+1, annoying. I've tried toggling desktop notifications but they still appear

fixed in v.3.3.0


New challenge

updated pointer to challenge repo so we may receive current updates.

not sure why the workflow file is "different" without having actual differences in main


Mac pip install error

Bug description

when install metagpt with the command: "pip install metagpt", found the error bellow
Collecting fire==0.4.0 (from metagpt)
Using cached https://pypi.tuna.tsinghua.edu.cn/packages/11/07/a119a1aa04d37bc819940d95ed7e135a7dcca1c098123a3764a6dcace9e7/fire-0.4.0.tar.gz (87 kB)
Preparing metadata (setup.py) ... error
error: subprocess-exited-with-error
× python setup.py egg_info did not run successfully.
│ exit code: 1
╰─> [1 lines of output]
ERROR: Can not execute setup.py since setuptools is not available in the build environment.
[end of output]
Bug solved method

Environment information

LLM type and model name:
System version: macos 15.0.1
Python version: 3.11.4
MetaGPT version or branch:
metagpt-0.8.1-py3-none-any.whl

packages version:
installation method:

Screenshots or logs

Try this:
python -m pip install pip

pip install setuptools

First, make sure setuptools is installed:
Run the following command in the terminal to ensure that setuptools is installed and is the latest version:
pip install --upgrade setuptools
Second, reinstall metagpt:
After installing setuptools, try to install metagpt again:
pip install metagpt
If it still doesn't work, try to redeploy your development environment using the servbay tool.

Fix bugs with the command bellow:
pip install metagpt --use-pep517
好好学习的郝 @.***> 于2024年10月25日周五 10:02写道：

Try this:
python -m pip install pip
pip install setuptools
—
Reply to this email directly, view it on GitHub
https://github.com/geekan/MetaGPT/issues/1538#issuecomment-2436658386,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABT425TCW65OJNV33TF3TRTZ5GREFAVCNFSM6AAAAABQQVSIOSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMZWGY2TQMZYGY
.
You are receiving this because you authored the thread.Message ID:
@.***>


Usage of brightness_step

Link
https://www.zigbee2mqtt.io/devices/LED1842G3.html#ikea-led1842g3
Adapter version
2.4.5
What is missing or not working
According to the docs for ikea/hue bulbs we should be able to use brightness_step attribute to control brightness in a given step of an integer (either up like 40 or down with -40) through zigbee2mqtt. I would expect there to be an object in the object browser of iobroker, just like we find brightness and brightness_move here.
Is that object missing and/or is that supposed to be utilized in another way?
Device exposes
--->>> fromZ2M -> 0x14b457fffe44edf0 exposes: {"date_code":"20181203","definition":{"description":"TRADFRI LED bulb E27 WW clear 250 lumen, dimmable","exposes":[{"features":[{"access":7,"description":"On/off state of this light","name":"state","property":"state","type":"binary","value_off":"OFF","value_on":"ON","value_toggle":"TOGGLE"},{"access":7,"description":"Brightness of this light","name":"brightness","property":"brightness","type":"numeric","value_max":254,"value_min":0}],"type":"light"},{"access":2,"description":"Triggers an effect on the light (e.g. make light blink for a few seconds)","name":"effect","property":"effect","type":"enum","values":["blink","breathe","okay","channel_change","finish_effect","stop_effect"]},{"access":7,"description":"Controls the behavior when the device is powered on","name":"power_on_behavior","property":"power_on_behavior","type":"enum","values":["off","previous","on"]},{"access":1,"description":"Link quality (signal strength)","name":"linkquality","property":"linkquality","type":"numeric","unit":"lqi","value_max":255,"value_min":0}],"model":"LED1842G3","options":[{"access":2,"description":"Controls the transition time (in seconds) of on/off, brightness, color temperature (if applicable) and color (if applicable) changes. Defaults to `0` (no transition).","name":"transition","property":"transition","type":"numeric","value_min":0}],"supports_ota":true,"vendor":"IKEA"},"endpoints":{"1":{"bindings":[],"clusters":{"input":["genBasic","genIdentify","genGroups","genScenes","genOnOff","genLevelCtrl","touchlink"],"output":["genScenes","genOta","genPollCtrl","touchlink"]},"configured_reportings":[],"scenes":[]},"242":{"bindings":[],"clusters":{"input":["greenPower"],"output":["greenPower"]},"configured_reportings":[],"scenes":[]}},"friendly_name":"Bad oben Retro Light","ieee_address":"0x14b457fffe44edf0","interview_completed":true,"interviewing":false,"manufacturer":"IKEA of Sweden","model_id":"TRADFRI bulb E27 WW clear 250lm","network_address":2628,"power_source":"Mains (single phase)","software_build_id":"2.3.093","supported":true,"type":"Router"}

Hi @7oku,
yes that's right brightness_step I haven't implemented in the adapter yet.
I'm looking into it, but can't tell you how long it will take me.

Please test the dev branch: https://github.com/o0shojo0o/ioBroker.zigbee2mqtt/tree/dev_%2396

Hey @o0shojo0o,
awesome, that was quite fast and works like a charm.
Closing the ticket!


Prisma schema : Can't use field mapping on the prisma schema

Description 🐜
Can't use field mapping on  prisma schema
"@next-auth/prisma-adapter": "^0.5.2-next.5",
"next-auth": "4.0.0-beta.2",
Is this a bug in your own project?
Yes
How to reproduce ☕
model Account {
  id                String  @id @default(uuid())
  userId            String  @map(name: "user_id")
  type              String
  provider          String
  providerAccountId String  @map(name: "provider_account_id")
  refreshToken      String? @map(name: "refresh_token")
  accessToken       String? @map(name: "access_token")
  expiresAt         Int?    @map(name: "expires_at")
  tokenType         String? @map(name: "token_type")
  scope             String?
  idToken           String? @map(name: "id_token")
  sessionState      String? @map(name: "session_state")
  oauthTokenSecret  String? @map(name: "oauth_token_secret")
  oauthToken        String? @map(name: "oauth_token")

  user User @relation(fields: [userId], references: [id], onDelete: Cascade)

  createdAt DateTime @default(now()) @map(name: "created_at")
  updatedAt DateTime @default(now()) @map(name: "updated_at")

  @@unique([provider, providerAccountId])
  @@map(name: "accounts")
}

Screenshots / Logs 📽
Invalid `prisma.account.create()` invocation:

{
  data: {
    provider: 'github',
    type: 'oauth',
    providerAccountId: '4693180',
    access_token: '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',
    ~~~~~~~~~~~~
    token_type: 'bearer',
    ~~~~~~~~~~
    scope: 'read:user,user:email',
    userId: '6b49ce63-4123-48b8-a237-de43b7388c77'
  }
}

Unknown arg `access_token` in data.access_token for type AccountUncheckedCreateInput. Did you mean `accessToken`? Available args:
type AccountUncheckedCreateInput {
  id?: String
  userId: String
  type: String
  provider: String
  providerAccountId: String
  refreshToken?: String | Null
  accessToken?: String | Null
  expiresAt?: Int | Null
  tokenType?: String | Null
  scope?: String | Null
  idToken?: String | Null
  sessionState?: String | Null
  oauthTokenSecret?: String | Null
  oauthToken?: String | Null
  createdAt?: DateTime
  updatedAt?: DateTime
}
Unknown arg `token_type` in data.token_type for type AccountUncheckedCreateInput. Did you mean `tokenType`? Available args:
type AccountUncheckedCreateInput {
  id?: String
  userId: String
  type: String
  provider: String
  providerAccountId: String
  refreshToken?: String | Null
  accessToken?: String | Null
  expiresAt?: Int | Null
  tokenType?: String | Null
  scope?: String | Null
  idToken?: String | Null
  sessionState?: String | Null
  oauthTokenSecret?: String | Null
  oauthToken?: String | Null
  createdAt?: DateTime
  updatedAt?: DateTime
}

Environment 🖥
System:
OS: macOS 11.6
CPU: (12) x64 Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz
Memory: 165.80 MB / 32.00 GB
Shell: 5.8 - /bin/zsh
Binaries:
Node: 14.15.4 - /var/folders/gw/p65jr67s79q056y170l5dhb40000gp/T/fnm_multishells/12637_1631912472478/bin/node
Yarn: 1.22.10 - /var/folders/gw/p65jr67s79q056y170l5dhb40000gp/T/fnm_multishells/12637_1631912472478/bin/yarn
npm: 6.14.10 - /var/folders/gw/p65jr67s79q056y170l5dhb40000gp/T/fnm_multishells/12637_1631912472478/bin/npm
Watchman: 2<IP_ADDRESS> - /usr/local/bin/watchman
Browsers:
Chrome: 93.0.4577.82
Chrome Canary: 96.0.4647.2
Firefox: 91.0.2
Safari: 14.1.2
npmPackages:
next: 11.1.2 => 11.1.2
next-auth: 4.0.0-beta.2 => 4.0.0-beta.2
react: 17.0.2 => 17.0.2
Contributing 🙌🏽
Yes,  I am willing to help solve this bug in a PR

We haven't done anything to block this, have you run prisma generate after creating your schema?

Yes sir, i did migrated the schema then generated the client.
I succeeded a signed up with the Email provider while there is also field mapping on the User and Session schema.
My guess is that there is an issue with the Github provider (i haven't tried others oauth providers yet) since only mapping on the Account schema raises errors.
model User {
id            String    @id @default(uuid())
name          String?
email         String?   @unique
emailVerified DateTime? @map(name: "email_verified")
image         String?
customer      Customer?
accounts      Account[]
sessions      Session[]
subscriptions Subscription[]
createdAt DateTime @default(now()) @map(name: "created_at")
updatedAt DateTime @default(now()) @map(name: "updated_at")
@@map(name: "users")
}
model Account {
id                String  @id @default(uuid())
userId            String  @map(name: "user_id")
type              String
provider          String
providerAccountId String  @map(name: "provider_account_id")
refreshToken      String? @map(name: "refresh_token")
accessToken       String? @map(name: "access_token")
expiresAt         Int?    @map(name: "expires_at")
tokenType         String? @map(name: "token_type")
scope             String?
idToken           String? @map(name: "id_token")
sessionState      String? @map(name: "session_state")
oauthTokenSecret  String? @map(name: "oauth_token_secret")
oauthToken        String? @map(name: "oauth_token")
user User @relation(fields: [userId], references: [id], onDelete: Cascade)
createdAt DateTime @default(now()) @map(name: "created_at")
updatedAt DateTime @default(now()) @map(name: "updated_at")
@@unique([provider, providerAccountId])
@@map(name: "accounts")
}
model Session {
id           String   @id @default(uuid())
sessionToken String   @unique @map(name: "session_token")
user         User     @relation(fields: [userId], references: [id], onDelete: Cascade)
userId       String   @map(name: "user_id")
expires      DateTime
createdAt DateTime @default(now()) @map(name: "created_at")
updatedAt DateTime @default(now()) @map(name: "updated_at")
@@map(name: "sessions")
}
model VerificationToken {
id         String   @id @default(uuid())
identifier String
token      String   @unique
expires    DateTime
createdAt DateTime @default(now()) @map(name: "created_at")
updatedAt DateTime @default(now()) @map(name: "updated_at")
@@unique([identifier, token])
@@map(name: "verification_requests")
}

I removed the mapping for  access_token and  token_type  and it worked
not working:
accessToken       String? @map(name: "access_token")
tokenType         String? @map(name: "token_type")
working:
access_token      String?
token_type        String?

We handle all providers equal. The Account data received by the adapter is always in the form of TokenSet with a few additional fields:
https://github.com/nextauthjs/next-auth/blob/cabcdc967ffd73789be33788280ef5a7eb6599c8/src/server/lib/oauth/callback.ts#L146-L151
https://github.com/panva/node-openid-client/blob/main/docs/README.md#tokenset

Wait, could you verify which version of that adapter you are using? It looks like you have mixed up the one needed for v4.
here is the default schema for that: https://github.com/nextauthjs/adapters/blob/next/packages/prisma/prisma/schema.prisma
So access_token and token_type are already in the form you want them to be!

@balazsorban44 so it is no possible to map those fields this way ? I would like all fields to be camelCase on  js side / snake_case in database
accessToken String? @Map(name: "access_token") tokenType String? @Map(name: "token_type")

This is some customization you have to look into yourself, but the above links should help.

@balazsorban44 I'm confused. I checked the link you provided but couldn't find a way to successfuly map access_token and token_type and make it works with oauth. Is there something i'm missing?

as said, you don't have to map them, those fields are received in snake_case by the adapter already.

Ok thx you @balazsorban44 , i'll live with no mapping 😅


bold weight erased

bold weight is deleted now

this task has already been completed?

this task has already been completed?

no bro as bold font been present


stream-run / appimage-run / buildFHSEnv cannot find gstreamer plugins

Worked in nixos-23.11, fails in nixos-24.05 and master.
To summarize, inside of a buildFHSEnv environment:

gstreamer 1.22.12 does not find gst-plugin-scanner, but finds plugins next to libgstreamer-1.0.so (e.g. /lib64/gstreamer-1.0).
gstreamer 1.24.2 finds gst-plugin-scanner, but canonicalizes the path to gstreamer-1.0.so and then ends up looking for plugins in the store (e.g. /nix/store/xxxx-gstreamer-1.24.2/lib/gstreamer-1.0) and does not find any.

Fails on nixos-24.05 (only relevant logs shown):
$ nix shell --impure 'github:NixOS/nixpkgs/nixos-24.05'#steam-run -c steam-run env GST_DEBUG='*:5' gst-play-1.0 /dev/zero
0:00:00.000023585 612897     0x18529fc0 DEBUG           GST_REGISTRY gstregistry.c:1605:priv_gst_get_relocated_libgstreamer: attempting to retrieve libgstreamer-1.0 location using dladdr()
0:00:00.000061848 612897     0x18529fc0 DEBUG           GST_REGISTRY gstregistry.c:1625:priv_gst_get_relocated_libgstreamer: real directory location: /nix/store/n90qk04jw71dk42g7c1ifwdswmbpm3ml-gstreamer-1.24.2/lib
0:00:00.000069111 612897     0x18529fc0 INFO                GST_INIT gst.c:574:init_pre: Initializing GStreamer Core Library version 1.24.2
0:00:00.000074021 612897     0x18529fc0 INFO                GST_INIT gst.c:575:init_pre: Using library installed in /nix/store/n90qk04jw71dk42g7c1ifwdswmbpm3ml-gstreamer-1.24.2/lib
...
0:00:00.000736194 598176     0x2e4942f0 DEBUG           GST_REGISTRY gstregistry.c:1853:scan_and_update_registry: using plugin dir /nix/store/n90qk04jw71dk42g7c1ifwdswmbpm3ml-gstreamer-1.24.2/lib/gstreamer-1.0
...
Failed to create 'playbin' element. Check your GStreamer installation.

Works on nixos-23.11 (only relevant logs shown):
$ nix shell --impure 'github:NixOS/nixpkgs/nixos-23.11'#steam-run -c steam-run gst-play-1.0 /dev/zero
0:00:00.000034795 598205     0x112f2300 DEBUG           GST_REGISTRY gstregistry.c:1609:priv_gst_get_relocated_libgstreamer: attempting to retrieve libgstreamer-1.0 location using dladdr()
0:00:00.000059923 598205     0x112f2300 LOG             GST_REGISTRY gstregistry.c:1613:priv_gst_get_relocated_libgstreamer: dli_fname: /lib64/libgstreamer-1.0.so.0
0:00:00.000062518 598205     0x112f2300 INFO                GST_INIT gst.c:576:init_pre: Initializing GStreamer Core Library version 1.22.12
0:00:00.000064392 598205     0x112f2300 INFO                GST_INIT gst.c:577:init_pre: Using library installed in /lib64
...
0:00:00.000645983 598205     0x112f2300 DEBUG           GST_REGISTRY gstregistry.c:1771:scan_and_update_registry: using plugin dir /lib64/gstreamer-1.0
...
Now playing /dev/zero

The problematic change comes from upstream gstreamer: https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6322
The change forces gstreamer to canonicalize the path where libgstreamer-1.0.so is found which then makes it look for plugins in the nix store instead of the apparent location it found the library in. However, the change description is also correct; without a canonicalized path, we do not find gst-plugin-scanner on nixos-23.11 (gstreamer 1.22.12) even though plugin loading does work in the end:
...
0:00:00.000766071 598205     0x112f2300 DEBUG     GST_PLUGIN_LOADING gstpluginloader.c:579:gst_plugin_loader_spawn: found libgstreamer-1.0 library at /lib64
0:00:00.000768135 598205     0x112f2300 DEBUG     GST_PLUGIN_LOADING gstpluginloader.c:595:gst_plugin_loader_spawn: constructing path to system plugin scanner using plugin dir: 'lib', plugin scanner dir: 'libexec'
0:00:00.000770319 598205     0x112f2300 DEBUG     GST_PLUGIN_LOADING gstpluginloader.c:609:gst_plugin_loader_spawn: using system plugin scanner at /lib64/../libexec/gstreamer-1.0/gst-plugin-scanner
0:00:00.000771922 598205     0x112f2300 LOG       GST_PLUGIN_LOADING gstpluginloader.c:433:gst_plugin_loader_try_helper: Trying to spawn gst-plugin-scanner helper at /lib64/../libexec/gstreamer-1.0/gst-plugin-scanner
0:00:00.001077291 598205     0x112f2300 ERROR     GST_PLUGIN_LOADING gstpluginloader.c:442:gst_plugin_loader_try_helper: Spawning gst-plugin-scanner helper failed: Failed to execute child process “/lib64/../libexec/gstreamer-1.0/gst-plugin-scanner” (No such file or directory)
0:00:00.001087510 598205     0x112f2300 INFO      GST_PLUGIN_LOADING gstpluginloader.c:617:gst_plugin_loader_spawn: No gst-plugin-scanner available, or not working

(gst-play-1.0:598205): GStreamer-WARNING **: 19:45:28.995: External plugin loader failed. This most likely means that the plugin loader helper binary was not found or could not be run. You might need to set the GST_PLUGIN_SCANNER environment variable if your setup is unusual. This should normally not be required though.
...

A workaround is to pass profile to buildFHSEnv to set the plugin path (it also works for appimageTools which passes any extra arguments down to buildFHSEnv):
profile = ''
  export GST_PLUGIN_SYSTEM_PATH_1_0=/usr/lib/gstreamer-1.0
'';

For me, this problem caused the OrcaSlicer appimage to fail when upgrading to nixos-24.05.

I'm not really sure what to do, but I'm pretty sure I found the root cause! Hopefully someone has a good idea for fixing it :-)
Some options:

Make buildFHSEnv aware of wrapGAppsHook GST_PLUGIN_SYSTEM_PATH_1_0 (or introduce some other way for packages to tell buildFHSEnv to set /etc/profile?)
Set GST_PLUGIN_SYSTEM_PATH_1_0 (or GST_PLUGIN_PATH) in steam-run/appimage-run by default
Patch gstreamer to look up plugins in a different way or not canonicalize the path (but still finding gst-plugin-scanner, which is used to load plugins in a separate process).
Give gstreamer a withPlugins kind of pattern to find plugins in the nix store

Should be resolved by https://github.com/NixOS/nixpkgs/pull/316016


[bn] Launch Bengali localization

This PR is created to merge  dev-1.23-bn.1 into main branch
Tracking issue: #31677

/language-bn

/retitle [bn] Merge dev-1.23 bn.1 into main

/hold
Before we unhold this, SIG Docs' localization group should check that the new localization is ready to launch

@sftim  I don't believe we are ready to launch. This PR was created just for the draft version of our future PR.

/assign @reylejano

Hello @mitul3737 is this ready for review, please?

Not yet @divya-mohan0209 . This PR is just for draft. We will mention you once we are done. Thank you.

/retitle [bn] Launch Bengali localization

Current build errors include:
ERROR 2023/04/14 14:24:59 [en] "docs/concepts/architecture/garbage-collection.md": "garbage-collection" is not a valid glossary term_id, see ./docs/reference/glossary/* for a full list
ERROR 2023/04/14 14:24:59 [en] "docs/concepts/architecture/cloud-controller.md": "cloud-controller-manager" is not a valid glossary term_id, see ./docs/reference/glossary/* for a full list
ERROR 2023/04/14 14:24:59 [en] "docs/concepts/architecture/controller.md": "controller" is not a valid glossary term_id, see ./docs/reference/glossary/* for a full list
ERROR 2023/04/14 14:24:59 [en] "docs/concepts/architecture/cri.md": "container-runtime-interface" is not a valid glossary term_id, see ./docs/reference/glossary/* for a full list
ERROR 2023/04/14 14:24:59 [en] "docs/concepts/configuration/configmap.md": "configmap" is not a valid glossary term_id, see ./docs/reference/glossary/* for a full list

How's this work going?

How's this work going?

We are almost done with all of the files. Just 2 files remaining before we create the PR. @sftim

@sftim I hope, we have done the basic localization and can move forward now.

Hi @mitul3737
There are a few obstacles to cover:

this PR is not mergeable (there is a merge conflict)
the PR is still marked as draft
the pull request fails to build
this PR uses the deprecated {{< param "fullversion" >}} shortcode

How is progress?
You are welcome to work as a team towards adding a new localization; however, if there is no progress then a maintainer may close this pull request.
Even if that happens, you are welcome to continue the work and to open a new pull request if you find you have more capacity to contribute.

Is this OK to close? (in favor of https://github.com/kubernetes/website/pull/45009)

@sftim  yes you can close this now .

Is this OK to close? (in favor of #45009)

Yes, it is ok to close this PR.


Create compare with current state page

Create a page to which the desired state view links. This page should be quite similar to the compare versions page.
The biggest differences are:

For each version there are multiple compares possible because this is snapshot.
On this page it is possible to request a new dryrun
It should show the date the dryrun was request and the progress. It is possible that a dryrun never fully completes.
It should show the diff for the request dryrun, similar to the other diff view. Resources for which no diff is available yet should be show in the overview with for example a clock to indicate that we are waiting for a result.

What do we do with resources for which we cannot get a dryrun? Currently the changes are set as empty. Should we indicate this differently? See also the get ticket. -> For example show a question mark.

Hey team! Please add your planning poker estimate with ZenHub @andraskvr @bartv @Stijnkool


summarizer demo not working because of unresolved module chat

Happens when the summarizer image is run

Thanks for catching that @jeffmaury. Should be fixed now with #10
Let me know if its still causing you problems.


Improve layout of multiline properties  fix #46

For Outlook 2013 .
Replaces white-space:pre-wrap with white-space:pre
see https://www.campaignmonitor.com/css/text-fonts/white-space/

related to #46

Thank you, looks good to me! 👍


refresh scene?

Hi, how do I add the refresh scene to the config? Because when you write !R, the video only turns black and then it goes back to the same video. So it does not change scene in between when updating? // Tony

Hi Blackwolf8202,
The refresh scene is not used anymore in v2, !refresh or !fix should solve any issues.

aha okay thanks =)


Issue error text from Formz

Keep in mind I'm pretty new to development so perhaps there is an obvious solution I'm missing.
I would like to have an option for different error messages. For example maybe a description field could give an error message that says "this field can't be blank" and another that says something about the length of the input if it is too long.
enum DescriptionValidationError { empty, tooLong }

class Description extends FormzInput<String, DescriptionValidationError> {
  const Description.pure() : super.pure('');
  const Description.dirty([String value = '']) : super.dirty(value);

  @override
  DescriptionValidationError validator(String value) {
    if (value.isEmpty) {
      return DescriptionValidationError.empty;
    } else if (value.length > 10) {
      return DescriptionValidationError.tooLong;
    } else {
      return null;
    }
  }
}

Is there a way in my textfield widget to say
errorText: state.description.errorText
I can do this in my widget but I'm not sure its really best to have that logic in the widget - it feels like it should be in the class that extends formz?
return BlocBuilder<InputCubit, InputState>(
      buildWhen: (previous, current) =>
          previous.description != current.description,
      builder: (context, state) {
        String errorText;
        switch (state.description.error) {
          case DescriptionValidationError.empty:
            errorText = 'This cant be empty';
            break;
          case DescriptionValidationError.tooLong:
            errorText = 'Its too long';
            break;
          default:
            errorText = null;
            break;
        }
        return FormTextInput(
          formKey: Key('recipeInput_descriptionField_textField'),
          onChanged: (title) =>
              context.read<InputCubit>().descriptionInputChanged(title),
          labelText: 'Description',
          errorText: state.description.invalid ? errorText : null,
          maxLength: 160,
        );
      },
    );

Best,
Nick

Hey @christnick great question!
Personally, I think separating the state from the error message itself is a good thing: state is part of the business logic, while the error message is part of the UI.
One thing you could, however, is to use a Dart extension (https://dart.dev/guides/language/extension-methods) to make this code a bit "prettier".
For example (in some pseudo code form):
extension ErrorMessage on DescriptionValidationError {
  /// Passing context in case you need to localize
  String? errorMessage(BuildContext context) {
        switch (this) {
          case DescriptionValidationError.empty:
            errorText = 'This cant be empty';
            break;
          case DescriptionValidationError.tooLong:
            errorText = 'Its too long';
            break;
          default:
            errorText = null;
            break;
        }
  }
}

...

return FormTextInput(
          formKey: Key('recipeInput_descriptionField_textField'),
          onChanged: (title) =>
              context.read<InputCubit>().descriptionInputChanged(title),
          labelText: 'Description',
          errorText: state.description.invalid ? state.description.errorMessage(context) : null,
          maxLength: 160,
        );

Hope that helps ;)

Hey @christnick great question!
Personally, I think separating the state from the error message itself is a good thing: state is part of the business logic, while the error message is part of the UI.
One thing you could, however, is to use a Dart extension (https://dart.dev/guides/language/extension-methods) to make this code a bit "prettier".
For example (in some pseudo code form):
extension ErrorMessage on DescriptionValidationError {
  /// Passing context in case you need to localize
  String? errorMessage(BuildContext context) {
        switch (this) {
          case DescriptionValidationError.empty:
            errorText = 'This cant be empty';
            break;
          case DescriptionValidationError.tooLong:
            errorText = 'Its too long';
            break;
          default:
            errorText = null;
            break;
        }
  }
}

...

return FormTextInput(
          formKey: Key('recipeInput_descriptionField_textField'),
          onChanged: (title) =>
              context.read<InputCubit>().descriptionInputChanged(title),
          labelText: 'Description',
          errorText: state.description.invalid ? state.description.errorMessage(context) : null,
          maxLength: 160,
        );

Hope that helps ;)

Hrmm... you could be right there. Either way I learnt about extension methods and implemented your pseudo code for now and its working nicely.
Learning to code here and I'm constantly taken aback by how helpful people can be. Thanks very much for your help :)

Hrmm... you could be right there. Either way I learnt about extension methods and implemented your pseudo code for now and its working nicely.
Learning to code here and I'm constantly taken aback by how helpful people can be. Thanks very much for your help :)


Istio Integration failing with envoy upstream request timeout

Describe the bug
When trying to use Istio service mesh (1.17.2) with Ambassador Edge Stack (8.6.0), Emissary-ingress (envoy) fails with an upstream request timeout.  This appears to be due to there being a missing secret when generating the TLSContext, but that may be a false lead.
To Reproduce
Note: I have not yet tried installing Istio without cert-manager yet
Steps to reproduce the behavior:

Install cert-manager using helm (https://cert-manager.io/docs/installation/helm/)
Install cert-manager-istio-csr using helm (https://cert-manager.io/docs/projects/istio-csr/)
Install Istio-base and istiod using helm.  (https://istio.io/latest/docs/setup/install/helm/)
Namespaces (ambassador) are configured to use istio-injection via labels.
Deploy a test manifest of a simple default host, TLSContext, deployment, service, and mapping.  See manifest below.

Expected behavior
The service should respond with valid upstream responses.
Versions (please complete the following information):

datawire/edge-stack;  helm v8.6.0, app v3.6.0
Kubernetes environment [Microk8s with k8s v1.16.4, Minikube v1.30.1 running k8s v1.26.3]
istio: helm v1.17.2, app v1.17.2

Additional context
I have reviewed similar issues but none seem to be the one I'm experiencing.
https://github.com/emissary-ingress/emissary/issues/4744
https://github.com/emissary-ingress/emissary/issues/3510
https://github.com/emissary-ingress/emissary/issues/4484
Under the section on configuring a TLSContext in the docs (https://www.getambassador.io/docs/emissary/latest/howtos/istio#configure-an-mtls-tlscontext) it states:
Emissary-ingress reads the mTLS certificates from /etc/istio-certs (per the AMBASSADOR_ISTIO_SECRET_DIR environment variable) and creates a Secret named istio-certs.

However, I never see a secret get generated, and so when I configure the TLSContext to use that secret, it's missing.  This is why I suspect maybe this is the issue.  I wanted to attempt to create this secret manually to test, but I am not sure what format to use/how to create it.  Not to mention, this will need to be constantly updated as cert-manager/istio rotate certs every few hours/days.
Here is a sample manifest file with what I'm testing:
# The helm chart  will create the two default Listeners for HTTP on port 8080 and HTTPS on port 8443.
---
apiVersion: getambassador.io/v3alpha1
kind: Host
metadata:
  name: wildcard-host
  namespace: ambassador
spec:
  hostname: "*"
  tlsSecret:
    name: istio-certs
  tlsContext:
    name: istio-upstream

---
apiVersion: getambassador.io/v3alpha1
kind: TLSContext
metadata:
  name: istio-upstream
  namespace: ambassador
spec:
  secret: istio-certs     # This Secret name cannot currently be changed.
  alpn_protocols: istio   # This is required for Istio.

---
apiVersion: getambassador.io/v3alpha1
kind:  Mapping
metadata:
  name:  catch-all
  namespace: ambassador
spec:
  prefix: /
  hostname: "*"
  service: default-http-backend-svc
  tls: istio-upstream

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: default-http-backend
  labels:
    app.kubernetes.io/name: default-http-backend
    app.kubernetes.io/version: "1.0"
  namespace: ambassador
spec:
  replicas: 1
  selector:
    matchLabels:
      app.kubernetes.io/name: default-http-backend
      app.kubernetes.io/version: "1.0"
  template:
    metadata:
      labels:
        app.kubernetes.io/name: default-http-backend
        app.kubernetes.io/version: "1.0"
    spec:
      terminationGracePeriodSeconds: 5
      containers:
        - name: default-http-backend
          image: gcr.io/google_containers/defaultbackend:1.0
          livenessProbe:
            httpGet:
              path: /healthz
              port: 8080
              scheme: HTTP
            initialDelaySeconds: 5
            timeoutSeconds: 5
          ports:
          - containerPort: 8080

---
apiVersion: v1
kind: Service
metadata:
  namespace: ambassador
  name: default-http-backend-svc
  labels:
    app.kubernetes.io/name: default-http-backend-svc
    app.kubernetes.io/version: "1.0"
spec:
  selector:
    app.kubernetes.io/name: default-http-backend
    app.kubernetes.io/version: "1.0"
  ports:
    - appProtocol: tcp
      name: tcp-80
      port: 80
      targetPort: 8080

Here are the results:
$> curl -Lki https://<IP_ADDRESS>/

HTTP/1.1 504 Gateway Timeout
content-length: 24
content-type: text/plain
date: Wed, 17 May 2023 19:37:44 GMT
server: envoy

upstream request timeout

$> kubectl get secrets -n ambassador

NAME                               TYPE                 DATA   AGE
ambassador                         Opaque               1      40m
sh.helm.release.v1.ambassador.v1   helm.sh/release.v1   1      40m
ambassador-internal                Opaque               2      40m
fallback-self-signed-cert          kubernetes.io/tls    2      40m

After all of that, and days of working on this, I finally added a port 80 to the end of the Mapping, and it started working.  I even remember reading that warning, here:  https://www.getambassador.io/docs/emissary/latest/howtos/istio#configure-mappings-to-use-mtls and https://www.getambassador.io/docs/emissary/latest/howtos/istio#configure-service-ports.
What's bothering me is that during initial development, I did use the port 80 syntax and I also used 80/443 on the service, and was running into some issues.  I wish I had documented better.  For anyone coming in the future, just beware of that if you see a timeout issue.
Two fixes:
---
apiVersion: getambassador.io/v3alpha1
kind:  Mapping
metadata:
  name:  catch-all
  namespace: ambassador
spec:
  prefix: /
  hostname: "*"
  service: default-http-backend-svc:80
  tls: istio-upstream

or
---
apiVersion: v1
kind: Service
metadata:
  namespace: ambassador
  name: default-http-backend-svc
  labels:
    app.kubernetes.io/name: default-http-backend-svc
    app.kubernetes.io/version: "1.0"
spec:
  selector:
    app.kubernetes.io/name: default-http-backend
    app.kubernetes.io/version: "1.0"
  ports:
    - appProtocol: tcp
      name: tcp-80
      port: 80
      targetPort: 8080
    - appProtocol: tcp
      name: tcp-443
      port: 443
      targetPort: 8080


Add 'filters' to list display (Part / Stock)

Enable display of inactive parts
Filter by tags?
Persistent (cookie?)

[ ] Part status (active / inactive)
[ ] In stock / out of stock

https://erpnext.com/docs/user/manual/en/using-erpnext/articles/search-filter


[python][interop] Add bootstrap generator test to nightly cron job against python master

Manually triggered run against this PR:

grpc/core/master/linux/grpc_xds_k8s_lb_python

Can you please merge this?


Display results as HTML

Create a HTML view for the results.
The view should:

[ ] display the current results
[ ] display a history of results
[ ] display a flame graph?

The current results are of type BenchmarkSummary. It should be possible to work with this type from memory, right after the export has been run.
To display a history, it should be possible to use the Renderer without running the exporter first. This means, it should be possible to import results from files.
Research what a flame graph is and how to display it based on the BenchmarkSummary.
Issue will be further refined as development continues.

Hey @atmoos, I started again with this Issue. I remember we had a talk about the way the Display Mode is passed to the interface, but I'm not sure about the details. Was it something along the lines, that you'd like the Mode to be extensible, so that if a user has it's own mode with it's own implementation, he can still use the Rendering part?
FYI, the current interface looks like this:
public interface IDisplay
{
   Task Render(IEnumerable<BenchmarkSummary> summaries, Mode displayMode, CancellationToken token = default);
}

The mods were defined as Enum, thus the library would need to be recompiled to extend them.
public enum Mode
{
    HtmlCurrentResults,
    HtmlHistory,
    HtmlEvolution
}

A simple alternative would be:
public interface IDisplay
{
   Task Render(Action<IEnumerable<BenchmarkSummary>> display, CancellationToken token = default);
}

We could then provide some convenience methods to Display the current benchmark summary as HTML, history, etc.


smart table filter design

any class i need to add into or something else to my status filter listbox,
so i can let list filter style like text filter?

Hey @wilson-young, you can just style the filter by using css.


new backend for scaffolder-backend-argocd

:heavy_check_mark: Checklist

[ ] Added tests for new functionality and regression tests for bug fixes (N/A)
[X] Added changeset (run yarn changeset in the root)
[ ] Screenshots of before and after attached (for UI changes) (N/A)
[X] Added or updated documentation (if applicable)

@htplbc would you mind updating the branch with main?

@htplbc would you mind updating the branch with main?

@punkle all done


Docker Desktop 4.1.1 is not compatible with integration test

For short, DO NOT upgrade your Docker Desktop for Mac to versions above 4.0.0
Description
I updated my Docker Desktop for mac(Intel Chip) to the latest 4.1.1(because it always reminds me of the upgrade), but found that the integration test could not be started due to spaces in environment variables values.
And the Docker can start up if Docker Desktop 4.0.0 or previous version is used.
Below is the variable definition where the error is reported
https://github.com/apache/druid/blob/33d9d9bd74ade384ef5feb31748b989122deb160/integration-tests/docker/environment-configs/common#L25
When starting the docker-compose, it says
unexpected character "-" in variable name near "-Dfile.encoding=UTF-8 .....

And if the variable value is quoted, there's no such error.
COMMON_DRUID_JAVA_OPTS="-Duser.timezone=UTC -Dfile.encoding=UTF-8 ...."

I don't want to fix our scripts to make it compatible with Docker Desktop 4.1.1 because we have to test the changes for different docker versions and different platforms.
Another reason is I have no idea how to make following variable value to be compatible. Looks like a little bit tricky.
druid_indexer_runner_javaOptsArray=["-server", "-Xmx256m", "-Xms256m", "-XX:NewSize=128m", "-XX:MaxNewSize=128m", "-XX:+UseG1GC", "-Duser.timezone=UTC", "-Dfile.encoding=UTF-8", "-Dlog4j.configurationFile=/shared/docker/lib/log4j2.xml"]

So I opened an issue at Docker side so that we can see what response we can get from Docker team.

4.12.0 (85629) Has no such problem. I think this might be a problem at DockerDesktop side.


Make BuildExtendedCommitInfo and BuildLastCommitInfo public and change their signature slightly

Related: https://github.com/cometbft/cometbft/discussions/1406#discussioncomment-7254221
Makes the BuildExtendedCommitInfo and BuildLastCommitInfo functions public,
and makes them take a validator set instead of the store as an input.
These functions  are useful to also call from outside of CometBFT if one has a need to obtain the CommitInfo structs,
in particular I am using them in a mock for cometbft.

PR checklist

[ ] Tests written/updated
[ ] Changelog entry added in .changelog (we use unclog to manage our changelog)
[ ] Updated relevant documentation (docs/ or spec/) and code comments

Closed and cherry-picked the commits against main