Add support for riot.js tag file

The tag file is similar to HTML block.
This is the example from riot.js live demo
sample.tag
<sample>

{ message }

{ name }

</sample>

Could you try running your riot.js code through http://prettydiff.com/?m=beautify
Pretty Diff is already included with atom-beautify.  If you are already satisfied with the results the next trick will be how to associate the tool so that riot.js files are specifically beautified with Pretty Diff, because the default beautifier is js-beautify and this is association is based only upon the file extension.  Clearly riot.js has a .js file extension, but is not actually JavaScript code.

The tag file works good with http://prettydiff.com/ to me.
riot.js has custom file extension .tag which will be compilered to native javascript , html and css.
Hope  I didn't confuse the extension which should be beautify , Thanks .

So long as the file is supplied the extension .tag to clearly separate it from JavaScript files and there is no conflict with anything else using that extension it seems support can be added immediately.  Glavin is busy right now so your options are:

Wait for Glavin to add this support as a new language
Modify the atom-beautify code to support the new language with Pretty Diff as the default beautifier and submit a pull request.

I submitted a pull request to provide support for this language.

The relevant code is merged to master, so now this is just pending the next release.

Published to v0.28.28


impl_modulus interaction with generic_const_exprs

Hi, I have encountered the following bug (or at least unexpected behaviour).
impl_modulus and generic_const_exprs do not seem to mix well together.
With the following code:
#![feature(generic_const_exprs)]
use crypto_bigint::{impl_modulus, U64};
impl_modulus!(RingInteger, BackendInteger, "30e4b8f030ab42f3");

I get a E0207 error claiming: 'the const parameter DLIMBS is not constrained by the impl trait, self type, or predicates'.
Removing generic_const_exprs fixes it.  Since the feature is unstable, this might not be intended usage of the library, but it would be great if it worked :)

That sounds like a bug in generic_const_exprs.
Anything that works on stable Rust today should continue to work even with new features enabled, and if not it's a bug in rustc.
If you have suggestions about how we can work around the issue, we can consider them, but otherwise nightly is a moving target and generic_const_exprs is currently expected to have bugs.


Unable to use standard decorators in Vanilla template, using TypeScript

Describe the bug
TypeScript 5 has supported decorators out of the box since version 5, but Vite's default TypeScript setup has syntax errors with decorators.
Reproduction
https://github.com/trusktr/vite-issue-18693
Steps to reproduce
git clone git@github.com:trusktr/vite-issue-18693.git
cd vite-issue-18693
git checkout 2586f5f17023716cbd0167d26aa9b16050ec53fd
npm clean-install
npm run build # error

System Info
System:
    OS: macOS 15.0.1
    CPU: (8) arm64 Apple M2
    Memory: 139.98 MB / 8.00 GB
    Shell: 5.9 - /opt/homebrew/bin/zsh
  Binaries:
    Node: 20.6.1 - ~/.n-node-versions/bin/node
    Yarn: 1.22.19 - ~/.n-node-versions/bin/yarn
    npm: 10.5.2 - ~/.npm-packages/bin/npm
    pnpm: 9.0.5 - ~/.npm-packages/bin/pnpm
    Watchman: 2<IP_ADDRESS> - /opt/homebrew/bin/watchman
  Browsers:
    Brave Browser: <IP_ADDRESS>
    Chrome: 130.0.6723.117
    Chrome Canary: 133.0.6836.0
    Safari: 18.0.1
    Safari Technology Preview: 18.0
  npmPackages:
    vite: ^5.4.10 => 5.4.11

Used Package Manager
npm
Logs

Click to expand!
❯ npm run build

><EMAIL_ADDRESS>build
> tsc && vite build

vite v5.4.11 building for production...
✓ 3 modules transformed.
x Build failed in 68ms
error during build:
src/main.ts (34:0): Using the export keyword between a decorator and a class is not allowed. Please use `export @dec class` instead. (Note that you need plugins to import files that are not JavaScript)
file: /Users/trusktr/src/vite-decorator-test/src/main.ts:34:0

32:
33: export
34: @element('kitchen-sink')
    ^
