Get-PNPGroup does not return Domain groups used in SharePoint Online

@officedocsbot assign @yogkumgit

Hello @istavnit thanks for your feedback.
Yes, currently, that is the expected behaviour of the cmdlet, as the article says Returns a specific SharePoint group or all SharePoint groups in site.
Thank you

@get-itips  Thank you very much for the contribution and sharing this explanation. @istavnit
Hope this comment is helpful for you. Thanks for taking out some time to open the issue. Appreciate and encourage you to do the same in future also.

@officedocsbot close


Issue with step and reset in TempVMPackingEnv

Hi team,
Awesome work, really like the paper.
I've found a couple of issues with the TempVMPackingEnv environment (VMPacking-v1).
The main one is that the custom logic of the step method was definied as step() instead of _STEP() and so steps in the environment were actually using _STEP() for the parent class. There's is also a small indexing error when demand is being removed from a PM, and I think it would be helpful to also round down any remaining use below tolerance to zero.
There was also an issue in the _RESET() method, where state was being created as an array istead of a dict, and so updates to the state, based on dict keys, did not work.
Proposed fixes below, with a comment followed by my initials (JMF) and an explanation for each changed/added line. Happy to raise a pull request if helpful.
   def _STEP(self, action): # JMF: _STEP instead of step, otherwise _STEP from parent used
        done = False
        pm_state = self.state["state"][:-1]
        demand = self.state["state"][-1, 1:]

        if action < 0 or action >= self.n_pms:
            raise ValueError("Invalid action: {}".format(action))

        elif any(pm_state[action, 1:] + demand > 1 + self.tol):
            # Demand doesn't fit into PM
            reward = -1000
            done = True
        else:
            if pm_state[action, 0] == 0:
                # Open PM if closed
                pm_state[action, 0] = 1
            pm_state[action, self.load_idx] += demand
            reward = np.sum(pm_state[:, 0] * (pm_state[:,1:].sum(axis=1) - 2))
            self.assignment[self.current_step] = action

        # Remove processes
        if self.current_step in self.durations.values():
            for process in self.durations.keys():
                # Remove process from PM
                if self.durations[process] == self.current_step:
                    pm = self.assignment[process] # Find PM where process was assigned
                    pm_state[pm, self.load_idx] -= self.demand[process][1:] # JMF: Index to exclude first element of demand array
                    pm_state[pm, self.load_idx] = np.where(pm_state[pm, self.load_idx]<self.tol, 0., pm_state[pm, self.load_idx]) # JMF: Deal with rounding
                    # Shut down PM's if state is 0
                    if pm_state[pm, self.load_idx].sum() == 0:
                        pm_state[pm, 0] = 0

        self.current_step += 1
        if self.current_step >= self.step_limit:
            done = True
        self.update_state(pm_state)
        return self.state, reward, done, {}

    def _RESET(self):
        self.current_step = 0
        self.assignment = {}
        self.demand = self.generate_demand()
        self.durations = generate_durations(self.demand)
        self.state = {
            "action_mask": np.ones(self.n_pms, dtype=np.uint8),
            "avail_actions": np.ones(self.n_pms, dtype=np.uint8),
            "state": np.vstack([
                np.zeros((self.n_pms, 3)),
                self.demand[self.current_step]],
                dtype=np.float32)
        } # JMF: Dict instead on NumPy array, otherwise update_state doesn't work
        return self.state

Could you please let me know how to use VMPacking-v1 or VMPacking-v0.  I'm not sure how to set up the env_config for this. Any help would be greatly appreciated.


[WIP]Datatype mapping: datetime to datetime2

This PR is to change datetime datatype mapping in JDBC mssqldialect.
What changes were proposed in this pull request?

override def getJDBCType(dt: DataType): Option[JdbcType] = dt match {
case TimestampType => if(oldDateTime) {Some(JdbcType("DATETIME", java.sql.Types.TIMESTAMP))} else {Some(JdbcType("DATETIME2", java.sql.Types.TIMESTAMP))}
Why are the changes needed?

Spark datetime type is timestamptype. This supports a microsecond resolution.
Sql supports 2 date time types
datetime can support only milli seconds resolution (0 to 999).
datetime2 is extension of datetime , is compatible with datetime and supports 0 to 9999999 sub second resolution.
datetime2 (Transact-SQL) - SQL Server | Microsoft Docs
datetime (Transact-SQL) - SQL Server | Microsoft Docs
Currently MsSQLServerDialect maps timestamptype to datetime. This implies results in errors when writing
Does this PR introduce any user-facing change?

How was this patch tested?

Can one of the admins verify this patch?


Sunset and sunrise time based on current location

Sunrise and sunset time can be based on the phones current location.
Also it would be nice if there was a feature where you can set an alarm based on the sunrise and sunset time, like 10 minutes before or after or however long.

This is not really planned, sorry. I don't see much value in adding an extra permission and adding extra complexity to the codebase when it is trivial to look up and input sunrise/sunset times on your own.


RDKTV-9417 : HDMI-CEC state does not persist

Reason for change:
HDMI-CEC_state_does_not_persist
Test Procedure: None
Risks: Low
Change-Id: I8374c97ed6a3ca901686d83a5e1115f8259a3baa
Signed-off-by:Anooj Cheriyan<EMAIL_ADDRESS>

New one created: https://github.com/rdkcentral/rdkservices/pull/1632


fix(huggingface): fix huggingface dataloader when using some huggingface third-party tokenizers

Motivation
Some huggingface tokenizer may generate empty input_ids for very short sentences when the sentence only contains special tokens.
Modification
fix huggingface dataloader when using some huggingface third-party tokenizers
BC-breaking (Optional)
None
Use cases (Optional)
None
Checklist
Before PR:

[ ] Pre-commit or other linting tools are used to fix the potential lint issues.
[ ] Bug fixes are fully covered by unit tests, the case that causes the bug should be added in the unit tests.
[ ] The modification is covered by complete unit tests. If not, please add more unit test to ensure the correctness.
[ ] The documentation has been modified accordingly, like docstring or example tutorials.

After PR:

[ ] If the modification has potential influence on downstream or other related projects, this PR should be tested with those projects.
[ ] CLA has been signed and all committers have signed the CLA in this PR.

Done and ready for merge.


Have our Tessen Implementation Reviewed by Project Tessen team member

Once we resolve all of our analytics bugs, we can work with Miguel to have someone on his team review our implementation of Tessen on our sites to ensure we've done it correctly to eliminate the possibility that Tessen was setup incorrectly which could be causing some of our data discrepancies in the analytics pipeline.
Acceptance Criteria
Resolve these issues first:
https://github.com/newrelic/docs-website/issues/1331
https://github.com/newrelic/docs-website/issues/1816
https://github.com/newrelic/docs-website/issues/1818
https://github.com/newrelic/docs-website/issues/1815
https://github.com/newrelic/gatsby-theme-newrelic/issues/339

We've done a lot of work in this area so I think we can pass on this issue and just mark it as won't do.


(aws-cloudfront-s3) Error when trying to add an edge lambda - Cannot read properties of undefined (reading 'role')

I'm using CloudFrontToS3 construct and I try to configure an edgeLambda as default behavior (in order to validate some security aspects). When trying to add this edge lambda I get an error Cannot read properties of undefined (reading 'role')
Reproduction Steps
lambda :
this.lambdaAuthorizer = new NodejsFunction(this, 'LambdaAuthorizer', {
      entry: path.join(__dirname, 'lambda-authorizer.cloudfront.js'),
      runtime: Runtime.NODEJS_18_X,
    });

    this.lambdaAuthorizer.addPermission('LambdaPermission', {
      principal: new iam.ArnPrincipal('cloudfront.amazonaws.com'),
    });

cloudfront :
const edgeLambdas = [];
    if (props.lambdaAuthorizer) {
      const edgeLambda = {
        functionVersion: props.lambdaAuthorizer.currentVersion,
        eventType: cloudfront.LambdaEdgeEventType.ORIGIN_REQUEST,
      };
      edgeLambdas.push(edgeLambda);
    }

const cloudfrontS3 = new CloudFrontToS3(
      this,
      `${props.stageName}-frontweb-cloudfront-s3`,
      {
        cloudFrontDistributionProps: {
          domainNames: [props.domainName],
          certificate: props.acmCertificate,
          defaultBehavior: {
            edgeLambdas: [edgeLambdas],
          },
        },
      }
    );

Error Log
TypeError: Cannot read properties of undefined (reading 'role')
    at .../node_modules/.pnpm/aws-cdk-lib@2.122.0_constructs@10.3.0/node_modules/aws-cdk-lib/aws-cloudfront/lib/private/cache-behavior.js:1:2227
    at Array.forEach (<anonymous>)
    at CacheBehavior.grantEdgeLambdaFunctionExecutionRole (.../node_modules/.pnpm/aws-cdk-lib@2.122.0_constructs@10.3.0/node_modules/aws-cdk-lib/aws-cloudfront/lib/private/cache-behavior.js:1:2168)
    at new CacheBehavior (.../node_modules/.pnpm/aws-cdk-lib@2.122.0_constructs@10.3.0/node_modules/aws-cdk-lib/aws-cloudfront/lib/private/cache-behavior.js:1:488)
    at new Distribution (.../node_modules/.pnpm/aws-cdk-lib@2.122.0_constructs@10.3.0/node_modules/aws-cdk-lib/aws-cloudfront/lib/distribution.js:1:2829)
    at Object.createCloudFrontDistributionForS3 (.../node_modules/.pnpm/@aws-solutions-constructs+core@2.49.0_aws-cdk-lib@2.122.0_constructs@10.3.0/node_modules/@aws-solutions-constructs/core/lib/cloudfront-distribution-helper.ts:163:26)
    at new CloudFrontToS3 (.../node_modules/.pnpm/@aws-solutions-constructs+aws-cloudfront-s3@2.49.0_@aws-solutions-constructs+core@2.49.0_@aws_jwial6ick6kxquuqlppejzoata/node_modules/@aws-solutions-constructs/aws-cloudfront-s3/lib/index.ts:147:58)
    at new FrontWebStack (.../apps/cdk/lib/front-web.ts:43:26)
    at createStatefulStacks (.../apps/cdk/bin/frontend.app.ts:56:3)
    at Object.<anonymous> (.../apps/cdk/bin/frontend.app.ts:23:5)

Environment

CDK CLI Version      : 2.122
CDK Framework Version: 2
AWS Solutions Constructs Version     : 2.49
OS                   : macOS
Language             : Typescript

Other

This is :bug: Bug Report

Thanks, we'll take a look

hmm sorry I think it was a stupid mistake on my part...
edgeLambdas is already an array, and it was set in another array in defaultBehavior
i'm closing this issue. Thanks!

Thanks for letting us know - glad you've got it working!


fix issue that string value that start with 0 will be treated as number during serializing

this issue will make the json result cannot be parsed.

CI builds re-ran and succeeded. Permission issues fixed.

@chaosddp you're right, according to json spec  a number does not start with '0' and then extend to more digits. However, we should at least check that the thing is not a single 0.

Done.

@chaosddp thanks! I think we can merge this for now -- but we will have to keep thinking about a long-term fix. maybe we should use bson or msgpack to carry the select payload so the types are preserved.


Add extra WiFi info to bundle format

We need to be able to set and compare the following extra attributes:

WiFi region (what are valid values for this?)
WiFi Client / AP mode (i.e connect to arena)
WiFi enabled / disabled - we may want to disable the wifi.

These are defined in the Metadata schema.
https://github.com/srobo/astoria/blob/fbcf065436411cb37faa57f46ac37d6760daf4f7/astoria/common/messages/astmetad.py#L61

For AP mode we will also need to provide an SSID and passphrase.

For AP mode we will also need to provide an SSID and passphrase.

Absolutely. These are already defined in the schema :)


