Aliases don't work correctly

Hello, when using the cosmo router aliases lead to "unable to resolve" error.
This query works
query MyQuery {
  __typename
}

This one doesn't
query MyQuery {
  alias: __typename
}

{
  "errors": [
    {
      "message": "could not resolve response"
    }
  ]
}

This is the error from logs:
{"level":"error","time":1695131151680,"caller":"core/graphql_handler.go:160","msg":"unable to resolve GraphQL response","hostname":"<<HOSTNAME>>","pid":1,"component":"@wundergraph/router","reqId":"<<HOSTNAME>>/FXBPUpQ8mo-000058","error":"Key path not found","errorVerbose":"Key path not found\ngithub.com/wundergraph/graphql-go-tools/v2/pkg/engine/resolve.(*Loader).loadAndPostProcess\n\tgithub.com/wundergraph/graphql-go-tools/v2@v2.0.0-rc.2.0.20230912132139-7fac6d9abf64/pkg/engine/resolve/load.go:731\ngithub.com/wundergraph/graphql-go-tools/v2/pkg/engine/resolve.(*Loader).resolveSingleFetch\n\tgithub.com/wundergraph/graphql-go-tools/v2@v2.0.0-rc.2.0.20230912132139-7fac6d9abf64/pkg/engine/resolve/load.go:676\ngithub.com/wundergraph/graphql-go-tools/v2/pkg/engine/resolve.(*Loader).resolveFetch\n\tgithub.com/wundergraph/graphql-go-tools/v2@v2.0.0-rc.2.0.20230912132139-7fac6d9abf64/pkg/engine/resolve/load.go:431\ngithub.com/wundergraph/graphql-go-tools/v2/pkg/engine/resolve.(*Loader).resolveObject\n\tgithub.com/wundergraph/graphql-go-tools/v2@v2.0.0-rc.2.0.20230912132139-7fac6d9abf64/pkg/engine/resolve/load.go:274\ngithub.com/wundergraph/graphql-go-tools/v2/pkg/engine/resolve.(*Loader).resolveNode\n\tgithub.com/wundergraph/graphql-go-tools/v2@v2.0.0-rc.2.0.20230912132139-7fac6d9abf64/pkg/engine/resolve/load.go:140\ngithub.com/wundergraph/graphql-go-tools/v2/pkg/engine/resolve.(*Loader).LoadGraphQLResponseData\n\tgithub.com/wundergraph/graphql-go-tools/v2@v2.0.0-rc.2.0.20230912132139-7fac6d9abf64/pkg/engine/resolve/load.go:123\ngithub.com/wundergraph/graphql-go-tools/v2/pkg/engine/resolve.(*Resolver).ResolveGraphQLResponse\n\tgithub.com/wundergraph/graphql-go-tools/v2@v2.0.0-rc.2.0.20230912132139-7fac6d9abf64/pkg/engine/resolve/resolve.go:132\ngithub.com/wundergraph/cosmo/router/core.(*GraphQLHandler).ServeHTTP\n\tgithub.com/wundergraph/cosmo/router@v0.0.0-20230914195341-bee77cc829c6/core/graphql_handler.go:152\nnet/http.HandlerFunc.ServeHTTP\n\tnet/http/server.go:2136\ngithub.com/go-chi/chi.(*Mux).routeHTTP\n\tgithub.com/go-chi/chi@v1.5.4/mux.go:436\nnet/http.HandlerFunc.ServeHTTP\n\tnet/http/server.go:2136\nataccama.com/cosmo-router/src/module.MyModule.Middleware\n\tataccama.com/cosmo-router/src/module/module.go:91\ngithub.com/wundergraph/cosmo/router/core.(*Router).initModules.func1.1\n\tgithub.com/wundergraph/cosmo/router@v0.0.0-20230914195341-bee77cc829c6/core/router.go:291\nnet/http.HandlerFunc.ServeHTTP\n\tnet/http/server.go:2136\ngithub.com/wundergraph/cosmo/router/core.(*Router).newServer.func3.1.1\n\tgithub.com/wundergraph/cosmo/router@v0.0.0-20230914195341-bee77cc829c6/core/router.go:570\nnet/http.HandlerFunc.ServeHTTP\n\tnet/http/server.go:2136\ngithub.com/wundergraph/cosmo/router/internal/metric.(*Handler).Handler-fm.(*Handler).Handler.func1\n\tgithub.com/wundergraph/cosmo/router@v0.0.0-20230914195341-bee77cc829c6/internal/metric/handler.go:117\nnet/http.HandlerFunc.ServeHTTP\n\tnet/http/server.go:2136\ngithub.com/wundergraph/cosmo/router/core.(*PreHandler).Handler-fm.(*PreHandler).Handler.func1\n\tgithub.com/wundergraph/cosmo/router@v0.0.0-20230914195341-bee77cc829c6/core/graphql_prehandler.go:184\nnet/http.HandlerFunc.ServeHTTP\n\tnet/http/server.go:2136\ngithub.com/wundergraph/cosmo/router/internal/trace.(*Middleware).Handler.func1\n\tgithub.com/wundergraph/cosmo/router@v0.0.0-20230914195341-bee77cc829c6/internal/trace/middleware.go:43\nnet/http.HandlerFunc.ServeHTTP\n\tnet/http/server.go:2136\ngo.opentelemetry.io/contrib/instrumentation/net/http/otelhttp.(*middleware).serveHTTP\n\tgo.opentelemetry.io/contrib/instrumentation/net/http/otelhttp@v0.43.0/handler.go:217\ngo.opentelemetry.io/contrib/instrumentation/net/http/otelhttp.NewMiddleware.func1.1\n\tgo.opentelemetry.io/contrib/instrumentation/net/http/otelhttp@v0.43.0/handler.go:81\nnet/http.HandlerFunc.ServeHTTP\n\tnet/http/server.go:2136\ngithub.com/go-chi/chi.(*Mux).ServeHTTP\n\tgithub.com/go-chi/chi@v1.5.4/mux.go:70\ngithub.com/go-chi/chi.(*Mux).Mount.func1\n\tgithub.com/go-chi/chi@v1.5.4/mux.go:311\nnet/http.HandlerFunc.ServeHTTP\n\tnet/http/server.go:2136\ngithub.com/go-chi/chi.(*Mux).routeHTTP\n\tgithub.com/go-chi/chi@v1.5.4/mux.go:436\nnet/http.HandlerFunc.ServeHTTP\n\tnet/http/server.go:2136\ngithub.com/wundergraph/cosmo/router/internal/handler/cors.(*cors).ServeHTTP\n\tgithub.com/wundergraph/cosmo/router@v0.0.0-20230914195341-bee77cc829c6/internal/handler/cors/config.go:74\ngithub.com/wundergraph/cosmo/router/internal/handler/requestlogger.(*handler).ServeHTTP\n\tgithub.com/wundergraph/cosmo/router@v0.0.0-20230914195341-bee77cc829c6/internal/handler/requestlogger/requestlogger.go:68\ngithub.com/wundergraph/graphql-go-tools/v2/pkg/engine/resolve.(*Loader).resolveSingleFetch\n\tgithub.com/wundergraph/graphql-go-tools/v2@v2.0.0-rc.2.0.20230912132139-7fac6d9abf64/pkg/engine/resolve/load.go:678\ngithub.com/wundergraph/graphql-go-tools/v2/pkg/engine/resolve.(*Loader).resolveFetch\n\tgithub.com/wundergraph/graphql-go-tools/v2@v2.0.0-rc.2.0.20230912132139-7fac6d9abf64/pkg/engine/resolve/load.go:431\ngithub.com/wundergraph/graphql-go-tools/v2/pkg/engine/resolve.(*Loader).resolveObject\n\tgithub.com/wundergraph/graphql-go-tools/v2@v2.0.0-rc.2.0.20230912132139-7fac6d9abf64/pkg/engine/resolve/load.go:274\ngithub.com/wundergraph/graphql-go-tools/v2/pkg/engine/resolve.(*Loader).resolveNode\n\tgithub.com/wundergraph/graphql-go-tools/v2@v2.0.0-rc.2.0.20230912132139-7fac6d9abf64/pkg/engine/resolve/load.go:140\ngithub.com/wundergraph/graphql-go-tools/v2/pkg/engine/resolve.(*Loader).LoadGraphQLResponseData\n\tgithub.com/wundergraph/graphql-go-tools/v2@v2.0.0-rc.2.0.20230912132139-7fac6d9abf64/pkg/engine/resolve/load.go:123\ngithub.com/wundergraph/graphql-go-tools/v2/pkg/engine/resolve.(*Resolver).ResolveGraphQLResponse\n\tgithub.com/wundergraph/graphql-go-tools/v2@v2.0.0-rc.2.0.20230912132139-7fac6d9abf64/pkg/engine/resolve/resolve.go:132\ngithub.com/wundergraph/cosmo/router/core.(*GraphQLHandler).ServeHTTP\n\tgithub.com/wundergraph/cosmo/router@v0.0.0-20230914195341-bee77cc829c6/core/graphql_handler.go:152\nnet/http.HandlerFunc.ServeHTTP\n\tnet/http/server.go:2136\ngithub.com/go-chi/chi.(*Mux).routeHTTP\n\tgithub.com/go-chi/chi@v1.5.4/mux.go:436\nnet/http.HandlerFunc.ServeHTTP\n\tnet/http/server.go:2136\nataccama.com/cosmo-router/src/module.MyModule.Middleware\n\tataccama.com/cosmo-router/src/module/module.go:91\ngithub.com/wundergraph/cosmo/router/core.(*Router).initModules.func1.1\n\tgithub.com/wundergraph/cosmo/router@v0.0.0-20230914195341-bee77cc829c6/core/router.go:291\nnet/http.HandlerFunc.ServeHTTP\n\tnet/http/server.go:2136\ngithub.com/wundergraph/cosmo/router/core.(*Router).newServer.func3.1.1\n\tgithub.com/wundergraph/cosmo/router@v0.0.0-20230914195341-bee77cc829c6/core/router.go:570\nnet/http.HandlerFunc.ServeHTTP\n\tnet/http/server.go:2136\ngithub.com/wundergraph/cosmo/router/internal/metric.(*Handler).Handler-fm.(*Handler).Handler.func1\n\tgithub.com/wundergraph/cosmo/router@v0.0.0-20230914195341-bee77cc829c6/internal/metric/handler.go:117\nnet/http.HandlerFunc.ServeHTTP\n\tnet/http/server.go:2136\ngithub.com/wundergraph/cosmo/router/core.(*PreHandler).Handler-fm.(*PreHandler).Handler.func1\n\tgithub.com/wundergraph/cosmo/router@v0.0.0-20230914195341-bee77cc829c6/core/graphql_prehandler.go:184\nnet/http.HandlerFunc.ServeHTTP\n\tnet/http/server.go:2136\ngithub.com/wundergraph/cosmo/router/internal/trace.(*Middleware).Handler.func1\n\tgithub.com/wundergraph/cosmo/router@v0.0.0-20230914195341-bee77cc829c6/internal/trace/middleware.go:43\nnet/http.HandlerFunc.ServeHTTP\n\tnet/http/server.go:2136\ngo.opentelemetry.io/contrib/instrumentation/net/http/otelhttp.(*middleware).serveHTTP\n\tgo.opentelemetry.io/contrib/instrumentation/net/http/otelhttp@v0.43.0/handler.go:217\ngo.opentelemetry.io/contrib/instrumentation/net/http/otelhttp.NewMiddleware.func1.1\n\tgo.opentelemetry.io/contrib/instrumentation/net/http/otelhttp@v0.43.0/handler.go:81\nnet/http.HandlerFunc.ServeHTTP\n\tnet/http/server.go:2136\ngithub.com/go-chi/chi.(*Mux).ServeHTTP\n\tgithub.com/go-chi/chi@v1.5.4/mux.go:70\ngithub.com/go-chi/chi.(*Mux).Mount.func1\n\tgithub.com/go-chi/chi@v1.5.4/mux.go:311\nnet/http.HandlerFunc.ServeHTTP\n\tnet/http/server.go:2136\ngithub.com/go-chi/chi.(*Mux).routeHTTP\n\tgithub.com/go-chi/chi@v1.5.4/mux.go:436\nnet/http.HandlerFunc.ServeHTTP\n\tnet/http/server.go:2136\ngithub.com/wundergraph/cosmo/router/internal/handler/cors.(*cors).ServeHTTP\n\tgithub.com/wundergraph/cosmo/router@v0.0.0-20230914195341-bee77cc829c6/internal/handler/cors/config.go:74\ngithub.com/wundergraph/cosmo/router/internal/handler/requestlogger.(*handler).ServeHTTP\n\tgithub.com/wundergraph/cosmo/router@v0.0.0-20230914195341-bee77cc829c6/internal/handler/requestlogger/requestlogger.go:68\ngithub.com/go-chi/chi/middleware.RealIP.func1\n\tgithub.com/go-chi/chi@v1.5.4/middleware/realip.go:34\ngithub.com/wundergraph/graphql-go-tools/v2/pkg/engine/resolve.(*Loader).resolveObject\n\tgithub.com/wundergraph/graphql-go-tools/v2@v2.0.0-rc.2.0.20230912132139-7fac6d9abf64/pkg/engine/resolve/load.go:276\ngithub.com/wundergraph/graphql-go-tools/v2/pkg/engine/resolve.(*Loader).resolveNode\n\tgithub.com/wundergraph/graphql-go-tools/v2@v2.0.0-rc.2.0.20230912132139-7fac6d9abf64/pkg/engine/resolve/load.go:140\ngithub.com/wundergraph/graphql-go-tools/v2/pkg/engine/resolve.(*Loader).LoadGraphQLResponseData\n\tgithub.com/wundergraph/graphql-go-tools/v2@v2.0.0-rc.2.0.20230912132139-7fac6d9abf64/pkg/engine/resolve/load.go:123\ngithub.com/wundergraph/graphql-go-tools/v2/pkg/engine/resolve.(*Resolver).ResolveGraphQLResponse\n\tgithub.com/wundergraph/graphql-go-tools/v2@v2.0.0-rc.2.0.20230912132139-7fac6d9abf64/pkg/engine/resolve/resolve.go:132\ngithub.com/wundergraph/cosmo/router/core.(*GraphQLHandler).ServeHTTP\n\tgithub.com/wundergraph/cosmo/router@v0.0.0-20230914195341-bee77cc829c6/core/graphql_handler.go:152\nnet/http.HandlerFunc.ServeHTTP\n\tnet/http/server.go:2136\ngithub.com/go-chi/chi.(*Mux).routeHTTP\n\tgithub.com/go-chi/chi@v1.5.4/mux.go:436\nnet/http.HandlerFunc.ServeHTTP\n\tnet/http/server.go:2136\nataccama.com/cosmo-router/src/module.MyModule.Middleware\n\tataccama.com/cosmo-router/src/module/module.go:91\ngithub.com/wundergraph/cosmo/router/core.(*Router).initModules.func1.1\n\tgithub.com/wundergraph/cosmo/router@v0.0.0-20230914195341-bee77cc829c6/core/router.go:291\nnet/http.HandlerFunc.ServeHTTP\n\tnet/http/server.go:2136\ngithub.com/wundergraph/cosmo/router/core.(*Router).newServer.func3.1.1\n\tgithub.com/wundergraph/cosmo/router@v0.0.0-20230914195341-bee77cc829c6/core/router.go:570\nnet/http.HandlerFunc.ServeHTTP\n\tnet/http/server.go:2136\ngithub.com/wundergraph/cosmo/router/internal/metric.(*Handler).Handler-fm.(*Handler).Handler.func1\n\tgithub.com/wundergraph/cosmo/router@v0.0.0-20230914195341-bee77cc829c6/internal/metric/handler.go:117\nnet/http.HandlerFunc.ServeHTTP\n\tnet/http/server.go:2136\ngithub.com/wundergraph/cosmo/router/core.(*PreHandler).Handler-fm.(*PreHandler).Handler.func1\n\tgithub.com/wundergraph/cosmo/router@v0.0.0-20230914195341-bee77cc829c6/core/graphql_prehandler.go:184\nnet/http.HandlerFunc.ServeHTTP\n\tnet/http/server.go:2136\ngithub.com/wundergraph/cosmo/router/internal/trace.(*Middleware).Handler.func1\n\tgithub.com/wundergraph/cosmo/router@v0.0.0-20230914195341-bee77cc829c6/internal/trace/middleware.go:43\nnet/http.HandlerFunc.ServeHTTP\n\tnet/http/server.go:2136\ngo.opentelemetry.io/contrib/instrumentation/net/http/otelhttp.(*middleware).serveHTTP\n\tgo.opentelemetry.io/contrib/instrumentation/net/http/otelhttp@v0.43.0/handler.go:217\ngo.opentelemetry.io/contrib/instrumentation/net/http/otelhttp.NewMiddleware.func1.1\n\tgo.opentelemetry.io/contrib/instrumentation/net/http/otelhttp@v0.43.0/handler.go:81\nnet/http.HandlerFunc.ServeHTTP\n\tnet/http/server.go:2136\ngithub.com/go-chi/chi.(*Mux).ServeHTTP\n\tgithub.com/go-chi/chi@v1.5.4/mux.go:70\ngithub.com/go-chi/chi.(*Mux).Mount.func1\n\tgithub.com/go-chi/chi@v1.5.4/mux.go:311\nnet/http.HandlerFunc.ServeHTTP\n\tnet/http/server.go:2136\ngithub.com/go-chi/chi.(*Mux).routeHTTP\n\tgithub.com/go-chi/chi@v1.5.4/mux.go:436\nnet/http.HandlerFunc.ServeHTTP\n\tnet/http/server.go:2136\ngithub.com/wundergraph/cosmo/router/internal/handler/cors.(*cors).ServeHTTP\n\tgithub.com/wundergraph/cosmo/router@v0.0.0-20230914195341-bee77cc829c6/internal/handler/cors/config.go:74\ngithub.com/wundergraph/cosmo/router/internal/handler/requestlogger.(*handler).ServeHTTP\n\tgithub.com/wundergraph/cosmo/router@v0.0.0-20230914195341-bee77cc829c6/internal/handler/requestlogger/requestlogger.go:68\ngithub.com/go-chi/chi/middleware.RealIP.func1\n\tgithub.com/go-chi/chi@v1.5.4/middleware/realip.go:34\nnet/http.HandlerFunc.ServeHTTP\n\tnet/http/server.go:2136\ngithub.com/go-chi/chi/middleware.RequestID.func1\n\tgithub.com/go-chi/chi@v1.5.4/middleware/request_id.go:76","stacktrace":"github.com/wundergraph/cosmo/router/core.(*GraphQLHandler).ServeHTTP\n\tgithub.com/wundergraph/cosmo/router@v0.0.0-20230914195341-bee77cc829c6/core/graphql_handler.go:160\nnet/http.HandlerFunc.ServeHTTP\n\tnet/http/server.go:2136\ngithub.com/go-chi/chi.(*Mux).routeHTTP\n\tgithub.com/go-chi/chi@v1.5.4/mux.go:436\nnet/http.HandlerFunc.ServeHTTP\n\tnet/http/server.go:2136\nataccama.com/cosmo-router/src/module.MyModule.Middleware\n\tataccama.com/cosmo-router/src/module/module.go:91\ngithub.com/wundergraph/cosmo/router/core.(*Router).initModules.func1.1\n\tgithub.com/wundergraph/cosmo/router@v0.0.0-20230914195341-bee77cc829c6/core/router.go:291\nnet/http.HandlerFunc.ServeHTTP\n\tnet/http/server.go:2136\ngithub.com/wundergraph/cosmo/router/core.(*Router).newServer.func3.1.1\n\tgithub.com/wundergraph/cosmo/router@v0.0.0-20230914195341-bee77cc829c6/core/router.go:570\nnet/http.HandlerFunc.ServeHTTP\n\tnet/http/server.go:2136\ngithub.com/wundergraph/cosmo/router/internal/metric.(*Handler).Handler-fm.(*Handler).Handler.func1\n\tgithub.com/wundergraph/cosmo/router@v0.0.0-20230914195341-bee77cc829c6/internal/metric/handler.go:117\nnet/http.HandlerFunc.ServeHTTP\n\tnet/http/server.go:2136\ngithub.com/wundergraph/cosmo/router/core.(*PreHandler).Handler-fm.(*PreHandler).Handler.func1\n\tgithub.com/wundergraph/cosmo/router@v0.0.0-20230914195341-bee77cc829c6/core/graphql_prehandler.go:184\nnet/http.HandlerFunc.ServeHTTP\n\tnet/http/server.go:2136\ngithub.com/wundergraph/cosmo/router/internal/trace.(*Middleware).Handler.func1\n\tgithub.com/wundergraph/cosmo/router@v0.0.0-20230914195341-bee77cc829c6/internal/trace/middleware.go:43\nnet/http.HandlerFunc.ServeHTTP\n\tnet/http/server.go:2136\ngo.opentelemetry.io/contrib/instrumentation/net/http/otelhttp.(*middleware).serveHTTP\n\tgo.opentelemetry.io/contrib/instrumentation/net/http/otelhttp@v0.43.0/handler.go:217\ngo.opentelemetry.io/contrib/instrumentation/net/http/otelhttp.NewMiddleware.func1.1\n\tgo.opentelemetry.io/contrib/instrumentation/net/http/otelhttp@v0.43.0/handler.go:81\nnet/http.HandlerFunc.ServeHTTP\n\tnet/http/server.go:2136\ngithub.com/go-chi/chi.(*Mux).ServeHTTP\n\tgithub.com/go-chi/chi@v1.5.4/mux.go:70\ngithub.com/go-chi/chi.(*Mux).Mount.func1\n\tgithub.com/go-chi/chi@v1.5.4/mux.go:311\nnet/http.HandlerFunc.ServeHTTP\n\tnet/http/server.go:2136\ngithub.com/go-chi/chi.(*Mux).routeHTTP\n\tgithub.com/go-chi/chi@v1.5.4/mux.go:436\nnet/http.HandlerFunc.ServeHTTP\n\tnet/http/server.go:2136\ngithub.com/wundergraph/cosmo/router/internal/handler/cors.(*cors).ServeHTTP\n\tgithub.com/wundergraph/cosmo/router@v0.0.0-20230914195341-bee77cc829c6/internal/handler/cors/config.go:74\ngithub.com/wundergraph/cosmo/router/internal/handler/requestlogger.(*handler).ServeHTTP\n\tgithub.com/wundergraph/cosmo/router@v0.0.0-20230914195341-bee77cc829c6/internal/handler/requestlogger/requestlogger.go:68\ngithub.com/go-chi/chi/middleware.RealIP.func1\n\tgithub.com/go-chi/chi@v1.5.4/middleware/realip.go:34\nnet/http.HandlerFunc.ServeHTTP\n\tnet/http/server.go:2136\ngithub.com/go-chi/chi/middleware.RequestID.func1\n\tgithub.com/go-chi/chi@v1.5.4/middleware/request_id.go:76\nnet/http.HandlerFunc.ServeHTTP\n\tnet/http/server.go:2136\ngithub.com/wundergraph/cosmo/router/internal/handler/recovery.(*handler).ServeHTTP\n\tgithub.com/wundergraph/cosmo/router@v0.0.0-20230914195341-bee77cc829c6/internal/handler/recovery/recovery.go:103\ngithub.com/go-chi/chi.(*Mux).ServeHTTP\n\tgithub.com/go-chi/chi@v1.5.4/mux.go:87\nnet/http.serverHandler.ServeHTTP\n\tnet/http/server.go:2938\nnet/http.(*conn).serve\n\tnet/http/server.go:2009"}

