Using diagnostic-channel for instrumentation

[x] This only affects the JavaScript OpenTelemetry library
[x] This may affect other libraries, but I would like to get opinions here first

Not sure if this has been discussed before, so please let me know if that's the case, but I was wondering why the actual instrumentation from plugins and context propagation was not done using diagnostic-channel. I think it would make a lot of sense to report events from the instrumentation that could then be converted to spans within OpenTelemetry. That model would make it possible to use these events for other things outside the realm of OpenTelemetry or even telemetry in general, and since the surface area of sending events to a centralized channel is a lot smaller, this would be a lot more likely to be exposed from within the libraries directly, and even eventually by Node. This would eventually remove the need to have the instrumentation at the OpenTelemetry level, and plugins would only build spans based on events.
What do you think?
cc @markwolff since you are contributing to both projects.
(P.S. I checked both checkboxes because I think eventually such a diagnostic channel could be standardized across languages)

I wasn't around when such early decisions were made, but I was also not aware of diagnostic-channel. One issue I see is that the diagnostic channel doesn't allow for any static analysis to make sure it is correct, where writing the instrumentations directly using a typescript API does. If we try to instrument modules which already support it then it might be a good place to start, but I don't see a strong reason to rewrite the instrumentations we have.

I would support this effort since this was the original intent of diagnostic-channel. Diagnostic channel shouldn't conflict with any of the existing stuff OpenTelemetry does. Mirroring what Roch mentioned, the main benefit here would be a super thin way for library writers to emit events (which could be used for anything, not just by APMs) instead of having to take a dependency on OpenTelemetry APIs. Currently no libraries emit these events. We do something similar for our existing .NET APM, DiagnosticSource, but I'm not sure if its used for otel at all.

Will still need patching for context extraction and propagation. If an event is emitted from a db driver that is all well and good, but what is its parent?

We expose channel.bindToContext(fn) to enable subscribers to add their own propagation callback that publishers would use. The channel doesn't do any context propagation itself, it just uses whatever was passed to it.
Injecting/extracting headers/metadata is something it does not currently do, but I think a similar pattern could be implemented, channel.addMetadataPropagation(...). This adds a bit of complexity that blurs the lines between the API & the channel though. Do you know how common of a scenario this would be beyond http/grpc?

If we try to instrument modules which already support it then it might be a good place to start, but I don't see a strong reason to rewrite the instrumentations we have.

The main advantage is that it's not reasonable to expect libraries to support OpenTelemetry internally, meaning that monkey-patching will always be necessary. Similar applies to Node where I don't think it would ever be considered to have OpenTelemetry built-in. However, a simple diagnostic channel could eventually land in both, removing the need for any monkey-patching. This would also benefit tools outside the realm of APM to consume these events, some of which might be completely unrelated to tracing.
If the community moves towards events at the core of Node diagnostics capability, opentelemetry-js will also end up having to be rewritten anyway. It's also worth noting that "rewrite the instrumentation we have" is not 100% correct since they could be reused and moved to diagnostic-channel for the most part.
cc @Qard since I know there are discussions around diagnostic-channel going on in Node Diagnostics.

Similarly, how would http headers be injected/extracted.

For this one, I will admit I'm not sure if it should go in diagnostic-channel or not. As mentioned by @markwolff it may be a concern outside the realm of the project, but at the same time, if the idea is to propagate diagnostics-related metadata it might make sense. Otherwise it would fall on the libraries to expose these hooks, which is not ideal but that could still be done through monkey-patching, but the extent of the patching would be significantly reduced.

One issue I see is that the diagnostic channel doesn't allow for any static analysis to make sure it is correct, where writing the instrumentations directly using a typescript API does.

That's not really an argument since the project's instrumentation could be updated so that it does include static analysis. This is especially true if OpenTelemetry contributors also start contributing to the project.

cc @Qard since I know there are discussions around diagnostic-channel going on in Node Diagnostics.

Very interested in this. If this becomes a language-supported feature, then it makes obvious sense to support.
@rochdev @markwolff how would you suggest we get started with this? You mentioned few/no projects are currently exporting data using diagnostic channels. Does this mean we would still need to use the same plugins we do now, but instead of calling opentelemetry APIs in the patched methods, we would emit events? What component would listen for the events?

Yeah, no way Node.js would ever land the full OpenTelemetry in core, but a lower-level data channel is a definite possibility I’m working towards now. The shape of it is likely to evolve somewhat from the original Microsoft design though, so I’m not sure how much sense it makes to use it right now but definitely worth tracking for future consideration.

Node already have the trace_events core module is pretty much focused on that use case, it already allow to "trace" dns/fs sync requests and more (you can also link trace between themselves).
However there are no javascript API exposed to user, not sure if it was discussed. I know @jasnell opened this PR to allow core code to emit more trace events.
cc @jasnell Do you have any insight about why it wasn't exposed to users ?
For reference about this system, i would recommend reading this doc: https://docs.google.com/document/d/1CvAClvFfyA5R-PhYUmn5OOQtYMH4h6I0nSsKchNAySU/edit#heading=h.jh64i9l3vwa1

The shape of it is likely to evolve somewhat from the original Microsoft design though

Wouldn't it be better if the design stays as close as possible? The idea being that if the design is standard, then it could be implemented in every language and become an actual standard of its own on which OpenTelemetry would sit in every language. I don't have enough knowledge of how other languages work to know if that would be feasible though, but given the simplicity of the design I think it should definitely be possible.

The issue is mainly around the design of the publish method. As it is currently, the inputs to the function will always be allocated/constructed regardless of if there is actually a subscriber. For something intended to be used very often, this could get expensive fast. It needs some changes to allow lazy input construction. Something like:
channel.publish('my-event', () => {
  return { myData: someExpensiveThing() }
})

or
if (channel.has('my-event')) {
  channel.publish('my-event', { myData: someExpensiveThing() })
}

The current model of sharing all events across a single global namespace is a bit worrying too. I'm considering a channel of channels where each module would get its own named channel. For example:
const dc = require('diagnostics-channel')

// Find or create a named channel
const channel = dc.channel('some-async-thing')

module.exports = function someAsyncThing (a, b, c, callback) {
  // Publish an event to the named channel
  channel.publish('start', { args: [ a, b, c ] })
  setImmediate(() => {
    channel.publish('stop')
    callback(a, b, c)
  })
}

// elsewhere...

const DiagnosticsChannel = require('diagnostics-channel')

// Find or create a named channel
const channel = dc.channel('some-async-thing')

// Subscribe to named events of named channel
channel.subscribe('start', recordStart)
channel.subscribe('stop', recordStop)

This would allow each named channel to have its own set of subscribers and publishers, making lookups faster. This way, an APM could attached hundreds of subscribers and only the ones on channels actually in-use would actually matter during runtime lookups for event routing.
I don't have a 100% solid idea of exactly what the final API should look like, but that's just some of what I've been thinking about on that.

For reference, @Qard opened an PR to land this into Node: https://github.com/nodejs/node/pull/34895 (also the discussion on the diagostics group)

Yep. Still very much experimental and will likely continue to evolve before it's ready to land.

@Qard I know you were deeply involved in the design of diagnostics_channel, so I'd be curious (if you're willing) to learn about whether things are now sufficiently far along on the Nodejs front that it'd be possible to have some sort of generic Otel adapter code to instrument modules using channels. I imagine the idea would be to take a list of channel names (for diagnostic channels or TracingChannels), plus some optional configuration, and convert the events from those channels into proper Otel spans/metrics/etc.

Yep, it has worked very well for Datadog so far. I'm happy to discuss whatever questions you might have at the next OTel JS library sync, or I can write something up explaining why things are the way they are in diagnostics_channel and how it could be a beneficial approach for OTel. In the meantime, if there's anything specific you want to know I'm happy to answer here. 🙂

@Qard Thanks for the quick response and willingness to engage!
A brief summary of the design rationale for diagnostics_channel, and how it could be applied with Otel, would be incredibly helpful (thanks!) — both for me and, I imagine, others trying to get up to speed on these new APIs. I did try reading the nodejs docs first, but I still don't have a great mental model of how the diagnostics_channel APIs are supposed to be used/fit together, or how stable different parts are.
In the meantime, I took a look at the dd-trace-js code, which helped me grok things a bit; I hadn't realized that DD is already using diagnostics_channel in production. From my read through, it seems like Datadog is basically:

monkeypatching the methods of the npm modules it's instrumenting, so that they publish to new channels;
doing the channel publishing within the context of a new AsyncResource, to correlate the messages;
then, in separate code, subscribing to these channels and converting their messages to spans.

Is that right?
If so, my primary questions are:

Eventually, I think the idea is for APM vendors to be able to collect traces without having to monkeypatch the modules they're instrumenting, right?

If so, it seems like the module authors would need to be able to write their code to publish messages without, knowing what tool is going to consume those messages to construct spans. My question is, with the new APIs, exactly what is that supposed to look like? In particular:

Is the idea that, with TracingChannel, module authors wouldn't need to create the AsyncResource that DD is creating, because of the shared context object passed to/created by the TracingChannel.trace*** methods?
For built-in Node modules that are already using diagnostics channels (say, the http.server.request.start/finish channels and the channels used by undici), is the idea that APMs would have to treat those channels specially, by knowing about some object in the messages (e.g., the request object) that has a consistent identity for message correlation?
Could you show a brief example of how this would all fit together? I.e., both what the module author would write, and then how external code (from Otel or elsewhere) would consume the module's output to correctly produce traces while managing all the trace context?

Thanks again, for your help here and your hard work getting these APIs into Node! :)

The path forward for APMs is to short/medium-term continue with their existing patching but emit diagnostics_channel events instead of calling their APIs directly and layer module plugins over that to describe how to map the event data to their API calls. Some things will map fairly directly but some will need a bit of restructuring to match their data model. It's not in-scope for diagnostics_channel events to always be able to map to spans directly with no code, but it should take very minimal code. This is part of why TracingChannel has different names for every source, so you can attach different logic to map those events into spans. It does follow a generalized pattern though to enable as much code reuse as possible for those plugins, and you can probably model some common patterns over similar models, like SQL client libraries can probably use the same or very similar plugins.
Eventually what is being captured and sent through diagnostics_channel in patches will be contributed upstream to those libraries, and we're already starting on that now. When those events get merged upstream we can start listening to those channels instead without needing any patches, which should be a huge improvement for performance. :)
The AsyncResource thing Datadog is doing currently is temporary. TracingChannel was designed with a shared context object to eliminate the need for that, and also can work in cooperation with channel.bindStore(...) to wrap your context around any given TracingChannel scope. Here's an example:
// publishing side
const { readFile } = require('fs')
const { tracingChannel } = require('diagnostics_channel')