Injector64 and Injector32 Single-Line error.

[19:21:31.805] [error]	Expected 2 arguments, received: 0
I receive this error in both the injector64 and injector32 logs.
Is this expected or should I be doing something different?

This tells me absolutely nothing. You should share all details and all relevant log files if you want help.

OH! Forgive me, I'm mentally incapacitated for not reading the readme for the injector <_<.


Test Kubeflow addon in Github actions

@ktsakalozos: Currently failing due to the apiserver restarting while enabling addons. That seems a lot like the troubles we were having with dqlite causing the apiserver to restart.


Document cargo doc --document-private-items in README

@tomhoule
Could you elaborate a little more on your intention of this issue?

Sorry I didn't reply earlier - there is a --document-private-items flag you can pass to cargo doc so the code generated by the derive is documented, even if it's private.

It's now in the README so I'll close this issue.


Fetching strategy

Hi,
My compagny is considering moving from OrientDB to ArangoDB.
Is there some AQL syntax or way to achieve OrientDB SQL fetchplan ?
Thanks.

The aim of fetch plans is to pre-load connected records in one shot.

I'm not an OrientDB expert, but it seems like it loads records lazily in general. Fetch plans can be used to make it load records more eagerly apparently.
In ArangoDB, you can write your traversals in AQL. There is only a single server roundtrip for a query, regardless of the traversal depth. Traversals use edge indexes, which are held in memory. It's super fast to read them and therefore to traverse. Loading the full vertex and optionally the edge documents may require harddrive / ssd access (if the collection is not fully loaded into RAM), but is generally fast as well (Arango uses memory-mapped files). A user-specified fetching strategy is not really required.
Can you tell us more about your use case though?

@Simran-B
first, thanks for your quick response.
We want to strore documents with properties bound to documents.
For example, we have an invoice document bound to a Customer with a property named "Cust"
Documents are connected with edges.
From a document managment perspective, we need to manage content versioning. Thus, document are not connected directly to the document targeted by the property (Cust) but to an intermediate document (called proxy) who responsability is to idenfity document's current version with a specific edge named CurrentVersion
[Document]Invoice -> [Edge]Property -> [Document]Customer_Proxy -> [Edge]CurrenVersion -> [Document]Customer_Data
What we want to do is to get Customer data when we get invoice document, in the simplest way
we already have done it this by using  :

using anonymous graph approach with traversal
using AQL Joins approach between Edge

Here is sample graph command
FOR invoice IN invoices
FOR vertex, edge IN 0..2 OUTBOUND invoice._id
propery , currentVersion
return { key :  vertex._id , edge : edge , value : vertex }
but we found that result is quit bit complex to analyse ( may be we just dont know how to do it right !)
How can we get result like  (or kind of) ?
{
invoice  : { invoideID : 12 , shippingDate : ...} ,
customer  : { name : "Customer one" , CustID : "158-47" ...}
}
In your resonse, you said

Traversals  use edge indexes, which are held in memory. It's super fast ...

am i right if i think that using joins on edges indexes (_from, _to ) is fast too ?
Thanks for your  response and congratulations for your good job on ArangoDB !

Been thinking about this for a while and 4 different data models came to my mind:

In your current model, an Invoice is linked to a Customer record via a Proxy. There is supposed to be a single CurrentVersion edge from a Proxy to a Customer record. This can't be ensured on the database level however. You actually need a transaction to delete the CurrentVersion edge in order to make another Customer record (new revision) the current version by inserting a new edge and getting rid of the old one. That seems sub-optimal. I wonder if there would be additional edges to link the Proxy to all (former) Customer records.

currentVersion: true could just be a flag of one of the edges that link Invoices with Customers via the Proxy. You would keep all edges created between Proxies and Customer records. But this would still require a transaction to update the existing edge (remove currentVersion attribute) and to insert the new Customer record as well as the edge to link it to the Proxy. A way to avoid that would be to use an increasing version number or timestamp instead of a boolean (leaving the previously existing edges untouched). If you follow the edge with the highest number / most recent timestamp, you'll get to the latest Customer record. You can actually remove the intermediate Proxy with this model altogether.

You could store the latest customer data in a single Customer record, and have a special attribute that holds the old revisions in an array of objects. There would be no Proxy in this model. The benefit: the attributes with the latest data can have indexes on them, whereas the old revisions would stick around without indexes in a growing array.

Instead of storing old revisions of the customer data inside each Customer record, you could have a separate collection (archive) and store the Customer keys along with it (one record per revision). Using the key, it is possible to join them to the main Customer records. The Customer records themselves would only store the latest version of the data. The benefit is that you can have indexes on the attributes in both collections if desired.

What the best approach is depends on how much data you will store, what queries will commonly we run etc.
On a different note: you don't have to use 0..2 traversal if the number of hops is fixed. You can actually do two 1..1 OUTBOUND traversals to go via Proxy to Customer. Maybe that helps to build the desired result data structure? You can also use the 3rd traversal variable with the path to construct it differently.