Please could you update your router to 0.17.1 and try again?

Hi @vasek I am happy to read that it solved your real issue.
Please could you check whether the alias for a __typename fails on any type or whether it's limited to the root type?
Thank you.

Looks like every __typename alias fails for me, not only in the root

Thank you for checking! I'll raise a bug.

Hi @vasek,
Please could you try again with router 0.19.0?

Working great, thanks for the quick fix @devsergiy @Aenimus!


Dataset Viewer issue for zeusfsx/ukrainian-news

Link
https://huggingface.co/datasets/zeusfsx/ukrainian-news
Description
The dataset viewer is not working for dataset zeusfsx/ukrainian-news.
Error details:
Error code:   JobRunnerCrashedError

Hi @OleksandrKorovii,
Do you get to load your dataset locally?
Looking at your loading script, I see that you try to load each JSON file entirely in memory:
with open(path, encoding="utf-8") as f:
    news = json.load(f)

And your JSON files are really huge: one of them is 34.4 GB.
Currently, your dataset can only be loaded in machines with RAM memory larger than 35 GB (approximately). That is the reason why the job runner for the dataset viewer crashed: not enough RAM.
If you would like to support loading your dataset in machines with lower RAM, you should:

either split your JSON files into smaller files, so that each of them can be loaded in memory
or change the format of your data files, from JSON to JSON-lines, so that the data files can be loaded in memory line by line, thus with manageable RAM requirements