35: class KitchenSink /*extends HTMLElement*/ {}

    at getRollupError (file:///Users/trusktr/src/vite-decorator-test/node_modules/rollup/dist/es/shared/parseAst.js:396:41)
    at ParseError.initialise (file:///Users/trusktr/src/vite-decorator-test/node_modules/rollup/dist/es/shared/node-entry.js:13645:28)
    at convertNode (file:///Users/trusktr/src/vite-decorator-test/node_modules/rollup/dist/es/shared/node-entry.js:15384:10)
    at convertProgram (file:///Users/trusktr/src/vite-decorator-test/node_modules/rollup/dist/es/shared/node-entry.js:14627:12)
    at Module.setSource (file:///Users/trusktr/src/vite-decorator-test/node_modules/rollup/dist/es/shared/node-entry.js:16368:24)
    at async ModuleLoader.addModuleSource (file:///Users/trusktr/src/vite-decorator-test/node_modules/rollup/dist/es/shared/node-entry.js:20266:13)

Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guidelines.
[X] Read the docs.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] Make sure this is a Vite issue and not a framework-specific issue. For example, if it's a Vue SFC related bug, it should likely be reported to vuejs/core instead.
[X] Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
[X] The provided reproduction is a minimal reproducible example of the bug.

If we modify this code,
export
@element('kitchen-sink')
class KitchenSink /*extends HTMLElement*/ {}

to this,
export {KitchenSink};
@element('kitchen-sink')
class KitchenSink /*extends HTMLElement*/ {}

then npm run build succeeds. However npm run dev still fails with Uncaught SyntaxError: Invalid or unexpected token.
Looks like prod vs dev are using different tools that can and cannot handle the syntax.

I tried setting build.target to es2022, but that still results in dev mode sending decorator syntax to the browser:

The Vite config is confusing. I was able to fix the issue by not using build.target, and instead using esbuild.target, which is not mentioned in Vite's Build Options docs, and in fact the Build Options docs explains that build.target is used for esbuild, so it isn't clear at all why I would want to use esbuild.target instead.
So instead of this which is not working,
/** @import {UserConfig} from 'vite' */

/** @type {UserConfig} */
export default {
  build: {
    target: 'es2022'
  }
}

this is working,
/** @import {UserConfig} from 'vite' */

/** @type {UserConfig} */
export default {
  esbuild: {
    target: 'es2022'
  }
}

but from the docs it is not clear why there are two target options for seemingly the same purpose, so to avoid any issues, I'm doing the following which based on the docs I've no idea if necessary:
/** @import {UserConfig} from 'vite' */

/** @type {UserConfig} */
export default {
  // Configure both `target`s just in case
  build: {
    target: 'es2022'
  },
  esbuild: {
    target: 'es2022'
  }
}

For syntax lowering during dev, esbuild.target or esbuild.supported needs to be used https://main.vite.dev/config/shared-options.html#esbuild. For example https://github.com/vitejs/vite/issues/13756#issuecomment-2163246322 It's also tracking a documentation issue, so we can close this in favor of that.

Hmm, maybe the thing vite could do that would be more intuitive is to accept a single build.target as the source of truth for all build varieties, otherwise it is confusing. Similar to this comment: https://github.com/vitejs/vite/issues/13756#issuecomment-1646981372.
I think it is a good idea. If someone wants to test dev mode without the same transform as prod, which is unlikely, there could be an option to override it.

Looking at the type definition, now I'm really confused. Is this how we are supposed to configure the target?
/** @import {UserConfig} from 'vite' */

const target = 'es2022'

/** @type {UserConfig} */
export default {
  build: {
    target
  },
  esbuild: {
    target
  },
  optimizeDeps: {
    esbuildOptions: {
      target
    }
  }
}


Pass oldValue in onchange function to keep functionality similar to V2

This change passes the old value of a cell after an update, so that it behaves the same as V2. My application used both newVal and oldVal in onChange and thus did not work in V3.

Thanks


Recreating thumbnail with new image

Hello!
Thanks for this plugin.
I seem to be having a problem, here is the workflow:
1.Thumbnail gets created with "_image":
Thumbnail(
dataResolver: () async {
return _image.readAsBytes();
},
mimeType: "image/" + _image.extension,
widgetSize: double.infinity,
)

_image is changed to another image and setState is called and the thumbnail should be recreated.

I have a breakpoint when debugging on the line "return _image.readAsBytes();" and it is run on step 1, but after setState is called the thumbnail code is rerun, but never the line  "return _image.readAsBytes();" and consequently, the image is not updated.
Perhaps i am missing something and there is no issue with the plugin.
Help appreciated.

Hello,
this is currently not supported for performance reasons.
One possible workound would be to provide widget with Key and change it after changing the _image variable. This way it should force flutter to recreate the widget state and load new thumbnail.
We have no plans to add support for updating the thumbnail at the moment but we would be happy to merge well written PR.

@carekb684 did u try imageCache.clear(); just before showing the new image?

I can totally understand your concern, you're facing thumbnail re-rendering issue. So, this is my code & it is working as expected. If in-case it won't work for you try - key: UniqueKey(), at line no. 211.


KERNEL AUTO BOOST LOCK ACQUISITION WITH RAISED IRQL [BSOD]

BSOD after stopped Shibari, this is my second time appear BSOD after stopping Shibari service.
Any driver information/version should I attach? Thank you in advance
Raised IRQL.zip
NB : In the first BSOD, the stop code is IRQL NOT LESS OR EQUAL, I can't find the log.

There is no log. A crash creates a memory dump in C:\Windows\memory.dmp right after the crash reboot. I'd need that file (probably a few hundred megs so compress it= over a confidential channel - preferably on the Discord - as it can contain sensitive information and must not be shared in public.

There is no log. A crash creates a memory dump in C:\Windows\memory.dmp right after the crash reboot. I'd need that file (probably a few hundred megs so compress it= over a confidential channel - preferably on the Discord - as it can contain sensitive information and must not be shared in public.

Since and with which version does it happen?

Since and with which version does it happen?

Since and with which version does it happen?

I got that error since I updated newest version of BthPS3 (v1.3.65), before that my laptop never encountered by BSOD.
BTW I've sent you friend request, for sending memory.dmp via direct message (discord)

Since and with which version does it happen?

I got that error since I updated newest version of BthPS3 (v1.3.65), before that my laptop never encountered by BSOD.
BTW I've sent you friend request, for sending memory.dmp via direct message (discord)

Thanks, I found the issue and am providing a fix soon.

Thanks, I found the issue and am providing a fix soon.

This has been fixed with v1.3.72

This has been fixed with v1.3.72


30 slim promo

Please always provide the GitHub issue(s) your PR is for, as well as test URLs where your change can be observed (before and after):
Fix #30
Test URLs:

Before: https://main--vonage--hlxsites.hlx.page/unified-communications/
After: https://30-slim-promo--vonage--hlxsites.hlx.page/unified-communications/

FYI: to test the clickable function at mobile breakpoints (<768) you'll need to refresh the page.


Performance Regression Tests

It would be cool to come up with some tests that protect against performance regressions. I'm not sure what tooling would be appropriate for this. Maybe @steveoh or @jacobdadams have suggestions?

What would you want to test the performance of? The cloud run metrics are pretty good for response times etc.

I think that integration test performance is my biggest concern. For example, how much did adding database queries to the reverse geocoding affect performance?


CI: don't run cron-fail-notify when the job just got canceled

Doesn't seem right to prepare a PR in that case

@bors r+

:pushpin: Commit d8e8b892bd8acd2013224a8b3eac2d4ec1d3b9e6 has been approved by RalfJung
It is now in the queue for this repository.

:hourglass: Testing commit d8e8b892bd8acd2013224a8b3eac2d4ec1d3b9e6 with merge 0c1edc494543e4457f3877d09f16eaba7d90483a...

@bors retry

:hourglass: Testing commit d8e8b892bd8acd2013224a8b3eac2d4ec1d3b9e6 with merge c2c707273f147376019663324f1045265d7b7090...

:sunny: Test successful - checks-actions
Approved by: RalfJung
Pushing c2c707273f147376019663324f1045265d7b7090 to master...


feat(ffe-core-react): Expose named exports

This PR creates an index file which exposes all components as named
exports from the top level @sb1/ffe-core-react import.
Previously, the user would have to dig into the node_modules to figure
out that the components were located under lib/typography/... Now, the
consumer can import components like this:
import { Paragraph, Heading2, Heading3 } from '@sb1/ffe-core-react';

Coverage remained the same at 80.028% when pulling 4efe35a10aac9cfad831df1be67b9f339392a8de on 248-expose-index-file into 833ec9fe9b142da2ca40963156a1e58225e89681 on develop.


onSetExtremes prop is not updated

Bug or Feature Request?
Bug.
Description
Trying to update the onSetExtremes event handler (for closures) will not work, but the initial value is always used. This can be surprising when trying to close over the previous extremes in the event handler (for example to check if new data needs to be loaded). It can be worked around with refs, but this should be documented.
Live demo demonstrating bug
https://stackblitz.com/edit/base-chart-example-closure-in-event-handler?file=MyChart.js
open the console, change extremes using the range selectors. Notice how the logged value in the chart's render function keeps changing, but the closed value logged from the event handler is always the same (the first one), even though a new event handler is created on every render.

Perhaps a matter of using .update vs .addEvent, as mentioned in https://github.com/highcharts/highcharts/issues/6538 ?

The axis events are bound only on createAxis:
https://github.com/whawker/react-jsx-highcharts/blob/c3d3106d42195415e6afa6475ed9ad8821feae97/packages/react-jsx-highcharts/src/components/Axis/Axis.js#L65
This is probably a bug or missing functionality. @whawker is there are reason why the axis eventhandlers are not updated when prop changes?
As there are more problems with highcharts event handlers (for example: https://github.com/highcharts/highcharts/issues/12067), I have been thinking about proxying all the eventhandlers so that they don't need to be passed to highcharts at all.
Something like this:
useCallback((eventName, ...args) => {
  props.[`on${eventName}`](...args);
},[]);

It is however a little tricky as some of those events need to pass this bound to something for example legendItemClick

@whawker is there are reason why the axis eventhandlers are not updated when prop changes?

I never really envisioned the event handlers changing, which is an obvious oversight now 🤦♂
If we we're to implement something similar to useModifiedProps for event handlers, we would need to have documentation on function equality between renders (i.e. wrapping in the event handler in useCallback) otherwise we might end up adding the same event handler multiple times?
Going completely off topic, I've been wondering if useModifiedProps is a mistake, currently when props change we figure out which ones have changed, and commit them as updates to the wrapped Highcharts chart.
I wonder instead if we should be utilising the oneToOne option of chart.update so that we can sure that the state in React representation of the chart, is the same as the internal Highcharts representation. However this might be undermining one of the fundamental principles of this project in the first place, to avoid destroying the chart completely between React re-renders)

I never really envisioned the event handlers changing, which is an obvious oversight now 🤦♂

Before hooks the eventhandlers were class methods, so they wouldn't change.

If we we're to implement something similar to useModifiedProps for event handlers, we would need to have documentation on function equality between renders (i.e. wrapping in the event handler in useCallback) otherwise we might end up adding the same event handler multiple times?

Would useManualEventHandlers work here?

Before hooks the eventhandlers were class methods, so they wouldn't change.

Cool. After hooks, do you think we should be advising useCallback? Or some other strategy?

Would useManualEventHandlers work here?

Possibly? I need to read the Highcharts source to see what happens to manually added events on update (as some things get destroyed), need to check if manually added events are reassigned to the newly created object.

While event handlers are often class methods, it's not uncommon to see code where the handler is created as a lambda too, in style of:
<MyComponent handler={() => props.parentHandler(state.myChangingState)} />

so I could imagine that even code still using class based components might get tripped by this.

After hooks, do you think we should be advising useCallback? Or some other strategy?

It might be good form to use useCallback in the examples, but unless there's a worse impact than usual, I would leave it as implicit React hooks knowledge. The same thing applies to any other case of passing functions as props. Or any non primitive data that is not wrapped in useMemo, for that matter.

It seems that this problem could now be fixed quite easily as highcharts has fixed a bug related to it:
https://github.com/highcharts/highcharts/pull/15658


Does Tora work with 5B-I2V model?

I did some test generations on my 3060 12 gb with i2v model and it seems like tora doesn't affect result much. Maybe im doing smth wrong? Can you share some settings for CogVideoX 5B I2V and Tora?

It does work, how well depends on the image. Some things move well and others don't. It's often even good idea to end it early by using low end_percent like 0.2
Some examples I've done:
https://github.com/user-attachments/assets/2f13ed4e-75ed-4c56-964f-11e53676dec6
https://github.com/user-attachments/assets/f9d1e812-081b-430c-9f6a-399d8c8c4dc7

Thanks, your examples look great, however i can't still get my image animated properly.
Maybe im running it with too low sampling steps or wrong scheduler?

I pretty much only have used the sampler and steps that are in the example testing workflow for this. It depends on the image, for example the above painting it never wanted to move the characters from their position, but controlling the hands was easy.

it never wanted to move the characters from their position

lasy ass cog : (

thanks


CircleCI failing due to missing environment variable

After submitting a pull request, CircleCI is failing with:
$ gcloud config set project $GOOGLE_CLOUD_PROJECT
ERROR: (gcloud.config.set) argument VALUE is required
Usage: gcloud config set SECTION/PROPERTY VALUE [optional flags]
  optional flags may be  --help | --installation | -h

For detailed information on this command and its flags, run:
  gcloud config set --help

gcloud config set project $GOOGLE_CLOUD_PROJECT returned exit code 2

Action failed: gcloud config set project $GOOGLE_CLOUD_PROJECT

See https://circleci.com/gh/GoogleCloudPlatform/ruby-docs-samples/1033.

Hi @rjmooney,
We currently don't allow Circle to test PRs for security reasons.
Thanks for bringing up this question though!


Fix scroll position not being updated after filtering

The height and position of the tracks was only updated on rendering, but the overall height of the TimeGraph is needed to determine the extent of the scrollbar.
Changed the behavior to have the height / pos calculation independent of the rendering.
Bug: b/182978978
To verify:

Take a capture
Scroll down in the capture window
Filter tracks

Before, the vertical scroll position was not updated. Now, it's updated.

LGTM! The division there in UpdateTrackPosition and UpdateTrackPrimitives is really nice!! :) :)
BTW, the bug (b/182978978) is still there. Maybe you solved another one, but if you move the screen too far below, there will be no information after writing in the filter tracks tab until you move the sliders.

As discussed offline, it's not as easy to reproduce as initially thought, and there may be some other side effects at play here. This PR fixes one clearly reproducible issue, but we'll leave the bug open for further investigation.

Seems to be fixed now.


Create pytests testing against regressions of the v1 rest API

BTW you are developing with visual studio?

Visual studio code, not visual studio.

see https://github.com/SimonBiggs/scriptedforms/issues/138


Dockerfile: Add the summary label, update the team mailing list, and grab the faq dependency from Github

/close


[YOSYS][issue/3594] print stack of script commands upon error

[YOSYS][issue/3594] print stack of script commands upon error; this is not a backtrace of program stack but of the Yosys script.
e.g.
-- Executing script file `./demo.ys' --

1. Executing Verilog-2005 frontend: ../yosys/f2.v
Parsing Verilog input from `../yosys/f2.v' to AST representation.
Successfully finished Verilog frontend.

2. Executing Verilog-2005 frontend: ../yosys/hello.v
Parsing Verilog input from `../yosys/hello.v' to AST representation.
Successfully finished Verilog frontend.

3. Executing CXXRTL backend.

3.1. Executing HIERARCHY pass (managing design hierarchy).

3.1.1. Finding top of design hierarchy..

3.2. Executing FLATTEN pass (flatten design).

3.3. Executing PROC pass (convert processes to netlists).

3.3.1. Executing PROC_CLEAN pass (remove empty switches from decision trees).
Cleaned up 0 empty switches.

3.3.2. Executing PROC_RMDEAD pass (remove dead branches from decision trees).
 Executing PROC_PRUNE pass (remove redundant assignments in processes).
Removed 0 redundant assignments.
Promoted 0 assignments to connections.

3.3.4. Executing PROC_INIT pass (extract init attributes).

3.3.5. Executing PROC_ARST pass (detect async resets in processes).

3.3.6. Executing PROC_ROM pass (convert switches to ROMs).
Converted 0 switches.

3.3.7. Executing PROC_MUX pass (convert decision trees to multiplexers).

3.3.8. Executing PROC_DLATCH pass (convert process syncs to latches).

3.3.9. Executing PROC_DFF pass (convert process syncs to FFs).

3.3.10. Executing PROC_MEMWR pass (convert process memory writes to cells).

3.3.11. Executing PROC_CLEAN pass (remove empty switches from decision trees).
Cleaned up 0 empty switches.

3.3.12. Executing OPT_EXPR pass (perform const folding).

ERROR: No such command: writx (type 'help' for a command overview)
Error while executing script:
	Running script on file './demo.ys'
---------------------------------
   1 read_verilog ../yosys/*.v
   2 write_cxxrtl demo.cxx
-->3 writx
---------------------------------

Fork off from branch https://github.com/YosysHQ/yosys/pull/3757 as per maintainer request


Adapt saturn-theme to use @frontity/h2r package

Fixes https://github.com/frontity/frontity/issues/76

@orballo @david, is this ready to merge? I need it for the release.

@DAreRodz @orballo I still need this

@luisherranz I think @DAreRodz was going to write some tests for the different processors, because not all of them had been tested.

Ok, then please my question so I can know if I can do the deploy today or not :)

@DAreRodz let me know when I should review this PR again :)

I've moved this PR back to "In progress" because @DAreRodz is working on it.
Once it's done, @DAreRodz should move it back to "In Review" again.

Perfect :smile:

Awesome, thanks guys!

:tada: This PR is included in version 1.6.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:

:tada: This PR is included in version 0.11.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Add reply, subject and sid to respmux callback invocation

Are reply, subject and sid args deliberately missing here and can they be added back plz?
https://github.com/nats-io/node-nats/blob/4079c2b928e0ee36566c3e3e2724b40c1bb4665f/lib/nats.js#L1474
I propose this way of invocation:
conf.callback(msg, reply, subject, conf.id)
to keep it compatible with subscription and "old" request callbacks

@omg thanks for the catch. The original implementation of request simply gave the message and the possible reply subject. Not quite sure if the additional arguments are useful, the subject certainly shouldn't be used, as the handler for those messages could be dropped and are internally generated.

@omg  this is fixed in v0.8.4

@aricart  Thank you, reply is sufficient for me. But "sid" arg can actually be useful when you have custom unsubscription logic other than max or timeout (by sid i mean here mux id, not actual subscription id). Subject may not be of much use but could be there for the sake of callback signature uniformity

@omg, the real issue is whether we are doing a 'subscription' or a convenience request api call. I think one shouldn't require management. Only reason why I didn't add the other arguments is that the old implementation didn't provide them.


Expired Token not getting refreshed

I wonder if anyone else is having this issue, if after having the site up for the duration of the IDTokens life, and visiting the site again (in a separate tab, or closing the window, etc), they find that they are still returned the expired token, as if it's cached? Only doing a refresh on the page, makes the token be re-generated. In the failed state, the app is delivered the IDToken with the old stale cookie value.
I've been trying to adjust configurations of the CloudFront caching policy to no success, after every expiration, the page is allowed to load without the proper authentication (old cookies), and any resources requiring authentication outside of CloudFront (Service calls into API Gateway using the token) fail, because the token is expired.

Hi @thertzelle . How sure are you it is not your browser's cache?

If I visit the page in a new window, and visit the cookies tab, I have an old cookie. It seems like it would be hard to visit the page and it to not have requested the default endpoint and refresh the tokens?

If I visit the page in a new window, and visit the cookies tab, I have an old cookie.

Yeah, cookies are shared by all tabs. If the cookie is old in the new tab, it will be old in all tabs.

It seems like it would be hard to visit the page and it to not have requested the default endpoint and refresh the tokens?

Yeah, if a refresh token is there that is still valid, the solution of this repo would use it to refresh the tokens. (Which is intended behavior)
If the user clicks "sign-out" explicitly, the cookies are thrown away. If the user doesn't do that, but just closes the browser, the cookies might be thrown away but this depends on:

If the cookiesettings you use in your Lambda@Edge-Auth setup include a max-age or expires, then the cookies will remain in your browser until that time

If the cookiesettings you use in your Lambda@Edge-Auth setup do not include a max-age or expires, then the cookies are session cookies, that depending on your browser setup get deleted when you close the browser. Many browsers nowadays do not do that, it is a browser setting that users can alter.

Another factor coming into play, is that the refresh token itself has an expiry date, that can be set in the Cognito User Pool config (defaults to 30 days).

Closing for now, as I do not believe there is an action for this repo.

Hi @ottokruse
Quick question: For scenarios, where we logout and we remove the cookies from the browser. But if we copy the id token before and use it to make further request from postman, it would still work.
What would be your recommendation to solve such use cases. (to invalidate the logged out id token since its stateless)

Best strategy I think is to have short token expiration so this risk becomes low enough to be acceptable.
Otherwise what you could do is call eg Cognito GetUser with the access token and if that fails you know the user is logged out. But it's not ideal to call that on every request (in checkauth lambda) because it adds latency and there is a max rps to it.

Having a short token expiration is still flagged by our info-sec team. And making a n/w call as you mentioned adds latency. Any other approach that would be practical enough to implement?  @ottokruse


Enforce that requests are mapped to connections for each Host: header values

This ended up being a much bigger branch than anticipated --- sorry for so much code to review!
This PR ensures that the mapping of requests to outbound connections is segregated by Host: header values. In most cases, the desired behavior is provided by Hyper's connection pooling. However, Hyper does not handle the case where a request had no Host: header and the request URI had no authority part, and the request was routed based on the SO_ORIGINAL_DST in the desired manner. We would like these requests to each have their own outbound connection, but Hyper will reuse the same connection for such requests.
Therefore, I have modified conduit_proxy_router::Recognize to allow implementations of Recognize to indicate whether the service for a given key can be cached, and to only cache the service when it is marked as cachable. I've also changed the reconstruct_uri function, which rewrites HTTP/1 requests, to mark when a request had no authority and no Host: header, and the authority was rewritten to be the request's ORIGINAL_DST. When this is the case, the Recognize implementations for Inbound and Outbound will mark these requests as non-cachable.
I've also added unit tests ensuring that A, connections are created per Host: header, and B, that requests with no Host: header each create a new connection. The first test passes without any additional changes, but the second only passes on this branch. The tests were added in PR #489, but this branch supersedes that branch.
This branch @seanmonstar's  proxy-te branch, so we should merge this branch after we merge his PR #457.
Fixes #415. Closes #489.

Please rebase this on top of the latest iteration of #457 to make it easier to review. In particular, this will be easier to review when 3f996f88a43693b23ee37f5a3ad28e8f919933be isn't part of the PR.

For the purposes of making this easier to review I set the base branch to #457's proxy-te branch. We should not merge this into that branch; when #457 is merged we'll rebase this PR onto master.
@seanmonstar Could you please do review of this? I'm swamped with 0.3.1-related stuff right now.

@seanmonstar Given our discussion regarding how rewriting the URIs before Bind (and thus the extension to indicate whether URIs were rewritten) is still necessary for telemetry, I think I've made the other changes you've requested as of 3b4661c1aa5c57632be42a9fea31221d1b0a98d5. This PR should be ready for another review.
Note that we still can't merge this until after #457 is merged.

Please add some test cases that specifically test HTTP/1.0 requests that do not have the Host header field set. In those test cases, verify that the server doesn't see a Host header field. That is, we shouldn't set the Host header field when it wasn't previously set.
Please add test cases for the case where the request URI has an authority and there is a Host header field in the request, where the request URI's host isn't equal (case-sensitively and case-insensitively) to the host in the Host header field. I think that in such a case, we should cancel the request with 400 bad request since the sender of the request is obviously confused. Note that the Conduit proxy is not a HTTP proxy so where rule in the HTTP spec that says that a proxy must do a replacement in his case doesn't apply to Conduit.

Please add test cases for the case where the request URI has an authority and there is a Host header field in the request, where the request URI's host isn't equal (case-sensitively and case-insensitively) to the host in the Host header field. I think that in such a case, we should cancel the request with 400 bad request since the sender of the request is obviously confused. Note that the Conduit proxy is not a HTTP proxy so where rule in the HTTP spec that says that a proxy must do a replacement in his case doesn't apply to Conduit.

I disagree here, Conduit is acting as n HTTP proxy. However, either way, this seems like a behavior change that is worth being in a separate issue, so we can discuss if it's actually something we want, instead adding on more things that this PR needs to change.

I disagree here, Conduit is acting as n HTTP proxy. However, either way, this seems like a behavior change that is worth being in a separate issue, so we can discuss if it's actually something we want, instead adding on more things that this PR needs to change.

This is now issue #518. I think, as far as the issue described in #518 is concerned, the main questions to ask here are:

Does this PR make the issue described in #518 any worse?
Does it still make sense to merge PR #514 into this PR? (AFAICT PR #514 is moving in the opposite direction of resolving #518, but maybe I am misunderstanding it.)

@briansmith

Does it still make sense to merge PR #514 into this PR? (AFAICT PR #514 is moving in the opposite direction of resolving #518, but maybe I am misunderstanding it.)

I don't believe there should be any change in externally visible behaviour due to #514. The reconstruct_uri function is still called for every request, and its behaviour should be unchanged. The only change is where it's called, and the removal of the extension that was used to retain information lost to reconstruct_uri, which is no longer necessary as the function is called after that information is needed.

Hi @briansmith, now that discussion of additional changes has moved to #518, I'm not sure which of the tests you requested in your earlier review should still be added on this branch. Can I get you to clarify that for me?

I don't believe there should be any change in externally visible behaviour due to #514. The reconstruct_uri function is still called for every request, and its behaviour should be unchanged. The only change is where it's called, and the removal of the extension that was used to retain information lost to reconstruct_uri, which is no longer necessary as the function is called after that information is needed.

Right. What I'm asking is if it makes sense to remove the extension, considering the issues in #514. Won't we need the extension to fix #514? I guess if we do, we can always undo #514.

Hi @briansmith, now that discussion of additional changes has moved to #518, I'm not sure which of the tests you requested in your earlier review should still be added on this branch. Can I get you to clarify that for me?

We can do the tests as part of #518.

@briansmith

Right. What I'm asking is if it makes sense to remove the extension, considering the issues in #518. Won't we need the extension to fix #518? I guess if we do, we can always undo #514.

It's possible that I'm wrong, but I don't think we will need the extension to fix #518 ---  based on my understanding of the issue, I think we can just make changes to the behaviour of reconstruct_uri?. Regardless, though, I think having a service that is added after Bind is the correct factoring for this behaviour, even if we do eventually end up adding an extension as well.

We can do the tests as part of #518.
Okay, thanks for clearing that up!

OK, sounds reasonable to me.

Okay, I've rebased this onto master and addressed @seanmonstar's most recent review comments.

@briansmith would love to get your final sign off on this before merging.

I'm not going to be able to review this today. I feel like the concerns I raised were adequately addressed already so I suggest you just rebase and merge this, based on @seanmonstar's review.


All adjustments to the Gaussian point color appearance should be converted into standard color representations, such as RGBA.

If I'm not mistaken, based on the current implementation, the logic for adjusting color appearance has been extended to the splat shader logic.As a result, the color-adjusted ply files exported from this editor cannot be directly used in other Gaussian renderers.

Hi @random-yang,
You are correctly that we apply the coloring in the shader, but we do this in order to be memory efficient while supporting undo/redo.
The settings are applied the data upon save too, so you can export. See https://github.com/playcanvas/supersplat/blob/main/src/splat-serialize.ts#L129
Thanks!

@slimbuck It sounds quite reasonable. Thanks!


Can not view MonthView mode

Hi,
Thanks for beautiful calendar view.
I setup Default project download and run in simulator iphone 5
I setup in info.plist file MonthView
But i have a problem, i can't view the mode .MonthView. the layout show not correct , maybe wrong size, i adjust by code but not get any luck!.

Hello @TechGuyVN,
The pre-release version is a huge one so I suggest to update your current code. To support the MonthView mode all you have to do is to implement CVCalendarViewDelegate with 2 methods presentationMode() and firstWeekday().
Regards,
Eugene


auth state: UNKNOWN

I replate API_ID and API_HASH then run app -> log auth state: UNKNOWN
Please help me.
Thank you!

Could you please provide more information about at which step did this happen? The app first asks for the phone number, than for the code (optionally is asks also for the password if the account has activated the two step verification) and finally it shows the chat list.
When entering the phone number, make sure it is in international format.
Please try out the latest commits and update to the latest tdlib.
I hope this helps solving your issue.


Use RDF extension when looking for files

JIRA Ticket: https://jira.lyrasis.org/projects/FCREPO/issues/FCREPO-3278
What does this Pull Request do?
When we write RDF we append the .nt extension to the id, but when we delete we just look for a file with the id name.
When trying to delete a child in an AG I got a 500 because it was trying to find a file called test2, but the actual file was test2.nt.
This refactors the Delete operations to track whether we are deleting a RDFSource or NonRDFSource object.
How should this be tested?
Before the PR:

Create an Archival Groupcurl -i -ufedoraAdmin:fedoraAdmin -H"Slug: parent" -H'Link: <http://fedora.info/definitions/v4/repository#ArchivalGroup>;rel="type"' -H"Content-type: text/turtle" -XPOST http://localhost:8080/rest

Create a child resource in the AG.curl -i -ufedoraAdmin:fedoraAdmin -H"Slug: child" -H"Content-type: text/turtle" -XPOST http://localhost:8080/rest/parent

Delete the child resource curl -i -ufedoraAdmin:fedoraAdmin -XDELETE http://localhost:8080/rest/parent/child

See 500 and explosion
Pull in this PR
Repeat steps
Joy.

Interested parties
@fcrepo4/committers

@pwinckles I wasn't sure if the resolveOCFLSubpath method was used to build the path to the entire object so I went with a separate method to handle file extensions. If this is more of what you want I can add the commit here.
Other comparison -> https://github.com/fcrepo4/fcrepo4/compare/master...whikloj:FCREPO-3278-2
Specific commit -> https://github.com/fcrepo4/fcrepo4/commit/0f51dabe3727234c390d6d673b01aac118bc7c14

@whikloj, yeah that does look a little cleaner. 👍

@pwinckles added


Use forward function from partitioning

Signed-off-by: Nikolay Maslarski<EMAIL_ADDRESS>

Coverage increased (+1.0%) to 92.991% when pulling 8bde7da88cea82794353a41ea72028ec86485ec0 on SAP:dataflow_partition into<PHONE_NUMBER>5c48957e2345358659e3ba63a15419 on cloudfoundry-incubator:master.

Coverage increased (+1.0%) to 92.991% when pulling 8bde7da88cea82794353a41ea72028ec86485ec0 on SAP:dataflow_partition into<PHONE_NUMBER>5c48957e2345358659e3ba63a15419 on cloudfoundry-incubator:master.

Coverage increased (+1.2%) to 93.251% when pulling 7d086d08f37825be271fe49373b7d2986d1f39c0 on SAP:dataflow_partition into<PHONE_NUMBER>5c48957e2345358659e3ba63a15419 on cloudfoundry-incubator:master.


lexgen failure case for richtext CBOR $type field missing #link suffix

This is a small test case which fails with regular lexgen output.
I manually tweaked the lexgen output to show what needs to change, and ran cborgen, and the test passes after. The fix needed here is to get lexgen to output the correct const= values by default.
Handing this PR off to @whyrusleeping for now. I took a 3-minute attempted at the lexgen change and it didn't work, requires deeper understanding of lexgen internals.

I re-based this and the problem seems to have been fixed at some point in the past... 6 months (!). would be good to merge this as a regression test.


feat: Modified Bot's Responses

Instructed the bot to :
1 - Never mention other libraries for bot development
2 - reply with a specific answer for any question about javascript or bdfd javascript
3 - updated, if the user wants to report someone
4 - brief explanation about BDFD app, BDScript and server's important channels to learn
5 - better answer for Spoon-feeding
6 - better answer for solving user's code issues
7 - explanations abou the BDFD Nodes and how the bots are hosted and maintained
8 - removed links embed

LGTM, but Javascript or BDFD JavaScript section has to be removed - it is based on incorrect information from a BDFD wiki.
I have already made changes to the wiki to fix this issue.

@kubastick yeah sure i have removed the incorrect section


[full-ci] Add Gateway flag to default config

This is needed in order to provide Reva with a valid configuration. This is only a patch until a more robust solution is found as it keeps the nightly builds from passing.
It also improves config parsing by memoizing the cli flags parsed for a given storage subcommand, preventing unnecessary code execution when iterating over flags and applying them to the flagset.
Description

Related Issue

Fixes <issue_link>

Motivation and Context

How Has This Been Tested?

test environment:
test case 1:
test case 2:
...

Screenshots (if appropriate):
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Technical debt
[x] Tests only (no source changes)

Checklist:

[ ] Code changes
[ ] Unit tests added
[ ] Acceptance tests added
[ ] Documentation ticket raised:

The small smoke test I had to verify this on reva side is essentially:
func (c *config) init() {
	if c.Network == "" {
		c.Network = "tcp"
	}

	if c.Address == "" {
		panic("beep, empty")
		c.Address = sharedconf.GetGatewaySVC("<IP_ADDRESS>:19000")
	}
}

no panic condition was triggered with this patch.


Tune AD and alerting tool descriptions

Description
This PR enhances the default descriptions of the AD and alerting tools in several ways:

more specific on the expected input types and returned output types (e.g., timestamps in epoch milliseconds format) to help guide the LLM to have valid suggestions when the tool generates the relevant search query / API calls.
adds options for params that are not clearly defined or interfaced (e.g., monitor types, alert state, alert severity level)
minor wording changes

It also fixes the parsing of the SearchMonitorsTool to parse monitor_type instead of type. type always is monitor, but monitor_type provides more detail, such as if the monitor is a query-level, bucket-level, or document-level monitor, which is more useful / user-expected
Variety of questions were tested on a test cluster with a provisioned LLM, and this PR is a direct result of where gaps were seen to help increase the effectiveness and accuracy of the tool itself.
Check List

[x] New functionality includes testing.

[x] All tests pass

[x] New functionality has been documented.

[x] New functionality has javadoc added

[x] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

All tests are passing besides known issue with neural sparse search tool:
30 tests completed, 2 failed
Tests with failures:
 - org.opensearch.integTest.NeuralSparseSearchToolIT.testNeuralSparseSearchToolInFlowAgent_withIllegalSourceField_thenGetEmptySource
 - org.opensearch.integTest.NeuralSparseSearchToolIT.testNeuralSparseSearchToolInFlowAgent_withIllegalEmbeddingField_thenThrowException


Add CakePHP 4.5 & Update 4.x releases

https://bakery.cakephp.org/2023/10/14/cakephp_450.html

@ravage84 Please review


execute(command) causes bash to throw errors

[ x ] I have read through the manual page (man fzf)
[ x] I have the latest version of fzf
[ x] I have searched through the existing issues

Info

OS

[x ] Linux
[ ] Mac OS X
[ ] Windows
[ ] Etc.

Shell

[ x] bash
[ ] zsh
[ ] fish

Problem / Steps to reproduce
Binding a script or command to execute causes bash to print error messages. Here is is the command I am using:
fzf --no-info --no-clear --reverse --header "MANAGE INSPECTION INFO" \
                --bind backward-eof:abort,j:down,k:up,change:accept,h:abort,l:accept,g:first,G:last --with-nth=2 -d '\t' \
                --preview="sqlite3 '$DBPATH' \"select note from inotes where rowid = {1};\"" --preview-window="70%,wrap" --print-query \
                --bind "e:execute(insearch2 -p 'manage_property_notes_edit_note {1}')+refresh-preview")

insearch2 is a bash script that I wrote. Passing the argument directly to the script from the command line works as expected.
I also tried execute(less {1}) and get similar error messages. The message flash so quickly that I can't completely see them, but what I can see is the following:
/bin/bash -c: line 1: unexpected EOF while looking for matching `''
/bin/bash -c: line 2: syntax error: unexpected end of file

Those lines are repeated  10 times.
As previously mentioned, I get no errors when I run these commands/scripts independently from fzf. It only seems to throw errors when running from fzf.
Apart from the error messages, everything functions as expected.
Is this an issue with fzf, or do I have an error in my code above?

Looking at this some more, I had been assigning the result of the selection from fzf to a variable like this:
var=$(fzf ...)
If I take the fzf command out of the var=(...) assignment, I don't get any error messages. I'll keep working on it, but not sure what would cause this. In any case, it seems like a bash problem rather than fzf. I'll go head an close this issues.


⚠ AGEG website (prod) has degraded performance

In b3b21bf, AGEG website (prod) (https://www.ageg.ca/) experienced degraded performance:

HTTP code: 200
Response time: 4161 ms

Resolved: AGEG website (prod) performance has improved in f59beb6.


write okify_regtests script, generalizing jwst and romancal versions

resolves SCSB-183
follow-up to https://github.com/spacetelescope/jwst/pull/8762
adds the okify_regtests script to the ci_watson package, generalized between the  existing jwst and romancal versions:

https://github.com/spacetelescope/jwst/blob/ffa02661593f4c53d66ab17fa837aa72a358def6/jwst/scripts/okify_regtests.py
https://github.com/spacetelescope/romancal/blob/9031ae12b14b22ba565581670e74b826d40ed86a/romancal/scripts/okify_regtests.py

This change would be coupled with removals of okify_regtests from both jwst and romancal:

https://github.com/spacetelescope/jwst/pull/8957
https://github.com/spacetelescope/romancal/pull/1513

Arguments
usage: okify_regtests [-h] [--dry-run] {jwst,roman} run-number

"okifies" a set of failing regression test results, by overwriting truth files on
Artifactory so that a set of failing regression test results becomes correct. Requires
JFrog CLI (https://jfrog.com/getcli/) configured with credentials (`jf login`) and write
access to the desired truth file repository (`jwst-pipeline`, `roman-pipeline`, etc.).

positional arguments:
  {jwst,roman}  Observatory to overwrite truth files for on Artifactory
  run-number    GitHub Actions job number of regression test run (see
                https://github.com/spacetelescope/RegressionTests/actions)

options:
  -h, --help    show this help message and exit
  --dry-run     do nothing (passes the `--dry-run` flag to JFrog CLI)

Usage Examples
okify_regtests jwst 956 --dry-run
okify_regtests roman 1317

difference between https://github.com/spacetelescope/jwst/blob/ffa02661593f4c53d66ab17fa837aa72a358def6/jwst/scripts/okify_regtests.py and https://github.com/spacetelescope/romancal/blob/9031ae12b14b22ba565581670e74b826d40ed86a/romancal/scripts/okify_regtests.py
2d1
<
7c6
< that have write access to the jwst-pipeline repository.
---
> that have write access to the roman-pipeline repository.
9c8
< import json
---
>
17d15
< from pathlib import Path
20,21d17
< import readchar
< from colorama import Fore
23,25c19,21
< ARTIFACTORY_REPO = 'jwst-pipeline-results'
< SPECFILE_SUFFIX = '_okify.json'
< RTDATA_SUFFIX = '_rtdata.asdf'
---
> ARTIFACTORY_REPO = "roman-pipeline-results"
> SPECFILE_SUFFIX = "_okify.json"
> RTDATA_SUFFIX = "_rtdata.asdf"
30c26
<     parser = ArgumentParser(description='Okify regression test results')
---
>     parser = ArgumentParser(description="Okify regression test results")
32,34c28,30
<         'build_number',
<         help='GitHub Actions build number for JWST builds',
<         metavar='build-number',
---
>         "build_number",
>         help="GitHub Actions build number for Roman builds",
>         metavar="build-number",
37c33
<         '--dry-run', action='store_true', help='pass the --dry-run flag to JFrog CLI'
---
>         "--dry-run", action="store_true", help="pass the --dry-run flag to JFrog CLI"
47c43
<         jfrog_args.append('--dry-run')
---
>         jfrog_args.append("--dry-run")
49c45
<     args = list(['jfrog', 'rt', 'cp'] + jfrog_args + [f'--spec={specfile}'])
---
>     args = list(["jfrog", "rt", "cp"] + jfrog_args + [f"--spec={specfile}"])
53,99d48
< def artifactory_folder_copy(specfile, dry_run=False):
<     """Copy a folder after removing target folder"""
<     jfrog_args = []
<     if dry_run:
<         jfrog_args.append('--dry-run')
<
<     # Since two different jfrog operations are required, need to read in
<     # the spec to perform the delete.
<     with open(specfile) as fh:
<         spec = json.load(fh)
<     pattern = spec['files'][0]['pattern'] + '/'
<     target = spec['files'][0]['target']
<
<     # Remove the target
<     folder = target + Path(pattern).stem
<     args = ['jfrog', 'rt', 'del', folder, '--quiet=true'] + jfrog_args
<     subprocess.run(args, check=True)
<
<     # Copy pattern to parent of target.
<     args = ['jfrog', 'rt', 'cp', '--spec', specfile] + jfrog_args
<     subprocess.run(args, check=True)
<
<
< def artifactory_dispatch(okify_op, specfile, dry_run):
<     """Perform the indicated artifactory operation
<
<     Parameters
<     ----------
<     okify_op : str
<         The operation to perform:
<         - 'file_copy': Copy individual files
<         - 'folder_copy': Replace whole folders
<
<     specfile : str
<         The full path to the jfrog spec file
<
<     dry_run : bool
<         True to just show what would be done
<     """
<     if okify_op == 'file_copy':
<         artifactory_copy(os.path.abspath(specfile), dry_run=dry_run)
<     elif okify_op == 'folder_copy':
<         artifactory_folder_copy(os.path.abspath(specfile), dry_run=dry_run)
<     else:
<         raise RuntimeError(f'Unknown artifactory operation: {okify_op}')
<
<
101c50
<     """Download specfiles or other breadcrumb from Artifactory associated with
---
>     """Download specfiles or other breadcrump from Artifactory associated with
104c53
<     An example search for build 586 would be:
---
>     An example search would be:
106,107c55,56
<     jfrog rt search jwst-pipeline-results/*_GITHUB_CI_*-586/*_okify.json
<     """
---
>     jfrog rt search roman-pipeline-results/*/*_okify.json --props='build.number=540;build.name=RT :: romancal'
>     """  # noqa: E501
109c58
<     # Retrieve all the okify specfiles for failed tests.
---
>     # Retreive all the okify specfiles for failed tests.
111c60
<         ['jfrog', 'rt', 'dl']
---
>         ["jfrog", "rt", "dl"]
113d61
<         + ['--flat']
117c65
<     return sorted(glob(f'*{suffix}'))
---
>     return sorted(glob(f"**/**/*{suffix}"))
125c73
<         raise RuntimeError('Different number of _okify.json and _rtdata.asdf files')
---
>         raise RuntimeError("Different number of _okify.json and _rtdata.asdf files")
128,129c76,77
<         if a.replace(SPECFILE_SUFFIX, '') != b.replace(RTDATA_SUFFIX, ''):
<             raise RuntimeError('The _okify.json and _rtdata.asdf files are not matched')
---
>         if a.replace(SPECFILE_SUFFIX, "") != b.replace(RTDATA_SUFFIX, ""):
>             raise RuntimeError("The _okify.json and _rtdata.asdf files are not matched")
150,153c98,101
<     with tempfile.TemporaryDirectory() as tmp_path:
<         print(f'Downloading test logs to {tmp_path}')
<         with pushd(tmp_path):
<             # Retrieve all the okify specfiles for failed tests.
---
>     with tempfile.TemporaryDirectory() as tmpdir:
>         print(f"Downloading test okify artifacts to local directory {tmpdir}")
>         with pushd(tmpdir):
>             # Retreive all the okify specfiles for failed tests.
158c106
<             print(f'{number_failed_tests} failed tests to okify')
---
>             print(f"{number_failed_tests} failed tests to okify")
161d108
<
164,168c111,114
<                     okify_op = af.tree['okify_op']
<                     traceback = af.tree['traceback']
<                     remote_results_path = af.tree['remote_results_path']
<                     output = af.tree['output']
<                     truth_remote = af.tree['truth_remote']
---
>                     traceback = af.tree["traceback"]
>                     remote_results_path = af.tree["remote_results_path"]
>                     output = af.tree["output"]
>                     truth_remote = af.tree["truth_remote"]
170c116
<                         test_name = af.tree['test_name']
---
>                         test_name = af.tree["test_name"]
172c118
<                         test_name = 'test_name'
---
>                         test_name = "test_name"
180,184c126
<                 print(
<                     f'{Fore.RED}'
<                     + (f' {test_name} '.center(TERMINAL_WIDTH, '—'))
<                     + f'{Fore.RESET}'
<                 )
---
>                 print(f" {test_name} ".center(TERMINAL_WIDTH, "—"))
186,188c128,130
<                 print(f'{Fore.RED}' + ('—' * TERMINAL_WIDTH) + f'{Fore.RESET}')
<                 print(f'{Fore.GREEN}OK: {remote_results}')
<                 print(f'--> {truth_remote}{Fore.RESET}')
---
>                 print("—" * TERMINAL_WIDTH)
>                 print(f"OK: {remote_results}")
>                 print(f"--> {truth_remote}")
190,194c132,133
<                     f'{Fore.RED}'
<                     + (
<                         f'[ test {test_number} of {number_failed_tests} ]'.center(
<                             TERMINAL_WIDTH, '—'
<                         )
---
>                     f"[ test {test_number} of {number_failed_tests} ]".center(
>                         TERMINAL_WIDTH, "—"
196d134
<                     + f'{Fore.RESET}'
201,209c139,141
<                     print(
<                         f'{Fore.GREEN}\'o\' to okify{Fore.RESET}, '
<                         f'{Fore.CYAN}\'s\' to skip{Fore.RESET}, '
<                         f'{Fore.MAGENTA}\'q\' to quit{Fore.RESET}: '
<                     )
<                     # Get the keyboard character input without pressing return
<                     result = readchar.readkey()
<                     if result not in ['o', 's', 'q']:
<                         print('Unrecognized command, try again')
---
>                     result = input("Enter 'o' to okify, 's' to skip: ")
>                     if result not in ["o", "s"]:
>                         print(f"Unrecognized command '{result}', try again")
212,215c144,146
<                 if result == 'q':
<                     break
<                 elif result == 's':
<                     pass
---
>
>                 if result == "s":
>                     print("Skipping\n")
217,220c148,149
<                     artifactory_dispatch(
<                         okify_op, os.path.abspath(specfile), dry_run=args.dry_run
<                     )
<                     print('')
---
>                     artifactory_copy(os.path.abspath(specfile), dry_run=args.dry_run)
>                     print("")
223c152
< if __name__ == '__main__':
---
> if __name__ == "__main__":

@spacetelescope/jwst-pipeline-maintainers @spacetelescope/jwst-pipeline-developers  @spacetelescope/romancal-maintainers thoughts on this consolidation?

added rglob from https://github.com/spacetelescope/jwst/pull/8970

Could you add basic documentation for this in the README or something like that?

@melanieclarke as you use okify_regtests for JWST, would you mind testing this script in this branch when you get a chance, and let me know if you'd like any changes to the workflow?

@zacharyburnett - will do, next time I have something to okify.  Thanks for working on this!

tested successfully for romancal (https://github.com/spacetelescope/romancal/pull/1513#issuecomment-2528310336)


Add "stop" event listen to daprd Windows

In what area(s)?

/area runtime

/area operator

/area placement

/area docs

/area test-and-release

Describe the feature
daprd currently doesn't listen for a stop event on Windows, as it does for dapr instances run through the CLI. The changes in the dapr list implementation now display independently run daprd instances to users, so they should be allowed to stop independent daprd sidecars on windows using dapr stop
Release Note

RELEASE NOTE:

It would be great! Could you post a PR for it?


RFC: New way to declare resolvers

I've just been to the GraphQL Europe conference and it got me thinking about how we specify resolvers. Using Go methods seemed nice at first, but is that really the best way? Please take a look at this alternative:
https://github.com/neelance/graphql-go/blob/new-resolvers/example/starwars/starwars.go#L291
Advantages:

no resolver wrappers, especially good for list results
API easier to learn
clean shortcuts like ResolverField
most type checking at startup is still possible
explicit name mapping between GraphQL and Go
automatic handling of GraphQL type assertions

Disadvanatages:

no type checking on return value if type is a GraphQL interface (they map to Go's interface{})

What do you think?
/cc @F21 @nicksrandall @acornejo @bsr203 @EmperorEarth

looks much simpler and easier for new users and looks great. I use relay "Node" interface a lot and not sure how much headache  would it be not having validation. But, I am ok with the tradeoff considering the overall simplification. Thanks for your continuing effort on improving the library. Cheers.

This looks like a good way to lower the entry to barrier.
Would the existing way to define resolvers still be supported?
It could be that I'm used to the current method of writing resolvers, but I have a few concerns about doing away with the existing method and going only with this approach:

would force the creation of API-specific models if the underlying data does not match the GraphQL schema.
would make it harder to unit test, unless the functions are named.
function names would have to be more verbose (maybe include the name of the object being resolved?) because we lose the ability to attach functions to types
it becomes a bit unclear how to organize graphql-related code inside your project (what if I want the registration to be separate from the function definitions?)
we lose some type checking
ResolverField is convenient for simple use cases but in advanced use cases (i.e. lazy-loading of fields) maybe not so much

However, the only drawback I can think of if this method of specifying resolvers lives alongside the existing is that multiple ways to do the same things can be confusing.

Would the existing way to define resolvers still be supported?

No, but you can emulate it via https://golang.org/ref/spec#Method_expressions.

would force the creation of API-specific models if the underlying data does not match the GraphQL schema.

What do you mean by that?

would make it harder to unit test, unless the functions are named.
function names would have to be more verbose (maybe include the name of the object being resolved?) because we lose the ability to attach functions to types

I think you can still have them attached to a type by using https://golang.org/ref/spec#Method_expressions.

it becomes a bit unclear how to organize graphql-related code inside your project (what if I want the registration to be separate from the function definitions?)

Please also explain some more.

I like it!
However, I feel that the downside is that if there is a missing resolver, it might not be caught.
For example, if I just have a schema, and have no resolvers, will the missing resolver only be caught during runtime?
s := graphql.ParseSchema(schemaIDL)
// no resolvers here.

Missing resolvers will throw an error at application startup, just like they do right now.

No, but you can emulate it via https://golang.org/ref/spec#Method_expressions.

Okay, that's perfect! I didn't realize methods could be used like this. This would remain largely the same as existing in this case.

would force the creation of API-specific models if the underlying data does not match the GraphQL schema

From the example given, it looks like the functions return the actual type rather than a resolver.
Here's an example
// This type seems to be specific to the API, used instead of resolver wrapper
type starship struct {
  ID     graphql.ID
  Name   string
  Length float64
}

// Imagine this is the type contained by starshipData
type legacyStarship struct {
  ID        int
  BrandName string
  Model     string
  Length    float32
}

s.Resolver("Query", "starship", func(r *Resolver, args *struct{ ID graphql.ID }) *starship {
  legacy := starshipData[args.ID]

  return &starship{
    ID:     graphql.ID(strconv.Itoa(legacy.ID)), // previously each of these would have a function that contains this logic
    Name:   strings.Join(" ", legacy.BrandName, legacy.Model),
    Length: float64(legacy.Length),
  }
})

Is it the case that you can no longer return a resolver type?

it becomes a bit unclear how to organize graphql-related code inside your project (what if I want the registration to be separate from the function definitions?)

Is it the case that you can no longer return a resolver type?

Sure you can. Why shouldn't it be possible?

Ah I was just confused... This seems great! I don't have any more concerns. Out of curiosity are there any performance implications to using this method?

I did not do any performance tests yet. However, ResolverField might be faster because it does no call.

It would be nice if you could define multiple field resolvers together to make it easier to keep track of the fields defined for your resolver
// graphql.FieldMap  = map[string]string

s.ResolveFields("Droid", graphql.FieldMap{
  "id": "ID",
  "name": "Name",
  "appearsIn": "AppearsIn",
  "primaryFunction": "PrimaryFunction",
})

or use struct tags
type droid struct {
	ID              graphql.ID   `gql:"id"`
	Name            string       `gql:"name"`
	Friends         []graphql.ID
	AppearsIn       []string     `gql:"appersIn"`
	PrimaryFunction string       `gql:"primaryFunction"`
}

If the struct tag route is up for discussion it wold be nice to just reuse json tags too if possible
Thanks for all the great work!

How do you plan to thread context?

@euforic I agree that such helpers may be nice. They should be easy to add on top of the simpler base API.
@nathanborror Sorry, but I don't understand your question.

I much, much, prefer the struct-based approach.
From your list of advantages:

API easier to learn

I don't think it's easier. The API currently is essentially 2 functions (from the examples):
graphql.ParseSchema(starwars.Schema, &starwars.Resolver{})
http.Handle("/query", &relay.Handler{Schema: schema})

And graphql.ID for resolvers That's about it.
In fact the API is very clean, and doesn't "overreach" in the app code. One way to see this is that the only dependency on graphql for the big chunk of the example code, is on graphql.ID. And the server implementation only calls graphql.ParseSchema and relay.Handler. That's it.

clean shortcuts like ResolverField

No shortcuts is cleaner. But I agree that for simple fields, maybe some json-like annotations like it was suggested in this issue and another one, could make things a tiny bit easier. That's also cleaner than ResolverField I think.
You suggested that method expressions can be used. Yes, but instead of just adding a method to a struct (which I need anyway), now I also have to add one line of code, calling ResolverField with string arguments.
To quote @neelance on a related discussion  ;)
I think that the following happened a lot during the design of the Go language:
Is it possible? Yes.
Would it give the option to write less code? Yes.
Should we add it? Probably not.

(Which made me laugh, because I think it's probably true :) )
And I think this that ResolverField one of those too. You save 2 lines of code with the shortcut, but it's not cleaner than the function which gives you more flexibility.

most type checking at startup is still possible

"most" is not as good, so this is a step backwards (and a big one in my opinion)

explicit name mapping between GraphQL and Go
automatic handling of GraphQL type assertions

I either don't really understand what you mean, or don't see the difference/improvement with how things are now. Passing strings as function arguments don't map any better than function names (ok, they match the case). In fact to me those strings are at least as magical as method names. If we were using something like ResolveField(schema.Human, schema.Friends, &Human.Friends) maybe, but again, this is just repeating what the Human.Friends struct/function is saying currently.
The other thing is that code organization is a bit more messy. The initSchema function is huge, and must have a direct dependency on every piece of the implementations, all the resolvers, all the fields. Of course I could pass around s, but it's still not as clean.
Ultimately, there is a much tighter link between the app code and the graphql-go library. Testing is not as easy (before, my tests would pretty much not know about graphql-go, just import my structs and my resolvers, and use that directly). Testing was mentioned before by @tonyghita, but another thing to add is   that now testing has to include this initSchema function, and the implementation of my resolvers. Before it was only the resolvers.
But losing some type safety is sort of the biggest issue I have. Actually, I think it's already a pretty big problem that some of that checking is done at startup time, and not build-time. It is a tradeoff to make the API simpler (pass the schema as a string, and not an object that you have to build). Ideally it should be possible to build the schema only from the top level resolver struct (api would look like graphql.BuildSchema(&starwars.Resolver{}) as long as it doesn't require some sort of schemaBuilder.Object like here)
Obviously all of these arguments can become moot with a single helper function that does reflection, and makes all the s.Resolver() and s.ResolverField() calls for me (which is roughly what is happening currently)

@yohcop Thanks a lot for your feedback. Some thoughts:
About the type safety: It is really only about GraphQL interfaces. I also wasn't fully happy about how they worked before, it was more complicated than it needs to be.
About ResolverField: This is not only a shortcut, but performance relevant. Calling a function is much more expensive than reading a field. ResolverField will not just be a wrapper around Resolver.
About your "single helper function that does reflection": That won't work easily. graphql-go currently traverses the schema and the Go types in parallel to figure out mappings between GraphQL types and Go types. This is quite implicit. With the new API this will be much clearer to understand.
I have started working on the new approach and the graphql-go implementation already became a bit less complicated, which I think is good. It will also make it easier to add some features requested in other issues. Please take a look at how the new API currently looks like, I have iterated on it a bit: https://github.com/neelance/graphql-go/blob/new-resolvers/example/starwars/starwars.go#L289
I hear your concerns, but right now this still looks like the right way to go.

Fair enough :) Actually I would take performance improvements over almost anything. I would be wary of promising improvements before benchmarks though (unless you have some already?).
Ultimately it's also your library, and you know it better than anyone.
Looking at the last iteration, I think I can live with it.  What's the purpose of it? I see it mirrors the more concrete types human, droid, etc. Is it just to fit the API?
I see the Schema() function returns b.Build(&root{}). If root is not really necessary, could this be replaced with b.Build() (or passed a dummy root object) and instead &root{} would be build at query time, in the http handler. It could then be used to pass information about the query through resolvers for Queries and Mutations (e.g. logged in user info). Currently one has to use the Context.WithValue/Context.Value in a non-typesafe way, but a user-defined struct would be much nicer. Another mechanism would be welcome too, if root doesn't work here.

I'll keep following, keep us updated :+1:

Moving from https://github.com/neelance/graphql-go/issues/15#issuecomment-311453283
When do you think that this'll be done with?

@neelance what's the decision on this? Is the new way final and just blocked on you finishing the work?

I like the approach it definitively would make
Also thanks @neelance for https://golang.org/ref/spec#Method_expressions

I found time to work on graphql-go today and made good progress on the new resolvers. My plan is to push a version tomorrow that is not fully finished, but ready for testing and feedback.

If you have a new release I'll test it out this week. Is there going to be
a release tag or other versioning system?
On Jul 3, 2017 8:58 PM, "Richard Musiol"<EMAIL_ADDRESS>wrote:

I found time to work on graphql-go today and made good progress on the
new resolvers. My plan is to push a version tomorrow that is not fully
finished, but ready for testing and feedback.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/neelance/graphql-go/issues/88#issuecomment-312756479,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA8asgmyzigYoXOaww9OKsfNkXlkmkACks5sKY49gaJpZM4NjiUs
.

All right, the new version on branch new-resolvers passes all tests. Feel free to give it a try. It still needs better error handling in a lot of places and code cleanup. I'm also not really happy about the top-level value (the argument passed to Build). One option would be to remove it entirely. Ideas on this and other feedback are welcome.

@arnos I'm still reluctant to put a version label on it, since the API does not yet feel stabilized to me. I'm still exploring the GraphQL world.

That tells me that this isn't really production ready :/

@ijsnow Depends on your definition of "production ready": If you mean "use it and expect bug fixes without occasionally having to invest work to adopt some API changes" then no, it is not this "production ready". If you mean "it does not have bugs all over the place", then yes, it is this "production ready".

I just tested the new version.
It seems to weird in some places compared to the old style: b.Resolvers("Query", (*root)(nil), map[string]interface{}{
But not having a func for every field which is just a getter is a lot better! :+1:

@metalmatze Thanks for giving it a try. Any ideas on how I could improve the new API? It also feels a bit weird to me, but maybe we're just not used to it.

@neelance tried it out some observations:

It works well and with Method expression you linked to earlier minimal changes are required

	SB.Resolvers(
		"Queries", (*Resolver)(nil), map[string]interface{}{
			"flavor": (*Resolver).Flavor,
			"flavors": (*Resolver).Flavors,
		},
	)

I like being able to use fields directly, (I have to keep custom wrapper function to convert time.Time to graphql.Time)

	SB.Resolvers(
		"Flavor", (*FlavorResolver)(nil), map[string]interface{}{
			"id":    "Id",
			"name":   "Name" ,
			"createdAt":    (*FlavorResolver).CreatedAt,
			"updatedAt":    (*FlavorResolver).UpdatedAt,
		},
	)

Using the clean architecture my models reside in a Domain package separate from the GraphQL package (I end up duplicating more code ... but that's a function of my design not the library)  as a result the only code that goes away are the simple field resolvers.

In terms of changes

a dead simple change is to extract the map, resolver type and not have it in the Resolvers method, this will make the API cleaner (IMHO) compare my query resolver example above with the following

	queryMap := map[string]interface{}{
		"flavor": (*root).Flavor,
		"flavors": (*root).Flavors,
	}
       rootResolver := (*root)(nil)

       SB.Resolvers("Queries", rootResolver, queryMap,)
       SB.Resolvers("Flavor", flavorResolver, flavorMap)

Overall I like the change it brings some duplication for me with the clean architecture

If you did make a version tag for the old API before you merge to master, it'd be really helpful for those of us using Glide and the like. We'd have better control of when we port our code to this new way of implementing resolvers.

Also what about trying to get complete feature support before changing the API? Like subscriptions

@neelance Do you think that the package is likely to go with this new way?

I browsed through the code a bit today. I see a lot of nice changes that happened behind the scenes where things seem more elegant.
But from the perspective of someone who would use the exterior API and not a maintainer, I don't see much benefit.
In fact, I would argue that the old way of doing things had less magic and was closer to the spirit of go, where we were relying on the type system explicitly (behind the scenes you still rely on this through reflection, but now the user only sees strings).
It is not entirely clear to me that some of the simplifications that happened behind the scenes required a move to the string indexed representation of the resolvers.
@neelance what did you set out to do with this refactor? I see you mention ResolverField but I see no such class/function in the API, do you mean the fact that for simple fields you can just use the string as a shortcut for a function that returns the type?
Is there a concrete example which you feel the new API simplifies, a code snippet would be great.

Ok with go 1.9 alias types I believe we have an even more interesting use case for the new resolvers structure. I have some time this week and beginning September to re-factor.
If I'm right I'll eliminate the bulk of boiler plate code

@neelance any word on the progress of this?

I completely agree with some of the earlier comments:

But from the perspective of someone who would use the exterior API and not a maintainer, I don't see much benefit... In fact, I would argue that the old way of doing things had less magic and was closer to the spirit of go...

The lack of "magic" of the current resolver system I think makes things clear to understand.
It would be neat if an approach could be taken similar to what grpc does (where they take a proto file and generate interfaces) where we could take a graphql file and generate interfaces that can make it even more go-like in that the provided resolver types must implement the given interfaces.
To me, using something like interface{} everywhere (like in the proposed new version) is a pretty strong anti-pattern given the simplicity of code generation that is available now.
Just my 2 cents.

Any update on this?

Hi everyone. I'm sorry that there currently is no progress on this library. This is because I am focused on bringing WebAssembly to the Go compiler, see https://github.com/golang/go/issues/18892#issuecomment-347057409.
Regarding the new way to declare resolvers: I liked the approach mentioned above better than the previous one, but I still wasn't fully happy with it. I did some more sketches and what I ended up was this:
func resolveHuman(req *HumanRequest, h *store.Human) *HumanResponse {
	var resp HumanResponse

	resp.ID = h.ID
	resp.Name = h.Name
	resp.AppearsIn = h.AppearsIn

	resp.Height = make([]float64, len(req.Height))
	for i, f := range req.Height {
		resp.Height[i] = convertLength(h.Height, f.Args.Unit)
	}

	if req.Mass && h.Mass != 0 {
		f := float64(h.Mass)
		resp.Mass = &f
	}

	if req.Friends != nil {
		for _, id := range h.Friends {
			resp.Friends = append(resp.Friends, resolveCharacter(req.Friends, id))
		}
	}

	if req.Starships != nil {
		for _, id := range h.Starships {
			resp.Starships = append(resp.Starships, resolveStarship(req.Starships, store.Starships[id]))
		}
	}

	return &resp
}

The idea is that GraphQL handlers should be similar to http.Handler. The "resolvers" API that I borrowed from graphql-js now feels like too much magic and indirect control flow and not really fitting for Go.
Right now this is all I can show to you, but I hope to continue working on this project at some point. Until then the project unfortunately is on hold, at least on my end. Can't clone myself. ;-)

That's a really interesting approach. I can't wrap my head around how the selection set would be efficiently executed... what am I missing?

I've been working on a new GraphQL server package and a large part of the reason why is that I'm unhappy with the interface of this package. I'm now re-thinking this and wondering if I can merge some of my work into this package, as it seems like it's emerging as the GraphQL package of choice.
My thinking about resolvers mostly rests on these principles:

There should absolutely be a Go interface for resolvers. This is the Go way and allows for nice things like composability and type safety.
Code generation should not be required (but optional is fine)
The resolver should be the one to decide whether a field is resolved asynchronously. It doesn't make sense to kick off an entire goroutine just to read a struct field.
Things should be as type-safe as possible (though there will undoubtedly be some sacrifices made here)

Currently I'm working with this interface:
// Resolver represents a GraphQL object type. It allows the query executor to resolve fields.
type Resolver interface {
	// Resolve returns a value for a field, according to the given field name and args.
	// If the field is itself a value with its own fields, another Resolver must be returned.
	// If the field is a list, a ListIterator should be returned.
	// Resolve is assumed to be a blocking function by default, but it may return a chan interface{}
	// if the field is being resolved asynchronously. The field value must be sent on the channel and
	// is treated the same way as if it had been returned directly from Resolve.
	// If the field name is not recognized by the Resolver, then Resolve's behavior is unspecified
	// and it may panic.
	Resolve(ctx context.Context, field string, args map[string]interface{}) (interface{}, error)

	// TypeName returns the name of the GraphQL type that the Resolver is resolving fields for.
	TypeName() string
}

I'm still not totally happy with this. For one thing, this Resolver differs from http.Handler in that Resolver objects tend to be constructed dynamically, during the GraphQL query, rather than ahead of time. (http.Handler objects can be constructed during requests too, but typically they're not.)
The reason is that there's no place to pass things like data loaders or other state. It wouldn't be hard to fix this by adding another interface{} parameter or similar, but that doesn't feel very elegant or type safe.
This interface does enable some pretty nice things. For example, I've got a helper function that can create a Resolver from a struct that has graphql tags on its struct fields:
// NewStructResolver returns a Resolver that resolves fields from a struct's fields.
// s must be a struct or a pointer to a struct.
// The returned Resolver resolves only fields that have the graphql tag. For example:
//
//	type Object struct {
//		StringField string `graphql:"string_field"`
//	}
func NewStructResolver(typeName string, s interface{}) (Resolver, error)

So now servers have the option of doing reflection magic to implement their resolvers, but aren't forced to. And the resolvers can compose nicely, so you can use a struct-based Resolver for most of your object fields, but have custom logic for the remaining ones.
I'm really interested in trying to engage with the community to solve this problem and working on this. Let me know what you think.

FWIW, my workplace has used the https://github.com/Applifier/graphql-codegen to stamp out all our resolvers for use with this library.
It works, but we're probably about to fork it to make some enhancements to the way it does types, and here's why: right now, that codegen emits interface{} wildcard type fields in the Go structures it generates whenever there's a Union declaration in your graphql schema.  And that's kind of unfortunate.
It looks to me like this graphql-go server library can handle interfaces just fine there, so, we should be able to make an interface (just with a marker method; in practice our code will still do type casing, because there's not much for real semantic interfaces here) to match each Union in our graphql schema.  This would make a lot of our nearby code quality higher; interface{} is the least useful thing for getting the compiler to give us any helpful checks at all.
This is orthogonal to all the other concerns about e.g. whether or not every resolver deserves a goroutine, etc (and for a datapoint, yes, my group too is almost entirely full of codegen'd resolvers which are just dereferencing struct fields).

Hopefully it's not too late to contribute to this discussion.
16:37
This discussion reminds me of Cheng Lou's talk on the Spectrum of Abstraction. It comes down to how well defined you think Resolvers are for users of your library. The more well-defined it is, the more you move down the ladder of abstraction, say from functions to structs, and get some perf wins. What you lose is expressiveness. In the linked section, Cheng Lou gives his understanding of a few libraries, the decisions they made, and how its affect their usage. Is it worth conceding some perf for expressiveness?
Personally, I don't think so, but this may be because I'm a mediocre programmer without the experience to reliably predict how I will use GraphQL resolvers. Right now, I'm using them in two ways:

Ideally, I grab a Viewer from the resolver struct and invoke a method on the Viewer type. In this case, my resolver is a thin adapter, which is how I like to think of my GraphQL layer: a thin API adapter. Most of the decision making, such as authorization, happens inside my core business logic.

	return r.v.ViewFoo(r.ctx, r.db)
}```
2) More commonly, since I'm optimizing my feature/hour rate at the expense of maintainability, I'm shoving my authorization, db calls, etc into my resolvers.
```func (r *FooResolver) Bar() (string, error) {
	// check 403
	// check redis
}```

 The perf wins and few key strokes saved just don't seem that huge. I think of GraphQL as a thin API layer when

Personally, I see your original implementation > first implementation and I'm unsure about the second. Sure the first feels too much like a map of strings to meaningless blobs, which according to Pike, is a meaningless map. I'm not sure it's worth saving a few keystrokes/codegen to do that. More importantly, I

https://www.youtube.com/watch?v=etax3aEe2dA
6:12

Dan Schafer's guidance: Core business logic handling authorization, etc as the single source of truth. From there, graphql-go is a thin API layer.

Ideally, my backend will grab the Viewer from context, and call `v.ViewFoo`, where method `ViewFoo` will call `MayViewFoo`

Hopefully it's not too late to contribute.
This discussion reminds me of Cheng Lou's talk on the Spectrum of Abstraction. It comes down to how well defined you think Resolvers are for users of your library. The more well-defined it is, the more you move down the ladder of abstraction, say from functions to structs, and get some perf wins. What you lose is expressiveness. In the linked section, Cheng Lou gives his understanding of a few libraries, the decisions they made, and how its affect their usage.
Personally, I don't think so, but this may be because I'm a mediocre programmer without the experience to reliably predict how I will use GraphQL resolvers. Right now, I'm using them in two ways:

Ideally, I grab a Viewer from the resolver struct and invoke a method on the Viewer type. In this case, my resolver is a thin adapter, which is how I like to think of my GraphQL layer: a thin API adapter. Most of the decision making, such as authorization, happens inside my core business logic.

	return r.v.ViewFoo(r.ctx, r.db)
}```
2) More commonly, since I'm optimizing my feature/hour rate at the expense of maintainability, I'm shoving my authorization, db calls, etc into my resolvers. Code omitted for brevity.

I think the first will reliably be a best practice, but I'm quite unsure. But I know I'll be prototyping using the second way for awhile, so a certain level expressiveness seems necessary. **I'm not sure a few perf wins and key strokes/codegen saved are worth adding to the API size**. For one, there's social value in keeping everyone speaking the same "language" so to speak, when talking about your library. For another, especially as a full stack developer, each individual library is fine adding a bit of API. But in the aggregate, it's just too much. It's one of the smaller reasons that drew me to Go in the first place. It *wasn't* C++.

i'm specifically looking for the ability to define resolvers at runtime (without using reflection & compiled-in types). i've started working on porting this library to support that use case. however, if there is a branch actively being developed i'd be happy to contribute there to make this a reality.
can anyone point me in the right direction for this?

There's an alternative project out there which has a very different
approach and generates type Resolver interface {...} in somewhat the way
described:
https://github.com/vektah/gqlgen/
It more or less forked the GQL parsing logic from this library, but then
started over on the resolvers.  The way it ended up, you can see all the
methods you need to implement on the generated Resolvers interface with
this approach (and the compiler can too... which is... VERY nice).
I'm not really one to say anything is ever "perfect", but more interfaces
-> more compile time checks -> more happy.
(I know I also said something about https://github.com/Applifier/
graphql-codegen earlier in this same thread.  Yeah, I abandoned that.  My
whole team went over to this vektah library and we're much happier there.)
On Tue, May 22, 2018 at 11:15 PM, Scott Weiss<EMAIL_ADDRESS>wrote:

i'm specifically looking for the ability to define resolvers at runtime
(without using reflection & compiled-in types). i've started working on
porting this library to support that use case. however, if there is a
branch actively being developed i'd be happy to contribute there to make
this a reality.
can anyone point me in the right direction for this?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/graph-gophers/graphql-go/issues/88#issuecomment-391143320,
or mute the thread
https://github.com/notifications/unsubscribe-auth/Afho_3ldaA59G0grwcf1Y-wpHOBYJiuCks5t1IAAgaJpZM4NjiUs
.

I was originally all for this change, especially after experiencing the quick iterations of graphql in node.js via https://github.com/matthewmueller/graph.ql.
Now, I'm -1 to changing the return values to be an interface{}. While it's true that writing each of the methods is much more verbose and time consuming than it is in node.js, it's a one-time task and you'll get to keep the type system.
As a tip, you can specify these fields like this:
// User resolver
type user struct {
	cfg *Config
	d   *users.User
}

// User fields

func (u *user) ID() string { return u.d.ID }
func (u *user) Email() string { return u.d.Email }
func (u *user) Password() string { return u.d.Password }
func (u *user) FirstName() string { return u.d.FirstName }

This can be cranked out very quickly using you editor's multi-cursor support.

@eric-am I've been using it as well. I've taken the schema and query parsing logic and basically made a custom "ExecutableSchema" that allows me to register / reregister new schemas (and their resolvers) at runtime

I'm not sure what the final approach with this feature will be, but just thought I'd throw my opinion in.
I don't mind the current approach to defining resolvers but like this issue, I do have a problem with basic accessor methods running as resolvers. I also have a concern with just passing through a struct to fetch the fields from. For example, if I want to implement a permissions model which should be used to determine if a client can read a particular field having a method here is key. So I propose that we have "opt in" accessor methods.
For example:
The following would be an accessor:
func (u *UserResolver) FirstName() *string {
	return &u.User.FirstName
}

While the following operates as a resolver:
func (u *UserResolver) FirstName() (*string, error) {
	return &u.User.FirstName, nil
}

Note returning an error.
This allows me to do something like:
func (u *UserResolver) FirstName() *string {
	if u.currentUser.hasPermissions("read_first_name") {
		return &u.User.FirstName
	}
	return nil
}

Without having to worry about the number of resolvers running in parallel.
I'm also open to different method signatures, but I'd prefer to not do away with accessor methods in favour of just using struct fields. Not sure if this is entierly possible since I haven't dug too deep into the library.

It would be nice if you could define multiple field resolvers together to make it easier to keep track of the fields defined for your resolver
// graphql.FieldMap  = map[string]string

s.ResolveFields("Droid", graphql.FieldMap{
  "id": "ID",
  "name": "Name",
  "appearsIn": "AppearsIn",
  "primaryFunction": "PrimaryFunction",
})

or use struct tags
type droid struct {
	ID              graphql.ID   `gql:"id"`
	Name            string       `gql:"name"`
	Friends         []graphql.ID
	AppearsIn       []string     `gql:"appersIn"`
	PrimaryFunction string       `gql:"primaryFunction"`
}

If the struct tag route is up for discussion it wold be nice to just reuse json tags too if possible
Thanks for all the great work!

Hey I just came upon this issue. I have mobile apps deployed in the production.
we had to change the name of the field for an update. now previous users are going to face the crash due to this change.
they are going to call the account_id and now the field is changed to account_sso_id.
"sso_id": &graphql.Field{ 				Type: graphql.String, 			},


Unable to run 'tfx extension create' as part of an automated build

I have been able to successfully create and package powershell extension manually. Since the extension will be used in our on-prem production system, I need to create a CI build initially to build, package and copy the extension to a shared network folder. The problem I am running into is when I try to package the extension from the build using a commandline task regardless of how I setup the task it cannot execute tfx. and get the error:  'tfx' is not recognized as an internal or external command, operable program or batch file.
I can log into my build server using the same account and run the command successfully, although I am running into issue #164 and have to change the path accordingly.
How should a build task be set up to execute the tfx extension create command?
When is #164 going to be fixed?

Hey,
I had this issue as well so I worked around with some PowerShell, another reason I done this was because I couldn't see the output in the logs of the build rig
#Ensure tfx-cli is installed and updated
npm install -g tfx-cli

#Get the path to your global npm install directory and find the tfx client under that
$path = npm prefix -g
$tfxCli = Join-Path $path "node_modules\tfx-cli\_build\tfx-cli.js"

#Call node directly and pass in args
 Invoke-Expression -Command "node $tfxCli extension publish"

Thanks

I do npm install tfx-cli  (without the g) and then tfx works, but only from inside an npm script:
excerpt from package.json:
"scripts": {
"installTfx": "npm install tfx-cli@latest"
"tfxExtensionCreate": "tfx extension create"
}
npm run installTfx
npm run tfxExtensionCreate


loss is inf

why is it that my loss is always like below:
| [806/1000][400/410] Loss: inf
0|train    | [807/1000][100/410] Loss: inf
0|train    | [807/1000][200/410] Loss: inf
0|train    | [807/1000][300/410] Loss: inf
0|train    | [807/1000][400/410] Loss: inf
0|train    | [808/1000][100/410] Loss: inf
0|train    | [808/1000][200/410] Loss: inf
0|train    | [808/1000][300/410] Loss: inf
0|train    | [808/1000][400/410] Loss: inf
0|train    | [809/1000][100/410] Loss: inf
0|train    | [809/1000][200/410] Loss: inf
0|train    | [809/1000][300/410] Loss: inf
0|train    | [809/1000][400/410] Loss: inf
0|train    | [810/1000][100/410] Loss: inf
0|train    | [810/1000][200/410] Loss: inf

i was able to rectify the issue, incase the length of train samples is over 26 i was getting the above issue.
I
Its reached till 1000, but has not saved any model in expr, do you by chance know the reason?

I havent changed anythin in params.py, But i still dont understand the reason :
heres snipped of my params.py
cuda = True # enables cuda
multi_gpu = False # whether to use multi gpu
ngpu = 1 # number of GPUs to use. Do remember to set multi_gpu to True!
workers = 0 # number of data loading workers
training process
displayInterval = 100 # interval to be print the train loss
valInterval = 1000 # interval to val the model loss and accuray
saveInterval = 1000 # interval to save model
n_test_disp = 10 # number of samples to display when val the model

Hi, sorry to reply now. You can check the code
            # do checkpointing
            if i % params.saveInterval == 0:
                torch.save(crnn.state_dict(), '{0}/netCRNN_{1}_{2}.pth'.format(params.expr_dir, epoch, i))

and i < len(train_loader) and len(train_loader) is related to batch_size
Of course, we need't make it so difficult, just change the params.saveInterval to smaller is OK.

Thank you. its working now anyways. you've been a great help.

Hi, please try the latest code, and i think i have fixed it, thank you~~~


Updated resource usage for Openshift templates

This pull request includes the changes for resource usage in Openshift templates.


Set DMatrix feature_names when passing in a dask dataframe

Trying to pass in dask dataframes/series into dask-ml GridSearchCV using XGBClassifier as an estimator results in data validation errors pre-train because:

xgboost will convert dask dataframe into a numpy array when initializing DMatrix which will strip feature names: here
dask-ml only converts train data directly into pandas series/dataframe and leaves any extra parameters passed through fit_params untouched. here

Being able to pass in eval_set as a dataframe is useful because it can stop bad configs early and passing in as a dataframe is useful to implement weighted sample scoring without metadata routing being supported with dask-ml.
This is only one use case, I imagine most dask-ml objects pass extra fit_params directly as is and could lead to some other non-intuitive behaviour. Not sure if this is a problem that should be addressed there instead though.
import xgboost as xgb
from dask.distributed import LocalCluster
import dask.dataframe as dd
import pandas as pd
from dask_ml.model_selection import RandomizedSearchCV as dRandomizedSearchCV

def get_data():
    X = pd.DataFrame.from_dict({
        "A": [1, 2, 3] * 100,
        "B": [4, 5, 6] * 100,
    })
    y = pd.Series([1, 0, 1] * 100)
    return X, y

def no_features():

        X, y = get_data()

        dmatrix = xgb.DMatrix(X, y)
        print(dmatrix.feature_names) # ["A", "B"]

        X = dd.from_pandas(X, npartitions = 1)
        y = dd.from_pandas(y, npartitions = 1)

        dmatrix = xgb.DMatrix(X, y)
        print(dmatrix.feature_names) #None

def distributed_grid_search_fail():
    model = xgb.XGBClassifier()
    param_grid = {
            'max_depth': [8, 9],
            'learning_rate': [.05, .1, 0.2,],
            'subsample': [0.7, 0.8, 0.9, 1.0],
            'colsample_bytree': [0.7, 0.8, 0.9, 1.0],
            'colsample_bylevel': [0.3, 0.6, 0.7, 0.8, 0.9, 1.0],
            'min_child_weight': [0.5, 1.0, 3.0, 5.0, 7.0, 10.0],
            'gamma': [0, 0.25, 0.5, 1.0],
            'reg_lambda': [1.0, 5.0, 10.0, 50.0, 100.0],
            'n_estimators': [1]
    }

    grid = dRandomizedSearchCV(
        estimator = model,
        param_distributions = param_grid,
        cv = 2,
        n_iter = 1

    )

    X, y = get_data()
    X = dd.from_pandas(X, npartitions = 1)
    y = dd.from_pandas(y, npartitions = 1)

    grid.fit(
        X,
        y,
        eval_set = [(X, y)]
    )

if __name__ == "__main__":
    with LocalCluster(n_workers = 1):
        no_features()
        distributed_grid_search_fail()

ValueError: training data did not have the following fields: A, B

Environment
xgboost==2.0.3
dask-ml==2023.3.24
scikit-learn==1.4.0

I think the meta routine will be the future once it's mature enough to be adopted in downstream projects. I looked into it, but haven't been able to support it in XGB as the feature is still in flux and most of the mechanics are private to sklearn

In the meantime for anyone that needs to do this, disabling feature validation temporarily should work.
#Patch validation method in core
from xgboost import Booster
Booster._validate_features = lambda _ : None