tks, i need to think more about it.
one question more about edges collection. From a memory perspective, is it better to have one big collection to hold all property edges (i' my case) or it's better to split it into more small collections ? i think the overall memory foot print should remain nearly the same but as is going to be a very huge collection, i'm wondering what's the best approach.

@thierry-github have a look at: https://docs.arangodb.com/3.0/Manual/Graphs/index.html#multiple-edge-collections-vs-filters-on-edge-document-attributes

thanks for the link


Add support of testing dynamically created ports

Updates
Dynamic ports testing

Added new functionality so testing nodes with dynamic port is possible now. Usage is pretty simple, just need to specify dynamic ports that would have been created on the gui, like here

.parameters({
    ...,
    'Output ports': ['upcoming', 'sold'],
})
.and()
.dynamicPorts(['upcoming', 'sold'])
.assertOutputs({
    Unfiltered: [{ status: 'for-sale' }],
    upcoming: [{ status: 'upcoming' }],
    sold: [{ status: 'sold' }],
})

Made assertOutput more configurable so it’s possible now to specify what port will be checked for the one output port

...
.assertOutput([{ status: 'for-sale' }], 'Unfiltered')
...

Added/fixed a couple of types

Filter tests
Added three more tests

of filtering with random values
of filtering with random values + dot notated paths
of filtering with random values + simple features

lodash usage
It’s always better to import things from lodash library like here
import cloneDeep from 'lodash/cloneDeep'

instead of importing of full library using asterix
import * as _ from 'lodash'

_.cloneDeep

That will significantly reduce the bundle size

.dynamicPorts(['upcoming', 'sold'])

This approach is a great start. Maybe, this could be handled directly in underlying DiagramBuilder .add()? . As NodeTester/"when" kind of emulates what a user would put in and user does not need to configure an extra setting "dynamic ports", perhaps it should not concern the NodeTester at all. Anyways the port columns is identifyable via their own type now so possibly NodeTester could figure that out right?
One related thing we can try is if the Filter node works as a demo in demos.tsx (that needs to be hooked back up into the localclient/load first though).

Great tests 💪 and noted on lodash imports! Im still trying to wrap my head around this so take these thoughts with a grain of salt 😅

Merging - lets revisit in follow ups


Allow multiple configurations

I'd love to be able to connect to two different dynamo tables in my app, which may be owned by different authenticated users.
auth_v4.RawReq is a 'static' function that reads the conf.Vals object every time.
I'd love to be able to initialize a struct with a conf object, which rawReq would read before making the request, rather than the global conf.Vals object.
I think it would presumably still be possible to have a background goroutine looking for config updates (like in the README example)?
I can take a stab at this if it sounds reasonable to you.

Hi Justin. Sad to say I am only getting around to looking at this now. Sorry, the holidays and kids have had me tied up. I'm proceeding to try to get this in to my own private branch to run a while before pushing public.
So I see in your conf.go branch, you are using unsafe.*. Is there any particular reason for this? I haven't used this package before so I'm not well versed in the advantages of using it in this way, but the docs seem to indicate fairly strongly that this package circumvents the Go compatibility requirements, so I'm inclined to try to accomplish what you have done here using mainstream packages. I presume just wrapping the setter (SetShared) with mutexes should suffice? If there is something more subtle here, let me know.
And happy new year!

https://github.com/bradclawsie/godynamo/tree/multiple-configs
I am working on this at the above branch in my own repo, little by little. At some point I will be ready to discusses some differences with the PR already offered

After thinking about this for a while and hacking away on a halfway counterproposal, I think I want to go back to the drawing board with this if it is to be considered at all. I'd like to open a discussion here to address this at a high level before committing to code.
First, it seems obvious that handling multiple configurations in a single GoDynamo program is something people need and want, and the lack of this feature from the start simply reflects my own use-case.
That said, I feel that this PR just bolts on a new parameter in a way that is incongruous with the existing architecture.
The new parameter sidesteps the Roles interface as defined in the goawsroles package. Given that the Roles interface was designed specifically to allow new mechanisms for propagating authentication information, I would prefer that we try to extend it for new use-cases.
Using the Roles interface to propagate authentication information would also allow methods to be defined on the Roles instance, allowing safe concurrent reading and updating of temporary credentials. While we can embed a Lock into the conf struct, it doesn't afford the same flexibility as using an interface.
By suggesting that an instance of the Roles interface be used in place of a conf struct, I am assuming that the real issue here is about parameterizing credentials, not parameterizing other values like Host, Port, Zone. It seems unlikely that a caller would want to change these for each request in a running program. If anyone reading this really does need to parameterize more than just credentials, let me know...otherwise I would like to work on a variant of this that exploits the Roles interface.
I'll leave this open for a while to solicit comments.

So pursuant to the unveiling of an "official" Go SDK last week (https://aws.amazon.com/blogs/aws/coming-soon-aws-sdk-for-go/)...the best way for me to proceed (imho) is to have the credentials param passed be the one used in the prospective SDK. This will allow users of GoDynamo to more sanely interact with other code using the official SDK while protecting their investment in GoDynamo. I will start tonight working on a way to mate the Roles interface in goawsroles to the prospective SDK credential type.
Comments?

I've started working on this here:
https://github.com/bradclawsie/goawsroles/tree/roles_master
sorry, I only realized too late that "roles_master" is a terrible name for a branch.
The point here is to introduce a new Role implementation called RolesMaster which handles "master" credentials. I've also added a new getter which will return the Credentials type used in the soon-to-be-official SDK.
Work in this branch isn't anywhere useful for anything but review and comments.

Sorry this PR has been silent for so long and seems to be fairly barren, I have a repo here
https://github.com/bradclawsie/godynamo/tree/credentials_param
that is basically ready soon to be made into a new branch to smugmug/godynamo which should address needs expressed here along with the goawsroles branch above.
Executive summary: no existing code will break, all methods that are relevant now also have a "WithConf" variant that will allow a conf to be passed. It will be more clear when I create a new PR here. soon!

My changes are ready as a PR
https://github.com/smugmug/godynamo/pull/17

The above PR is currently in use at SmugMug. Barring a comment, it will be merged to master early next week.

PR has been merged into master, you may now begin using paramterized configs.


Spec third party invites in auth rules

Based on #1591

I'll update the formatting once #1591 lands
Refs: https://github.com/matrix-org/synapse/blob/74854a97191191b08101821753c2672efc2a65fd/synapse/event_auth.py#L602


Add taskflow

"make all" seems to succeed about 75% of the time, but the rest causes a seg-fault

Splitting changes into distinct PRs


snippets json not using "JSON with comments" language mode

testing #39588
F1
Open user snippets
Pick JavaScript
javascript.json opens
result: language mode is JSON,
expected: language mode is JSON with Comments

Same happens for any/all of the other language snippet files (e.g. css.json, csharp.json, etc.)

duplicate of #39642


Firegento doesn't update with new releases

Don't know why, have to investigate... If anyone has more experience with Firegento and an idea why this happens, help is always welcome.

@icurdinj The Firegento repository is a Satis repository. As such, it  follows the rules outlined here: https://getcomposer.org/doc/02-libraries.md#tags with regard to picking up on valid version numbers.
The current tag naming scheme for this project, CE-X.Y.Z or EE-X.Y.Z -- these do not match any of the formats outlined in the documentation. A more appropriate tag naming scheme for composer compatibility might be something like X.Y.Z-CE or X.Y.Z-EE.
You might also consider splitting this project into separate repos or branches to distinguish between the CE/EE versions of the module. This would eliminate the need for tag prefixes/suffixes.

@icurdinj I just tried to pull in your 1.0.3-CE tag into my private satis repo, but it didn't show up in the releases section. Additionally, I created a test repo and tried a few variations of tags which included CE in them, and none of them counted as "releases" in the eyes of Satis/Composer.
If you want releases to show up in a satis repository, it looks like you must be very conservative in your tag naming. Any git tag prefix/suffix beyond what is explicitly listed in the documentation will result in the tag not counting as a "release".
IMO, the best way to proceed from here is the split repo approach. One repo for the CE version, and one repo for the EE version.
In the split-repo layout, a Magento CE user might specify in their composer.json:
"require": {
  "inchoo/php7-ce": "^1.0.4"
}

Whereas the Magento EE user would do this:
"require": {
  "inchoo/php7-ee": "^1.0.4"
}

Thank you very much @t-richards for all the information and effort. Since the difference between CE and EE versions is very small, and it is very convenient to keep everything in one repository and just 2 branches, I finally decided to make a simple "1.0.3" release of master branch, which is for CE and should show up on Firegento. EE version will just have to be installed from "dev-EE" version/branch, at least for the time being.
At least it's better for CE users, while being the same as it was for EE users and contributing developers, so I guess it's some small progress after all.

The 1.0.3 tag looks good to me. It shouldn't be too much longer before it appears on the Firegento repo.


Offset change prevent songs from being completed in subsequent plays.

Using Etterna 0.55.2 — if you make any sort of offset change to a song as it is playing and save it, the song becomes unable to be completed; the game fades as if the song has completed.
This bug is retroactive: if you close the game and restart it, those songs that were affected by this bug remain affected. Additionally, restoring the offset to what it was prior does not resolve the issue for the current session, or after the game is closed and reopened.
Here's a video showcasing this: https://www.youtube.com/watch?v=BuLdN1ONiMc

yeah this is a known issue that has started to come up quite a lot in recent days, the solution is to manually reload the file from disk using ctrl shft r at music select on the file or to wipe the cache for the file from the cache dir and restart the game (more or less the same thing the cache is the problem)
at this point I am considering another small patch that will forcibly reload the file from disk after sync changes are applied along with other minor crash and bug fixes
originally I was waiting for 0.56 to fix it however that sort of ended up being ahead of schedule and in a weird way that may have pushed it back since there's an opportunity to increase the scope of updates
I haven't settled on a decision but I'm leaning toward another minor patch in a couple days

Works for me temporarily; thanks a bunch for that, at least.

fixed with 8eec96f5bc107c11aa57ff81c88989fb266bafc8


Implement string and character literals

String and character literals pop up a bit in binary formats, for example in OpentType's table tags, or in the 'magic' strings at the beginning of file formats.

This was implemented in ac15adfdd58e131426a6faaf5652b4f90dcf28e0


Update 1 40

Checklist

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

Hi! This is the friendly automated conda-forge-linting service.
I wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml) and found some lint.
Here's what I've got...
For recipe/meta.yaml:

The home item is expected in the about section.
The summary item is expected in the about section.
This recipe is using a compiler, which now requires adding a build dependence on {{ stdlib("c") }} as well. Note that this rule applies to each output of the recipe using a compiler. For further details, please see https://github.com/conda-forge/conda-forge.github.io/issues/2102.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml) and found it was in an excellent condition.


W-12183598-shared-responsibilities-kt

Writer's Quality Checklist
Before merging your PR, did you:

[ ] Run spell checker
[ ] Run link checker to check for broken xrefs
[ ] Check for orphan files
[ ] Perform a local build and do a final visual check of your content, including checking for:

Broken images
Dead links
Correct rendering of partials if they are used in your content
Formatting issues, such as:

Misnumbered ordered lists (steps) or incorrectly nested unordered lists
Messed up tables
Proper indentation
Correct header levels

[ ] Receive final review and signoff from:

Technical SME
Product Manager
Editor or peer reviewer
Reporter, if this content is in response to a reported issue (internal or external feedback)

[ ] If applicable, verify that the software actually got released

Closing as opened new PR with verified commits https://github.com/mulesoft/docs-connectors/pull/2252


Giving nodes a default size causes focused node to be too small at detailed node zoom level

Turns out the changes leading to the Vizceral v4.3.6 release caused the double-clicked node to be drawn too small in the detailed node zoom level view.  Setting the node size of the double-clicked node in focusedChildTrafficGraph.js fixes this without altering the node's size in the traffic data.

Good find, merged and released 4.3.8.


[<Firebase_Auth>] Unable to Catch SignInWithEmailAndPassword Exception

I'm on Android platform.
I've been trying to catch and display the exception for wrong email or password on the app screen.
here's my code:
try {
        await FirebaseAuth.instance
              .signInWithEmailAndPassword(
                  email: _emailTextController.text,
                  password: _passwordTextController.text)
                  .then((u) {
                      Navigator.push(
                          context,MaterialPageRoute(builder: (context) => HomePage()),
                        );
                      });
                    } on FirebaseAuthException catch (e) {
                      setState(() {
                        errorMessage = e.message;
                      });
                      print(e.code);
                      print(e.message);
                    }

It worked fine with firebase_auth: ^0.16.1. I could catch and display the exception and app doesn't stop so I can make correction and re-try login.
flutter doctor output:
Doctor summary (to see all details, run flutter doctor -v):
[√] Flutter (Channel beta, 1.20.0, on Microsoft Windows [Version 10.0.19041.450], locale id-ID)

[√] Android toolchain - develop for Android devices (Android SDK version 29.0.3)
[√] Chrome - develop for the web
[√] Android Studio (version 4.0)
[√] VS Code (version 1.48.1)
[√] Connected device (4 available)

• No issues found!

Web/Android/iOS?

Android.
I manage to catch it on Web platform after adding user null check after .then method.
but still couldn't catch it on android platform.

@dhanniex82 Can you update that repo (and link it here again) with the code and I'll try on Android.

@Ehesp I have updated the repo.
please check https://github.com/dhanniex82/flutterFireAuthExample
you can try with web platform, it caught the exception and display it on screen but doesn't work on android platform.
email<EMAIL_ADDRESS>password: 123456

Seems to be working for me:

so far I have tried a few things.
flutter clean -> failed
tried on android 8 emulator -> failed
tried on android 9 emulator -> failed
tried on real phone -> failed.
then I switched from vs code to Android Studio IDE -> passed. It caught the exception and keep the app running.
not sure what happened with my vs code but I see from your screenshot that you are using vs code.


Pathogen detection from (direct Nanopore) sequencing data using Galaxy - Foodborne Edition, training update 2024

I have updated the training based on the latest update for the used workflow
I kindly ask for a review

Thanks @EngyNasr! This looks good from my side

@shiltemann Thank you soooo much :) , I was pushing some changes to two of the workflows same time, so I made a conflict by mistake, I applied all your changes in the last push but manually to resolve the conflict

Thanks @EngyNasr for all the changes. I will merge now!


[Task]: Upload client build's source map to s3 bucket

Is there an existing issue for this?

[X] I have searched the existing issues

SubTasks
The source maps are required for debugging performance profiles shared by users. Without the source maps, the performance profiles contain obfuscated info about the stack trace. Source maps de obfuscated the stack trace and add actual function names.
The source maps are generated when a client build is made.
Suggested solution:

The source maps can be uploaded to s3 bucket whenever a build is tagged or code is merged to master.
The source maps would need to be annotated with workflow run ids in the s3 bucket.
The source maps are deleted at the moment here
We can decide to not delete the source maps at the step mentioned above and instead add it to client build workflow. The steps are mentioned here.
The upload script should delete source maps in the s3 bucket older than 6 months.

Closing because team has decided to add source map to production build.


Kong Mesh is missing OPA Policy doc

Where is the problem?
https://docs.konghq.com/mesh/2.1.x/policies/meshopas
What happened?
404
What did you expect to happen?
expected to see Mesh Policy for OPA
Code of Conduct and Community Expectations

[X] I agree to follow this project's Code of Conduct
[X] I agree to abide by the Community Expectations

Like from the GUI. Maybe worth adding a redirects.