// A TracingChannel is a container of channels that follow a consistent naming
// scheme and behavioural model.
//
// This will contain channels for:
// - tracing:something:start
// - tracing:something:end
// - tracing:something:asyncStart
// - tracing:something:asyncEnd
// - tracing:something:error
const channel = tracingChannel('something')

// traceCallback will trigger a start and end around the sync portion of the
// function given as the first argument. The second argument will set the
// position of the callback to wrap. The callback received by the given
// function will then be wrapped with another function which will trigger the
// asyncStart and asyncEnd events around the execution of the callback.
channel.traceCallback(readFile, -1, { file }, undefined, file, () => {})

// subscribing side
const { channel } = require('diagnostics_channel')

// The start channel can be used as a scope for AsyncLocalStorage
const start = channel('tracing:something:start')

start.bindStore(spanStore, (context) => {
  const parentSpan = spanStore.getStore()
  const span = new Span({
    // get whatever is needed from the context data
  }, parentSpan)
  context.span = span
  return span
})

// By storing the span on the context object it's possible to manually restore
// context in the event that AsyncLocalStorage fails to propagate, for
// whatever reason. This is generally not recommend and should probably be
// considered a bug if AsyncLocalStoragevis not propagating correctly.
const asyncStart = channel('tracing:something:asyncStart')

asyncStart.bindStore(spanStore, (context) => {
  return spanStore.getStore() || context.span
})

From the publishing side, it's the intent that they will share any data they have in the context object and the consumer can extract what they want from that. For example, an http request will share the request and response objects and the subscriber can extract things like method and path from that data.
As for the question about existing channels, TracingChannel can be used to map over existing channels that don't necessarily need to follow the naming convention, but if the don't match the behavioural convention it may not make sense. In the case of http we'll probably wrap a TracingChannel around the request/response lifetime but as a separate set of events from what exists currently.
For a more complete example of the tracing side:
const { channel } = require('diagnostics_channel')

const start = channel('tracing:something:start')
const end = channel('tracing:something:end')
const error = channel('tracing:something:error')
const asyncStart = channel('tracing:something:asyncStart')
const asyncEnd = channel('tracing:something:asyncEnd')

start.bindStore(spanStore, (context) => {
  const parentSpan = spanStore.getStore()
  const span = new Span({
    // get whatever data is needed from the context data
  }, parentSpan)
  context.span = span
  return span
})

// Error events can be attributed to the span
end.subscribe((context) => {
  const currentSpan = spanStore.getStore() || context.span
  if (!currentSpan) return
  currentSpan.setError(context.error)
})

// For a sync source, you could trigger a span end when the end event happens
end.subscribe((context) => {
  const currentSpan = spanStore.getStore()
  if (!currentSpan) return
  currentSpan.end({
    // get whatever additional data is needed from the context data.
    // With `traceSync(...)`, the context object will also contain
    // `result` and `error` where relevant.
  })
})

// For an async source, either the asyncStart or asyncEnd could be used to mark the span end,
// which you should use depends on if you consider callback execution time as being part of the span.
// In either case the `result` or `error` properties will be set.
asyncStart.subscribe((context) => {
  const currentSpan = spanStore.getStore()
  if (!currentSpan) return
  currentSpan.end({
    // get whatever additional data is needed from the context data.
    // With `traceCallback(...)` and `tracePromise(...)`, the context object will
    // also contain `result` and `error` where relevant.
  })
})