@albertvillanova what is the limit of the file?

@OleksandrKorovii, if you prefer to keep the JSON format (instead of JSON-Lines), in order to make your dataset loadable by most of the NLP community members, I would suggest that your JSON files should be around 500 MB each.

@OleksandrKorovii has replaced the data file format from JSON to JSON-Lines and the issue is fixed.


CORS Issues

Hi,
Thanks for this usefull package.
I'm wondering about how I can add the credentials to the fetch request.
This crendentials are needed as we must be logged to have the rights access.
For the time being, I updated directly the code of fileLoader.js :
from
   return fetch(documentURI, { signal: signal })
to
    return fetch(documentURI, { signal: signal, credentials: 'include' })
Is there another solution to solve this issue ?
Thanks in advance

@milinkovitch can you tell me when you were having this cors issues and how did you fixed it.Thanks.

Okay got it :
Worked this way :
Give fileType
fileType: 'docx'
      const urlData = !!path ? [{ uri: path, fileType: 'docx' }] : [];

        <DocViewer
          className="doc-viewer"
          documents={urlData}
          config={{
            header: {
              disableHeader: false,
              disableFileName: false,
              retainURLParams: false,
            },
          }}
          pluginRenderers={DocViewerRenderers}
        />

I have the same problem. I'm using sample pdf file and it gives me CORS error in console and the loader for pdf file keeps loading forever.  Ideally it should display error message - Couldn't load pdf file.
const docs = [     {         uri: "http://www.africau.edu/images/default/sample.pdf",         fileType: "pdf",     }, ];

same

hey @hemanth12321, I am also facing the same issue have you got any answer?

I have the same problem, please help!!!

All you need to do is pass in the fileType and URI, I had the same issue but got it working by passing only these two. I was previously passed the URI only

fileType guys, fileType. It's a must.

import DocViewer, { PDFRenderer } from "react-doc-viewer";

const show = () => {

    const docs = [
        { uri: "https://www.w3.org/WAI/ER/tests/xhtml/testfiles/resources/pdf/dummy.pdf", fileType: "pdf", },
    ];

    return <DocViewer documents={docs} pluginRenderers={[PDFRenderer]} />

}

export default show

use this still cors


test: added switch unit test

希望大佬帮忙看看 switch.spec.ts 中的 TODO，有点懵

changeClass is a async function

希望大佬帮忙看看 switch.spec.ts 中的 TODO，有点懵

The changeState function will trigger its internal changeClass function, which contains a setTimeout of 300. Due to the await , the dispatch('click') will wait for it to finish executing before triggering.


SMF crashing during detach

Smf crashing at deregistration request
When deregistration request is sent smf is crashing ,but deregistration accept is sending back to UE.
Please find below the pcaps of deregistration request and logs of smf
detach.pcapng.gz
SMF logs.txt

The issue didn't follow the issue template.

The issue didn't follow the issue template.


Intellisense stops working in .fsx script (due to issue loading list of assembly references correctly?)

Repro steps

clone https://github.com/smoothdeveloper/fsharp.playground
checkout commit 1aae8afd63cf0fa048a1074a95290484a26eb877
run build.bat (restores all nugets)
open smoothdev.Utils.sln
open smoothdev.Utils\src\smoothdev.Utils.Azure\Script.fsx file in VS
type . and CTRL+SPACE after open Microsoft.Azure

Expected behavior
Autocomplete works
Actual behavior
Autocomplete doesn't work
Known workarounds
I haven't found one
Related information

Windows 7 x64
VS 2015 Update 1
.NET 4.5

The workaround is to add
#r "System.Threading.Tasks"

to your script.

Thanks for this repo.  This is actually a really important bug to fix since the workaround is basically impossible to determine without the fix.