https://docs.konghq.com/mesh//policies/meshopas to https://docs.konghq.com/mesh//features/meshopa/


proposal: reflect: allow creation of recursive types atomically

Background and introduction
The proposal in #39528 has been criticised for the fact that it would introduce "incomplete" instances of reflect.Type. This alternative proposal addresses that shortcoming: here, newly created recursive reflect.Types can emerge only through a single function, reflect.Bind. This new function either returns a reflect.Type which can be used with the same expectations as any other reflect.Type, or it panics (hence, "atomically"). The remainder of the reflect API is not affected.
This convenience comes at the cost of building a partially parallel infrastructure to describe the type to be newly created. The central component is a new interface reflect.TypeDesc instances of which are immutable descriptions of a type (or type-to-be) and a number of functions for the construction of such descriptions.
Proposal
We provide the proposal in the form of go source code. For orientation, the following new objects parallel existing objects in the reflect package:

New
Existing

DescArray
Array

DescChan
Chan

DescFunc
Func

DescInterface
Interface

DescInvalid
Invalid

DescKind
Kind

DescMap
Map

DescPtr
Ptr

DescSlice
Slice

DescStruct
Struct

DescribeArray
ArrayOf

DescribeChan
ChanOf

DescribeFunc
FuncOf

DescribeMap
MapOf

DescribePtr
PtrTo

DescribeSlice
SliceOf

DescribeStruct
StructOf

MethodDesc
Method

StructFieldDesc
StructField

TypeDesc
Type

The following new objects have no parallel:

New

Bind

Complete

DescComplete

DescIncomplete

DescribeInterface

Incomplete

Proposal as go code:
// A DescKind represents the specific kind of type description that a TypeDesc
// represents. The zero DescKind is not a valid type description kind.
type DescKind uint

const (
	DescInvalid             = DescKind(Invalid)
	DescArray               = DescKind(Array)
	DescChan                = DescKind(Chan)
	DescFunc                = DescKind(Func)
	DescInterface           = DescKind(Interface)
	DescMap                 = DescKind(Map)
	DescPtr                 = DescKind(Ptr)
	DescSlice               = DescKind(Slice)
	DescStruct              = DescKind(Struct)
	DescIncomplete DescKind = (1 << 5) - 2
	DescComplete   DescKind = (1 << 5) - 1
)

// String returns the name of dk.
func (dk DescKind) String() string

// TypeDesc represents a description of a (possibly incomplete) type. A type
// description is a safe way to describe the layout of a (possibly recursive)
// type with the Complete, Incomplete, DescribeArray, DescribeChan,
// DescribeFunc, DescribeInterface, DescribeMap, DescribePtr, DescribeSlice,
// and DescribeStruct functions before the actual Type is created with Bind.
type TypeDesc interface {
	// ChanDir returns a channel description's direction.
	// It panics if the description kind is not DescChan.
	ChanDir() ChanDir

	// Elem returns the element type description for this type description.
	// It panics if the description kind is not DescArray, DescChan, DescMap,
	// DescPtr, or DescSlice.
	Elem() TypeDesc

	// Field returns a struct type description's i'th field description.
	// It panics if the description kind is not DescStruct.
	// It panics if i is not in the range [0, NumField()).
	Field(i int) StructFieldDesc

	// FieldByName returns the struct field description with the given name
	// and a boolean indicating if the field description was found.
	// It panics if the description kind if not DescStruct.
	FieldByName(name string) (StructFieldDesc, bool)

	// Key returns a map type description's key type description.
	// It panics if the description kind is not DescMap.
	Key() TypeDesc

	// Kind returns the specific description kind of this type description.
	Kind() DescKind

	// In returns the type description of a function type descriptions's i'th
	// input parameter.
	// It panics if the description kind is not DescFunc.
	// It panics if i is not in the range [0, NumIn()).
	In(i int) TypeDesc

	// IsVariadic reports whether a function type description's final input
	// parameter is a "..." parameter. If so, td.In(td.NumIn() - 1) returns the
	// parameter's implicit actual type description []T.
	//
	// For concreteness, if td describes func(x int, y ... float64), then
	//
	//	td.NumIn() == 2
	//	td.In(0) is a reflect.TypeDesc for "int"
	//	td.In(1) is a reflect.TypeDesc for "[]float64"
	//	td.IsVariadic() == true
	//
	// IsVariadic panics if the description kind is not DescFunc.
	IsVariadic() bool

	// Len returns the length property of an array description.
	// It panics if the description kind is not DescArray.
	Len() int

	// Method returns the i'th method description in the type description's
	// method description set.
	// It panics if the description kind is not DescInterface,
	// or if i is not in the range [0, NumMethod()).
	//
	// In particular, Method does not work on descriptions with kind DescStruct.
	// Method returns only method descriptions explicitly added with
	// DescribeInterface, not methods implicitly acquired through embedded fields.
	//
	// The returned method description describes the method signature, without a
	// receiver. The Func field is nil.
	//
	// There is no guarantee that the methods of the resulting type will have the
	// same sort order as in the description.
	Method(int) MethodDesc

	// MethodByName returns the method description for the method with that name
	// in the type descriptions's method description set and a boolean indicating
	// if the method was found.
	// It panics if the description kind is not DescInterface.
	//
	// The returned method description describes the method signature, without a
	// receiver. The Func field is nil.
	MethodByName(string) (MethodDesc, bool)

	// Name returns the name of the described type.
	// It panics if the description kind is not DescIncomplete.
	Name() string

	// NumField returns a struct type description's field description count.
	// It panics if the description kind is not DescStruct.
	NumField() int

	// NumIn returns a function type description's input parameter count.
	// It panics if the description type is not DescFunc.
	NumIn() int

	// NumMethod returns the number of method descriptions in the type
	// description's method set.
	// It panics if the description kind is not DescInterface.
	NumMethod() int

	// NumOut returns a function type description's output parameter count.
	// It panics if the description kind is not DescFunc.
	NumOut() int

	// PkgPath returns the designated package path in a description of an
	// incomplete type. It panics if the description kind is not DescIncomplete.
	PkgPath() string

	// Out returns the type description of a function type description's i'th
	// output parameter.
	// It panics if the description kind is not DescFunc.
	// It panics if i is not in the range [0, NumOut()).
	Out(i int) TypeDesc

	// Underlying returns the actual type underlying this type description.
	// It panics if the description kind is not DescComplete.
	Underlying() Type
}

// StructFieldDesc describes a struct field.
type StructFieldDesc struct {
	// Name is the field name. It must start with an uppercase letter.
	Name string

	// Type is the description of the field type.
	Type TypeDesc

	// Tag is the field tag string.
	Tag StructTag

	// Anonymous indicates whether or not this struct field description
	// describes an embedded field.
	Anonymous bool
}

// MethodDesc describes a method.
type MethodDesc struct {
	// Name is the method name. It must start with an uppercase letter.
	Name string

	// Type describes the method type.
	//
	// For interface descriptions, Type should describe the signature of the
	// method.
	//
	// For descriptions of incomplete types, Type should describe a function
	// whose first argument is the receiver.
	Type TypeDesc

	// Func is nil if this description describes an interface method.
	//
	// For descriptions of methods of incomplete types, Func is the method
	// implementation with receiver, arguments and return values in terms of
	// reflect.Value.
	// Methods for incomplete types are not implemented yet.
	Func func(recv Value, in []Value) []Value
}

// Incomplete creates a type description for an incomplete named type.
// It panics if name is not a valid identifier starting with an uppercase
// letter. The package name may be empty but it is recommended that each
// package use a unique string here (such as its fully qualified package name)
// to avoid naming clashes with other packages.
func Incomplete(pkgName, name string) TypeDesc

// Complete creates a description of the given already complete type.
func Complete(typ Type) TypeDesc

// DescribeArray creates a description of an array type with the given count and
// element type described by elem.
// It panics if elem's description kind is DescIncomplete.
func DescribeArray(count int, elem TypeDesc) TypeDesc

// DescribeChan creates a description of a channel type with the given
// direction and element type described by t.
//
// The gc runtime currently imposes a limit of 64 kB on channel element types.
// If t is not of description kind DescIncomplete and describes a type whose
// size is equal to or exceeds this limit, DescribeChan panics. If t describes
// an incomplete type, a later call to Bind will panic if the resulting type
// would violate this limit.
func DescribeChan(dir ChanDir, t TypeDesc) TypeDesc

// DescribeFunc creates a description of the function type with the argument
// and result types described by in and out.
//
// The variadic argument controls whether the description of a variadic function
// is returned. If variadic is true and in[len(in)-1] does not represent a
// slice (i. e., is either of description kind DescSlice, or DescComplete and
// describes a slice type), DescribeFunc panics.
func DescribeFunc(in, out []TypeDesc, variadic bool) TypeDesc

// DescribeInterface creates a description of the interface type with the
// methods described by methods.
func DescribeInterface(methods []MethodDesc) TypeDesc

// DescribeMap creates a description of the map type with key and
// element types described by key and elem, respectively.
// It panics if key's description kind is DescIncomplete.
//
// Map key types must be comparable (i. e., implement Go's == operator).
// DescribeMap does not perform this check, but a later call to Bind will
// panic if the resulting type would not be a valid key type.
func DescribeMap(key, elem TypeDesc) TypeDesc

// DescribePtr creates a description of the pointer type with element type
// described by t.
func DescribePtr(t TypeDesc) TypeDesc

// DescribeSlice creates a description of the slice type with element type
// described by t.
func DescribeSlice(t TypeDesc) TypeDesc

// DescribeStruct creates a description of the struct type with the fields
// described by fields.
func DescribeStruct(fields []StructFieldDesc) TypeDesc

// Bind creates a new type by binding the type name given by incomp to the type
// described by def.
//
// The methods argument must be nil. A later version may lift this restriction.
//
// It panics if the (package name, name) combination given incomp has been used
// to create a type with Bind before. This does not mean the name of the
// resulting type is unique as this restriction only applies to types created
// with Bind.
//
// It panics if the description kind of def is DescIncomplete, or if def
// indirectly references a description of an incomplete type other than incomp,
// or if a resulting type would be illegal for some reason (for example, a
// channel type whose element size would be too big, or a map key type not
// implementing Go's == operator).
func Bind(incomp, def TypeDesc, methods []Method) Type

Open questions

The proposal above does not explicitly allow creation of interfaces with embedded interfaces. If deemed necessary, the DescribeInterface function can get an additional embedded []TypeDesc parameter. This would allow the creation of interfaces with unexported methods if the embedded interfaces have unexported methods.

I am continuing the implementation of https://github.com/golang/go/issues/39528, and the incompleteness and mutability of the few reflect.Type created with NamedOf is spreading to all of them through the function ArrayOf ChanOf MapOf FuncOf SliceOf StructOf. It starts looking like a major refactoring of reflect.Type methods.
So I welcome a different API that avoids this problem. Out of curiosity: is there a reason why you did not try to leverage go/types.Type API?