Thanks @Qard! Those examples are super helpful. I was mostly asking because, for my own modules, I'd like to start emitting diagnostics channel events (rather than, e.g., directly depending on the OTel API). Then, if I use those modules at work, I will need to hook those events into Otel, so I wanted a fuller picture of how that would work as well. I think your response answers all my questions!
I ended up doing a deep dive into these APIs over the weekend (including watching your talk at Node Congress 2023), and I'm very excited to see all this work coming to fruition!
While learning the APIs, I did have two small pieces of feedback. I realize that's a bit off topic to this issue, but I don't feel strongly enough about these ideas to open a new issue for them, so I just wanted to mention them to you briefly here. Feel free to ignore them/take them with a giant grain of salt — they may be totally off the mark (I'm still missing much context behind the design here). But, they were:

The runStores method name was pretty confusing to me... namely, I didn't expect that it would also publish on the underlying channel. In my mental model, running a function with some context is logically independent from publishing diagnostics events messages, so I didn't understand why it'd make sense to couple them and why the data that's fed to the store transformers would make sense as an event message. But, assuming there is some good reason to couple them for common use cases, which I suspect there is, then I still think the name could hint at that better. I also found the docs on runStores a bit confusing; I had to read the source code to understand it.

I wonder if it would make sense for the error/result properties that Node adds to the context object of TracingChannel messages to be named with symbols, rather than strings? Since error and result are pretty common property names, it seems like there's some risk of event publishers either accidentally overwriting them, or having the data they put in those properties get clobbered by Node. Also, if the TracingChannel APIs ever wants to add a new property to these objects in the future, there will be no safe/backwards-compatible way to do it except to make that new property use a Symbol, and then it might be weird to have two of the properties use strings while the new ones use symbols.

But those are just nits. Again, thanks for all your work here!

Yeah, agreed that runStores is not the clearest API. I wasn't getting any better names for it though. As for why it does both things, the original intent was that any event could trigger the bindStore wrapping, which originally used enterWith on the store, but that was too unreliable so I changed it to use run on the store but that required making an actual function scope to wrap. I could have split the concepts at that point, but I felt it probably was best to not burned module authors so much with deciding data relevance differences between the event need and the scoping need and to instead just pass along all the data they have on hand and let the consumer decide what to do with it. This meant runStores and publish would basically always occur in the same place with the same arguments. We also didn't want to put the users in a position where that ordering could change as we designed it such that the scoping will run first so ever event in the span should have the store value set with bindStore as the current store state in the subscribers for any of the channels. (Assuming context doesn't break for async events.)

Yeah, agreed that runStores is not the clearest API. I wasn't getting any better names for it though.

I'm not sure. Maybe just runAndPublish?

For error/result, attaching it directly to the context object seemed the most appropriate.

Yeah, I agree with putting the key directly on the context object; I was just proposing possibly putting it at context[require('node:diagnostics_channel').error] and context[require('node:diagnostics_channel').result], where those would be symbols. I think that might make sense for avoiding conflicts, even if no more properties are added. (Although I think I also saw some chatter about possibly adding an async property too?)

PRs are welcome if you have ideas for improvements. Best to make any changes now while it's still marked experimental. I would probably go for something like tracingChannel.getResult(context) and tracingChannel.getError(context) as an abstraction over that symbol storage or something like that to allow for possible future changes to the implementation details of how it works though. 🤔

PRs are welcome if you have ideas for improvements. Best to make any changes now while it's still marked experimental.

I agree that now'd be the time to make changes, but I really don't feel like I have the bandwidth for a long discussion, unfortunately, which I suspect a PR would prompt. So I more just wanted to plant these ideas in your head, in case you think (with much more context than me) that they're worth pursuing. But now I'll stop hijacking this thread 😁

I would probably go for something like tracingChannel.getResult(context) and tracingChannel.getError(context) as an abstraction over that symbol storage or something like that to allow for possible future changes to the implementation details

I like those methods for ease-of-use, but I don't think they'd really make the implementation changeable down the line if the Symbols are observable (i.e., added as a key in the object); to make it changeable, you'd probably have to put the error/result in a weakmap that those helpers would access, which could work too.


Use of volatile read is unsound

The volatile read at https://github.com/Amanieu/seqlock/blob/master/src/lib.rs#L147 is unsound - according to the LLVM memory model, volatile reads on data which is being concurrently modified are UB:

Note that NotAtomic volatile loads and stores are not properly atomic; do not try to use them as a substitute.

- https://llvm.org/docs/Atomics.html
This should be a relaxed atomic load instead.

That's not what your quote says. It just says that the operations aren't properly atomic, which means that they may be split into multiple operations, which would not be atomic (i.e. you could observe a mix of the new and old value). Also volatile operations don't have any of the memory ordering properties that atomic operations have.
We don't actually need either of these properties in seqlock:

We discard the data if it is concurrently modified, so we don't care about split reads/writes.
We enforce memory ordering with other atomic operations and fences.

In practice, using volatile to read concurrently modified data is fine, and the Linux kernel even relies on this for their READ_ONCE macro (which just does a volatile read). It is extremely unlikely that LLVM would break existing code that relies on these semantics.

So I get where you're coming from on that interpretation. I'm honestly a bit surprised because when I was looking at the spec to find the relevant quote, I could've sworn seeing a stronger wording in the past (explicitly calling out using volatile on concurrently-modified memory as UB). It's possible I'm just making that up. In any case, it strikes me that a) the spec definitely isn't precisely worded enough to guarantee that this isn't technically UB, but also that b) your point about the fact that people rely on this behavior is a fair one.
In any case, I came here from https://github.com/rust-lang/rust/pull/59155#issuecomment-473570191, so hopefully that will obsolete this anyway.
Cheers!


Compile Error error C2280: “blackbone::MemBlock::MemBlock(const blackbone::MemBlock &)”: Try to reference the deleted function

When I use vs2017 to compile, I encountered such an error. Don't know how to solve it, hope someone can help me

I have the same problem……

When I use vs2017 to compile, I encountered such an error. Don't know how to solve it, hope someone can help me

try to add a copy constructor in the file MemBlock.h .
line:109
BLACKBONE_API MemBlock(MemBlock& rhs) { _pImpl.swap(rhs._pImpl); }


fix(runPersistedQuery): handle multiple variables

runPersistedQuery is not being able to handle multiple variables.
The resulting variablesString in actual code causes a ServletError when persisted queries with more than one variable are requested via the HTTP GET method.
Description

Wrapping the result of the existing map function with encoencodeURIComponent instead of applying it to each variable, and specifying an empty string as separator in the method Array.prototype.join() makes variableString works in all scenarios and solves the problem.
Related Issue

 https://github.com/adobe/aem-headless-client-js/issues/28#issue-1071753352
Motivation and Context

It is required in order to make the runPersistedQuery work with multiple variables.
How Has This Been Tested?

How changes were tested:
I persist a query with more than one variable
I called runPersistedQuery with a valid path and more than one variable in the parameters
No more errors were thrown by __handleRequest
No other code areas were affected
Screenshots (if appropriate):
Types of changes

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

Checklist:

[x] I have signed the Adobe Open Source CLA.
[x] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[x] I have read the CONTRIBUTING document.
[x] I have added tests to cover my changes.
[x] All new and existing tests passed.

Thanks @opapito


The goal of this project was to provide a very easy way to share files on Discord through a web server. While this project does not bypass Discord's file size limit, it is a workaround for it. I believe that README is technically correct and not a lie, but I'll change it anyway to prevent any confusion.


Allow targeting nodes in CilumNetworkPolicy

Proposal / RFE
Cilium already supports a couple of methods to specify endpoints policies https://docs.cilium.io/en/stable/policy/language/#layer-3-examples.
Some Kubernetes constructs are supported too https://docs.cilium.io/en/stable/policy/kubernetes/.
In certain scenarios it can be useful to filter on nodes.
As an example, allowing egress from master nodes of a cluster to nodes that host ETCD proves to be difficult today.
Something like this might work if the IP adresses in the toCIDR statement are for nodes that belong to the cluster:
apiVersion: cilium.io/v2
kind: CiliumClusterwideNetworkPolicy
metadata:
  name: etcd
spec:
  nodeSelector:
    matchLabels:
      node-role.kubernetes.io/control-plane: ''
  ingress:
  - fromEntities:
    - kube-apiserver
    toPorts:
    - ports:
      - port: '2379'
        protocol: TCP
      - port: '2380'
        protocol: TCP
  egress:
  - toCIDR:
    - <IP_ADDRESS>/32
    - <IP_ADDRESS>/32
    - <IP_ADDRESS>/32
    toPorts:
    - ports:
      - port: '2379'
        protocol: TCP
      - port: '2380'
        protocol: TCP

Policy verdict log:
Policy verdict log: flow 0xa6c1d821 local EP ID 2007, remote ID kube-apiserver, proto 6, egress, action audit, match none, <IP_ADDRESS>:57124 -> <IP_ADDRESS>:2380 tcp SYN

Something like this will work if the kube-apiserver and ETCD run on the same nodes:
apiVersion: cilium.io/v2
kind: CiliumClusterwideNetworkPolicy
metadata:
  name: etcd
spec:
  nodeSelector:
    matchLabels:
      node-role.kubernetes.io/control-plane: ''
  ingress:
  - fromEntities:
    - kube-apiserver
    toPorts:
    - ports:
      - port: '2379'
        protocol: TCP
      - port: '2380'
        protocol: TCP
  egress:
  - toEntities:
    - kube-apiserver
    toPorts:
    - ports:
      - port: '2379'
        protocol: TCP
      - port: '2380'
        protocol: TCP

Although this is quite confusing as one would expect this to NOT work as the destination is definitely not targeting kube-apiserver.
Describe the solution you'd like
It would be nice to be able to use node selector in policy rules.
Something along those lines:
apiVersion: cilium.io/v2
kind: CiliumClusterwideNetworkPolicy
metadata:
  name: etcd
spec:
  nodeSelector:
    matchLabels:
      node-role.kubernetes.io/control-plane: ''
  ingress:
  - fromEntities:
    - kube-apiserver
    toPorts:
    - ports:
      - port: '2379'
        protocol: TCP
      - port: '2380'
        protocol: TCP
  egress:
    # select nodes based on node labels
  - toNodes:
    - matchLabels:
        node-role.kubernetes.io/etcd: ''
    toPorts:
    - ports:
      - port: '2379'
        protocol: TCP
      - port: '2380'
        protocol: TCP

See original slack discussion https://cilium.slack.com/archives/C01JALNQAR1/p1647017730769119 too

An upcoming feature in Cilium v1.15 goes part way on this: https://github.com/cilium/cilium/pull/27464 , you should be able to try it out with v1.15.0-pre.1 or later. It looks like there are other PRs linked above that will further build on that logic to potentially allow selecting nodes by label, but they are not yet merged.


Handling of typenames that match Rust typenames

Here is the minimal wit file:
record result {
    data: list<u8>,
}

func: function() -> expected<result, string>

Which yields the following error:
error[E0107]: this struct takes 0 generic arguments but 2 generic arguments were supplied
 --> sdk/src/client.rs:1:1
  |
1 | wit_bindgen_rust::import!("./wit/some.wit");
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^- help: remove these generics
  | |
  | expected 0 generic arguments
  |
note: struct defined here, with 0 generic parameters
 --> sdk/src/client.rs:1:1
  |
1 | wit_bindgen_rust::import!("./wit/some.wit");
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  = note: this error originates in the macro `wit_bindgen_rust::import` (in Nightly builds, run with -Z macro-backtrace for more info)

It wasn't obvious what's going on, but the generated code contains the following:
  pub fn func() -> Result<Result,String>{

We wit-bindgen should either emit some warnings/errors, or perhaps use full paths like ::core::result::Result? The latter is common in macros for any other types, but I think it's not common for Result and Option, so not sure what is the best option.
The issue is pretty minor, though.

I think the best bet is to probably reference standard rust types through their fully qualified paths instead of assuming the prelude-defined names are the ones that refer to them (e.g. the ::core::result::Result option you mentioned). While a bit of a pain it's generally just generated code so hopefully not the end of the world.

It might make sense to implement #54 first and use the scaffolding that gives us to implement this issue.


Us041 scheduled state

When mandatory events are added, the collection exercise state becomes SCHEDULED

 US041: Create and View 'Scheduled' State of a CE [M]

Super-seeded by https://github.com/ONSdigital/rm-collection-exercise-service/pull/30/files


intergration spec

In this repo: Add integration specs for views and fix n+1 problems
In this branch, we implemented the following:
Made sure that the N+1 problem is solved when fetching all posts and their comments for a user.
before

after

-Used Capybara to write integration tests for each view in your project.
*User index page:
I can see the username of all other users.
I can see the profile picture for each user.
I can see the number of posts each user has written.
When I click on a user, I am redirected to that user's show page.
user show page:
I can see the user's profile picture.
I can see the user's username.
I can see the number of posts the user has written.
I can see the user's bio.
I can see the user's first 3 posts.
I can see a button that lets me view all of a user's posts.
When I click a user's post, it redirects me to that post's show page.
When I click to see all posts, it redirects me to the user's post's index page.
User post index page:
I can see the user's profile picture.
I can see the user's username.
I can see the number of posts the user has written.
I can see a post's title.
I can see some of the post's body.
I can see the first comments on a post.
I can see how many comments a post has.
I can see how many likes a post has.
I can see a section for pagination if there are more posts than fit on the view.
When I click on a post, it redirects me to that post's show page.
Post show page:
I can see the post's title.
I can see who wrote the post.
I can see how many comments it has.
I can see how many likes it has.
I can see the post body.
I can see the username of each commentor.
I can see the comment each commentor left.

Hey am leaving this comment because I had done this project and it had requested changes bt it gave me too much trouble so I decided to move forward to other projects when I was merging the devise branch I ended up merging the branch that wasnt approved bt I have done everything the test and the n+1 project as per the project requirement I really dint have many options. I was to create a pull request on the same branch but I realized if I work on that and I have other branches with the current work it would affect the project performance so I figured out it was wise for me to create a new branch with the current project kindly consider my project and review.
Thanks

I push because i realised it had a conflict


Macro-step does sometimes two steps

The you might reproduce the bug:
Usually happens in the method with more than 2 parameters.

fixed after commits: c87332d, b44e855, 3fc0efd


API Gateway DEFAULT_4XX and DEFAULT_5XX gateway response setting disappears from time to time

Before opening, please confirm:

[X] I have installed the latest version of the Amplify CLI (see above), and confirmed that the issue still persists.
[X] I have searched for duplicate or closed issues.
[X] I have read the guide for submitting bug reports.
[X] I have done my best to include a minimal, self-contained set of instructions for consistently reproducing the issue.
[X] I have removed any sensitive information from my code snippets and submission.

How did you install the Amplify CLI?
npm
If applicable, what version of Node.js are you using?
14.17.16
Amplify CLI Version
8.1.0
What operating system are you using?
Mac
Did you make any manual changes to the cloud resources managed by Amplify? Please describe the changes made.
no
Amplify Categories
api
Amplify Commands
push
Describe the bug
This is a continuation of https://github.com/aws-amplify/amplify-cli/issues/9540
Today I discovered our API Gateway "Gateway Response" setting has been unset, and was causing users issues.
See screenshot below. We have not made any recent changes to our Rest API settings. What could be causing this?

amplify push --force does not change anything.
Expected behavior
API Gateway should respect cloudformation settings
Reproduction steps
Not sure how to repro.
GraphQL schema(s)

# Put schemas below this line

Log output

# Put your logs below this line

Additional information
No response

Hey @hisham :wave: thanks for raising this! As we begin to look at this issue can you confirm the series of commands leading up to the discovery of the missing settings?

I didn't do anything specific with amplify. A customer complained he couldn't login to our system. From previous experience, I knew this was related to computer clock drift (https://github.com/aws-amplify/amplify-js/issues/6494) which has been fixed by amplify by adding these gateway response settings. And our system had these settings pushed after doing a force push (see https://github.com/aws-amplify/amplify-cli/issues/9540), but I guess in some other amplify push the settings got reverted even though I do see them in the cloudformation...


Adds support to Stacker templates for AWS Cloudformation List<> types.

Adds support to Stacker templates for the AWS Cloudformation List<> types.  Now when you want to launch an instance with multiple SecurityGroups, instead of specifying multiple parameters you can specify a single ListAWS::EC2::SecurityGroup::Id parameter.

Cool idea - I really like this feature.  I want to do another run through of it (later today), but can you also update the doc strings where they reference the output lookups here?

I suppose I can update _resolve_parameters()... was there any other docstrings you had in mind?

Looks good!  Thanks!


Save target report images

Signed-off-by: Ian Chen<EMAIL_ADDRESS>The changes enable 2 sets of images to be saved when a target is reported:

An image from the image stream transmitted by the user (over comms) is saved.

I added a new dependency, cv_bridge, for saving sensor_msgs::msgs::Image to file. So you'll need to run rosdep again or apt install ros-galactic-cv-bridge if you don't have this package.
This image file is saved  to ~/.ros/mbzirc. Reason is that the video relay node is run on the bridge container on the cloud, and in this container we are uploading the .ros directory to s3.
Only the last image of a particular target type is saved, e.g. if the user reported small target vessel twice, the last one will be saved.

An image is saved by the GameLogicPlugin. The image is taken from the rendering camera in the simulator when a report is received. This is the original uncompressed image.

The image is saved to /tmp/ign/mbzirc/logs/target_images.
One image is saved per report, e.g. f the user reported small target vessel twice, there will be 2 images.

To test, follow the same instructions for reporting targets in https://github.com/osrf/mbzirc/pull/195. Make sure to apply the diff for making the drone and vessel static. After each target report, you should see new png files saved in ~/.ros/mbzirc/ and /tmp/ign/mbzirc/logs/target_images.

My only minor suggestion is that if the only purpose for the new mutex member is to protect this->saveImage, we could change this member to be std::atomic<bool>.

yeah I did that first but later on I added saveImagePrefix which also needs to be protected so I changed to use a mutex


Added section about setup on windows to README.md

Explained line ending issue in kibana/entrypoint.sh on windows.

Awesome ! Thanks :+1:


Setting ols.json options globally in neovim

I'm trying to set the checker_args option globally to "-vet" so that I can catch unused imports etc.
This works well with the standard ols.json but I'd like to have this enabled for all odin files, if possible.
I've made an educated guess at what I think the config should look like, but so far I've been unable to get this working:
        require("lspconfig").ols.setup({
            settings = {
                ols = {
                    checker_args = "-vet",
                },
            },
        })

I've tried searching for other config examples or relevant documentation but have found nothing helpful thus far.

Got it working!
ols config is set via init_options. Here's what worked for me in the end:
        lspconfig.ols.setup({
            init_options = {
                checker_args = "-vet -strict-style",
            },
        })


Empty View when in Main Tab

Describe the bug
Very often, when the Time-Ruler is in the Main Tabs, the full view is empty.
Maybe this is also the reason the Issue reported in #53
To Reproduce
Steps to reproduce the behavior:

Open the ruler
Move the Tab to the Main Tabs
Close Obsidian
Open it again And "often" (sometimes it works, awesome bugs..) it breaks into an empty view

Obsidian Version:

[ ] Mobile
[x] Desktop

Additional context
OS: Mac 13.4.1 (c) (22F770820d)
Plugin Version: 1.3.1
Probably a timing issue, haven't checked the code yet
Even reloading Obsidian its not showing up afterwards,  its strange 😬
Console Errors:
// (3x times the following)

Uncaught TypeError: Failed to execute 'observe' on 'ResizeObserver': parameter 1 is not of type 'Element'.
    at eval (plugin:time-ruler:70148:14)
    at commitHookEffectListMount (plugin:time-ruler:31778:34)
    at commitPassiveMountOnFiber (plugin:time-ruler:33031:17)
    at commitPassiveMountEffects_complete (plugin:time-ruler:32999:17)
    at commitPassiveMountEffects_begin (plugin:time-ruler:32989:15)
    at commitPassiveMountEffects (plugin:time-ruler:32979:11)
    at flushPassiveEffectsImpl (plugin:time-ruler:34360:11)
    at flushPassiveEffects (plugin:time-ruler:34317:22)
    at performSyncWorkOnRoot (plugin:time-ruler:33738:11)
    at flushSyncCallbacks (plugin:time-ruler:24009:30)
    at commitRootImpl (plugin:time-ruler:34302:11)
    at commitRoot (plugin:time-ruler:34147:13)
    at finishConcurrentRender (plugin:time-ruler:33675:15)
    at performConcurrentWorkOnRoot (plugin:time-ruler:33588:15)
    at workLoop (plugin:time-ruler:15071:42)
    at flushWork (plugin:time-ruler:15050:22)
    at Immediate.performWorkUntilDeadline (plugin:time-ruler:15258:29)
    at process.processImmediate (node:internal/timers:476:21)

-------------------

plugin:time-ruler:28910 The above error occurred in the <App2> component:

    at App2 (plugin:time-ruler:69977:17)

Consider adding an error boundary to your tree to customize error handling behavior.
Visit https://reactjs.org/link/error-boundaries to learn more about error boundaries.

-------------------

plugin:time-ruler:68344 TypeError: Cannot destructure property 'folder' of '(intermediate value)' as it is null.
    at getDailyNoteInfo (plugin:time-ruler:68330:11)
    at async setupStore (plugin:time-ruler:69979:27)

Just saw the there is already an update to 1.3.3 (not in Obsidian avaiable?) - will try that version using "BRAT" - and report if the issue still exists

I can confirm the errors are still existing in the 1.3.3

I hope this is fixed in upcoming 1.4.0, let's see if it is.


support LIST/VECTOR data types in schema and storage

增加了LIST或者说VECTOR作为datatype #350
todo：
1.参照schema_test, test_field_data_helper, test_field_extractor, test_data_convert等涉及data_type的测试文件，增添相应的测试代码
2.完善代码修改

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

增加了LIST或者说VECTOR作为datatype #350 todo： 1.参照schema_test, test_field_data_helper, test_field_extractor, test_data_convert等涉及data_type的测试文件，增添相应的测试代码 2.完善代码修改

加个ut？


chore: Add warning message for missing credentials

Description

Note: The updated function is only used for Cypress plugin integration. The Cypress runner uses the afterRunTestReport function to collect reports. Since afterRunTestReport does not check account settings, there is no need for additional checks on the SAUCE_VM setting.

Since afterRunTestReport does not check account settings, there is no need for additional checks on the SAUCE_VM setting.

I think you do need to check it still. If the user is using this plugin while having a mixed use of environments where Cypress runs (some locally, in CI and Sauce Labs), any time they'd run their tests—even if partially—via Sauce Labs, they'd get this warning.

Good point!


Undertow plugin finish local test, request  component Id

Please answer these questions before submitting your issue.

Why do you submit this issue?

[x] Feature or performance improvement

Question

I have alredy finish Undertow plugin localtest
my plugin use component Id is

public static final OfficialComponent UNDERTOW =  new OfficialComponent(45, "Undertow");
I want pull a request , So , should remain this id

The ID value is not important. I think you could include this value in your PR should be good enough.


Uncaught Error: Cannot find module 'lodash'

TL;DR: Solution
[by Linter Team]
Reload atom with View > Reload
This problem is probably going to happen to everyone as you upgrade. We're sorry, but we couldn't test the upgrade process and were unable to predict this problem.
Original report
[Enter steps to reproduce below:]

...
...

Atom Version: 0.211.0
System: Mac OS X 10.10.3
Thrown From: linter package, v1.0.0
Stack Trace
Uncaught Error: Cannot find module 'lodash'
At module.js:330

Error: Cannot find module 'lodash'
  at Module._resolveFilename (module.js:328:15)
  at Function.Module._resolveFilename (/Applications/Atom.app/Contents/Resources/app.asar/src/module-cache.js:383:52)
  at Function.Module._load (module.js:270:25)
  at Module.require (module.js:357:17)
  at require (module.js:376:17)
  at LinterJshint.Linter.getEditorScopesForPosition (/Users/roland/.atom/packages/linter/lib/linter.coffee:291:31)
  at LinterJshint.Linter.computeRange (/Users/roland/.atom/packages/linter/lib/linter.coffee:337:5)
  at LinterJshint.Linter.createMessage (/Users/roland/.atom/packages/linter/lib/linter.coffee:16:3)
  at LinterJshint.<anonymous> (/Users/roland/.atom/packages/linter/lib/linter.coffee:235:37)
  at Function.self.forEach (/Users/roland/.atom/packages/linter/node_modules/xregexp/xregexp-all.js:542:22)
  at LinterJshint.Linter.processMessage (/Users/roland/.atom/packages/linter/lib/linter.coffee:236:7)
  at /Users/roland/.atom/packages/linter/lib/linter.coffee:165:7
  at triggerExitCallback (/Applications/Atom.app/Contents/Resources/app.asar/src/buffered-process.js:213:47)
  at ChildProcess.<anonymous> (/Applications/Atom.app/Contents/Resources/app.asar/src/buffered-process.js:235:18)
  at emitTwo (events.js:87:13)
  at ChildProcess.emit (events.js:169:7)
  at Process.ChildProcess._handle.onexit (child_process.js:1057:12)

Commands
  2x -1:35.2.0 core:move-left (atom-text-editor.editor.is-focused)
     -1:34.7.0 core:move-right (atom-text-editor.editor.is-focused)
     -1:34.4.0 editor:select-to-end-of-line (atom-text-editor.editor.is-focused)
 16x -1:34.2.0 core:select-left (atom-text-editor.editor.is-focused)
     -1:32.1.0 core:copy (atom-text-editor.editor.is-focused)
     -1:31.9.0 core:move-up (atom-text-editor.editor.is-focused)
     -1:31.7.0 editor:newline (atom-text-editor.editor.is-focused)
     -1:31.4.0 core:paste (atom-text-editor.editor.is-focused)
     -1:31 editor:move-to-first-character-of-line (atom-text-editor.editor.is-focused)
     -1:28.4.0 editor:move-to-end-of-line (atom-text-editor.editor.is-focused)
     -1:26.3.0 editor:newline (atom-text-editor.editor.is-focused)
  2x -1:25.2.0 core:save (atom-text-editor.editor.is-focused)
  3x -0:03.7.0 core:move-left (atom-text-editor.editor.is-focused)
     -0:03.0 core:move-right (atom-text-editor.editor.is-focused)
  7x -0:02.6.0 core:backspace (atom-text-editor.editor.is-focused)
     -0:00.1.0 core:save (atom-text-editor.editor.is-focused)

Config
{
  "core": {
    "disabledPackages": [
      "autoflow",
      "autocomplete",
      "language-c",
      "language-clojure",
      "language-coffee-script",
      "language-csharp",
      "language-go",
      "language-java",
      "language-mustache",
      "language-objective-c",
      "language-perl",
      "language-python",
      "language-ruby",
      "language-ruby-on-rails",
      "language-toml",
      "metrics",
      "spell-check",
      "linter-csslint"
    ],
    "themes": [
      "atom-light-ui",
      "atom-light-syntax"
    ],
    "audioBeep": false
  },
  "linter": {
    "lintOnChange": false,
    "lintOnEditorFocus": false,
    "showHighlighting": false,
    "showGutters": false,
    "showErrorInline": true,
    "statusBar": "Show all errors"
  }
}

Installed Packages
# User
atom-jshint, v2.0.0
autocomplete-paths, v1.0.2
highlight-line, v0.11.0
highlight-selected, v0.10.1
keyboard-localization, v1.4.3
language-css-plus, v0.3.0
language-php, v0.26.0
language-smarty-php, v0.5.0
linter, v1.0.0
linter-jshint, v0.1.6
linter-php, v0.0.15
php-twig, v4.0.0

# Dev
No dev packages

:crying_cat_face:

I'm looking at this, but any additional info would be appreciated. I don't see where linter or linter-jshint depend on lodash, so I don't know how this is being thrown.

It threw bucketloads of big red ERROR boxes on the top right corner after updating the plugin, but I did not restart Atom. I'll exit, kill the process, restart, and see if it still happens.

The stack trace for me references linter/lib/linter.coffee:296, and in particular:
291   getEditorScopesForPosition: (position) ->
292     try
293       # return a copy in case it gets mutated (hint: it does)
294       @editor.displayBuffer.tokenizedBuffer.scopesForPosition(position).slice()
295     catch
296       # this can throw if the line has since been deleted
297       []

Not sure why the stack trace would be bubbling up through this. Will keep digging.

@brianmhunt did you try a restart?

Had the same issue immediately after updating atom and linter. Updated, opened a js file (using eslint), got that error. Restarted atom, reopened the same js file, linter worked correctly with no errors.

Yes, and the problem is gone.

I think the old linter (and maybe linter-*) don't shut down properly during the upgrade, so you have old code in-memory. The new linter doesn't use lodash so it's been uninstalled.
I think restarting atom or ctrl+alt+r to reload will fix it.

To the next person to encounter this: Please let us know if View > Reload (ctrl+alt+r) fixes this.

@AsaAyers Yes indeed, that fixes it (keyboard binding in my Mac is alt-shift-cmd-L).

@mrextreme Thanks for the solution!

confirmed from module.js 330
Error: Cannot find module 'lodash'
  at Module._resolveFilename (module.js:328:15)
  at Function.Module._resolveFilename (/Applications/Atom.app/Contents/Resources/app.asar/src/module-cache.js:383:52)
  at Function.Module._load (module.js:270:25)
  at Module.require (module.js:357:17)
  at require (module.js:376:17)
  at LinterCsslint.Linter.getEditorScopesForPosition (/Users/david/.atom/packages/linter/lib/linter.coffee:291:31)
  at LinterCsslint.Linter.computeRange (/Users/david/.atom/packages/linter/lib/linter.coffee:337:5)
  at LinterCsslint.Linter.createMessage (/Users/david/.atom/packages/linter/lib/linter.coffee:16:3)
  at LinterCsslint.<anonymous> (/Users/david/.atom/packages/linter/lib/linter.coffee:235:37)
  at Function.self.forEach (/Users/david/.atom/packages/linter/node_modules/xregexp/xregexp-all.js:542:22)
  at LinterCsslint.Linter.processMessage (/Users/david/.atom/packages/linter/lib/linter.coffee:236:7)
  at /Users/david/.atom/packages/linter/lib/linter.coffee:165:7
  at triggerExitCallback (/Applications/Atom.app/Contents/Resources/app.asar/src/buffered-process.js:213:47)
  at ChildProcess.<anonymous> (/Applications/Atom.app/Contents/Resources/app.asar/src/buffered-process.js:235:18)
  at emitTwo (events.js:87:13)
  at ChildProcess.emit (events.js:169:7)
  at Process.ChildProcess._handle.onexit (child_process.js:1057:12)

@DavidAwad did you try the solution by AsaAyers?

@AsaAyers 's solution of  view > Reload worked for me, though I had to do it via the GUI - neither alt-shift-cmd-L nor ctrl+alt+r keybinds seemed to work for me.

Closing as not really a bug but an update issue.


 We just uploaded a new gif walkthrough that shows all the core functionalities. I sincerely apologize for the delay.

:+1: Good work so far on the group project. Your team has made great progress in the last week. Hope you are proud of what you have achieved in ~6 weeks.

Consider taking actions on the review comments and please create [milestones] (https://github.com/fitness-buddy/Fitness-Buddy-Group-Project/milestones) for each of your sprint. Good to see the tasks being equally distributed among team members.
Good to see all the members are [contributing] (https://github.com/fitness-buddy/Fitness-Buddy-Group-Project/graphs/contributors) to the project
Good work implementing the core flows. You guys have made great progress in sprint 2 and it seems like most of your application logic is in place.
Good to see that you have already started adding partial UI polish to your app.
Keep working on integrating the core flows and make sure all pieces fit together perfectly.
Consult with your mentors to get their feedback as often as you can. Remember they are here to help!
While working on polishing your app for next sprint, remember that your app follows the [android design guidelines] (http://guides.codepath.com/android/Android-Design-Guidelines) and also benchmark your app on sites such as [android app patterns] (http://www.android-app-patterns.com/) to improve the UI/UX.

Take time this week to clean up and polish your app. Generally, most of these tasks are small and easy, but go a long way in making an impact on how your app will get perceived. I would also encourage you to start thinking about coming up with a user story for the demo day. It is the apps with the most appealing story that gains the most attention on the demo day. Excited to see your progress next week!


refactor: simplify code, remove spaces

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


Grammatical fix

Changed grammatical errors such as diction and spelling mistakes.

[x] I have read freeCodeCamp's contribution guidelines.
[x] My pull request has a descriptive title (not a vague title like Update index.md)
[x] My pull request targets the master branch of freeCodeCamp.
[x] None of my changes are plagiarized from another source without proper attribution.
[x] My article does not contain shortened URLs or affiliate links.

If your pull request closes a GitHub issue, replace the XXXXX below with the issue number.
Closes #XXXXX

Congrats @TrangNgu65 on your first pull request (PR)! 🎉
Thank you for your contribution to the page! 👍
We're happy to accept these changes, and look forward to future contributions. 📝


Reading string

Hi, Thank you for this beautiful package.
I am new to javascript and using HDF5 files. In Python we do dataset.asstr() Would you know how to read strings in js?
In the example file you provided, I presume the file types, is a string. Would you be able to show me how you read that into the browser? How can I modify the second line below?
const spatialPostionDataset = await hdfFile.get('/replica10_chr1/types')
const getString = await spatialPostionDataset.asstr();

Thank you very much.

I'm not sure I understand the question, spatialPostionDataset in the example is not a string, and cannot be converted to one, it is a 'dataset' in the hdf5 file.   Datasets are converted to javascript objects in the jsfive reader this is built on.  The object has several properties,  'dtype' I think is a string.   I'm not sure what you are referring to by types.
You can get a string representation of spatialPositionDataset,  but its not going to be anything useful.  It's probably something like "Object".
What are you actually trying to do?

Ahh I see types, that is not a file is an HDF5 path.

Apologies for my confusing question. Yes types is a dataset that contains elements that are of dtypestring, I was wondering how do you load that into a javascript object.
In python, I would say how can I load the contents of the types datasets as a list of strings into a variable.
some like : ['B3', 'B3', ... ]

No problem, I think I'm the one who was confused.   Well it should be as simple as this
const typesDataset = await hdfFile.get('/replica10_chr1/types')
const types = await typesDataset.value

However there is a problem appears to be a problem, specifically it looks like jsfive (which this is based on) does not support the variable length string type.   I will look into fixing that.  In general conversions to the specified type are handled automatically,  the value attribute will return an array, or array of arrays if multidimensional,  of the values.   There is no conversion.
RE extracting and printing array contents as strings, in general you don't need to do anything to a primitive object to "print" it (I assume you mean console.log()),  it will happen automatically.

Looking at jsfive (itself a port of pyfive),   it looks like variable length strings are not supported for datasets, they are supported for attribute values.   This looks straightforward to fix, I have it on my list.

OK, that was an easy fix.   The code below will return the variable length string dataset 'types' as an array of strings.  There is no equivalent to the python .asstr(), but I don't think it should be needed.
If building from source you will need to "npm install" again as the jsfive dependency has changed.
        const hdfFile = await openH5File({path: "test/spleen_1chr1rep.indexed.cndb"})
        const typesDataset = await hdfFile.get('/replica10_chr1/types')
        const types = await typesDataset.value

        // type = ['B3', 'B3', ....] etc

BTW there are lots of awaits because most of the functions in this library are asynchronous because they go back to the file for something.  Python doesn't really have an equivalent to this.  Without the 'await' you get a Promise for the result.   This is not normal looking javascript (so many awaits), its just the nature of this library.

Wow, I'm incredibly grateful, @jrobinso! The program is now working perfectly, thanks to your help. Your patient explanation of the syntax was greatly appreciated.
I didn't realize that you were the creator of IGV. It's truly an honor to have had the opportunity to correspond with you. Thank you once again for your assistance.

Your welcome.  Ta da,  issue #1 resolved.   There should be some kind of prize or badge for filing the first issue on a project.


MINOR: TopologyTestDriver should not require dummy parameters

TopologyTestDriver comes with a paper cut that it passes through a
config requirement that application.id and bootstrap.servers must be
configured. But these configs are not required in the context of
TopologyTestDriver specifically. This change relaxes the requirement.
Committer Checklist (excluded from commit message)

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation (including upgrade notes)

Only flaky tests failed. I updated the corresponding Jira tickets.

Thanks @mjsax . Your suggestions sound good to me. I'll circle back on this PR in a bit.

retest this please

@vvcephei -- Random thought: with this change, we still require people to pass in Properties object. As it can be empty, I am wondering if we should do a small KIP and add a constructor that does not require to pass in a Properties object?

Closing in favor of https://github.com/apache/kafka/pull/9477, since I've recycled my fork since opening this PR and can no longer update the PR.


Bug: Harvester

Hi, i have a bug, when setup a harverster.
WARNING: coremods are present:
llibrary (llibrary-core-1.0.11-1.12.2.jar)
MicdoodlePlugin (MicdoodleCore-1.12.2-<IP_ADDRESS>.jar)
iceandfire (iceandfire_1.12.2_1.8.2.jar)
TransformLoader (DynamicSurroundings-1.12.2-<IP_ADDRESS>.jar)
EnderCorePlugin (EnderCore-1.12.2-0.5.72-core.jar)
Contact their authors BEFORE contacting forge
// Don't be sad, have a hug! <3
Time: 5/5/20 2:30 AM
Description: Ticking block entity
java.lang.NullPointerException: Ticking block entity
at io.moonman.emergingtechnology.machines.harvester.HarvesterTileEntity.isIdle(HarvesterTileEntity.java:447)
at io.moonman.emergingtechnology.machines.harvester.HarvesterTileEntity.cycle(HarvesterTileEntity.java:201)
at io.moonman.emergingtechnology.machines.MachineTileBase.func_73660_a(MachineTileBase.java:38)
at net.minecraft.world.World.func_72939_s(World.java:1838)
at net.minecraft.world.WorldServer.func_72939_s(WorldServer.java:613)
at net.minecraft.server.MinecraftServer.func_71190_q(MinecraftServer.java:767)
at net.minecraft.server.dedicated.DedicatedServer.func_71190_q(DedicatedServer.java:397)
at net.minecraft.server.MinecraftServer.func_71217_p(MinecraftServer.java:668)
at net.minecraft.server.MinecraftServer.run(MinecraftServer.java:526)
at java.lang.Thread.run(Unknown Source)

Hi,
Thanks for the bug report!
Which version of Emerging Technology are you using? I believe this bug is from an older release, so updating to latest should resolve the issue.
Cheers

Hi,
Yap, i used to old version 1.3.9-beta.

Hi,
Unfortunately the bug is in that version. Please make a backup of your world and also as a precaution break and replace any harvester machines before updating 😁
Thanks!


Fix a bug in HttpPostEmitter

Fixes #8204.
The bug was introduced in #5592.

This PR has:

[x] been self-reviewed.

Duplicate of #8205


refactor(interactive): Replacing nlohmann-json with rapidjson

What do these changes do?
The main change in this PR is the addition of a new submodule: rapidjson, which replaces nlohmann-json with rapidjson.
#4143

TODO: make sure the nlohmann json is fully removed in all code @zhanglei1949

@lidongze0629 Is rapidjson installed system-wide in graphscope?

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 34.40%. Comparing base (4eadc2e) to head (e9895a7).
Report is 56 commits behind head on main.

Additional details and impacted files

@@             Coverage Diff             @@
##             main    #4194       +/-   ##
===========================================
- Coverage   46.45%   34.40%   -12.06%
===========================================
  Files         173      126       -47
  Lines       16171    13209     -2962
===========================================
- Hits         7512     4544     -2968
- Misses       8659     8665        +6

see 162 files with indirect coverage changes

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 0662b37...e9895a7. Read the comment docs.


Added swiftenv to '.travis.yml' to recognize content of '.swift-version'

Without using either swiftenv or cocoapods .swift-version doesn't appear to be recognized.

Codecov Report

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

@@           Coverage Diff           @@
##           master      #20   +/-   ##
=======================================
  Coverage   91.98%   91.98%
=======================================
  Files          13       13
  Lines         549      549
=======================================
  Hits          505      505
  Misses         44       44

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 5d5e3d3...4299b07. Read the comment docs.


Replace Anjelique Loveless' Hex-Blaster and Redeemer's Pistol with proper items

The items she was carrying were modified dueling pistol and arquebus instead of the proper items from the pack.

Reexporting data from Foundry also stripped linkedWeapon flags from the attacks. Please check if this is intentional.
I've deliberately kept the item ids the same, even though the items were added to the actor from the pack, as I don't see a reason to change those.

Reexporting data from Foundry also stripped linkedWeapon flags from the attacks. Please check if this is intentional.
I've deliberately kept the item ids the same, even though the items were added to the actor from the pack, as I don't see a reason to change those.

The linkedWeapons were likely removed when the original weapons were deleted from inventory. These need to be present for CriticalSpecialization to function correctly.

I've manually edited in the flags and weaponType property as I don't see a way to set it in Foundry.

I redid the strikes in Foundry with #16071


Use 'as' keyword instead of explicit cast for MobileServiceClient type conversion to avoid potential InvalidCastException

MobileServiceClient internalClient = (MobileServiceClient)client; explicit type conversion could throw InvalidCastException in the runtime, 'as' type conversion will return null in this case.

@soninaren or @pragnagopa, can you take a look?

Looks good to me. :shipit:

:+1:


feat: support spawnOpts for geckodriver child process

I am currently migrating Cypress to use webdriver and geckodriver for our firefox automation. We have the needs to propagate some environment variables to the geckodriver process (better outlined in this bugzilla comment), which we are patching this package to accomplish now. This PR is to move this patch upstream as a contribution.
In order to propagate environment variables to the firefox process started with geckodriver, the environment variables need to be passed to the geckodriver process directly in order to be passed to firefox. This is important for setting MOZ_ prefixed variables, like MOZ_HEADLESS_HEIGHT or MOZ_HEADLESS_WIDTH. This PR allows spawn options to be passed into the geckodriver process.

Great stuff, LGTM 👍

awesome I will get the docs updated then we should be good to go!

docs updated @christian-bromann . Thank you for the really fast review on this!


Web API Authorization

Hi there,
Are there any plans to include the "Client credentials flow" https://developer.spotify.com/web-api/authorization-guide/#client-credentials-flow Auth headers?
I'm unable to figure out how to provide an access token, and would like o make it possible to make simple calls without logging a user in.
Thanks for any advise on this.
Cheers!

@mmmmyers, is that possible? The Spotify docs say that the Client Credential flow must include a server side exchange.

Hi. Yep you're right.
I ended up using https://github.com/thelinmichael/spotify-web-api-node to get a token using the client credentials method and then subscribed to this from the client to create auth headers and pass the token to any Spotify calls.

@mmmmyers, Thanks, that could be really helpful. Really annoying to set up a backend just for that though 0_o


[v6.0.0] Discussions and proposals

Since v6.0.0 the lib should use Android's Keystore to encrypt data for better security purposes before saving it into shared preferences.
The problem
Data stored using RNSInfo's versions > 6 was saved in Android's shared preferences without keystore encryption then releasing v6.0 these data could be lost?
On the other hand, data stored using keystore's branch wouldn't be affected by v6
Checklist

[x] Improve documentation
[x] Create a branch which merges master and keystore
[x] Release an alpha version
[x] Add support for tvOS and MacOS in react-native-sensitive-info.podspec
[x] Merge everything into master
[ ] Fix macOS build error #222
[ ] Find a way to automatically migrate data from shared preferences to keystore? (should the library itself handle this?)

Official RN docs included your library to the Security page https://reactnative.dev/docs/security. It would be amazing if eventually we get Android's Keystore as default storage :)

@kneza23 thanks for pointing it out! I didn't know 😱  Yeah, I think it is time to do this migration

This afternoon I will create a new branch from master and I'll merge keystore into that branch. So, we gonna have a starting point for this 👏 👏 👏

Already merged in keystoreAsDefault. Also, it includes the  new example app, but it is a WIP 😄

There are a new release available in npm which includes keystore by default. For more information, please read here.

Is there a solution for data migration? I would love to integrate this version but I'm also afraid that it will cause quite some troubles to users that have data saved..

Is there a solution for data migration? I would love to integrate this version but I'm also afraid that it will cause quite some troubles to users that have data saved..

Unfortunately there is not. Maybe we need an extra method to read from sharedPreferences without using keystore something like getAllUncryptedDataFromSharedPreferences and then every users should handle saving all these infos again using setItem and now everything will be encrypted in Android.

@mCodex That would be ideal... I think what we need is to have a way to trigger the migration from everything that is stored on SharedPreferences to the KeyStore, keeping the same structure and then deleting it from SharedPreferences. That would save the hassle of the first time run after upgrading.

@mCodex That would be ideal... I think what we need is to have a way to trigger the migration from everything that is stored on SharedPreferences to the KeyStore, keeping the same structure and then deleting it from SharedPreferences. That would save the hassle of the first time run after upgrading.

Yeah, I couldn't agree more. This is why v6.0 is yet in alpha release. I don't want to developers updating RNInfo and their users losing data. On the other hand, there is a work to do to handle this scenario but no one is taking care of it right now. I'll see if I can code something to speed up this release.

@mCodex  when are your hope to release v6, we are waiting for great news ❤

Can you write the changes between alpha versions?
and the alpha version is stable to use in production new?

@mCodex That would be ideal... I think what we need is to have a way to trigger the migration from everything that is stored on SharedPreferences to the KeyStore, keeping the same structure and then deleting it from SharedPreferences. That would save the hassle of the first time run after upgrading.

Yeah, I couldn't agree more. This is why v6.0 is yet in alpha release. I don't want to developers updating RNInfo and their users losing data. On the other hand, there is a work to do to handle this scenario but no one is taking care of it right now. I'll see if I can code something to speed up this release.

Do you need any help with this?

@mCodex That would be ideal... I think what we need is to have a way to trigger the migration from everything that is stored on SharedPreferences to the KeyStore, keeping the same structure and then deleting it from SharedPreferences. That would save the hassle of the first time run after upgrading.

Yeah, I couldn't agree more. This is why v6.0 is yet in alpha release. I don't want to developers updating RNInfo and their users losing data. On the other hand, there is a work to do to handle this scenario but no one is taking care of it right now. I'll see if I can code something to speed up this release.

Do you need any help with this?
@mCodex

Hi Marcus, of course! Being honest I still haven't looked into this yet.
PRs are always welcome.

@mCodex I'll take a look then

In lieu of some kinda wholesale migration to deal with old unencrypted values in shared preferences, we have cooked up something super simple for our app: when we call getItem() we wrap it in a try/catch and (if it fails) then call getItem() again with a { dontDecrypt: true } option we patched into the library.
The patch is just a one line change to RNSensitiveInfoModule's getItem() method:
    @ReactMethod
    public void getItem(String key, ReadableMap options, Promise pm) {
        // ...omitted...
        if (value != null && options.hasKey("touchID") && options.getBoolean("touchID")) {
            // ...omitted...
//****
// The following line is the only one we changed (it used to be just else if (value !== null) {)
        } else if (value != null && !(options.hasKey("dontDecrypt") && options.getBoolean("dontDecrypt"))) {
//****
            try {
                pm.resolve(decrypt(value));
            } catch (Exception e) {
                pm.reject(e);
            }
        } else {
            pm.resolve(value);
        }
    }

Again: super simple. Maybe too simple... and it does require the caller to do some work so still a breaking change. This could be made completely transparent (to callers) by dropping the dontDecrypt option we added and instead changing pm.reject(e); to pm.resolve(value) in the function I pasted above... though that may be dissatisfying too. Definitely not as satisfying as a real wholesale migration. But if this or some variant of it seems like something you'd like to have in the library I am happy to submit a PR.

Hi guys. Any news or estimates on this?

Hi, is it possible to include fail attempt for each biometric authentication for both Android and iOS?

Hi, is it possible to include #264 as well? That will greatly improve the user experience.

I am using  "react-native-sensitive-info": "^6.0.0-alpha.9" on React Native Windows 0.64.7. I think that module autolinking does not work, it is not done after calling npx react-native autolink-windows. There is no any changes into AutolinkedNativeModules.g.cs

I am using "react-native-sensitive-info": "^6.0.0-alpha.9" on React Native Windows 0.64.7. I think that module autolinking does not work, it is not done after calling npx react-native autolink-windows. There is no any changes into AutolinkedNativeModules.g.cs

Manual linking seems to work in App.xaml.cs PackageProviders.Add(new RNSensitiveInfoCPP.ReactPackageProvider());

Hi. May I know whether 6.0.0 supports Face Recognition for Android?

I would like to propose a delete all function

Is macOS support added ?

Are there any news on the data migration part?
Version 6.x is documented as stable but it looks like it's actually still considered alpha because of the data migration. So I think many projects are stuck with 5.x until there is either a silent migration or at least some workaround to ensure no data is lost.

Are there any news on the data migration part?
Version 6.x is documented as stable but it looks like it's actually still considered alpha because of the data migration. So I think many projects are stuck with 5.x until there is either a silent migration or at least some workaround to ensure no data is lost.

Any update on the issue? The data migration is a very important part for us because we don't want all our users to login again.

Is there a way to opt out of encryption? one of the things that I value a lot is backing up the data, and in the past I used a library on flutter that allowed for optional encryption on android, but all the libraries I saw on react-native use encryption or don't use SharedPreference.


Create a new pull request by comparing changes

Co-authored-by: XhmikosR<EMAIL_ADDRESS>

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 95.746%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
1983

Relevant Lines:
2031

💛  - Coveralls


Create csi-flex CSI plugin

This epic tracks issues related to creating a new CSI plugin, csi-flexvolume.
This CSI plugin would translate the CSI RPCs into k8s FlexVolume calls.
This would allow any existing Flex Volume driver to be called via CSI. The plugin would be responsible for making the calls to the Flex Volume driver according the spec.

Combined with #1037, this would allow Docker to consume k8s Flex Volume drivers.

Hey @codenrhoden,
Interesting data point for you on this one. As far as I can tell REX brings the majority of platforms that are available for Flex endpoints. I wonder if this is necessary since simple adding CSI support to REX brings brought majority of platforms using Flex over right away? Otherwise it might be interesting to see which platforms have a good Flex story that we aren't tracking or that might benefit here.
https://docs.google.com/spreadsheets/d/1hreEQeZv37JnnkY7PtSrwE6E-X5f4RxJr6bBovS9iAI/edit#gid=1768322522
How about the opposite? Build a CSI plugin and get Flex support? Lets make sure we are clear which way the translation is occurring and that we are looking at attracting people to develop CSI plugins that are REX compatible which then take advantage of Flex/Docker support in addition to CSI vs shims which might be short lived.

Hi Clint,
Please see my comment on the Docker issue for a review of the following reasoning.
We're trying to centralize everything into a CSI framework so that all fixes and features are based on CSI. And because we can already load CSI plug-ins externally, and the ask was to be able to consume Flex plug-ins by REX, I proposed a CSI->Flex adapter as a means of easily introducing runtime, Flex support to REX.
Hopefully this clears up the confusion.

Thanks for the update @akutz. Lets chat about it this week. I think https://github.com/codedellemc/rexray/issues/1037#issuecomment-331737174 is the interesting one that may have the longer term value. It would be great to mock up some basic diagrams to make sure the translation and direction is clear.


Example fix for accidental event listener fire and double init on fir…

…st page load for Chrome desktop

#61

Wow, this is excellent. I had been trying to track this bug down for awhile, and it's hard to reproduce, so I figured it was probably a race condition of some kind, but couldn't figure out where.
Thank you thank you thank you! ❤


[DOP-19933] - update worker, scheduler, keycloak documentation

Change Summary

Add Worker, Scheduler and KeycloakAuthProvider documentation

Related issue number

Checklist

[x] Commit message and PR title is comprehensive
[x] Keep the change as small as possible
[ ] Unit and integration tests for the changes exist
[ ] Tests pass on CI and coverage does not decrease
[x] Documentation reflects the changes where applicable
[ ] docs/changelog/next_release/<pull request or issue id>.<change type>.rst file added describing change
(see CONTRIBUTING.rst for details.)
[x] My PR is ready to review.

BTW, could you please update the architecture diagram? I think including Excel among the external systems might be confusing

BTW, could you please update the architecture diagram? I think including Excel among the external systems might be confusing

updated


[Bug]: Capitalization of Package.jl in Zotero title

Debug log ID
GZSDI9US-refs-euc
What happened?
Thanks for creating that nice package; it really helps me a lot :) However, I found a problem with the apply title-casing to titles option in some cases: Titles like
ControlSystems.jl: A Control Toolbox in Julia
will be exported as
{{ControlSystems}}.Jl: {{A Control Toolbox}} in {{Julia}}
with wrongly capitalized .Jl. Apparently, it treats the . as a sentence-end marker even without whitespace after it.

I could shift the bracing, but I'm using Zotero's title-caser under the hood, and that transforms

ControlSystems.jl: A Control Toolbox in Julia

into

ControlSystems.Jl: A Control Toolbox in Julia

so shifting the bracing doesn't solve your problem (this will also be the case for Zotero-generated bibliographies for a title-cased style), but if that is fixed in Zotero, BBT will automatically follow. In the mean time, the Zotero-supported way to get the output you want is to change the title into

ControlSystems.jl: A Control Toolbox in Julia

Sorry I was on vacation. Great tip! The  in the title is all I need for know.  If i find time I'll report it in the Zotero forums, still think the default behavior is rather agressive.
Thanks for pointing me in the right direction and thanks for maintaining better-bibtex! :)


black formatter somehow formatted the bazel build files

Currently using VSCode 1.86.1 with Black Formatter v2024.0.0.
The Formatter seems to start to format the bazel build files, is there any way to stop that? Thanks.

@GTRay Is the language for those files set as Python? You could explicitly set the language type to plain text to prevent it from being formatted. You can also try the --force-exclude flag in black which takes in a regex. I recommend the changing the language of the files.

Gotcha, that is probably why, let me give it a try then. Thanks.

After installing the vscode bazel extension, it seems to have fixed the issue. My guess is that the bazel extension detect the build files as Starlark files as in https://github.com/microsoft/vscode/issues/133297.


[SPARK-16586][core] Handle JVM errors printed to stdout.

Some very rare JVM errors are printed to stdout, and that confuses
the code in spark-class. So add a check so that those cases are
detected and the proper error message is shown to the user.
Tested by running spark-submit after setting "ulimit -v 32000".
Closes #14231

Test build #63281 has started for PR 14508 at commit 4ed4483.

Test build #63284 has started for PR 14508 at commit 5e9c042.

Test build #63281 has finished for PR 14508 at commit 4ed4483.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/63281/
Test PASSed.

Test build #63284 has finished for PR 14508 at commit 5e9c042.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/63284/
Test PASSed.

Merged build finished. Test PASSed.

Merging to master.


Add differential build for PR

🚀 Feature
When a change is just for particular configs we want to build a configuration with includes these configs as in principal al configs shall be completely independent and so isolated...
We may use GH CLI, ask if the change is only the one config and then skip all others...
Our CLI: input PR number and the config path and return bool if the config shall be build
Logic: build particular configs in all changes are only in configs and this is one of the changed
GH action: for execution steps add if: ... with skip if no need for building
Motivation
we want to be as efficient as possible so do not build anything which is not really needed
also taking too many resources with growing ecosystem size may suck pool for other our projects as the pool org-wide shared
Pitch
the targeted build will speed up PR checks and lower the costs
Alternatives

Additional context

seems GH CLI does not offer a simple list of changed files, but this could work:
git --no-pager diff --name-only FETCH_HEAD $(git merge-base FETCH_HEAD main)

see: https://stackoverflow.com/a/25071749/4521646

we can set one job for all which would be determining changed configs and set it as output,
see https://stackoverflow.com/a/61236803/4521646

Azure pipelines:
conditional skip for jobs:

https://docs.microsoft.com/en-us/azure/devops/pipelines/process/conditions
https://docs.microsoft.com/en-us/azure/devops/pipelines/process/expressions

sharing job outputs:

https://docs.microsoft.com/en-us/azure/devops/pipelines/process/variables#use-outputs-in-a-different-job


-Dkarate.config.dir with full path on windows

Hi,
I want to test karate with dynamic variables for my clients.
I try to launch it with this command but it not work
Command :
java -jar "-Dkarate.config.dir=C:/Users/1234/Documents/Projects/Sace/IntegrationTests.City/bonneuil/configurations" karate.jar -e itg -T 5 -o C:/Users/1234/Documents/Projects/Sace/IntegrationTests.City/results/bonneuil/itg C:/Users/1234/Documents/Projects/Sace/IntegrationTests.City/bonneuil/features
Output :
11:13:53.338 [main] INFO  com.intuit.karate.netty.Main - Karate version: <IP_ADDRESS>
11:13:53.790 [main] INFO  c.i.karate.cucumber.CucumberRunner - Karate version: <IP_ADDRESS>
11:13:54.869 [pool-1-thread-1] WARN  com.intuit.karate - skipping bootstrap configuration: could not find or read file: karate-config.js, prefix: CLASSPATH
11:13:54.878 [pool-1-thread-1] DEBUG com.intuit.karate - skipping bootstrap configuration for env: itg - could not find or read file: C:Users1234DocumentsProjectsSaceIntegrationTests.Citonneuilconfigurationskarate-config-itg.js, prefix: FILE
11:13:54.897 [pool-1-thread-1] INFO  c.i.karate.cucumber.CucumberRunner - <<<< feature 1 of 1 on thread pool-1-thread-1: infotrafic/sectors.feature
---------------------------------------------------------
feature: infotrafic.sectors
report: C:\Users\1234\Documents\Projects\Sace\IntegrationTests.City\results\bonneuil\itg\TEST-infotrafic.sectors.xml
scenarios:  1 | failed:  1 | skipped:  0 | time: 0,92
---------------------------------------------------------

Any idea ?
Thanks a lot

no with the info you have provided. please use stack overflow or refer this:
https://github.com/intuit/karate/wiki/How-to-Submit-an-Issue


Syntax error when starting a Java style single-line comment like a statement in scope

Here's an example of a statement producing a syntax error:
create or replace and compile java source named "Util" as
public class Util {
   public static long toEpoch(java.sql.Timestamp ts) {
      // commit
	   return ts.getTime();
   }
}
/

However, when adding a no before the commit then no syntax error is reported.

to be fixed in the scope lexer


Runnymede, UK

http://maps.runnymede.gov.uk/ArcGIS/rest/services/rimslayers/MapServer/81

I'm interested in others' opinions here. The UK isn't quite as forgiving on its data licensing...

Their TOS disallow our use-case:

https://www.runnymede.gov.uk/article/4466/Terms-of-use

On Tue, Apr 11, 2017 at 3:07 PM, Ian Dees<EMAIL_ADDRESS>wrote:

I'm interested in others' opinions here. The UK isn't quite as forgiving
on its data licensing...
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/openaddresses/openaddresses/issues/2857#issuecomment-293414640,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA0EO4zvEuDaKri6YcCbfEoyArWEcYFeks5ru_mQgaJpZM4M6tNo
.

(I’m still generally fine adding data with ambiguous terms, especially in
the USA, but this one says not to.)
On Tue, Apr 11, 2017 at 3:42 PM, Nathaniel Kelso<EMAIL_ADDRESS>wrote:

Their TOS disallow our use-case:

https://www.runnymede.gov.uk/article/4466/Terms-of-use

On Tue, Apr 11, 2017 at 3:07 PM, Ian Dees<EMAIL_ADDRESS>wrote:

I'm interested in others' opinions here. The UK isn't quite as forgiving
on its data licensing...
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/openaddresses/openaddresses/issues/2857#issuecomment-293414640,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA0EO4zvEuDaKri6YcCbfEoyArWEcYFeks5ru_mQgaJpZM4M6tNo
.


TypeScript augmentation challenge

TypeScript Version: 1.8.0
Code Version: 1.2.0
Code:
I've put all the code in a gist, but the crux is that I want type system support for this line in example.ts:
store.dispatch(thunkedAction(1) as any);
I don't want to have to cast the thunkedAction result to any, but it's the only way I've found to make the compiler happy. It might be any of the following, but I've no idea which:

Compiler bug
Compiler feature gap edge case due to combination of typings globals, typings modules, npm modules, and local .d.ts files
Insufficiently helpful documentation
Insufficiently helpful messages
A developer so frustrated he can no longer think straight

I sincerely hope it's the latter, as then someone will be able to set me straight quickly.
Typings supporting the above code:
declare module "redux-thunk" {
    import { Middleware, Dispatch } from 'redux';

    export interface Thunk extends Middleware {}
    export interface ThunkInterface<R> {
      <S>(dispatch: Dispatch<S>, getState?: () => S): R;
    }

    var thunk: Thunk;
    export default thunk;
}

Failing augmentation for redux.Dispatch which seems to override node_modules/redux/index.d.ts for the entire project:
declare module "redux" {
    export interface Dispatch<S> {
        <R>(thunkAction: ThunkInterface<R>): R;
    }
}

Expected behavior:
Per reactjs/redux#1712, being able to augment redux.Dispatch<S>.
Actual behavior:
Wailing, gnashing of teeth, dumpster fires, sirens in the distance.

So i am not familiar with redux to know if the issue is in the usage or the declaration. The module augmentation seems to work fine for me using your project i am not sure i understand what is the issue.

A note for future issue reporting, a git repo is much better way to share the state than a gist.

@mhegazy The problem is that if you put the module augmentation in a separate file then it hides the module definition in node_modules/redux.
@garthk The only way I have found to get it working is to move redux's index.d.ts out of node_modules and wrap it's contents with
declare module 'redux' { ... }
Then module augmentations work as expected. I don't know enough about TypeScript to know why this behaves differently to using the typings distributed with redux, or how to solve it in a better way. What I have is an npm postinstall script that does all this, and as unsatisfactory as it is, it is the only way I have found that works.
If you or anyone else finds a better way, please let me know!

@mhegazy The problem is that if you put the module augmentation in a separate file then it hides the module definition in node_modules/redux.

The file needs to be a module. just like i did.
so something like this should work:
/// myAugmentationFile.ts
import * as redux from "redux";

declare module "redux" {
    export interface Dispatch<S> {
        <R>(thunkAction: ThunkInterface<R>): R;
    }
}

Yes, that works! I was just missing the import statement at the top of my augmentation file.
Thank you @mhegazy!

glad it is resolved.


README: fix link to preprocessing spec

This PR fixes a broken link to the preprocessing specification in the README.

Thanks!


Occasionally outdated versions of Security Advisories are provided

Describe the bug
We check the Security Advisory feed

https://technet.microsoft.com/en-us/security/rss/advisory

once every 3600s for updates. Since February 4th, ~2130 UTC we occasionally crawl outdated versions of

https://docs.microsoft.com/en-us/security-updates/securityadvisories/2017/4053440

in this way. Most of the time we get V3.0 of the advisory, sometimes we receive an older version.
To Reproduce
Steps to reproduce the behavior:

regularly check https://technet.microsoft.com/en-us/security/rss/advisory for advisories
check individual advisorie's source code
compare certain parts of the source to last imported version

Expected behavior
always get the latest version of each advisory
Screenshots
n/a
Desktop
n/a, only source code is processed
Additional context
In the example given, the source code of the latest version hints at the use of markdown language for the content of the provided advisories, e. g. 'sourcefile', 'sourcestartline' and 'sourceendline' in

Microsoft Security Advisory 4092731

According to tech team, these markdown features are not present in the source code of the outdated advisory we occasionally find at the same URL. Maybe there is something like loadbalancing involved and we occasionally receive

https://docs.microsoft.com/en-us/security-updates/securityadvisories/2017/4053440

from a server that does not know of markdown or didn't receive the (alleged) February 4th security advisory markdown update?
Edit
The issue may also be related to Akamai's CDN services.

UPDATE
last import of outdated version of advisory 4053440 was on February, 20th 23:03 UTC.
looking good since then. I'll keep You udated.


ISSUE-833: Fix failing AvroStreamsSnapshotDeserializerTest

Change-Id: Ic782797a78708d65a0a1c7c820e0ae7a3e0cf750

@satishd I have already pushed this fix to HDF-3.0-maint since it was breaking the build and was a blocker. Can you review? If you want to make any changes then we will need to make it in HDF-3.0-maint as well

@priyank5485 I am fine with these changes except using withEqual as mentioned in the comment.

I also don't have strong opinion on that. Please treat it as one of opinions. +1 on the change.

I also don't want to be too picky about it, but withEqual is just adding some extra, unnecessary, complexity to the code. As the method's javadoc states, it's better and advisable to simply pass the actual object. I would favor that to keep it simple.


chore: update axios peer dependency to >=0.26.0

It's been some time since the peer dependency for Axios has been bumped.

Closed due to branch name change to reflect the changes better.


Showing Wrong Time For Game Dev Fridays

Hey @mightyiam, we merged this: https://github.com/mobusoperandi/website/pull/260
but the website it still showing it at the wrong time... it should be at 3pm based on the yaml in main branch now 🤔

did it fail it build or deploy? can you add that stuff to display on github please.
Is this line here the correct way to do US eastern time? https://github.com/mobusoperandi/website/blob/master/mobs/mobile_game_dev_fridays.yaml#L10

Sorry. Will look into it.

Here it is:
https://github.com/mobusoperandi/website/actions/runs/10857662314/job/30134447229#step:8:17
Which valid entry would be the most correct? Here's the list.

Thanks @mightyiam, I'm trying to do the time for "America/New_York". Let me try it just like that similar to the vienna example in mobrpg.yaml 👍


build failure with repository on UNC path.

trying to build the repository, I run in to an error.  I almost exclusively store files on UNC paths.  Why?  Guaranteed there is a bug out there to be squashed when it comes to UNC paths.
Running Start-PSBootstrap resulted in
Installing PowerShell build dependencies
WARNING: Could not find 'dotnet', appending C:\Users\Carl\AppData\Local\Microsoft\dotnet to PATH.
WARNING: Still could not find 'dotnet', restoring PATH.
dotnet not present.  Installing dotnet.
Processing -File 'Microsoft.PowerShell.Core\FileSystem::\\svr-2015-01\User Documents\Carl\Git Repositories\PowerShell\tools\dotnet-install.ps1' failed: The given path's format is not supported. Specify a valid path for the -File parameter.
Windows PowerShell
Copyright (C) Microsoft Corporation. All rights reserved.

Try the new cross-platform PowerShell https://aka.ms/pscore6

Execution of { & $fullPSPath -NoLogo -NoProfile -File $fullDotnetInstallPath -Channel $Channel -Version $Version } by build.psm1: line 1541 failed with exit code -196608
At \\svr-2015-01\User Documents\Carl\Git Repositories\PowerShell\build.psm1:2036 char:17
+                 throw $errorMessage
+                 ~~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : OperationStopped: (Execution of { & $f\u2026h exit code -196608:String) [], RuntimeException
+ FullyQualifiedErrorId : Execution of { & $fullPSPath -NoLogo -NoProfile -File $fullDotnetInstallPath -Channel $Channel -Version $Version } by build.psm1: line 1541 failed with exit code -196608

PowerShell doesn't even support its own path syntax for its -file parameter.    This appears that this is just a problem with Windows PowerShell, which is being called to support the dotnet installer on Windows.  It looks like PowerShell core does not exhibit this issue.

It is not clear that you want - build PowerShell Core from UNC or report an language issue/bug? For first I think it make no sense to fix build scripts until we will really need this in development process. For second please make simple repo steps to demo a problem you want fix.

Step 1:  Attempt to build a fresh clone of PowerShell Core from a UNC path in a fresh environment.
The build process fails at this point:
https://github.com/PowerShell/PowerShell/blob/9140e421eceeef9d92cf671cc6aaa0782ea343cd/build.psm1#L1541
The actual issue is that Windows PowerShell's FILE parameter does not accept 'provider path notation' and the UNC path when resolved by JOIN-PATH results in a PSPATH that contains the provider which is then sent to Windows PowerShell which fails. I am really surprised that more people do not use UNC paths, but I suppose even 'nix users utilize mount points (links) instead of UNC paths.
I relocated the clone of the repository to a local drive, and let the install-dotnet script run there, but I suspect that the install-dotnet script would have worked in a UNC path, but didn't try it.  I could try it, and if it works, I think I could suggest a solution to the install-dotnet function that would allow for calling Windows PowerShell with the install-dotnet script path.
https://github.com/PowerShell/PowerShell/blob/9140e421eceeef9d92cf671cc6aaa0782ea343cd/build.psm1#L1540
$fullDotnetInstallPath = (Join-Path -Path $pwd.Path -ChildPath $installScript) -replace '^[^:]*::', ''

the install-dotnet script would have worked in a UNC path

@TravisEz13 Could you please comment this? Make sense to track/fix this?

Alternately:
$fullDotnetInstallPath = Join-Path -Path $pwd.ProviderPath -ChildPath $installScript

I agree this is an issue with the script, but building from UNC would not be officially supported as it creates issues with debugging.  But on the other hand, most people don't run in the supported configuration.  We only check that if you go to create a package.


Add code to run sass command to program

Have homepage.py run the sass command to generate the style.css file.  The goal is to remove the dependency on make

created a function to run the sass.js script