@dsyme thanks, could you describe (if possible) how you figured out that "impossible to determine" fix?
I haven't had chance to look at how this reference / assembly loading from script is all working in F# tooling / FSI, I think first measure would be error reporting with the name of missing reference.
The include scripts are generated by paket and there might be some holes in the logic or missing metadata in nuget packages which lead to that missing System.Threading.Tasks assembly, I'll try to see if there is a bug to report in any of the nuget package to mention that assembly.
In the context of developing that paket feature, we had to put hardcoded workarounds for FSharp.Core (should never load it, even if using the nuget one) and mscorlib (if it is `#r "mscorlib" more than once, FSI complains with an error).
It would be great to throw together few notes (with knowledge of implementation details the visualfsharp team has) about all those concerns related to assembly/reference loading in FSI and tooling.

Is this the one that is due to the Tasks BCL / extension assembly?

@smoothdeveloper I ran
devenv /debugexe devenv.exe

and looked at the exception.  I'd debugged this once before, and we've already added a default reference to the DLL mentioned above. However we hadn't fixed the error reporting in the general case so that people would know that they needed to add this
@isaacabraham Yes, more or less.  I believe the silent error happens with Visual Studio 2015 whenever an F# script references an F# profile 7, 78, 259 or ,NET Standard 1.x component.

@dsyme Thanks. That works! It puzzled me for quite a while! Where's the documentation for #r? I didn't know you can directly reference the assembly name without the .dll or .exe extension name. I don't see it mentioned here

@kflu I think the behaviour is the same as when you give a --reference or what you give in project files, those place can also mention (GAC registered) assemblies just by name.


.Srm save files dont work

title says it all

Additionally, please try removing any spaces/special characters from the file path before dragging it in. That's known to cause issues

changing the name worked, thank you


REST api - Document usage of 'namespace'

document usage of 'namespace'  attribute - which entities is it relevant to, when different namespaces should be used, can all namespaces be extracted to check what exists on the environment, etc.

This is a good place to start https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/design/namespaces.md

@smarterclayton indeed a good place to start, thank you.
I didn't find in that document the following (and there's no place to comment there):

How can someone create a namespace?  Can it be done via REST? Because creating a pod/service on a namespace should imply that a namespace already exists.
Getting a list of all already existing namespaces?
should clients specify namespace as an internal attribute of an entity in addition to specifying it in the url? if yes, it's duplication.
once an entity was set a namespace - is there a way to move it between namespaces?
I am assuming there will be a validation that entities do not communicate cross namespaces? let's say pod belongs to namespace 'default' and service that works with that pod was defined as part of namespace "new_namespace" - that will fail on the service creation?
thank you

A few comments:

There is no process to create a namespace.  If policy allows a user to create a pod in a namespace, then the namespace exists, and is allowed to be used.
This is not supported yet.  There is some discussion on materializing a namespace in etcd to support this, but right now, this is not the case.
The value on the URL is used if not specified in the entity.  If a value in the entity is specified that is different than the URL, an error occurs.  The value in the entity is common to be supplied on update operations.
There is no ability to move across namespaces at this time.
This is how things work today - if there is a space where that is not happening, its a bug, and feel free to open an issue, I will address.  We plan to add network level isolation in the future.

Thanks!
----- Original Message -----
From: "abonas"<EMAIL_ADDRESS>To: "GoogleCloudPlatform/kubernetes"<EMAIL_ADDRESS>Sent: Monday, January 5, 2015 9:04:14 AM
Subject: Re: [kubernetes] REST api - Document usage of 'namespace' (#3173)
@smarterclayton indeed a good place to start, thank you.
I didn't find in that document the following (and there's no place to comment there):

How can someone create a namespace?  Can it be done via REST? Because creating a pod/service on a namespace should imply that a namespace already exists.
Getting a list of all already existing namespaces?
should clients specify namespace as an internal attribute of an entity in addition to specifying it in the url? if yes, it's duplication.
once an entity was set a namespace - is there a way to move it between namespaces?
I am assuming there will be a validation that entities do not communicate cross namespaces? let's say pod belongs to namespace 'default' and service that works with that pod was defined as part of namespace "new_namespace" - that will fail on the service creation?
thank you

Reply to this email directly or view it on GitHub:
https://github.com/GoogleCloudPlatform/kubernetes/issues/3173#issuecomment-68711242

@derekwaynecarr  thank you for clarifications.
Regarding  "There is no process to create a namespace. If policy allows a user to create a pod in a namespace, then the namespace exists, and is allowed to be used." - so it means that the namespace must be created upfront (not from REST api) as part of the policy, is that correct?
Regarding "The value in the entity is common to be supplied on update operations" - if the value of namespace is not supported to be updated, then why it should be part of the entity, especially since the update anyway occurs on the specific namespace in the url?
Is namespace as part of url as described in the doc supported only in v3? I am getting 404 on v1 for:
GET http://localhost:8080/api/v1beta1/ns/default/services

There is no explicit creation of a namespace - a namespace is just used when content is assigned to it.
Regarding "The value in the entity is common to be supplied on update operations", it's more an issue on the client flow.
I hope there is no disagreement that we need the namespace in the resource that is returned from the server.  This is a common need for things like the replication controller that do query operations like the following:

LIST/WATCH replication controllers across all namespaces
For each replication controller X, list pods in X.Namespace  (to do this, the replication controller X needed to have its namespace in the response entity)

Since the object returned has the namespace, it's sensible to think that clients will just mutate that object and PUT it back when making changes, for example, when you update the replication size of a replication controller, you most likely will get the object from the server, change one field, and put it back.  As a result, it will have the namespace on the input request entity.
Regarding "Namespace as part of URL"
It works fine on HEAD now (just confirmed) using Vagrant based env.
If you have a client using v1beta1, it will generate urls of the form http:///api/v1beta1/?namespace=, but the server will accept both formats.  If you have a v1beta3 client, it will generate urls of form http:///api/v1beta3/ns//
You should be able to curl the following:
curl -k -u vagrant:vagrant https://<IP_ADDRESS>/api/v1beta1/ns/default/services
curl -k -u vagrant:vagrant https://<IP_ADDRESS>/api/v1beta1/services?namespace=default
Thanks,
----- Original Message -----
From: "abonas"<EMAIL_ADDRESS>To: "GoogleCloudPlatform/kubernetes"<EMAIL_ADDRESS>Cc: "Derek Carr"<EMAIL_ADDRESS>Sent: Monday, January 5, 2015 9:41:16 AM
Subject: Re: [kubernetes] REST api - Document usage of 'namespace' (#3173)
@derekwaynecarr  thank you for clarifications.
Regarding  "There is no process to create a namespace. If policy allows a user to create a pod in a namespace, then the namespace exists, and is allowed to be used." - so it means that the namespace must be created upfront (not from REST api) as part of the policy, is that correct?
Regarding "The value in the entity is common to be supplied on update operations" - if the value of namespace is not supported to be updated, then why it should be part of the entity, especially since the update anyway occurs on the specific namespace in the url?
Is namespace as part of url as described in the doc supported only in v3? I am getting 404 on v1 for:
GET http://localhost:8080/api/v1beta1/ns/default/services

Reply to this email directly or view it on GitHub:
https://github.com/GoogleCloudPlatform/kubernetes/issues/3173#issuecomment-68715904

@derekwaynecarr  I am using a hack/local setup, not vagrant

The only thing that would differ is the server location, but it should work fine there as well.
----- Original Message -----
From: "abonas"<EMAIL_ADDRESS>To: "GoogleCloudPlatform/kubernetes"<EMAIL_ADDRESS>Cc: "Derek Carr"<EMAIL_ADDRESS>Sent: Monday, January 5, 2015 11:00:47 AM
Subject: Re: [kubernetes] REST api - Document usage of 'namespace' (#3173)
@derekwaynecarr  I am using a hack/local setup, not vagrant

Reply to this email directly or view it on GitHub:
https://github.com/GoogleCloudPlatform/kubernetes/issues/3173#issuecomment-68728319

@derekwaynecarr , if there's no way to list namespaces, how  users are expected to work with urls containing namespaces to get all entities in an environment, or even per namespace without knowing its name? like the use case that you mention - LIST/WATCH replication controllers across all namespaces - I am assuming that at least the LIST is supposed to be a GET operation cross namespaces - how the request should look like?

I am still wrestling with the need to materialize a namespace as an object in our store.  There is an issue where this is being discussed.
I don't think its 100% settled, and I imagine we will ultimately need to support a LIST namespaces API.
Today, you can list across all namespaces for a particular resource type by just doing:
GET /api/v1beta3/
will return pods in namespace a, b, c, etc.
----- Original Message -----
From: "abonas"<EMAIL_ADDRESS>To: "GoogleCloudPlatform/kubernetes"<EMAIL_ADDRESS>Cc: "Derek Carr"<EMAIL_ADDRESS>Sent: Monday, January 5, 2015 2:04:37 PM
Subject: Re: [kubernetes] REST api - Document usage of 'namespace' (#3173)
@derekwaynecarr , if there's no way to list namespaces, how  users are expected to work with urls containing namespaces to get all entities in an environment, or even per namespace without knowing its name? like the use case that you mention - LIST/WATCH replication controllers across all namespaces - I am assuming that at least the LIST is supposed to be a GET operation cross namespaces - how the request should look like?

Reply to this email directly or view it on GitHub:
https://github.com/GoogleCloudPlatform/kubernetes/issues/3173#issuecomment-68757919

@derekwaynecarr I would say that based on the feature description, it does have to be an object resource for those exact 2 reasons at least:
a. putting it as part of url makes it a resource (versus filtering with it as a query parameter). a resource based on REST is usually representing an entity/independent persisted object.
b. the need to be able to list namespaces (or perhaps add/delete too) in order to be able to use it from REST.

To clarify point 5 above.  If you create a pod in namespace "foo" and a service in "bar", that service will not find the pod, even if the labels are a match.  Right?
But that is not an error event, it's just an empty result from a selector.
And further, as far as I know there is not network isolation across namespaces - pods can ping each other if they know the right IPs, and pods can consume services in other namespaces if they know the service IPs (which DNS makes easier).
I think this has to be allowed, though perhaps (in the fullness of time) that can be policy based rather than wide open.

Some of the work Rajat and Mrunal are doing enables namespace based VXLANs with a simple SDN controller on OVS.  In that model, there has to be an admin policy to allow communication across namespaces.  But I think that's orthogonal to this discussion - policy (determined by an admin) is what controls that network segregation.

Could we get a summary of this discussion into the namespaces doc?

Yes.  Working on documentation updates

The namespaces design doc was updated.  please re-open or ask for clarifications to that doc as needed if you still have questions.


Standalone POST endpoint request sometimes throws cryptic errors.

Describe the bug
I was playing around with standalone endpoints that call request.formData() and wanted to recreate the requests in curl to see what happens.
I tested curl -x POST http://localhost:3000/<path> (which i assume provides an empty body to the request), and my yarn dev terminal showed that the request threw Cannot read properties of null (reading 'startsWith').
After a bit more testing, I found out that request.json() also behaves inappropriately (Unexpected end of JSON input).
In my view, the expected behaviour for both of the functions should be to return the default output values (empty FormData and {}, respectively).
Reproduction
I created a small repository from the skeleton, located here: https://github.com/AlexVasiluta/sveltekit-bug-report.
Steps to reproduce:

Start the webserver with yarn dev;
Run ./curl_commands.sh, I redirected curl's outputs and added -s for clarity in the output;
Look at the webserver logs.

Logs
Server output from the reproduction above (after running ./curl_commands.sh):

2:20:27 PM [vite] page reload formdata_output.html
Cannot read properties of null (reading 'startsWith')
TypeError: Cannot read properties of null (reading 'startsWith')
at Request.formData (file:///home/alexv/src/bug-report/node_modules/@sveltejs/kit/dist/install-fetch.js:4832:10)
at post (/home/alexv/src/bug-report/src/routes/formData.js:3:28)
at render_endpoint (file:///home/alexv/src/bug-report/.svelte-kit/runtime/server/index.js:171:25)
at resolve (file:///home/alexv/src/bug-report/.svelte-kit/runtime/server/index.js:3305:17)
at async respond (file:///home/alexv/src/bug-report/.svelte-kit/runtime/server/index.js:3250:20)
at async file:///home/alexv/src/bug-report/node_modules/@sveltejs/kit/dist/chunks/index.js:294:24
2:20:27 PM [vite] page reload json_output.html
Unexpected end of JSON input
SyntaxError: Unexpected end of JSON input
at JSON.parse (<anonymous>)
at Request.json (file:///home/alexv/src/bug-report/node_modules/@sveltejs/kit/dist/install-fetch.js:4868:15)
at async post (/home/alexv/src/bug-report/src/routes/json.js:3:14)
at async render_endpoint (file:///home/alexv/src/bug-report/.svelte-kit/runtime/server/index.js:171:19)
at async resolve (file:///home/alexv/src/bug-report/.svelte-kit/runtime/server/index.js:3305:11)
at async respond (file:///home/alexv/src/bug-report/.svelte-kit/runtime/server/index.js:3250:20)
at async file:///home/alexv/src/bug-report/node_modules/@sveltejs/kit/dist/chunks/index.js:294:24

System Info
System:
OS: Linux 5.17 Fedora Linux 35 (Workstation Edition)
CPU: (12) x64 AMD Ryzen 5 5600X 6-Core Processor
Memory: 7.60 GB / 15.54 GB
Container: Yes
Shell: 5.1.8 - /bin/bash
Binaries:
Node: 17.9.0 - /usr/bin/node
Yarn: 1.22.19 - /usr/bin/yarn
npm: 8.5.5 - /usr/bin/npm
Browsers:
Firefox: 100.0
npmPackages:
@sveltejs/adapter-auto: next => 1.0.0-next.43
@sveltejs/kit: next => 1.0.0-next.335
svelte: ^3.44.0 => 3.48.0

Severity
annoyance
Additional Information
No response

I don't believe this is incorrect behavior. SvelteKit tries to stick as closely as possible to spec behavior where it can -- and in this case, you're receiving a standard Request object. The default behavior for request.json() and request.formData() is not to return {} when there is no body. The default behavior is to throw the errors you're seeing. In the case of JSON, if you set the body to "{}", you'll get {} back, but if you set no body, you're never going to get an empty JSON object -- you're going to get an error. Same for formData, but I'm not sure what an empty formData object looks like as a body.
Try this in your browser console (comment out either await line to see the behavior you want):
const request = new Request('/myEndpoint', {
  method: 'POST'
});

await request.formData();
await request.json();

Here's a repro to show you what's going on.. Run it like a normal SvelteKit app and click the buttons on the root page. It'll show you what's happening in the endpoint.

@tcc-sejohnson is right, this is expected behavior even with the browser's Request and Response object.
It's possible to provide better errors during dev, but the priority on that is likely to be pretty low.


Support median and std aggregates in OmniSci backend

Prototype for stddev was implemented in OmniSci. It covers only a single hash table layout and doesn't support reduction (so, works for tables with a single fragment). Prototype version works for a simple groupby.agg testcase, but it looks we need to spend too much time to make this patch working in all cases.
For now I stop work on direct stddev support in OmniSci and start work on std support on Modin side (to decompose std into simpler aggregates and math ops)

intel-go/modin#58 added support for std in groupby.agg

HDK engine is deprecated and will be removed in a future version.


Enable search using duration

Let us get the results in lrclib.net after entering the duration.
Example

I searched 'Numb'. Got many results.

I want to get the lyrics of the second song with runtime 3:06. I searched for 'Numb 3:06' but got no results

Please let us get results by using runtime
Tip : also include results for 'Numb 3:05' and 'Numb 3:07' when searched for 'Numb 3:06'

As per the API

Note: The provided duration is crucial. LRCLIB will attempt to provide the lyrics only when the duration matches the record in LRCLIB's database, or at least with a difference of ±2 seconds in duration.

So it should probably show any result within ±2 seconds

As per the API

Note: The provided duration is crucial. LRCLIB will attempt to provide the lyrics only when the duration matches the record in LRCLIB's database, or at least with a difference of ±2 seconds in duration.

So it should probably show any result within ±2 seconds

even ±2 seconds will do if it means I'll get the lyrics easily.

Yeah, it's the same thing as what you suggested in the Tip at the end of your original post, just a bit more tolerant and consistent with the LibLRC API.


Support Db2 cdc connector (cp from #450)

Support Db2 cdc connector , cherry pick from #450 .

@ruanhang1993 DB2 unit test is not runned , you can modify file in directory tools/azure-pipelines and tools/ci.

implemented in 3592dcc4ee7bc6891e68dbdf2a02b82d6b098f40


How to disable video recording except prod?

Just a query:
I want to disable the video recording feature on Dev and QA environment. How can we achieve this? Is it there any API to disable while making video call request?

@Balasnest
First I'd like to apologize for the late response getting back to you.
I'm assuming you are talking about your environments, Production, QA and Dev, correct? At the current time, recording is set on a group room when the room is created. So it all depends on how you are creating your rooms.
If you are using the REST API to create rooms, you can provide the RecordParticipantsOnConnect parameter to enable recordings or disable recordings.
If you are creating ad-hoc rooms, that is the room is created when the first participant connects, the default parameter for recording is used. This parameter is set from the Rooms Settings page in the console. If you wanted to have different values for recordings, you could create Twilio sub accounts for each of your environments with the recoding setting as appropriate for that environment. You would then use the sub account info when creating tokens for the different environments. This would ensure that the appropriate sub account and settings are used when connecting to the room.
Being able to stop and start recordings after the room is created is on the product roadmap, but I do not have a timeframe of when that will be available.
Please let me know if you have any further questions regarding this approach.
Ryan

@paynerc Thanks you for addressing this. I am cleared now. It's great to hear new things.


Upgrade libgit2 library

---
Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/27614526-upgrade-libgit2-library?utm_campaign=plugin&utm_content=tracker%2F7081451&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F7081451&utm_medium=issues&utm_source=github).

AFAIK we are running the lastest and greatest libgit2. @vtemian, please reopen if needed.


add marker on click

Is it possible to add marker on click?

A rough example: https://github.com/acteng/inspectorate_tools/blob/00f518b40cbbc79a3244f0b96e6fb0a4793888f0/src/routes/route_check/critical_issues_log/MapEntry.svelte#L20

You can add a click callback to the map yourself
In that handler, update some state with a new position
For each item in that list, create a marker

There might be nicer patterns, but this is a start

Yeah that's probably the best way right now.
See also https://github.com/dimfeld/svelte-maplibre/issues/57. Easiest win here would be to add a global click handler on the MapLibre component, but there are other options for more flexible event handling discussed in there as well.

#161, coming probably later this week, will make this a lot easier

Here's an example that works with the just-released v0.9.2: https://svelte-maplibre.vercel.app/examples/marker_on_click


Using the commandline...
dotnet new --install Microsoft.AspNetCore.SpaTemplates::2.0.7
...seems to complete correctly, but a subsequent invocation of...
dotnet new angular
...generates a project in the same style as when I had V2.0.0 of the template installed.
The distinguishing factor (for me) is the a 2.0.0 project has package.json in the root of the project, and a 2.0.7 project has package.json in the ClientApp directory. (and the 'burger' menu works correctly in a 2.0.7 project)
The reason that I know what the two version of a project should look like is because I did the same upgrade (to V2.0.7 of the template) on my laptop and the effect was immediately noticable.
Am I missing something subtle - have checked versions of Node/NPM/Visual Studio etc. and can't see any differences?

I've just realised one thing that's different - desktop = Windows 7, laptop = Windows 10

Update: As of today, attempts to create a new project - on either my desktop or laptop - result in a V2.0.0 style project. This is very perplexing, as I very clearly have an existing project that uses the V2.0.7 style, so I must have had the update template working at some point. Maybe this is the result of recent VS2017 updates?

It's also possible that you have multiple .NET Core SDK installations, and were generating projects in the context of a different SDK than the one with the newer template installed. In any case, I'm glad it's now all straightened out for you!


Sometimes ceph radosgw fail to start in gate/at

When I enable debug in radosgw, I see below logs. It seems a data corruption ?
2015-04-20 13:37:38.350764 7fcceeffd700  2 RGWDataChangesLog::ChangesRenewThread: start
2015-04-20 13:37:38.351667 7fcd08dcb7c0 20 get_obj_state: rctx=0x7fcd0a7921a0 obj=.rgw.root:default.region state=0x7fcd0a792578 s->prefetch_data=0
2015-04-20 13:37:38.351687 7fcd08dcb7c0 10 cache get: name=.rgw.root+default.region : miss
2015-04-20 13:37:38.353110 7fcd08dcb7c0 -1 failed reading default region info: (6) No such device or address
2015-04-20 13:37:38.353902 7fcd08dcb7c0 -1 Couldn't init storage provider (RADOS)

In general radosgw gets default region info from a file in .rgw.root pool; after getting the name as value from conf file as rgw region. The error generally means that this file couldn't be placed by ceph, in order to ensure what exactly is the error, you need to get the debug logs of the messenger layer as well, ie debug ms=1 (or a higher value) should also be set to be sure what is the file/problem ceph is running into

okay, ill check that. Thanks


Common URI utility methods

This PR adds common utility methods for URIs.
Those methods are based on RFC 3986 with links to the spec.

Uri::isDefaultPort
Uri::isAbsolute
Uri::isNetworkPathReference
Uri::isAbsolutePathReference
Uri::isRelativePathReference
Uri::isSameDocumentReference
Uri::composeComponents
UriNormalizer::normalize
UriNormalizer::isEquivalent
UriResolver::relativize

Putting all the static methods in the Uri class made it too crowded, especially with the constants for the normalizer. So instead new classes UriNormalizer and UriResolver were created to logically group methods. Due to that Uri::resolve and Uri::removeDotSegments have been deprecated and moved to the UriResolver.
I'm pretty proud of the relativize method as it was pretty complex to get right for all edge cases. It is highly tested. A similar method also exists in (java)[https://developer.android.com/reference/java/net/URI.html#relativize(java.net.URI)] but is much less sophisticated as the java solution does not support to travel the hierarchical URI upwards with dot-segments.
Todo

[x] tests for some methods are missing
[x] the phpdoc is already good. but readme.md needs update
[x] optionally add Percent-Encoding Normalization: https://tools.ietf.org/html/rfc3986#section-<IP_ADDRESS>

@mtdowling this is ready. Could you please review?

I'll try to review this as well in the next couple of days. Looks cool though.

@jeremeamia I'd be happy to get your feedback

I looked through this for about a half hour last night. It looks good to me. Nice additions.

Thanks. Can I merge then?

Good work! 🚢

Added explanation for workaround #111 and I also added a normalization for the file default host.


ovh-angular-module-status

Migrate ovh-angular-module-status component
The goals of the migrations is:

Drop the Bower support
Apply ESLint Airbnb rules
Provide clean and concise README file.

We might consider using the share rollup configuration (cf: component-rollup-config)
Requirements
👀 Does the component is still used?

no.

💅 Does the component must be renamed?

no.

🚨 Does the component has a dependency to another pending migration?

no.

⚓ Related pull request

none.

ovh-angular-module-status repository has been archived.


Npm warning when initializing new Roots project<EMAIL_ADDRESS>

When initializing a new project in Roots, the following warning is shown:
$ roots new example-project

npm WARN deprecated<EMAIL_ADDRESS>Jade has been renamed to pug, please install the latest version of pug instead of jade

This warning is caused by Jade being forced to rename itself to Pug :(
I'm running Roots v4.0.1.
$ roots -v
4.0.1

We're going to have to deal with this for now, because pug has only released an alpha breaking version on npm, so the only stable option right now is still jade.
http://registry.npmjs.org/pug
Closing this for now, but we will update the dependency once there's a stable version of pug out!


Have you tried different mask threshold?

In
https://github.com/yikaiw/TokenFusion/blob/6fe364ee6229e2d950dcadd9c011b5a48f45c0ec/semantic_segmentation/models/mix_transformer.py#L120
and in paper, the threshold is set to 0.02, but it seems to be a hyper-parameter of training? Have you tried tune it or where do you borrow from?

It is a hyper-parameter of training. This threshold simply follows the default threshold setting in CEN and I find the result already reaches SOTA.

I am just confused it. We learn a predictor like in DynamicViT by inputting tokens and outputting tokens' mask as indicator to reflect informative or uninformative ones. But it seems no direct supervision to guide learning of predictor and use final nll loss to propogate gradients to predictor module so that no extract meaning about predictor function?

ok. but when you write code of CEN or something ealier, you should investigate the value of activation map and set to 0.02 right?

In CEN (appendix), we investigate the value of threshold and observe that the performance is not sensitive given the threshold around 0.02.

I am just confused it. We learn a predictor like in DynamicViT by inputting tokens and outputting tokens' mask as indicator to reflect informative or uninformative ones. But it seems no direct supervision to guide learning of predictor and use final nll loss to propogate gradients to predictor module so that no extract meaning about predictor function?

Yes, currently there is no direct supervision added to the predictor. It is hoped that when l_1 norm is placed along the gradient path (of the final nll loss), it can find out uninformative tokens during training.

Thanks for your reply. Please help me figure out anothor two questions:

in paper equation5, there is l1 loss for scoring function (also called predictor in code) but no implementation in code, right?
in line 139, you use logsoftmax to get mask , but the output of logsoftmax is negative number, I think they won't be larger than the mask threshold 0.02 forever?https://github.com/yikaiw/TokenFusion/blob/9539baff20420926d8fff7d2b54646b9cd8d7602/semantic_segmentation/models/mix_transformer.py#L125-L140

Oh for first question, I have found that part code.

The mask is not directly obtained by logsoftmax, but uses a softmax function to force the output positive:
https://github.com/yikaiw/TokenFusion/blob/9539baff20420926d8fff7d2b54646b9cd8d7602/semantic_segmentation/models/mix_transformer.py#L361-L366


Feat: Added UI/UX changes to fix issue #36

Description

Fixed routing issue on +6 More measurement button.
Developed the functionality of the +More button

Fixes #36
Type of change

[x] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)

How Has This Been Tested?

[x] Tested in all browsers  Chrome - 114.0.5735.133, Mozilla Firefox 114, Safari 5.1.7

Checklist:

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my code
[x] I have commented on my code, particularly in hard-to-understand areas
[x] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[x] New and existing unit tests pass locally with my changes
[x] Any dependent changes have been merged and published in downstream modules

Screenshots
Before

After

On click '+3 More Measurement Button'

Hello @Malay-dev!
Thank you for submitting this pull request Your pull request will be reviewed by maintainers shortly. Meanwhile make sure you have referenced the respected issue in this pr Your pr will not be merged if it does not have reference to respected issue
please read our Contributing Guidelines https://github.com/UBA-GCOEN/StichHub/blob/main/CONTRIBUTING.md And Code of Conduct https://github.com/UBA-GCOEN/StichHub/blob/main/CODE_OF_CONDUCT.md


"Context already exists" but it does not exist

Description:
Create an API with the context /foo and get the "/foo context already exists" warning but the exact context is not already there. But another API already has /int/foo context.
Reproducing steps:
create and publish an API with the /int/foo context.
Try to create another API with the /foo context.
We also get the "/foo context already exists" warning as follows.

This is not reproduce in latest pack


loss did not decrease

I applied trl to my own dataset, and print the loss at each step（https://github.com/lvwerra/trl/blob/main/trl/trainer/ppo_trainer.py#L682）, and found that the loss is difficult to decrease, even in the first few steps, it is useless to find a significant reduction, which means that the model does not seem to try Convergence, what is the general reason for this? Or can you give some advice? Or which indicator in the trl code can see whether the model is converging? Thank you so much

Hello @Mryangkaitong
Thanks for the issue!
In fact this can depend on a lot of factors, firstly being the "domain gap" between your target dataset and the pre-trained model.
What is the purpose of your dataset and what is the model that you are using? You might need to first pre-train your model on a dataset that is similar to yours.
Also note that in the examples we have used a LR that is adapted to the model that has been pre-trained on imdb. Hence, you might need to play with that parameter a lot (i.e. use higher learning rate). You can also play with the KL penalty coefficient: https://github.com/lvwerra/trl/blob/a05ddbdd836d3217c80a4b3e679ba984bfd4fa24/trl/trainer/ppo_config.py#L84 to give the model more degree of freedom and deviate from its original distribution
Let us know if this helps!

Hi @Mryangkaitong, note that in RL the loss is less an indicator of model convergence than in normal supervised learning. It is more important to look at the distribution of rewards and how they shift throughout training.

Thank you very much for your reply. I have fintune my model first (similar to a chatgpt model), and now I want to use the ppo algorithm to further optimize it. In order to test whether trl is effective, my reward model is very simple, just a rule: For example, when the reply has the special character  (this can be understood as a newline symbol, which means that the response is replied in sections, which is considered good). Specifically reward = response.count("")*2
Another change is here:
https://github.com/lvwerra/trl/blob/main/trl/trainer/ppo_trainer.py#L610
Because my model logits and decoder_input_ids can correspond one-to-one, so my changes here are like this：

I have debugged init_kl_coef (increase or decrease) and lr and other parameters are not working, my configuration is as follows:
 config = PPOConfig( model_name="my_model", learning_rate=5e-5, batch_size=16, ppo_epochs=1, init_kl_coef=0.3, log_with="wandb", remove_unused_columns=False, mini_batch_size=8  )
The current result is：

Now for all prompts, the responses are now exactly the same

I solved it, thanks

@Mryangkaitong I'm facing the same issue. Can you please explain more how did you solve this?


various changes

add documentation to exporteed functions
update semver to latest version 3.2.0
link slots now an int, not *int, -1 is "unspecified"
added another test for link creation with slots

Coverage: 92.244% (+1.3%) from 90.909% when pulling 13d7152f910143a1a3184f4e38bb7ea6b8e37d14 on dev into c701a0fd70215ceb5e52652091dbe6d7400f425d on main.


luci-admin-full: add wifi option

This commit adds option to disable scan for 40mhz channel, permit to tweak beacon interval and other advanced configuration.
Based on this #1699
Signed-off-by: Ansuel Smith<EMAIL_ADDRESS>

ok should be good now @jow-

Merged with further fixes in 39cabc036


cellsketch-add-mask

Hi, super excited to play around with CellSketch!!!
When trying to add the mitochondria mask from your provided dataset, I get this response:
16:33:52 INFO ~ Cellsketch-add-mask is started.
16:33:54 INFO ~ "#ffffff" is not a valid value for "--color".
16:33:54 INFO ~
16:33:54 INFO ~ Example: java en.frauzufall.cellsketch.command.AddMask
16:33:55 INFO ~ Terminates cellsketch-add-mask
And the n5 project file remains unchanged.
Any idea what i am doing wrong? Much appreciated.
Stefan

Hi @redven, thank you for reporting this and sorry for responding so late, I somehow missed the notification for this issue :(
the color has to be provided in a different format (RGBA, i.e. "255:255:0:255") and the default value for `color in the solution didn't match this format - we fixed the issue and actually moved the next versions the solutions to a separate betaseg-solutions catalog - please check out https://github.com/betaseg/cellsketch/blob/main/GUIDE_QUICKSTART.md for updated instructions. Thank you for being an early tester and sorry for the trouble.


Configurable Email Backend

Is your proposal related to a problem?

Our app sends lots of admin emails through internal smtp servers, but our business and customer emails need to egress Sparkpost. Using Sparkpost as an email provider for Wagtail - but not Django - is the easiest way to accomplish this.
Describe the solution you'd like

I'd like a new setting to allow me to set an email backend for Wagtail.
Describe alternatives you've considered

To date, I just monkey patch it:
class UtilsConfig(AppConfig):
    name = 'cms.utils'

    def ready(self):
        # BEGIN monkey patch of Wagtail's send_mail to use WRDSSparkPostEmailBackend
        import wagtail
        from wagtail.admin.mail import send_mail as original_send_mail
        from users.messaging.sparkpost_email import WRDSSparkPostEmailBackend
        def send_mail_wrapper(*args, **kwargs):
            kwargs['connection'] = WRDSSparkPostEmailBackend()
            return original_send_mail(*args, **kwargs)

        # Replace the original send_mail with the wrapper
        wagtail.admin.mail.send_mail = send_mail_wrapper
        # END monkey patch of Wagtail's send_mail to use WRDSSparkPostEmailBackend

Additional context

Really, I think it's as simple as having wagtail.admin.mail.send_mail use the backend connection described in a setting, when set.
Working on this

I'm more than happy to submit a PR, but as the monkey patch works fine, I'll hold off on writing the code until and unless this is accepted.
Thank you core team, all contributors, Torchbox, and all the sponsors, for making this project rock!
Anyone can contribute to this. View our contributing guidelines, add a comment to the issue once you’re ready to start.

Wagtail already has WAGTAILADMIN_NOTIFICATION_FROM_EMAIL which proves that customising the email config for notifications is a reasonable thing to require. And Wagtail wraps the Django behaviour, so I think it is fair to ask Wagtail not to shield Django features from integrators.
Note that Django, allows to specify a custom connection:
https://docs.djangoproject.com/en/5.1/topics/email/#send-mail

connection: The optional email backend to use to send the mail. If unspecified, an instance of the default backend will be used. See the documentation on Email backends for more details.

To make it happen, Wagtail needs to introduce WAGTAILADMIN_NOTIFICATION_CONNECTION, dotted path to some connection.
and if defined, use it. Otherwise use the current get_connection().  This logic would live here: https://github.com/wagtail/wagtail/blob/main/wagtail/admin/mail.py#L97
This is how a integrator could specify a custom connection:
# connection.py
from django.core.mail import get_connection

custom_connection = get_connection(
    backend='django.core.mail.backends.smtp.EmailBackend',  # Specify the backend to use
    host='smtp.example.com',  # SMTP server
    port=587,                 # Port number
    username='your_username', # Your SMTP username
    password='your_password', # Your SMTP password
    use_tls=True,             # Use TLS for secure connection
)

And settings:
# settings.py
WAGTAILADMIN_NOTICICATION_CONNECTION = "path.to.custom_connection"

This change would introduce another Wagtail setting, but it is a justified addition. The feature is lightweight to maintain, relying primarily on core Django functionality, and it provides integrators with a clean, reliable way to customize notification email connections. Without this enhancement, integrators are forced to resort to undesirable workarounds like monkey patching. Enabling this configuration aligns with Wagtail's philosophy of flexibility and integrator support, making it a positive step forward


Split the implementation of backends into wrappers which provide better developer experience, and generic backends which implement the actual logic

As an attempt to reduce the code duplication required to implement backend wrappers, I'd like to propose splitting the backend implementation into two parts:

GenericBackend, which roughly corresponds to today's SttpBackend, with two type parameters: effect & capabilties. That's where the actual logic resides. However, this type shouldn't be used directly
a family of Backend traits, which aim to provide better developer experience, by moving the capability requirements from type parameters to top-level types. That's where you have SyncBackend, WebSocketBackend, etc.

In a way, we are replacing inheritance (between Backend and AbstractBackend) with composition: a Backend now contains an instance of GenericBackend, to which it delegates running the logic. There's also a Backend.wrap method, which allows to modify the contained GenericBackend, retaining the wrapper type.
Some pros & cons:

(+) there's no .send method on Backend, hence the only "correct" way to send a request is using request.send
(+) relatively straightforward to implement a backend wrapper - it should operate on the level of GenericBackends
(-) a bit more difficult to implement a backend wrapper for a specific effect - it needs to be generic
(-) the relation between Backend and GenericBackend might be non-obvious at first
(+) an escape hatch: any request can always be sent using any backend using GenericBackend.send(AbstractRequest), given that the type parameters align. So it is still possible to implement higher-level logic which is polymorphic in effects & capabilities

Note: only the core/jvm module is migrated; others have partial changes (through automatic refactorings), and definitely don't compile. Let me know what you think, and if this looks good, I'll migrate the rest as well.

I'll be on vacation next week so if you'd have any comments, please excuse me for slow responses :)