Out of curiosity: is there a reason why you did not try to leverage go/types.Type API?

I briefly considered it but discarded the idea for the simple reason that I'm not terribly familiar with that API, which, at first sight, seemed unnecessarily complex to me. My interest in the reflect package comes from writing generic pieces of code, and while I might be wrong, I suspect it's similar for most users, so I tried to make the TypeDesc API as similar as possible to the familiar Type API. I understand that for people whose primary interest in reflect comes from parsing actual Go code, priorities might be different.
I'm not sure how important that actually is, but another aspect to consider might be the dependencies of the reflect package. I might be misinterpreting this, but it seems to me the implementers went to certain lengths to avoid pulling in "convenience" packages such as fmt. The biggest dependencies currently appear to be Unicode related. go/types with its own dependencies would significantly increase the size of reflect dependencies.

The reflect package can't depend on go/types, because go/types depends on fmt and fmt depends on reflect.  It would be quite awkward to rewrite go/types such that it does not depend on reflect in any way.

This is certainly a complex API to design.
I understand the need in a Go interpreter, but it's unclear that the benefit outweighs the very significant API cost.
We should keep thinking about whether there are ways to simplify the cost (API surface, complexity of implementation).
Maybe it would make sense to have a separate package with the same constructors as reflect but that operates only on these incomplete types:
package incomplete // import "reflect/incomplete"

type Type ...

func Complete(list []Type) []reflect.Type
func Of(reflect.Type) Type
func StructOf
PointerTo
ChanOf
MapOf
...

That would at least solve the "Desc everywhere" problem. I'm not sure how much that would end up being a second copy of reflect. And I'm not sure how methods get attached, if anyone wants to try to figure that out.

An external package that allows building recursive reflect.Types could in theory depend on go/types.
Then a minimal API could be:
package convert // import "reflect/convert"
import (
    "go/types"
    "reflect"
)
func ToType(reflect.Type) *types.Named
func ToReflect(*types.Named) reflect.Type

with these two constraints:

ToType only accepts named (i.e. defined) reflect.Types
ToReflect only accepts types.Named which satisfy one of the two conditions:

either returned by a previous call of ToType
or constructed by the user from an underlying type that, when traversed recursively, contains only unnamed types (which are themselves traversed) or named types returned by a previous call of ToType

This would allow a user to collect the named reflect.Types he wants, convert them to types.Type, build a new named type (say X) from them with the usual go/types API - which supports recursive types - then convert such named type to a reflect.Type

Update: or even
package convert // import "reflect/convert"
import (
    "go/types"
    "reflect"
)
func ToGoType(reflect.Type) types.Type
func ToReflect([]types.Type) []reflect.Type

@rsc Separate package sounds good.
There would certainly be some overlap with existing reflect functionality. It seems unnatural exclude "incidentally" non-recursive  types (maybe even unnamed types if there is a Complete API) from the new package, so the *Of functions of reflect would become redundant in the sense that the new API could be used to the same effect (the original *Of functions would still be easier to use for the quick creation of a non-recursive, unnamed type).
@cosmos72 your idea to leverage the go/types package sounds intriguing, especially given it comes with type checking facilities. I've never used it, though, and glancing at it, the API seems quite complex to me, and also not quite geared towards the kind of runtime type creation you'd want in reflect. For example, to create a named recursive type, you'd need a call to NewPackage, NewTypeName and NewNamed, and I don't know what would be sensible arguments for pos and path in a reflectesque context. Also, the type checker only works on an entire file set.
As for implementation complexity, I guess some stuff would probably have to be moved from reflect to some new reflect/internal package, in particular the lookup caches which reflect maintains in order to ensure that for two reflect.Types t1 and t2 we have t1 == t2 if and only if t1 and t2 are identical. The internal package would then be used by both reflect and the new package for incomplete types.

The idea to leverage go/types is useful to understand what's the absolute minimum API needed to create recursive reflect.Types atomically. It has the downside of involving go/types, which:

Has a verbose type creation API, slightly more complicated than strictly needed
Is a large package - it also contains a lot of type-checking features, which are not used in this case
Depends on fmt, which depends on reflect - the implementation of reflect/convert may become tricky, as it cannot depend on reflect

so that's the price to pay for the minimal API: offload the complexity to some other existing package, which does what's needed but also has other features (unused in this case)
Any other API which avoids go/types needs at least:

A two-step process to create named and/or recursive types
A whole series of functions ArrayOf ChanOf MapOf FuncOf PtrTo SliceOf StructOf to compose (possibly incomplete) types
Convenience methods to examine the contents of (possibly incomplete) types: Key Elem ChanDir Field In Out Variadic etc.

thus it cannot be much simpler than your proposal or @rsc one.

Is it not possible to take a middle road, when we still have incomplete types, but only for a defined amount of time. Something like:
NamedOf(name Name, k Kind, m []Method, fn func(t Type) (underlying Type)) Type

This allows the incomplete type to only exist in the closure (as t) but it is an actual type of kind k and will panic if the underlying returned is not the same kind as k. It could be documented that functions like Elem on t would panic, and this no longer needs to be guarded. This seems simple enough to fit in the reflect package and does not cause any duplication of methods.

If you build on go/types you'd also have to build some kind of bridge between the types already built into the binary and the go/types API. Those are really meant to be separate. It doesn't make sense to cross-connect them just for reflection. Let's focus on non-go/types solutions.
Like @cosmos72 said above, it really does seem like the full API (as in https://github.com/golang/go/issues/39717#issuecomment-648975825) is needed, and we just want to get it as lightweight as possible.
Maybe someone would be interested to try to build the API sketched in that comment and see how well it works?

@rsc
Attempt at expanding your sketch
// Package incomplete implements run-time reflection for incomplete types.
// Its purpose is the creation of recursive types.
//
// Invariants:
//
//     Complete([]Type{Of(t)}, nil)[0] == t
//     ArrayOf(n, Of(t)) == Of(reflect.ArrayOf(n, t))
//     ChanOf(d, Of(t)) == Of(reflect.ChanOf(d, t))
//     FuncOf([]Type{Of(in[0]), …, Of(in[len(in)-1])}, []Type{Of(out[0]), …, Of(out[len(out)-1]}, v) == Of(reflect.FuncOf(in, out, v))
//     MapOf(Of(k), Of(e)) == Of(reflect.MapOf(k, e))
//     PtrTo(Of(e)) == Of(reflect.PtrTo(e))
//     SliceOf(Of(e)) == Of(reflect.SliceOf(e))
//     StructOf([]StructField{
//       StructField{ Name: "Foo", Type: Of(ft) },
//     }) == Of(reflect.StructOf([]reflect.StructField{
//       reflect.StructField{ Name: "Foo", Type: ft },
//     })
package incomplete

import "reflect"

// Type represents an incomplete type, or part of an incomplete composite type.
// It is a safe way to define the layout of (possibly recursive) types
// with the Of, NamedOf, ArrayOf, ChanOf, FuncOf, InterfaceOf, MapOf, PtrTo,
// SliceOf, StructOf, and SetUnderlying functions before the actual types are
// created with Complete.
type Type interface {
	// interface shared with reflect.Type
	ChanDir() reflect.ChanDir
	IsVariadic() bool
	Len() int
	Name() string
	NumField() int
	NumIn() int
	NumMethod() int
	NumOut() int
	PkgPath() string

	// reflect.Type analogous methods
	Elem() Type
	Field(int) StructField
	FieldByName(string) (StructField, bool)
	Key() Type
	In(int) Type
	Method(int) Method
	MethodByName(string) (Method, bool)
	Out(int) Type

	// incomplete.Type-specific methods

	// Kind returns the specific kind of this type. It returns reflect.Invalid
	// if this type was returned by NamedOf and it has not been defined yet.
	Kind() reflect.Kind

	// Define defines a named type as the given type. It panics if the type's
	// kind is not reflect.Invalid, if the defining type's kind is
	// reflect.Invalid, or if the result would contain an invalid recursion.
	Define(Type)

	// AddMethod adds the given method to this type. It panics if there is a
	// method name clash, or if methods with distinct, non-empty PkgPath strings
	// are added, or if this type has already been embedded in an interface or
	// a struct type. Furthermore, one of the following cases must apply:
	//
	// Case 1: this type was created with InterfaceOf.
	//
	// Case 2: this type was created with NamedOf and defined to a non-pointer,
	// non-interface type.
	//
	// Case 3: this type was created with PtrTo, with an element type which
	// Case 2 applies to.
	AddMethod(Method)

	// Underlying returns a type's underlying type.
	//
	// The underlying type of an interface type, an unnamed type, or a type with
	// a predeclared name is the type itself. For a user-defined non-interface
	// named type, the underlying type is the first unnamed or predeclared type
	// in its definition chain. For example, if the type represents A in
	//
	//     type A B
	//     type B byte
	//
	// then its underlying type is the type which represents byte (i. e., uint8).
	//
	// If a named type has not been defined yet, Underlying returns nil.
	Underlying() Type
}

// StructField is analogous to reflect.StructField, minus the Offset and Index
// fields.
type StructField struct {
	Name, PkgPath string
	Type          Type
	Tag           reflect.StructTag
	Anonymous     bool
}

// Method represents an incomplete method.
// Unlike in reflect.Method, the implementing Func is not part of this
// structure.
type Method struct {
	Name, PkgPath string
	Type          Type // receiver = first arg, except for interface methods
}

// Of returns a Type representing the given complete reflect.Type.
func Of(reflect.Type) Type

// NamedOf creates the incomplete type with the specified package path and name.
// The name can be bound to an underlying type with the Define method.
func NamedOf(pkgPath, name string) Type

// ArrayOf creates an incomplete array type with the given count and
// element type described by elem.
// It panics if elem's kind is still incomplete.
func ArrayOf(count int, elem Type) Type

// ChanOf is analogous to reflect.ChanOf.
func ChanOf(dir reflect.ChanDir, elem Type) Type

// FuncOf is analogous to reflect.FuncOf.
func FuncOf(in, out []Type, variadic bool) Type

// InterfaceOf returns an incomplete interface type with the given list of
// named interface types. InterfaceOf panics if one of the given embedded types
// is unnamed or its kind is not reflect.Interface. It also panics if types
// with distinct, non-empty package paths are embedded.
//
// Explicit methods can be added with AddMethod.
func InterfaceOf(embedded []Type) Type

// MapOf creates an incomplete map type with the given key and element types.
// It panics if key's kind is reflect.Invalid.
func MapOf(key, elem Type) Type

// PtrTo is analogous to reflect.PtrTo.
func PtrTo(t Type) Type

// SliceOf is analogous to reflect.SliceOf.
func SliceOf(t Type) Type

// StructOf is analogous to reflect.StructOf.
// It panics if one of the fields' type's kind is invalid.
func StructOf(fields []StructField) Type

// Complete completes the incomplete types in in, transforming them to a list
// of reflect.Type types. The function method is called once for each method
// added with AddMethod and should return an implementation of that method:
// a function whose first argument is the receiver.
// The list out contains the fully usable resulting types, except that methods
// can be called on them only after Complete has returned. The index indicates
// which type will be the method receiver, and stub indicates the method.
func Complete(
	in []Type,
	method func(out []reflect.Type, index int, stub Method) interface{},
) []reflect.Type

I've used @nrwiersma's idea to add method implementations in the Complete step, when the resulting types are completely constructed and usable, except for calling methods on their values.
This API is slightly more restrictive compared to what you can do at compile-time, but only as regards order of declarations. For example, given the run-time equivalent of the fragment
type A B
func (A) Print() { println("Foo") }
type B int

the API would not allow the declaration of Print before the declaration of B (because if B were bound to, say, *int instead, the method Print should not exist in the first place).

Thanks for the effort :) Some quick comments:

// Define defines a named type as the given type. It panics if the type's
// kind is not reflect.Invalid, if the defining type's kind is
// reflect.Invalid, or if the result would contain an invalid recursion.
Define(Type)

what about SetUnderlying(Type)? It seems more intuitive to me

Underlying() Type

This may or may not be necessary, depending on the exact semantic of Define() or SetUnderlying() above.

// StructField is analogous to reflect.StructField, minus the Offset and Index
// fields.
type StructField struct {
Name, PkgPath string
Type          Type
Tag           reflect.StructTag
Anonymous     bool
}

Please keep the Index field.

// MapOf creates an incomplete map type with the given key and element types.
// It panics if key's kind is reflect.Invalid.
func MapOf(key, elem Type) Type

MapOf also needs to accept key's kind = reflect.Invalid.
Otherwise you cannot create this type:
type Foo struct {
  Map map[Foo]string
}

The check on whether key Type is acceptable as map key,
and in general all non-recursion checks,
must be delayed until Define or SetUnderlying gets invoked.

// StructOf is analogous to reflect.StructOf.
// It panics if one of the fields' type's kind is invalid.
func StructOf(fields []StructField) Type

Also, StructOf needs to accept fields whose type is incomplete, i.e. their kind is reflect.Invalid.
Otherwise you cannot create these mutually recursive types:
type Foo struct {
  Bar Bar
}
type Bar *struct { // notice the '*'
  Foo Foo
}

Thanks for checking my post!
@cosmos72 wrote:

	// Define defines a named type as the given type. It panics if the type's
	// kind is not reflect.Invalid, if the defining type's kind is
	// reflect.Invalid, or if the result would contain an invalid recursion.
	Define(Type)

what about SetUnderlying(Type)? It seems more intuitive to me

I've decided against SetUnderlying and Bind because you can define a type A to a type B as in
type A B
type B int

but the underlying type of A is then int, and A is bound to that underlying type.

	Underlying() Type

Underlying may or may not be necessary, depending on the exact semantic of Define or SetUnderlying above.

Underlying may not return the same thing that was set with Define, so it may be useful.

// StructField is analogous to reflect.StructField, minus the Offset and Index
// fields.
type StructField struct {
	Name, PkgPath string
	Type          Type
	Tag           reflect.StructTag
	Anonymous     bool
}

Please keep the Index field, it costs basically nothing and makes programmers' life easier.

OK.

// MapOf creates an incomplete map type with the given key and element types.
// It panics if key's kind is reflect.Invalid.
func MapOf(key, elem Type) Type

MapOf also needs to accept key's kind = reflect.Invalid.
Otherwise you cannot create this type:
type Foo struct {
  Map *map[Foo]string
}

The check on whether key Type is acceptable as map key, and in general all non-recursion checks, must be delayed until Define or SetUnderlying gets invoked.

// StructOf is analogous to reflect.StructOf.
// It panics if one of the fields' type's kind is invalid.
func StructOf(fields []StructField) Type

Also, StructOf needs to accept fields whose type is incomplete, i.e. their kind is reflect.Invalid.
Otherwise you cannot create these mutually recursive types:
type Foo struct {
  Bar Bar
}
type Bar *struct { // notice the '*'
  Foo Foo
}

Yup, you're correct. I also removed the restriction that you cannot add methods to types which have already been embedded because, e. g., this here is legal:
type T struct {
  A
}
type A []T
func (A) Foo() {
  println("foo")
}
…
T{}.Foo()

So yes, we have to delay these checks.
Can the restriction not to declare methods on an t.Kind() == reflect.Invalid type remain? I think so, at the cost of the implementation of Type.Method* for interfaces and structs with embedded fields becoming somewhat more complex.

I don't see an obvious reason to replicate reflect.Type in incomplete.Type.  The program that constructs the incomplete type presumably does not need to interrogate it.

I don't see an obvious reason to replicate reflect.Type in incomplete.Type. The program that constructs the incomplete type presumably does not need to interrogate it.

I guess you're talking about most methods of incomplete.Type in @TheCount comment https://github.com/golang/go/issues/39717#issuecomment-657280594
and about my remark

Convenience methods to examine the contents of (possibly incomplete) types: Key Elem ChanDir Field In Out Variadic etc.

I intentionally named them "convenience" methods: it's certainly possible to make incomplete.Types opaque (i.e. no way to inspect them) by removing most of their methods.
But using them it will not be pleasant: complicated code will need lots of them, and may even choose to keep them around, to avoid re-creating them every time. I think that making them opaque would often force to maintain the same information externally - duplicating it and risking discrepancies.

I've decided against SetUnderlying and Bind because you can define a type A to a type B as in
type A B
type B int

but the underlying type of A is then int, and A is bound to that underlying type.

There are two alternatives here:

the Type u passed to Type.Define(u Type) must be its own underlying type, i.e. u.Underlying() == u (or however you compare two incomplete.Types).
The code type A B; type B int is then equivalent to:

import "reflect/incomplete"
var A = incomplete.NamedOf("A", "mypackage")
var B = incomplete.NamedOf("B", "mypackage")
B.Define(/*type of int*/)
A.Define(B.Underlying()) // non-trivial dependency: A.Define() must be *after* B.Define()

This also requires Type.Underlying.

the Type u passed to Type.Define(u Type) will not be used exactly - its underlying type will be used instead.
The code type A B; type B int is then equivalent to:

import "reflect/incomplete"
var A = incomplete.NamedOf("A", "mypackage")
var B = incomplete.NamedOf("B", "mypackage")
A.Define(B)               // any order will do: A.Define() can be before or after B.Define()
B.Define(/*type of int*/)

This does not strictly require Type.Underlying.

@ianlancetaylor wrote:

I don't see an obvious reason to replicate reflect.Type in incomplete.Type. The program that constructs the incomplete type presumably does not need to interrogate it.

I don't think it's strictly necessary. A program which has from the beginning a clear plan from in its mind probably wouldn't interrogate the incomplete types. For something like a Go interpreter, where types may be constructed on the go, it might be convenient. In any case, it looks like a separable problem, so we could start with a minimal API and add interrogation methods later on.
FWIW, here is a stripped down version of the API.
package incomplete

import "reflect"

// Type represents an incomplete type, or part of an incomplete composite type.
// It is a safe way to define the layout of (possibly recursive) types
// with the Of, NamedOf, ArrayOf, ChanOf, FuncOf, InterfaceOf, MapOf, PtrTo,
// SliceOf, and StructOf functions before the actual types are created with
// Complete.
type Type interface {
	// Define defines a named type as the given type. It panics if the type
	// is not a named type, the type has already been defined, or if the result
	// would contain an invalid recursion.
	Define(Type)

	// AddMethod adds the given method to this type. The Index field of the given
	// method is ignored. It panics if there is a method name clash, or if
	// methods with distinct, non-empty PkgPath strings are added. Furthermore,
	// one of the following cases must apply:
	//
	// Case 1: this type was created with InterfaceOf.
	//
	// Case 2: this type was created with NamedOf and defined to a non-pointer,
	// non-interface type.
	//
	// Case 3: this type was created with PtrTo, with an element type which
	// Case 2 applies to.
	AddMethod(Method)
}

// StructField is analogous to reflect.StructField, minus the Index and Offset
// fields.
type StructField struct {
	Name, PkgPath string
	Type          Type
	Tag           reflect.StructTag
	Anonymous     bool
}

// Method represents an incomplete method.
// Unlike in reflect.Method, the implementing Func is not part of this
// structure.
type Method struct {
	Name, PkgPath string
	Type          Type // receiver = first arg, except for interface methods
	Index         int
}

// Of returns a Type representing the given complete reflect.Type.
func Of(reflect.Type) Type

// NamedOf creates the incomplete type with the specified name and package path.
// The name can be bound to an underlying type with the Define method.
func NamedOf(name, pkgPath string) Type

// ArrayOf creates an incomplete array type with the given count and
// element type described by elem.
func ArrayOf(count int, elem Type) Type

// ChanOf is analogous to reflect.ChanOf.
func ChanOf(dir reflect.ChanDir, elem Type) Type

// FuncOf is analogous to reflect.FuncOf.
func FuncOf(in, out []Type, variadic bool) Type

// InterfaceOf returns an incomplete interface type with the given list of
// named interface types. InterfaceOf panics if one of the given embedded types
// is unnamed or its kind is not reflect.Interface. It also panics if types
// with distinct, non-empty package paths are embedded.
//
// Explicit methods can be added with AddMethod.
func InterfaceOf(embedded []Type) Type

// MapOf creates an incomplete map type with the given key and element types.
func MapOf(key, elem Type) Type

// PtrTo is analogous to reflect.PtrTo.
func PtrTo(t Type) Type

// SliceOf is analogous to reflect.SliceOf.
func SliceOf(t Type) Type

// StructOf is analogous to reflect.StructOf.
func StructOf(fields []StructField) Type

// Complete completes the incomplete types in in, transforming them to a list
// of reflect.Type types. The function method is called once for each method
// added with AddMethod and should return an implementation of that method:
// a function whose first argument is the receiver.
// The list out contains the fully usable resulting types, except that methods
// can be called on them only after Complete has returned. The index indicates
// which type will be the method receiver, and stub indicates the method.
func Complete(
	in []Type,
	method func(out []reflect.Type, index int, stub Method) interface{},
) []reflect.Type

I've also swapped the order of arguments to NamedOf, so name and pkgPath match the order in StructField and Method (rather than the order in go/types).
@cosmos72: regarding type definitions, I would lean towards your 2., just so the behaviour is not too surprising for users of the API.

But using them it will not be pleasant: complicated code will need lots of them,

Why would code need them?
Those methods are for understanding an unknown reflect.Type that is passed to general-purpose code.
It's hard to see why you'd need them halfway through constructing a new type.
Wouldn't the code building the type know about the type?
It seems like it would be enough to just do a sentinel interface like:
type Type interface {
    isType()
}

Unless you have a specific example of code where those extra methods would be needed?
Otherwise the sketch looks about right. Would you like to try implementing it and see if it satisfies your use case?

  This alternative proposal addresses that shortcoming:
here, newly created recursive reflect.Types can emerge only through a
single function, reflect.Bind. This new function either returns a
reflect.Type which can be used with the same expectations as any other
reflect.Type, or it panics (hence, "atomically"). The remainder of the
reflect API is not affected.
This convenience comes at the cost of building a partially parallel
infrastructure to describe the type to be newly created. The central
component is a new interface reflect.TypeDesc instances of which are
immutable descriptions of a type (or type-to-be) and a number of functions
for the construction of such descriptions.
Proposal
We provide the proposal in the form of go source code. For orientation,
the following new objects parallel existing objects in the reflect
package:
New Existing
DescArray Array
DescChan Chan
DescFunc Func
DescInterface Interface
DescInvalid Invalid
DescKind Kind
DescMap Map
DescPtr Ptr
DescSlice Slice
DescStruct Struct
DescribeArray ArrayOf
DescribeChan ChanOf
DescribeFunc FuncOf
DescribeMap MapOf
DescribePtr PtrTo
DescribeSlice SliceOf
DescribeStruct StructOf
MethodDesc Method
StructFieldDesc StructField
TypeDesc Type
The following new objects have no parallel:
New
Bind
Complete
DescComplete
DescIncomplete
DescribeInterface
Incomplete
Proposal as go code:
// A DescKind represents the specific kind of type description that a TypeDesc// represents. The zero DescKind is not a valid type description kind.type DescKind uint
const (
DescInvalid             = DescKind(Invalid)
DescArray               = DescKind(Array)
DescChan                = DescKind(Chan)
DescFunc                = DescKind(Func)
DescInterface           = DescKind(Interface)
DescMap                 = DescKind(Map)
DescPtr                 = DescKind(Ptr)
DescSlice               = DescKind(Slice)
DescStruct              = DescKind(Struct)
DescIncomplete DescKind = (1 << 5) - 2
DescComplete   DescKind = (1 << 5) - 1
)
// String returns the name of dk.func (dk DescKind) String() string
// TypeDesc represents a description of a (possibly incomplete) type. A type// description is a safe way to describe the layout of a (possibly recursive)// type with the Complete, Incomplete, DescribeArray, DescribeChan,// DescribeFunc, DescribeInterface, DescribeMap, DescribePtr, DescribeSlice,// and DescribeStruct functions before the actual Type is created with Bind.type TypeDesc interface {
// ChanDir returns a channel description's direction.
// It panics if the description kind is not DescChan.
ChanDir() ChanDir
// Elem returns the element type description for this type description.
// It panics if the description kind is not DescArray, DescChan, DescMap,
// DescPtr, or DescSlice.
Elem() TypeDesc
// Field returns a struct type description's i'th field description.
// It panics if the description kind is not DescStruct.
// It panics if i is not in the range [0, NumField()).
Field(i int) StructFieldDesc
// FieldByName returns the struct field description with the given name
// and a boolean indicating if the field description was found.
// It panics if the description kind if not DescStruct.
FieldByName(name string) (StructFieldDesc, bool)
// Key returns a map type description's key type description.
// It panics if the description kind is not DescMap.
Key() TypeDesc
// Kind returns the specific description kind of this type description.
Kind() DescKind
// In returns the type description of a function type descriptions's i'th
// input parameter.
// It panics if the description kind is not DescFunc.
// It panics if i is not in the range [0, NumIn()).
In(i int) TypeDesc
// IsVariadic reports whether a function type description's final input
// parameter is a "..." parameter. If so, td.In(td.NumIn() - 1) returns the
// parameter's implicit actual type description []T.
//
// For concreteness, if td describes func(x int, y ... float64), then
//
//	td.NumIn() == 2
//	td.In(0) is a reflect.TypeDesc for "int"
//	td.In(1) is a reflect.TypeDesc for "[]float64"
//	td.IsVariadic() == true
//
// IsVariadic panics if the description kind is not DescFunc.
IsVariadic() bool
// Len returns the length property of an array description.
// It panics if the description kind is not DescArray.
Len() int
// Method returns the i'th method description in the type description's
// method description set.
// It panics if the description kind is not DescInterface,
// or if i is not in the range [0, NumMethod()).
//
// In particular, Method does not work on descriptions with kind DescStruct.
// Method returns only method descriptions explicitly added with
// DescribeInterface, not methods implicitly acquired through embedded fields.
//
// The returned method description describes the method signature, without a
// receiver. The Func field is nil.
//
// There is no guarantee that the methods of the resulting type will have the
// same sort order as in the description.
Method(int) MethodDesc
// MethodByName returns the method description for the method with that name
// in the type descriptions's method description set and a boolean indicating
// if the method was found.
// It panics if the description kind is not DescInterface.
//
// The returned method description describes the method signature, without a
// receiver. The Func field is nil.
MethodByName(string) (MethodDesc, bool)
// Name returns the name of the described type.
// It panics if the description kind is not DescIncomplete.
Name() string
// NumField returns a struct type description's field description count.
// It panics if the description kind is not DescStruct.
NumField() int
// NumIn returns a function type description's input parameter count.
// It panics if the description type is not DescFunc.
NumIn() int
// NumMethod returns the number of method descriptions in the type
// description's method set.
// It panics if the description kind is not DescInterface.
NumMethod() int
// NumOut returns a function type description's output parameter count.
// It panics if the description kind is not DescFunc.
NumOut() int
// PkgPath returns the designated package path in a description of an
// incomplete type. It panics if the description kind is not DescIncomplete.
PkgPath() string
// Out returns the type description of a function type description's i'th
// output parameter.
// It panics if the description kind is not DescFunc.
// It panics if i is not in the range [0, NumOut()).
Out(i int) TypeDesc
// Underlying returns the actual type underlying this type description.
// It panics if the description kind is not DescComplete.
Underlying() Type
}
// StructFieldDesc describes a struct field.type StructFieldDesc struct {
// Name is the field name. It must start with an uppercase letter.
Name string
// Type is the description of the field type.
Type TypeDesc
// Tag is the field tag string.
Tag StructTag
// Anonymous indicates whether or not this struct field description
// describes an embedded field.
Anonymous bool
}
// MethodDesc describes a method.type MethodDesc struct {
// Name is the method name. It must start with an uppercase letter.
Name string
// Type describes the method type.
//
// For interface descriptions, Type should describe the signature of the
// method.
//
// For descriptions of incomplete types, Type should describe a function
// whose first argument is the receiver.
Type TypeDesc
// Func is nil if this description describes an interface method.
//
// For descriptions of methods of incomplete types, Func is the method
// implementation with receiver, arguments and return values in terms of
// reflect.Value.
// Methods for incomplete types are not implemented yet.
Func func(recv Value, in []Value) []Value
}
// Incomplete creates a type description for an incomplete named type.// It panics if name is not a valid identifier starting with an uppercase// letter. The package name may be empty but it is recommended that each// package use a unique string here (such as its fully qualified package name)// to avoid naming clashes with other packages.func Incomplete(pkgName, name string) TypeDesc
// Complete creates a description of the given already complete type.func Complete(typ Type) TypeDesc
// DescribeArray creates a description of an array type with the given count and// element type described by elem.// It panics if elem's description kind is DescIncomplete.func DescribeArray(count int, elem TypeDesc) TypeDesc
// DescribeChan creates a description of a channel type with the given// direction and element type described by t.//// The gc runtime currently imposes a limit of 64 kB on channel element types.// If t is not of description kind DescIncomplete and describes a type whose// size is equal to or exceeds this limit, DescribeChan panics. If t describes// an incomplete type, a later call to Bind will panic if the resulting type// would violate this limit.func DescribeChan(dir ChanDir, t TypeDesc) TypeDesc
// DescribeFunc creates a description of the function type with the argument// and result types described by in and out.//// The variadic argument controls whether the description of a variadic function// is returned. If variadic is true and in[len(in)-1] does not represent a// slice (i. e., is either of description kind DescSlice, or DescComplete and// describes a slice type), DescribeFunc panics.func DescribeFunc(in, out []TypeDesc, variadic bool) TypeDesc
// DescribeInterface creates a description of the interface type with the// methods described by methods.func DescribeInterface(methods []MethodDesc) TypeDesc
// DescribeMap creates a description of the map type with key and// element types described by key and elem, respectively.// It panics if key's description kind is DescIncomplete.//// Map key types must be comparable (i. e., implement Go's == operator).// DescribeMap does not perform this check, but a later call to Bind will// panic if the resulting type would not be a valid key type.func DescribeMap(key, elem TypeDesc) TypeDesc
// DescribePtr creates a description of the pointer type with element type// described by t.func DescribePtr(t TypeDesc) TypeDesc
// DescribeSlice creates a description of the slice type with element type// described by t.func DescribeSlice(t TypeDesc) TypeDesc
// DescribeStruct creates a description of the struct type with the fields// described by fields.func DescribeStruct(fields []StructFieldDesc) TypeDesc
// Bind creates a new type by binding the type name given by incomp to the type// described by def.//// The methods argument must be nil. A later version may lift this restriction.//// It panics if the (package name, name) combination given incomp has been used// to create a type with Bind before. This does not mean the name of the// resulting type is unique as this restriction only applies to types created// with Bind.//// It panics if the description kind of def is DescIncomplete, or if def// indirectly references a description of an incomplete type other than incomp,// or if a resulting type would be illegal for some reason (for example, a// channel type whose element size would be too big, or a map key type not// implementing Go's == operator).func Bind(incomp, def TypeDesc, methods []Method) Type
Open questions

The proposal above does not explicitly allow creation of interfaces
with embedded interfaces. If deemed necessary, the DescribeInterface
function can get an additional embedded []TypeDesc parameter. This
would allow the creation of interfaces with unexported methods if the
embedded interfaces have unexported methods.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/39717, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AA2GIBFUCPVLIOUPSQRP4XTRXPALPANCNFSM4ODAFBWA
.

@TheCount and/or @cosmos72, any interest in implementing the package sketched above and see if it serves your use case?

My use case is a Go interpreter.
For this particular case, it can be modeled as a library that takes a slice of arbitrary go/types.TypeSpec as input, and uses reflect and reflect/incomplete to create a corresponding slice of reflect.Type.
I tried a mental experiment, and the proposed reflect/incomplete API seems powerful enough for such task, which can be summarized as "a library that creates reflect.Types from arbitrary source code".
About implementing reflect/incomplete: it's definitely non-trivial, in part because it needs access to reflect internal types, starting from *rtype