Another downside of this approach is that there is no subtyping relationship between WebSocketStreamingBackend and WebSocketBackend/StreamingBackend - I don't think it can be added, given our usage of type members.
To be able to use a WebSocketStreamingBackend when e.g. a StreamingBackend is required, would require explicit casting using .asStreamingBackend (I don't think that implicit conversions are a good idea here). Also, we'd need to add additional .send methods to StreamingRequest / WebSocketRequest.

In the end I'm abandoning this idea: the type-inference turned out to be inferior as to the original solution, or we lost the subtyping relationship between the backend types; also, stacking multiple modifications turned out to be impossible to type correctly in Scala 3.


feat!: migrate to capacitor 6

Migrated to capacitor 6 and updated code and dependencies to latest

+1 to support capacitor 6

Close in favor of https://github.com/Cap-go/capacitor-data-storage-sqlite/pull/78


Further prefix updates and corrections

Should now be enough for some noticeable improvement in Biolink adherence.
Will need to refresh the transforms. Should be able to regenerate graph files without performing all transforms from scratch (i.e., can keep the JSON versions).


Login and Logout issues

Logout (auth0.webAuth.clearSession()) Issues:

If the user is signed in, it will logout the user but it will not return to the app. Instead, it will continue on to the login page on the web browser. And once logged in, it will proceed to the account profile page. Basically it is treated as a normal web session and will never exit the browser and return to the app.

If the user is NOT signed in, it will crash and exit the app, without event throwing errors/exceptions.

Login (auth0.webAuth.authorize()) Issues:

If the user is already signed in, it will crash and exit the app, without event throwing errors/exceptions.

Sorry, wrong forum.


[ie/eplus] detect DRM by using Microsoft Edge UA; make regex more robust; Support eplus account login

IMPORTANT: PRs without the template will be CLOSED
Description of your pull request and other information

Hello!
There is some DRM-protected content on this site, so I added some lines to detect it.
Open Streaming test | STREAMING PLUS by Firefox and see the notification.
Meaningless structure of drmEncryptKey :
"drmEncryptKey": {
    "assetId": "####-production-######-####-###-######",
    "userId": "VIP-#####",
    "prestoLicense": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9...."  // JWT RS256
}

Note
For the sample page, "listChannels" is empty and "channels_hls" is accessible; for normal event page, "listChannels" is OK but "channels_hls" is 403. So, please do not try to download the sample DRM video without modifying the regex.
Template

Before submitting a pull request make sure you have:

[x] At least skimmed through contributing guidelines including yt-dlp coding conventions
[x] Searched the bugtracker for similar pull requests
[x] Checked the code with flake8 and ran relevant tests

In order to be accepted and merged into yt-dlp each piece of code must be in public domain or released under Unlicense. Check all of the following options that apply:

[x] I am the original author of this code and I am willing to release it under Unlicense
[ ] I am not the original author of this code but it is in public domain or released under Unlicense (provide reliable evidence)

What is the purpose of your pull request?

[x] Fix or improvement to an extractor (Make sure to add/update tests)
[ ] New extractor (Piracy websites will not be accepted)
[ ] Core bug fix/improvement
[ ] New feature (It is strongly recommended to open an issue first)

LGTM - please test the latest changes and let me know if all is good

I confirm that the latest code works well. I'm able to view restricted content with login credentials.
Thank you everyone. I couldn't complete this extractor without you.


Issues/2972/decouple_mixins

Refs #2972 #1468
First attempt to decouple CheckoutSessionMixin into multiple mixin classes and try to make it more modular.

Is this now ready for review and complete?

Is this now ready for review and complete?

@specialunderwear yep.


fix: utxo tx detection lp

Description

Serialize utxo tx index correctly so we pick up txs and are able to show completed state
Upsert found pending txs in tx history to avoid having forever pending txs in your tx history
Rename address -> pubkey on parsed transactions to better clarify value as either address or xpub for utxos
Make remove liquidity

Pull Request Type

[x] :bug: Bug fix (Non-breaking Change: Fixes an issue)
[ ] :hammer_and_wrench: Chore (Non-breaking Change: Doc updates, pkg upgrades, typos, etc..)
[ ] :nail_care: New Feature (Breaking/Non-breaking Change)

Issue (if applicable)

N/A
Risk

High Risk PRs Require 2 approvals

Low

What protocols, transaction types or contract interactions might be affected by this PR?

Testing

Ensure utxo lp deposit/withdrawals show completed state
Ensure pending txs are updated to confirmed in tx history

broadcast a transaction
wait for pending tx to show up in tx history (keep track of txid)
close app so you don't get a confirmed update via websocket
re-open app after tx has confirmed on chain
tx should update/show confirmed

Engineering

:point_up:
Operations

:point_up:
Screenshots (if applicable)

Moved to draft. I am actually going to update the naming change to only affect chain adapter type and up (leaving unchained type untouched)


force_encoding': can't modify frozen String (RuntimeError)

First off let me say that this is my first time using Ruby and I am posting this here to help other Ruby newbs who may get this error.  I am trying to use RunDeck on Cent OS 7 to manage Windows servers using WinRM.  I created a RunDeck plugin to pass commands through to Windows servers using this Ruby WinRM module. However, when passing the password to WinRM like so:
#!/usr/bin/ruby

require 'winrm'

puts 'starting ruby'

_host_command = ENV['RD_EXEC_COMMAND']
_host_name = ENV['RD_NODE_HOSTNAME']
_host_name = 'server name goes here'
_host_endpoint = "http://#{_host_name}:5985/wsman"
_host_username = ENV['RD_OPTION_USER_NAME']
_host_password = ENV['RD_SECUREOPTION_PASSWORD']

opts = {
  endpoint: _host_endpoint,
  user: _host_username,
  password: _host_password
}
conn = WinRM::Connection.new(opts)
conn.shell(:cmd) do |shell|
  shell.run(_host_command) do |stdout, stderr|
    STDOUT.print stdout
    STDERR.print stderr
  end
end

I receive the following error:
/usr/local/share/gems/gems/rubyntlm-0.6.0/lib/net/ntlm/encode_util.rb:42:in `force_encoding': can't modify frozen String (RuntimeError)
I had to change the password assignment line to the following to get it to work:
_host_password = ENV['RD_SECUREOPTION_PASSWORD'].dup
Hope this helps a future Ruby newb.
Cheers,
Todd

This seems like a library usability issues to me, I wouldn't expect the call to fail just because the string is frozen.

I think I have run into this before. rubyntlm mutates the encoding of the given password. So if you pass it a value from the ENV, then this error gets raised. We probably want to put a dup in rubyntlm to protetc from this.

submitted https://github.com/WinRb/rubyntlm/pull/30 to fix

closed via https://github.com/WinRb/rubyntlm/pull/30


The program isn't sufficiently isolated thus users can access files they probably shouldn't

If a user enters similar to the following they're capable of querying the system for
const std = @import("std");

pub fn main() void {
    std.debug.print("Hello, {}!", .{@embedFile("../../etc/profile")});
}

Along with being root
const std = @import("std");

pub fn main() !void {
    const result = try std.ChildProcess.exec(.{
        .allocator = std.heap.page_allocator,
        .argv = &[_][]const u8{ "sh", "-c", "whoami" },
    });

    std.log.err("{s}", .{result.stdout});
}

The program should probably be isolated using namespaces and under a different user such that it's not possible for it to see anything other than the stdlib files and dependencies.

I think this is a fair argument although I don't know how to stop a user from doing things like this. Just to compare it to another playground site, Go let's you print a similar file.
It's also running as root.
The playground is running in a container which doesn't make it inherently secure but I don't host anything else alongside it. I'm more or less depending on my hosting provider for security.

I would worry more about a Bad Person using wget to replace ~/static/index.html with Bad Things, or apt-get install -y to install a few missing tools and taking the server with a reverse shell followed by setting up more permanent access for Bad Deeds.  The thing already had Perl on it anyway, so they probably wouldn't have to even use apt to get a reverse shell going.
The Go playground looks like it has it's static files bundled into the binary (from server filesystem digging, might be wrong, I don't Go) so it would be a lot harder to do this.  Someone could still do it by building a new binary with Bad Files and uploading it to the server with wget, stomping the good copy.
Long story shorter:  This is a hard thing to fix, people get paid a lot of money to make things like this secure, and I am not one of those people.  A good starting point though would be getting the exec'd process to not be root, that would close up a lot of the more common attack vectors.  Give the new user read-only access to the static files in the filesystem and throw them in a chroot so they can't find other things to play with.  I woucd make sure their PATH is sane as well, but a chroot should take care of that.  Not sure if you can set all that up with Docker, so some is probably outside the scope of this repo.
The test server was missing netcat by the way, I installed it for you while testing the validity of these claims.

I'm not sure what you mean by replacing the HTML content via wget?

I installed it for you while testing the validity of these claims.

Could you elaborate here?


Start and wait for a checkup Job to finish

This PR introduce the logic for actually executing a checkup in a cluster.
With this PR changes the framework will create a batch Job to run the checkup image
and waits for it to finish.
A Job is considered as finished when its status has 'Completed' or 'Failed' condition.

Changes: Addressed code review comments.
Also use context with timeout when waiting for the checkup job to finish.

Changes: Check conditions.status when watching the checkup Job.

Changes: Change the injected Job event condition definition to be explicit on tests, and cover the case that was mentioned at https://github.com/kiagnose/kiagnose/pull/27#discussion_r858336398


logger: Add command line option to escape c-style escape sequences in application logs

Currently, application logs are not sanitized of c-style escape sequences. If any filter logs a message that contains newline characters, the logs will be printed to a new line. This breaks log formats set by the --log-format option, breaking integration with log viewers.
This change adds a command line option to escape c-style escape characters in application logs before they are outputted. Enabling this flag ensures newline characters in logs are ignored, meaning that each call to ENVOY_LOG will result in at most 1 line outputted. This flag works for both Stderr and File loggers.
Risk Level: Low
Testing:

Unit test
Manual verification (see comments in PR)

Docs Changes: Added docs to command line options about new flag and possible use cases
Release Notes: Added release notes about new flag
Fixes #8637

Manual verification of change
Flag off:
./bazel-bin/source/exe/envoy-static -c ./configs/google_com_proxy.v2.yaml

[2019-10-18 16:40:25.658][238439][info][main] [source/server/server.cc:342] admin address: <IP_ADDRESS>:9901
[2019-10-18 16:40:25.660][238439][info][main] [source/server/server.cc:462] runtime: layers:
  - name: base
    static_layer:
      {}
  - name: admin
    admin_layer:
      {}
[2019-10-18 16:40:25.660][238439][info][config] [source/server/configuration_impl.cc:62] loading 0 static secret(s)

Flag on:
./bazel-bin/source/exe/envoy-static -c ./configs/google_com_proxy.v2.yaml --log-format-escape-newlines

[2019-10-18 16:40:54.796][238755][info][main] [source/server/server.cc:342] admin address: <IP_ADDRESS>:9901
[2019-10-18 16:40:54.799][238755][info][main] [source/server/server.cc:462] runtime: layers:\n   - name: base\n     static_layer:\n       {}\n   - name: admin\n     admin_layer:\n       {}
[2019-10-18 16:40:54.800][238755][info][config] [source/server/configuration_impl.cc:62] loading 0 static secret(s)

Note that this newline sanitizer only works for the standard stderr logger. It will have no effect if envoy is configured to log to a file via --log-path.
We can either:

Clarify this behavior in the docs
Try to get this to work with the file loggers. Not sure how much duplicated code or inefficiency this would introduce.

Let me know what's best.

Still need to add unit test
/wait

Rebased on master, had to force push. Sorry if this makes the review harder.

Hi, could anyone help me understand the ASAN failure? I don't understand how my changes could be affected by Runtime.
==================== Test output for //test/common/runtime:runtime_flag_override_test:
source/common/common/logger.cc:72:7: runtime error: load of value 190, which is not a valid value for type 'bool'

Line 72 is:
if (should_escape_) {

Why did you have to force-push? I'm not clear why anyone should need to force-push in git TBH; but I kind of follow a straight and narrow path.
It does indeed make reviews harder usually. It makes it difficult to see previous comment context.

Why did you have to force-push? I'm not clear why anyone should need to force-push in git TBH; but I kind of follow a straight and narrow path.
It does indeed make reviews harder usually. It makes it difficult to see previous comment context.

OK, I see why it makes it harder. Is it recommended to merge master instead of rebase then?
You have to force push after a rebase: https://stackoverflow.com/a/8940299/4402434

yes, I always merge master and only run into problems when I do something ninja like revert a commit.
That made me sad and I had to start a whole to PR :)

Ready for review! Let me know if my replies to the previous comments make sense @htuch @jmarantz

Verified that the logs are still correct:
./bazel-bin/source/exe/envoy-static -c ~/bin/bootstrap.json --log-format '%L%m%d %T.%e %t envoy] [%t][%n]%v' --log-format-escaped --log-path tmp.escaped.log

I1031 17:48:27.460 179320 envoy] [179320][main][source/server/server.cc:278] buffer implementation: new
I1031 17:48:27.471 179320 envoy] [179320][main][source/server/server.cc:344] admin address: <IP_ADDRESS>:8001
I1031 17:48:27.474 179320 envoy] [179320][main][source/server/server.cc:458] runtime: layers:\n  - name: base\n    static_layer:\n      {}\n  - name: admin\n    admin_layer:\n      {}
I1031 17:48:27.474 179320 envoy] [179320][config][source/server/configuration_impl.cc:62] loading 0 static secret(s)

Well it looks like Github is having issues. I pushed my commit to the branch but it is not updating here...

Ready for review
cc @htuch

Has anyone seen writes to stderr stop at some point after this change? I am going to try to revert this in our tree and see if makes it go away.

Ok false alarms, the output is there via docker logs -f  so it's just that our file redirection broke somehow.


How to use jasypt.encryptor.password in Hibernate @TypeDef ?

I am using jasypt-spring-boot and it works great for encypting properties in property files by passing --jasypt.encryptor.password=mysecretpassword.
Is it also possible to use that property in the Hibernate annotation?
I currently have this:
@TypeDef(
        name = "encryptedInteger",
        typeClass = EncryptedIntegerAsStringType.class,
        parameters= {
                @Parameter(name="password", value="mysecretpassword")
        }
)

But that is obviously not very convenient as it hardcodes the password in the code.

Never mind. Just found it myself.
First declare a @Bean in a @Configuration class like this:
    @Value("${jasypt.encryptor.password}")
    private String jasyptPassword;

 @Bean
    public HibernatePBEStringEncryptor hibernateIntegerEncryptor() {
        HibernatePBEStringEncryptor hibernatePBEStringEncryptor = new HibernatePBEStringEncryptor();
        hibernatePBEStringEncryptor.setRegisteredName("hibernateIntegerEncryptor");
        hibernatePBEStringEncryptor.setPassword(jasyptPassword);
        return hibernatePBEStringEncryptor;
    }

Then change the @TypeDef annotation to:
@TypeDef(
        name = "encryptedInteger",
        typeClass = EncryptedIntegerAsStringType.class,
        parameters= {
                @Parameter(name="encryptorRegisteredName", value="hibernateIntegerEncryptor")
        }
)

Then in your entity:
    @Type(type = "encryptedInteger")
    private int x;

Cool, so it allows you to reference the encryptor by name in the TypeDef but, what picks it up from the Spring Context? Just curious, since you are using "setRegisteredName" it seems that there's a registry being kept somewhere.

I have no idea how it works internally. I used the documentation about the hibernate integration on the Jasypt website to come to this.


auro-hyperlink: add new no-exit feature

Alaska Airlines Pull Request
Fixes: #52
Summary:
This PR adds a new feature allowing users to designate a noexit option on the `target="_blank" attribute.
Type of change:
Please delete options that are not relevant.

[x] New capability
[ ] Revision of an existing capability
[ ] Infrastructure change (automation, etc.)
[ ] Other (please elaborate)

Checklist:

[x] My update follows the CONTRIBUTING guidelines of this project
[x] I have performed a self-review of my own update

By submitting this Pull Request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
Pull Requests will be evaluated by their quality of update and whether it is consistent with the goals and values of this project. Any submission is to be considered a conversation between the submitter and the maintainers of this project and may require changes to your submission.
Thank you for your submission!
-- Auro Design System Team

:tada: This PR is included in version 2.4.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Can't change unauthorized project's cloud variables

I used to change projects' cloud variables with the set_cloud_variable function even with projects that were not mine. But now, when I run the script, the scratch cloud variable won't change
Any ideas?

I just found out that Scratch bans Replit's IP so prob it's Scratch's fault. Guess I've to log in using sessionID then

Yes but loggin in with Session ID may not work now because Scratch made some
changes a few days ago :(
It now blocks a request sent from Replit!  Any suggests for Replit alternatives?

Sorry, I don't know any Replit alternatives. Many people are facing the same problem: https://scratch.mit.edu/discuss/topic/612435/
Also, this issue should be closed as it is not the library's error. It's the Scratch's API error which blocks the requests from Replit :(


security/acme-client is creating TXT record twice and reports error

Description
Hi,
The usage of ACME plugin for Let's Encrypt in combination with DNS-01 is causing an wired error when configured to use Cloudflare API token instead of global token.
It seems to me, that the acme plugin tries to create the needed TXT Record twice and gets an API error back.
At the beginning everything looks good:
Dec  9 12:57:56 gw acme.sh[70815]: [Thu Dec  9 12:57:56 CET 2021] Using CA: https://acme-v02.api.letsencrypt.org/directory
Dec  9 12:57:56 gw acme.sh[30490]: [Thu Dec  9 12:57:56 CET 2021] Creating domain key
Dec  9 12:57:56 gw acme.sh[68878]: [Thu Dec  9 12:57:56 CET 2021] The domain key is here: /var/etc/acme-client/home/test.mydomain.de_ecc/test.mydomain.de.key
Dec  9 12:57:56 gw acme.sh[41323]: [Thu Dec  9 12:57:56 CET 2021] Multi domain='DNS:test.mydomain.de,DNS:test.mydomain.de'
Dec  9 12:57:56 gw acme.sh[94874]: [Thu Dec  9 12:57:56 CET 2021] Getting domain auth token for each domain
Dec  9 12:57:58 gw acme.sh[35004]: [Thu Dec  9 12:57:58 CET 2021] Getting webroot for domain='test.mydomain.de'
Dec  9 12:57:58 gw acme.sh[99960]: [Thu Dec  9 12:57:58 CET 2021] Getting webroot for domain='test.mydomain.de'
Dec  9 12:57:58 gw acme.sh[55954]: [Thu Dec  9 12:57:58 CET 2021] Adding txt value: avrolWn5txxxXXXxxN5h-G4fXt5uRe0IixvubaSMENg for domain:  _acme-challenge.test.mydomain.de
Dec  9 12:58:02 gw acme.sh[74048]: [Thu Dec  9 12:58:02 CET 2021] Adding record
Dec  9 12:58:03 gw acme.sh[78341]: [Thu Dec  9 12:58:03 CET 2021] Added, OK
Dec  9 12:58:03 gw acme.sh[54082]: [Thu Dec  9 12:58:03 CET 2021] The txt record is added: Success.

But then the client tries to create the same TXT record again and fails:
Dec  9 12:58:03 gw acme.sh[64649]: [Thu Dec  9 12:58:03 CET 2021] Adding txt value: avrolWn5tmsmRZIHcN5h-G4fXt5uRe0IixvubaSMENg for domain:  _acme-challenge.test.mydomain.de
Dec  9 12:58:07 gw acme.sh[780]: [Thu Dec  9 12:58:07 CET 2021] Adding record
Dec  9 12:58:08 gw acme.sh[96710]: [Thu Dec  9 12:58:08 CET 2021] Add txt record error.
Dec  9 12:58:08 gw acme.sh[91409]: [Thu Dec  9 12:58:08 CET 2021] Error add txt for domain:_acme-challenge.test.mydomain.de
Dec  9 12:58:08 gw acme.sh[59228]: [Thu Dec  9 12:58:08 CET 2021] Please add '--debug' or '--log' to check more details.
Dec  9 12:58:08 gw acme.sh[22418]: [Thu Dec  9 12:58:08 CET 2021] See: https://github.com/acmesh-official/acme.sh/wiki/How-to-debug-acme.sh
Dec  9 12:58:09 gw acme.sh[54647]: [Thu Dec  9 12:58:09 CET 2021] Removing DNS records.
Dec  9 12:58:09 gw acme.sh[26880]: [Thu Dec  9 12:58:09 CET 2021] Removing txt: avrolWn5txxxXXXxxN5h-G4fXt5uRe0IixvubaSMENg for domain: _acme-challenge.test.mydomain.de
Dec  9 12:58:14 gw acme.sh[61771]: [Thu Dec  9 12:58:14 CET 2021] Removed: Success

At this point the veryfication fails and no new certificate will be issued. Anyhow if you try to reissue directly the certificate is going to
be issued.
Dec  9 12:58:20 gw acme.sh[48398]: [Thu Dec  9 12:58:20 CET 2021] Using CA: https://acme-v02.api.letsencrypt.org/directory
Dec  9 12:58:20 gw acme.sh[70521]: [Thu Dec  9 12:58:20 CET 2021] Multi domain='DNS:test.mydomain.de,DNS:test.mydomain.de'
Dec  9 12:58:20 gw acme.sh[1142]: [Thu Dec  9 12:58:20 CET 2021] Getting domain auth token for each domain
Dec  9 12:58:22 gw acme.sh[79052]: [Thu Dec  9 12:58:22 CET 2021] Getting webroot for domain='test.mydomain.de'
Dec  9 12:58:22 gw acme.sh[4763]: [Thu Dec  9 12:58:22 CET 2021] Getting webroot for domain='test.mydomain.de'
Dec  9 12:58:22 gw acme.sh[89189]: [Thu Dec  9 12:58:22 CET 2021] test.mydomain.de is already verified, skip dns-01.
Dec  9 12:58:22 gw acme.sh[49957]: [Thu Dec  9 12:58:22 CET 2021] test.mydomain.de is already verified, skip dns-01.
Dec  9 12:58:22 gw acme.sh[30909]: [Thu Dec  9 12:58:22 CET 2021] Verify finished, start to sign.
Dec  9 12:58:22 gw acme.sh[80187]: [Thu Dec  9 12:58:22 CET 2021] Lets finalize the order.

 Install ACME Plugin
2. Create Cloudflare API Token
2. Configure challenge to use token
4. Create certificate
5. Retry validation
6. Have a look on the logs

**Expected behavior**
Validation should work at the first attempt.

*Version:*
OPNsense 21.7.6-amd64FreeBSD 12.1-RELEASE-p21-HBSDLibreSSL 3.3.5
acme.sh-3.0.1
os-acme-client-3.5

Dec  9 12:58:08 gw acme.sh[96710]: [Thu Dec  9 12:58:08 CET 2021] Add txt record error.

This looks like an issue in acme.sh (or the Cloudflare dnsapi), the ACME client we're using here. I don't think the OPNsense ACME client plugin is doing something wrong here.
So I think this cannot be fixed in the OPNsense plugin. Please report the issue to the upstream acme.sh project:
https://github.com/acmesh-official/acme.sh


Clarify breaking changes and deprecation

Came up in the chat; it's useful to clarify these things to our potential users so they know where they stand with this project.

@mergify rebase

@Mergifyio rebase


React 18 hydrateRoot support

After upgrading to React 18, we're seeing a react console error:

(error text: "ReactDOM.hydrate is no longer supported in React 18. Use hydrateRoot instead. Until you switch to the new API, your app will behave as if it's running React 17.")
When calling singleSpaReact with renderType = hydrate:
import React from "react";
import ReactDOM from "react-dom";
import singleSpaReact from "single-spa-react";
/* truncated for brevity */
singleSpaReact({
    React,
    ReactDOM,
    rootComponent,
    domElementGetter,
    renderType: "hydrate"
});

Will hydrateRoot be supported in PR https://github.com/single-spa/single-spa-react/pull/148? Do you know when that PR will be merged?
P.S. the need for our project is not urgent, just curious to know the timeline for planning purposes.

Will hydrateRoot be supported in PR https://github.com/single-spa/single-spa-react/pull/148?

Yes. You can verify this in the PR code here: https://github.com/single-spa/single-spa-react/pull/148/files#diff-cb30a967d456081f97d512503f30d39a71d3d112c66264972c01fbf8b7960ddaR15

Do you know when that PR will be merged?

No ETA. I just want as many eyes on it from the core team, and our time has been limited lately.


Integrate Telegram bot support

https://www.npmjs.com/package/telegram-bot-api
This shouldn't be too bad, it'll follow the exact same pattern as MQTT. I've personally never used Telegram though so I have no idea how to test this or how to have it work cleanly in the dev container.

In progress: https://github.com/danecreekphotography/node-deepstackai-trigger/tree/danecreekphotography/issue37
At the moment this is stubbed through the entire system and just needs two things:

Create the API object when TelegramManager's loadConfiguration is called
Call Telegram in the processTrigger() method.

This works! It sends a photo message.
I'd really like to get it sending both a string and a photo message async but ran into some problems figuring out how to get all the promises to return in the right array format.


Device Name (OS X)

The BLENO_DEVICE_NAME is not working on OS X.
I tried both solutions:
Setting the env on runtime using
process.env['BLENO_DEVICE_NAME'] = name;

And tried also to set the env var with the startup, using BLENO_DEVICE_NAME=name npm start.
Both work on Linux, using nRF Connect to debug, but both shows the hostname on the device name, using a MacBook Pro as host, and the LightBlue to debug.

I have had issues too with the device name being completely blank when scanning them.  Once I connect to the device and what not it will work again.

Also experiencing this.

This is only supported on Linux.


Update config.yml

Pull Request
Before you submit
Before you submit a Pull Request, make sure:

There's a corresponding issue in the Issue Tracker;
The issue is greenlit for contribution (accepted tag);
The issue isn't actively worked on (pending tag).

If you can't find an issue that covers your request, please create one and wait for acceptance.
By submitting a Pull Request, you confirm that you have:

[x] Read and accepted the Contributor Guidelines;
[x] Read and acccepted the Code of Conduct;
[x] Read and accepted the License terms.
[x] Cleaned the project (Build > Clean Project in Android Studio)

Type of Pull Request
(Please tick appropriate)

[ ] Bug Fix
[ ] Feature
[ ] Code style update (formatting, renaming)
[ ] Refactoring
[ ] Documentation update
[ ] Documentation content update
[ ] CI/CD continuous integration

Link to Issue
(Insert URL of issue)
Description
update circleci config.yml file as build is failing
Commit Message
update circleci config.yml file
Screenshots
(Provide a screenshot if appropriate)
Other Relevant Information

Obsolete.


Any schedule to release the code?

Hey Isabella,
Thanks for sharing the great work! Do you have any schedules to release the code? It would be great if you set an approximate time so we can stay tuned and follow up in time!
Thanks a lot !

+1

Hi @ruili3 and @antithing, thank you for showing interest in our work! We plan to release the code upon the paper's acceptance. :)


THRIFT-3787 Fix Node.js Connection object error handling

The connected property on Connection instances was not accurately maintained if reconnection retries are not enabled. Line 194 was moved to Line 176 to fix this.
Furthermore, reconnection retries are not possible with secure sockets, so this commit returns early in that case, preventing long delays waiting for the secureConnect event which will never fire again. It's not explicitly stated in the Node.js documentation, but calling connect() on an instance of a TLSSocket will only reconnect the underlying TCP connection; it is not possible to cause the socket to re-handshake at the TLS layer.
(You can peruse the source for tls.connect to see that it performs many more operations than just instantiating a TLSSocket instance and calling connect() on it. This stands in contrast to an ordinary TCP Socket instance from the net module, where reconnection is possible via these means.)
Supporting reconnection for secure sockets would require a deep refactor to enable the Thrift Connection instance to replace its underlying socket, and I didn't feel up to the challenge today.

Somebody please kick Jenkins — it's repo instance is in a bad state.

Ping, @RandyAbernethy. I removed the hunk relating to the error event, per your comments in JIRA.


complete and approve Add Evidence form specification

I've created a spreadsheet that contains a specification for the Add Evidence form, and will email the share link around. It contains columns for the field name, description of the field's element(s), description of the field's behavior (mostly active assistance for getting the proper value into the field), and the field's help text.
I'll be creating these for every add/edit form and these will supersede the help text spreadsheet that contains help text for all the forms. Once this is completed and approved Adam and I can start implementing it.

Went through the spreadsheet and made some minor suggestions.  It sounds great to me.

Closing, the form is pretty much done except for the gene typeahead feature.


ode: 0.16.4 -> 0.16.5

Description of changes
https://bitbucket.org/odedevs/ode/src/master/CHANGELOG.txt
Things done

Built on platform(s)

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

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

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

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

[x] Fits CONTRIBUTING.md.

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

Result of nixpkgs-review pr 299784 run on x86_64-linux 1

4 packages built:

fluxus
freecad
ode
xmoto