Hello, as developer of yaegi, also a go interpreter, I'm very interested in having 2 missing features in reflect:

the ability to create recursive types (this is today poorly emulated),
the ability to add methods to a created type, so it implements one or several interfaces (this is impossible to get it right without improving reflect).

To me, a problem is that the pre-compiled code must be able to check that an object instantiated from a such created type implements an existing interface. It seems not trivial to achieve.
Also the need to create a new interface type (not existing in the pre-compiled code) is less obvious to me, as only the interpreted code uses it, it can be handled internally in the interpreter (and is already, at least in gomacro and yaegi).
I understand that the proposed reflect/incomplete package is useful primarily to isolate the effort involved in the creation of a recursive type. It's not clear to me yet how it helps for the point 2. May be through the NamedOf ?
I agree also that this package is for  reflect type creation only, not interrogation, as an interpreter has already its own type representation and spec.
Once successfully implemented, I don't get yet the interest of keeping this package exposed. It seems to rather belong to internal, and having the interesting functions accessible through reflect only.
But yes definitely interested to participate and help if I can, and put efforts on it. and for info, @nrwiersma an I work in the same team on yaegi.

Question:
is it acceptable to move to a new package reflect/internal the types and functions from reflect that are also needed by this proposal?
Doing so would simplify the implementation and reduce duplicated code/types.
The types to move would be at least: rtype and its wrapper types: arrayType chanType funcType interfaceType interfaceType interfaceType sliceType structType, plus structField and possibly others.

@cosmos72 Perhaps you can use the already existing package internal/reflectlite.  But yes, it would be OK to create a new internal package if required.

@mvertes

Once successfully implemented, I don't get yet the interest of keeping this package exposed. It seems to rather belong to internal, and having the interesting functions accessible through reflect only.

The reason to have the package exposed is that it factors the API out of reflect, where we can use the package name to help shorten the other names. You're right that it would be quite tied up with reflect in the implementation, but it helps keep the concept of incomplete types out of the exported reflect API.
As far as methods, the proposed reflect.NamedOf in #16522 has the benefit that it creates a newly named type with methods in one step - by creating and attaching methods in the same operation, it avoids the potential confusion of having a type that does not have any methods at one moment and then does have methods the next. But of course that wouldn't work with recursive types: creating the named type is necessary to finish the recursion. So attaching methods may need to be in this new reflect/incomplete package as well.
And of course reflect/incomplete could be used to create non-recursive types as well as recursive types, so it might be that adding methods should be done here. A type that doesn't have methods yet (but will) is incomplete in a different way. I would certainly support exploring that in the API as well.
It sounds like in general we think this new package is the right approach, but the devil is in the details.
Putting on hold until there is an implementation we can look at.

I am continuing my implementation at https://github.com/cosmos72/go/tree/issue-39717/src/reflect/incomplete
Legal: it is a fork of https://github.com/golang/go and has the same license, but if needed I can also submit a CL
Status: it's not complete yet, but the main skeleton is there.
The idea is:

*incomplete.itype is the only implementation of incomplete.Type and it contains all available information about an incomplete type. It should be canonical i.e. only one instance per type.
it has a field itype.incomplete *rtype which is filled incrementally when the user calls the various API functions/methods.
when such *rtype is complete, it is copied to the field itype.complete reflect.Type which is then returned by Complete()

Comments/suggestions are welcome


Application crashes if no data entered

Application crashes if data contains only zero values and otherwise if there is no data.

I'm no longer maintaining the Objective-C-only version of this project. If it's still an issue with the current release please feel free to re-open.


Fails to build on Mac OS X

Attempting to install this on Mac OS X has been an adventure. I had multiple issues with dependencies. After wrestling with ocamlfuse and getting it to install, the last thing remaining is google-drive-ocamlfuse. Unfortunately, it fails to link src/gdfuse.ml.
Finished, 0 targets (0 cached) in 00:00:00.
+ ocamlfind ocamlopt -g -linkpkg -package threads -package sqlite3 -package gapi-ocaml -package camlidl -package Fuse -thread src/appDir.cmx src/utils.cmx src/config.cmx src/cache.cmx src/concurrentGlobal.cmx src/keyValueStore.cmx src/state.cmx src/context.cmx src/gaeProxy.cmx src/mime.cmx src/oauth2.cmx src/drive.cmx src/gdfuse.cmx -o src/gdfuse.native
Undefined symbols for architecture x86_64:
  "___fuse_exited", referenced from:
      _camlidl_Fuse_bindings___fuse_exited in libFuse_stubs.a(Fuse_bindings_stubs.o)
     (maybe you meant: _camlidl_Fuse_bindings___fuse_exited)
  "___fuse_process_cmd", referenced from:
      _camlidl_Fuse_bindings___fuse_process_cmd in libFuse_stubs.a(Fuse_bindings_stubs.o)
     (maybe you meant: _camlidl_Fuse_bindings___fuse_process_cmd)
  "___fuse_read_cmd", referenced from:
      _camlidl_Fuse_bindings___fuse_read_cmd in libFuse_stubs.a(Fuse_bindings_stubs.o)
     (maybe you meant: _camlidl_Fuse_bindings___fuse_read_cmd)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
File "caml_startup", line 1:
Error: Error during linking
Command exited with code 2.
Compilation unsuccessful after building 40 targets (39 cached) in 00:00:01.
E: Failure("Command ''/Users/sorin/.homebrew/bin/ocamlbuild' src/gdfuse.native -tag debug' terminated with error code 10")

I appreciate the issue was closed long time ago, but I'm facing a similar problem when trying to install. I'm running OSX 10.10. Install fails with a very similar pattern - looks like OSXFUSE is not being linked up correctly. Both FUSE and opam were installed via Homebrew if that is relevant
=-=- Processing actions -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=  🐫
[ERROR] The compilation of ocamlfuse failed at "make -C lib
        INCDIRS=/Users/Denis/.opam/system/lib/camlidl".
Processing  1/2: [ocamlfuse: ocamlfind remove]
#=== ERROR while installing ocamlfuse.2.7.1-cvs2 ==============================#
# opam-version 1.2.1
# os           darwin
# command      make -C lib INCDIRS=/Users/Denis/.opam/system/lib/camlidl
# path         /Users/Denis/.opam/system/build/ocamlfuse.2.7.1-cvs2
# compiler     system (4.02.1)
# exit-code    2
# env-file     /Users/Denis/.opam/system/build/ocamlfuse.2.7.1-cvs2/ocamlfuse-38445-e7966f.env
# stdout-file  /Users/Denis/.opam/system/build/ocamlfuse.2.7.1-cvs2/ocamlfuse-38445-e7966f.out
# stderr-file  /Users/Denis/.opam/system/build/ocamlfuse.2.7.1-cvs2/ocamlfuse-38445-e7966f.err
### stdout ###
# camlidl -header  \
# [...]
# making ._ncdi/Fuse_bindings.di from Fuse_bindings.mli
# making ._d/Fuse_bindings.d from Fuse_bindings.ml
# making ._d/Fuse.d from Fuse.ml
# making ._d/Fuse_lib.d from Fuse_lib.ml
# making ._d/Unix_util.d from Unix_util.ml
# making ._d/Result.d from Result.ml
# ocamlc -c -cc "cc" -ccopt "-fPIC -D_FILE_OFFSET_BITS=64 -I. -pthread \
# 				-DPIC -DNATIVE_CODE   \
# 				  -I/Users/Denis/.opam/system/lib/camlidl  -o Fuse_bindings_stubs.o " Fuse_bindings_stubs.c
### stderr ###
# In file included from Fuse_bindings_stubs.c:17:
# ./Fuse_bindings.h:16:10: fatal error: 'fuse.h' file not found
# #include <fuse.h>
#          ^
# 1 error generated.
# make[1]: *** [Fuse_bindings_stubs.o] Error 2
# make: *** [native-code-library] Error 2

=-=- Error report -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=  🐫
The following actions were aborted
  ∗  install google-drive-ocamlfuse 0.5.17
The following actions failed
  ∗  install ocamlfuse 2.7.1-cvs2
No changes have been performed


[backport] Add support for CUDA 11.1

Backport of #4184

[automatic post] Jenkins, test this please.

Jenkins CI test (for commit d755bca44d03ede0ff0e4abde5a0c6adac99f7b7, target branch v8) succeeded!


feat: add basic structure for a CITATION.cff file

Add a template for CITATION.cff file, some changes can be made to complete the file during setup:

Ask for ORCID and Affiliation
Separate Family Name and Given Name
Ask for keywords
Provision for multiple authors

File format referred from hist/CITATION.cff, I believe that currently Nox is failing a few tests.

Is it better to leave the unfilled items empty or commented out? I'd like this to work out of the box as well as possible if someone forgets to customize it. CC @matthewfeickert.

Is it better to leave the unfilled items empty or commented out?

I would be inclined to say that if it doesn't pass pipx run cffconvert --validate that is a problem. Empty entries will automatically fail validation and commented out entries aren't much better as you still need to have a minimum viable spec. In my mind this means that it should either be customized as part of setup or that it should be left as a suggestion but not an automatic part of cookie.

cffconvert offers a validate-cff pre-commit hook: https://github.com/citation-file-format/cffconvert/blob/main/.pre-commit-hooks.yaml
@henryiii Would it be OK for me to help move forward the two CFF PRs and also add documentation about what a CITATION.cff file does and how to set up the Zenodo-GitHub integration to automatically generate DOIs? Since these haven't had activity since 2022 I want to check what's up before I start :)

Docs for sure. The problem with adding this by default is that a user has to configure it to use it, a partial file isn't helpful and not everyone wants or knows to set it up. What I'd really like is support for a check boxes in cookiecutter and copier, then we could provide a list of optional features to enable.

support for a check boxes in cookiecutter and copier

Fairly sure we can have a boolean answer in copier that we can use to create or not create file, is that what you mean?

Yes, but I'd like a series of these, and having to answer for each one is less ideal than a list of checkboxes. But having a "Include citation file?" is probably the right way to go for now.


Add MiddlewareServer into Alerts Profiles

This PR is the first of a series with the goal to add support for alerts based on Middleware models.
This one enable MiddlewareServer on alerts profile and lets to define a new alert based on MiddlewareServer models.
@miq-bot add-label providers/hawkular enhancement

@miq-bot add-label providers/hawkular, enhancement

LGTM - the test failures come from the general build failure on master due to issues with jQuery-rails since last night.
@miq-bot assign @chessbyte

@chessbyte @gmcculloug what is missing in order to get this merged?

@abonas Just needed a reminder as I missed this when it was assigned.