Concerns about the new Chef.node API

So I'm really worried that this new API is a line we shouldn't cross. We has so far avoided having per-run data (i.e. not truly global config et al) in globals, passing the node or run_context object through APIs as needed. This is certainly frustrating sometimes, but adding a global variable for this kind of indirection risks all the old campfire stories about global-driven spaghetti code. It is probably too late to pull this API from 12.3 but as a compromise could we mark them as explicitly internal and not subject to API compatibility? This would allow a do-over for 12.4, as I think @jkeiser is planning to majorly revamp the code that caused Chef.node to be added in the first place.

My understanding is that Chef class static methods are intended to be a
public facing API. They are global, but they are also singleton, and this
might be fine during the chef run time, as there are only one node and
run_context(top level). Are you concerned as a raw API or from other
libraries perspective its pain? Can you give examples on how this will be
harder to maintain? Given these are methods, they can use non global
components underneath, but this enables us to access the common gears
standard way. We already discussed how the top level class based static
methods will help us maintain version specific or breaking changes etc,
hence I'm asking.
On Apr 23, 2015 7:05 PM, "Noah Kantrowitz"<EMAIL_ADDRESS>wrote:

So I'm really worried that this new API is a line we shouldn't cross. We
has so far avoided having per-run data (i.e. not truly global config et al)
in globals, passing the node or run_context object through APIs as
needed. This is certainly frustrating sometimes, but adding a global
variable for this kind of indirection risks all the old campfire stories
about global-driven spaghetti code. It is probably too late to pull this
API from 12.3 but as a compromise could we mark them as explicitly internal
and not subject to API compatibility? This would allow a do-over for 12.4,
as I think @jkeiser https://github.com/jkeiser is planning to majorly
revamp the code that caused Chef.node to be added in the first place.
—
Reply to this email directly or view it on GitHub
https://github.com/chef/chef/issues/3275.

It means you can never be certain if a particular method varies based on node data or not. I don't have specific examples of why global variables are bad, nor do I think specifics are really needed. It is something this field learned the hard way, keeping the values that a method has access to limited to object data (read: things passed to other methods on the same object) and method arguments allows far simpler mental modelling of how a given section of code works. I can tell you for a fact there is not a single run_context, for example, as use_inline_resources calls dup on it for every action that is run (and Poise/Crazytown do similar things). I would much rather see a design pattern of passing the needed data in places that need it, it adds some extra arguments in places, but it will make things far more grokkable.

This is only intended to be used in situations where the node isn't easily accessible otherwise, such as when library files are evaluated. Using them when not absolutely required in core code is definitely discouraged, as is already documented in the code. For example, it'd be great if we could move LWRPs inside a Chef.lw_resource do ... end block in libraries, which would allow you to require them in test code (this change would also give us a sane path to supporting subclassing). Right now, we do some magic to make node, run_context, etc. available to LWRPs at eval time, which could not be done from a top-level binding context without some form of static method. Likewise, no data can be sent to the formatters/event handlers from a top-level context, since currently these objects are directly passed to related objects. Yet another example, is Ranjib's RFC for defining event handlers in library code--we need to have access to the run context in order to add the event handler to the set.
As with any global state, there's always potential for abuse. Even in Erlang, you can screw yourself pretty good with the process dictionary if you have a mind to. That said, making these objects available as (mostly) read-only static methods goes a long way to preventing the most egregious problems with global state and gives us the option of reducing the number of specialized file evaluation contexts in the future, which I think is worthwhile.

It reduces the need to build out the APIs for, say, calling Handlers by virtue of making it impossible to track what is using that data. The node object is still full of methods like include_attribute that can easily mutate global state. Saying "this is a huge, loaded footgun but it makes life easier" is literally the sound of tech debt being born. I agree that global state is hard to do correctly at the best of times, which is why I'm saying it is a bad idea and we shouldn't do that. As the person on the planet that has probably written the most code evaluated under libraries/ I can say I've found better solutions to every place that a global would have allowed a lazy approach.

No, it's not to "make life easier," there are things we want to do that are impossible otherwise (except for ObjectSpace, but that's rather worse), which I listed above. That you haven't yet needed the functionality doesn't diminish the value.

certain in behavior or data? currently many public facing APIs (like
resource, provider) uses these objects anyway, and they dont dupe it. Node,
run_context, events system are almost always passed on, in some way they
are already  global, this class to a great extend consolidates them. the
concern you have mentioned, is already their, you can tamper the attribute
of a node from resource, via run_context. why dont you share a concrete
example? As in a library writer would un-intentionally screw the chef run
due to this method? cause if someone is doing it intentionally i dont see
how we can stop that even without this.
on similar note, i always felt the config class was more of global state
pain, not these, cause node, run_context , events  even if global in their
essence, are implemented by pretty decent subsystems and instantiated as
object (unlike the config). Chef::Config is more prone to the problems that
you are concerned about
On Thu, Apr 23, 2015 at 8:26 PM, Noah Kantrowitz<EMAIL_ADDRESS>wrote:

It means you can never be certain if a particular method varies based on
node data or not. I don't have specific examples of why global variables
are bad, nor do I think specifics are really needed. It is something this
field learned the hard way, keeping the values that a method has access to
limited to object data (read: things passed to other methods on the same
object) and method arguments allows far simpler mental modelling of how a
given section of code works. I can tell you for a fact there is not a
single run_context, for example, as use_inline_resources calls dup on it
for every action that is run (and Poise/Crazytown do similar things). I
would much rather see a design pattern of passing the needed data in places
that need it, it adds some extra arguments in places, but it will make
things far more grokkable.
—
Reply to this email directly or view it on GitHub
https://github.com/chef/chef/issues/3275#issuecomment-95788559.

The difference with Chef::Config that makes it slightly less bad is that it is immutable, but I would certainly prefer if it wasn't a magic global (perhaps a #config on the run context). I have not yet found a use case that ended up being impossible despite making Chef jump through some pretty serpentine hoops. That is far from an exhaustive proof, but it is a vote in the "I've not needed it" from an expert.
Due to ObjectSpace existing we can't ever totally prevent this, but the leap from "is possible via heap munging" to "a supported API from Chef" is a huuuuge one. This will definitely allow kinds of very clever tricks, but it does so at a huge cost to maintainability and our ability to reason about the code by looking at it locally. If this is going to be used to power some internal features, at a minimum it can be marked as a private API (in the YARD sense, not the #private one) which will allow for reconsideration in the future. In places where we need to zigzag through a global, we should still call to "user code" with it as an argument so they are isolated from the terribleness of globals.

I only brought up ObjectSpace because it's the only other alternative that does what we want. Of course anyone using it for anything other than memory debugging is probably misguided.
Re: Chef::Config, we're getting a bit off in the weeds here, but it's 100% mutable, you can change chef_server_url, ssl_verify_mode, whatever you want, at any time. I think most (all?) classes that use it should have it passed in via DI, but there's no business argument for me to spend my time refactoring all that right now.
Again, just because you've not wanted to do something that needed this API, doesn't mean it's not valuable. Registering an event handler from library code is the perfect example. You must have access to the run context (or at least the event dispatcher it owns) to do this. I'll say that what you're advocating as good OO software design is correct for the general case, which is why run context and the event dispatcher are not currently singleton classes. However, we now have use cases we want to support where these things need to be accessible from a top level binding, which is the thing you can't do with a pure-DI pattern.

Is it true that the method_missing and related changes will make the only use of run_context and node go away?  If so, why not privatize the API when we make those changes, and reintroduce it when we have a specific compelling use case, so that we can have a concrete discussion around that?  APIs without users are begging for trouble :)  And it does seem prudent to exercise caution around global APIs in particular (not a blanket disapproval, but a real note of caution).
If library event handler registration is a real potential use case (or is it an actual one?), then let's discuss that case specifically :)  Is the use case a gem that provides an event handler, and when the gem is loaded we want it to start listening to events from the run_context?

Is it true that the method_missing and related changes will make the only use of run_context and node go away?

I don't see why they would. Can you explain why you think so?

If library event handler registration is a real potential use case (or is it an actual one?), then let's discuss that case specifically :) Is the use case a gem that provides an event handler, and when the gem is loaded we want it to start listening to events from the run_context?

https://github.com/chef/chef-rfc/blob/master/rfc039-event-handler-dsl.md
These are event handlers defined in library files within cookbooks, which need to create an event handler class, instantiate it, and then register it with the event dispatch object.

I don't see why they would. Can you explain why you think so?

I have no idea--I inferred it from @coderanger's initial comment.  Thus why I'm asking if they are true :)

https://github.com/chef/chef-rfc/blob/master/rfc039-event-handler-dsl.md

These are event handlers defined in library files within cookbooks, which need to create an event handler class, instantiate it, and then register it with the event dispatch object.

Ah!  So they should only attach to one run.  I grok.
Question: why not evaluate library files with a context so they can get information?  Like, instance_eval them in an object with run_context and node?  Seems like it would be generally pretty useful.

Question: why not evaluate library files with a context so they can get information? Like, instance_eval them in an object with run_context and node? Seems like it would be generally pretty useful.

This makes testing pretty frustrating because there's extra magic that's not easy to find or understand happening. You can't just require 'file_i_want_to_test' and go, you have to set up extra magic to eval things in the right context. This also makes testing LWRPs much more difficult than necessary, since you have to figure out that you need to call the magical incantations on the relevant LWRPBase class.

(This might solve the case in question, but it's actually not just about that--it feels like communicating run state to files in a cookbook/recipe as we evaluate them fits the Chef pattern pretty well.)

It may be possible to do this with terrible Binding hacks, like eval-ing library files in a specially crafted binding with the relevant things set as locals. In the case of Chef.event_handler {}, the event handler method would then have to grab the binding of the block and extract the locals. All of this is way more terrifying to me than just exposing some data that's pretty much exposed everywhere anyway via a static method. The binding magic is significantly more non-obvious (assuming it even works).

You can't use a require to correctly do it in a test anyway, unless you can guarantee a different handler load every time--in which case, there's no point in doing a require anyway, you may as well use an inline block.  Like, I don't think any test would work the way you are talking about.
As to scariness, we're already eval'ing, instance_eval'ing would be the only change.  No binding magics, just the self in which the library file is loaded, which is already a super typical case (Chef::Config for example).  No change at all to how any local variables work.

And I was about to offer that this case doesn't matter, because the library file could require a file from a gem that did the actual load work ... but that would fail on a second run in the same process because the require wouldn't even happen.  It feels like you need to pass actual context to do it right.

(To be clear, I think what @ranjib put in the RFC will totally work!  It just seems there may be a reasonable alternative that doesn't require globals.)

You can't use a require to correctly do it in a test anyway, unless you can guarantee a different handler load every time--in which case, there's no point in doing a require anyway, you may as well use an inline block. Like, I don't think any test would work the way you are talking about.

You don't need to do multiple stubbed Chef runs in your test, you just need the DSL to generate the class you want to test, then you test it like you would any other class, or like we do any internal class in core chef.

(To be clear, I think what @ranjib put in the RFC will totally work! It just seems there may be a reasonable alternative that doesn't require globals.)

I can't think of anything that isn't way worse.

I can't think of anything that isn't way worse.

I would say the better way is to use a registration pattern like we do with Resources. There is still a global, but it is hidden internally behind a method call. So Chef.event_handler would store the block you give it under some later time in the run (after loading the library file for example where is can instantiate the event handler and pass it the node object either via block args or an initializer. This still has a global in the mix to allow for registration, but unlike the node object it is very well defined about what state is stored and how it is manipulated. The node and run_context objects are more all over the place in what kind of data they store and how that data is mutated.

As for why we don't just revisit this later, once the method hits the public API, it will be a compat break to remove it. If we mark it as internal for now, we don't have to wait for Chef 13 to finish this discussion.

It'd also be nice to be able to get at the CLI options from knife.rb/config.rb but that's also impossible.  The Chef class can also be extended and safely used in recipe code without worrying about the problems of injecting new methods into the recipe DSL that might clobber someone's variable names.

#2403 is another example of a pre-existing bug that is addressed by Chef.node and Chef.run_context

@lamont-granquist Alternate solution with no global variables https://github.com/poise/poise/blob/master/lib/poise/helpers/lazy_default.rb#L20-L30


unable to run select queries

I am unable to run select queries while writes are happening fine. I tried on both web UI and CLI.
Build no. 0.9.5-nightly-827c513

show measurements
ERR: json: cannot unmarshal array into Go value of type tsdb.MapperOutputJSON

Looks like a dupe of https://github.com/influxdb/influxdb/issues/4561

I mean https://github.com/influxdb/influxdb/issues/4550


Sort MetricsDescriptorRequests on Name and MetricDescriptor.Name

Fixes #421
Ref https://github.com/GoogleCloudPlatform/opentelemetry-operations-go/pull/468

We may want to consider dropping the "sort" approach altogether and change to a "check everything expected exists and nothing unexpected exists" instead. I couldn't find an existing semantic equality checking function for arbitrary slices

That would also work

@dashpole please merge


Erros with Android 6

Whrn i Prove thsi transcations with Android 6 I have a problem whrn back to activity A(with stat activity again, not with back button) I can't touch anything I have thsi warning n=0, id[0]=0, x[0]=827.0, y[0]=1133.0, toolType[0]=TOOL_TYPE_FINGER, buttonState=0, metaState=0, flags=0x0, edgeFlags=0x0, pointerCount=1, historySize=0, eventTime=303259760, downTime=303259642, deviceId=4, source=0x1002 }
12-09 16:28:18.831 6865-6865/ad.andorratelecom.my_andorra_telecom
Only with Android 6 in Android 5 works fine

Sorry but is really hard to understand what is going on. Can you please provide more detailed information on what is happening to you?

It is very tricky, this code run good in Android 5 and above but not in Android 6.
If you us navigation up with start activity to return to previous activity in this activity you cant touch any element

I also encountered this situation in Android 4.4.4

@orangecoder  setExitTransition requires API level 21 maybe 4.4.4 is too slow

I have the same problem /:


[rewrite] RouteResolver bugs

Several routing issues seem to be present on latest RC.
This toy app attempts to demo mocked authentication logic.
https://jsbin.com/nuduba/edit?js,console,output
The default route is /home, which just has a render.
Next is /profile, which has render and onmatch. Onmatch checks to see if you're authenticated and redirects you to /login if you're not
/login renders a form which some delay after submission (no input validation) authenticates you and redirects you to where you were attempting to access (/profile or /home)
/logout has no render, just an onmatch which unauthenticates you and sends you back /home
Each render function returns a fragment whose first node is a heading, and whose second is the persistent Nav component, which displays either /login or /logout depending on authentication status

The bugs:

If you inspect the rendered links, /home and /profile are prefixed with #! as per the documentation. The third link, /login or /logout, is always in 'path' mode, ie without the hashbang. This doesn't seem to have any adverse effects (all links work as expected the first time round) but it's mysterious nonetheless.
When navigating to /profile, onmatch is always triggered, contrary to the documentation (I believe this is a good thing, mind)
But the /profile page's render function never triggers - it appears as though a RouteResolver can have either onmatch or render but not both
If I get routed to an onmatch route twice in a row, m.route.get returns nothing

Since the href changes, you must also set onupdate to  m.route.link (that's a potential gotcha, which we may want to document (adding onupdate to the description would be a good start).
Yes, I forgot to update the docs (I missed that sentence actually).
You forgot to call resolve() when authenticated to finalize the resolution.
You're using cdn.rawgit.com, which has probably cached an older version. I can't repro with the bare rawgit.com link which points to the current tip.

Right on all counts - it's all fixed here: https://jsbin.com/nuduba/edit?html,js,console,output


implementation Easy Issue (JavaScript)

Description
Implementation Easy Issue (JavaScript)
Print the sum of two numbers.

Merged

This is an automated message from Fork, Commit, Merge [BOT].

Thank you for your contribution! Your pull request has been merged. The files have been reset for the next contributor.
What's next?
If you're looking for more ways to contribute, I invite you to check out my other projects. Just click here to find more. These projects contain real issues that you can help resolve. You can also check out the Influences section in the README to find more projects similar to this one.
Also please leave a star to this project if you feel it helped you, i would really appreciate it.
I look forward to seeing your contributions!


Should ReactiveElement.getPropertyOptions be public?

In writing Apollo Elements I've had opportunity to do some hacking into ReactiveElement's lifecycle. Specifically, I wrote a TypeScript decorator which forwards fields from a controller to the host and vice-versa.
function defineOnReactiveElement<T extends ReactiveElement & ApolloControllerHost>(
  proto: T,
  name: string & keyof T,
  opts: DefineOptions
): void {
  // Run our property effects
  defineOnHTMLElement(proto, name, {
    ...opts,
    // In addition to any user-defined side-effects,
    // also notify the ReactiveElement lifecycle
    onSet(this: T, x: unknown) {
      const old = this[name];
      opts?.onSet?.call?.(this, x);
      this.requestUpdate(name, old);
    },
  });
  // And also run ReactiveElement's property effects
  const Class = proto.constructor as typeof ReactiveElement;
  // @ts-expect-error: i know it's protected
  Class.createProperty(name, Class.getPropertyOptions(name));
}

In doing so, I end up calling createProperty (which is public) with getPropertyOptions (which is protected). In order to lubricate this workflow for TypeScript users, should getPropertyOptions be public?

That sounds reasonable. Feel free to submit a PR for this.

I think in the longer term I'd like to encourage people to use multiple decorators together, including possibly us separating out some of the responsibility of @property() into @attribute():
class X extends LitElement {
  @attribute('foo-bar')
  @property()
  foo: string;
}

So even though for no I agree with @sorvell, I wonder if you could have a decorator which is meant to be used with @property()?

You mean like this?
  /**
   * If true, perform a query refetch if the query result is marked as being partial,
   * and the returned data is reset to an empty Object by the Apollo Client QueryManager
   * (due to a cache miss).
   *
   * The default value is false for backwards-compatibility's sake,
   * but should be changed to true for most use-cases.
   *
   * @summary Set to retry any partial query results.
   */
  @controlled({ path: 'options' })
  @property({ type: Boolean, attribute: 'partial-refetch' })
  partialRefetch?: boolean;

https://github.com/apollo-elements/apollo-elements/blob/dcccc4ca778378ad3f0b4823011680f7bbada8c8/packages/lit-apollo/apollo-query.ts#L117-L129

@bennypowers yes. Are you trying to consolidate that decorator to make @property() not necessary?
My main concerns are around us having to keep public APIs that we might be able to optimize away over time, and static analysis that understands @property() but not other decorators. I don't generally want tools to assume @property() is special, since getters can be reactive, but right now @property() is a convenient way to know the property-attribute association.

Are you trying to consolidate that decorator to make @property() not necessary?

No, I just want to lose the @ts-expect-error. I want composable decorators, too.


how can i get the instance of 'editor'

Hi, Thank you sincerely for this component which made me free, at the same time , there is something i doubt , please you could tell me anything about it.

how can i get the instance of 'editor' : const editor = ace.edit(id: string)
forgive my ignorance...

使用 @init 事件，第一个事件参数就是
https://github.com/CarterLi/vue3-ace-editor/blob/master/index.ts#L78

got it, thanks again


Improved translation up to "Prefer let-bindings over var-bindings whereve...

...r possible"
Corrected error in translation and made sentences into natural Japanese.

@pluis91 Thank you for correcting my Japanese.
It makes sense at all!


How to download bundle if I wasn't logged in when I purchased?

When I purchased my last bundle, i only provided an email address.
So I received a link by email to download the bundle without the intermediate login step.
Then pasted the email link in the browser location bar, then copied the _simpleauth_sess cookie value and used that, to no avail
humblebundle-ebook-downloader --format pdf --download-limit 1 --auth-token "${_simpleauth_sess}"
Starting...
Validating session...
An error occured, exiting.
Error: Could not validate session, unknown error, status code: 401
    at Request.request.get [as _callback] (/usr/local/lib/node_modules/humblebundle-ebook-downloader/index.js:114:17)
    at Request.self.callback (/usr/local/lib/node_modules/humblebundle-ebook-downloader/node_modules/request/request.js:185:22)
    at emitTwo (events.js:126:13)
    at Request.emit (events.js:214:7)
    at Request.<anonymous> (/usr/local/lib/node_modules/humblebundle-ebook-downloader/node_modules/request/request.js:1154:10)
    at emitOne (events.js:116:13)
    at Request.emit (events.js:211:7)
    at IncomingMessage.<anonymous> (/usr/local/lib/node_modules/humblebundle-ebook-downloader/node_modules/request/request.js:1076:12)
    at Object.onceWrapper (events.js:313:30)
    at emitNone (events.js:111:20)

The only thing that looks weird in the auth token are these characters right before the first vertical bar. This could create all sorts of escaping nightmares with my download command.
...\075\075|

Has anyone managed to successfully download an 'anonymous' bundle (one purchased without a login)? Is there any trick i should know?

Hi,
You will need to create an account, and claim the bundle to your account.
Then you should be able to copy the cookie value when logged in, and use the tool.
Instructions for how to do the claiming can be found at https://support.humblebundle.com/hc/en-us/articles/203523930-How-to-claim-a-Humble-Bundle-purchase-or-gift


update fluentbit to v3.1.4

What this PR does / why we need it:
Which issue(s) this PR fixes:

Fixes #
Does this PR introduced a user-facing change?

Additional documentation, usage docs, etc.:

Dockerfile has been updated in https://github.com/fluent/fluent-operator/pull/1266

Thanks @jiuxia211  - I had already built and shipped v3.14 images but forgot to do this!


Add hyperparameter config, use generic training interfaces

Currently, sklearn and keras training have separate pre-processing logic before their fit routines are called. Their configuration also loosely types the keyword arguments, by accepting kwargs. This opens the possibility for typos in configuration to go unnoticed, and makes it hard to document what options are available. It also puts model-specific concerns into the top-level routines, instead of being able to dispatch those concerns to Estimator classes.
This PR adds the concept of a hyperparameter configuration class for an Estimator, which contains all of the init arguments for that estimator. This is integrated into the TrainingConfig, and is the only part of the configuration that differs between different estimators.
Added public API:

Added OptimizerConfig and RegularizerConfig which replace the current arguments for optimizer and regularizer on DenseModel

Refactored public API:

Removed DenseTrainingConfig and SklearnTrainingConfig, added DenseHyperparameters and RandomForestHyperparameters which strongly type the hyperparameter configuration
Added hyperparameter class to the API for register_estimator
Renamed get_config_class to get_hyperparameter_class
Predictor now takes **kwargs in its API to satisfy mypy, but raises a TypeError if any are passed

Significant internal changes:

Modified Estimator classes to take a single "hyperparameters" dataclass argument, instead of multiple keyword arguments

added RandomForest estimator which wraps the existing SklearnWrapper estimator, and also provides functionality from now-deleted sklearn/_train.py

Removed target_scaler and n_jobs from the SklearnWrapper init, as there was no way to set these from configuration

[ ] Tests added

Resolves # [JIRA-TAG]
(Delete this for the commit message)
You are encouraged to check the PR against the Code Review Checklist.

Thanks Jeremy, the new interface is much cleaner! The responses to the couple of comments I left LGTM.

Integration tests passed https://app.circleci.com/pipelines/github/VulcanClimateModeling/fv3net/8551/workflows/c46866c3-1f89-467c-b87b-457ab89c69a1


Software vulnerability due to CVE-2016-6501

artifactory-client-java suffers from LDAP entry poisoning
CVE explains what the problem is.
At the company where i work we can't release software with CVE's above the rating of 7.5 so this problem blocks our release.
CVE discovered by OWASP

This issue was fixed before it was announced, thanks to a responsible security researcher discussing it with us.  Please upgrade to artifactory 4.11 or later, as per the CVE, and the issue will be fully addressed.  In general I would recommend upgrading out to 5.4.6, but if you can't upgrade to 5.x, 4.16.1 is a good choice as well.

Thank you for the information, I will communicate this within the company I work for.


Formatting error

Describe the bug
Using long usernames is resulting in formatting error on the top right corner of the flaskBlog.
Expected behavior
The formatting must be consistent with how it appears for short usernames
Screenshots

Desktop (please complete the following information):

OS: Ubuntu 22.04
Browser : Chrome
Version 119.0.6045.159 (Official Build) (64-bit)

Thank you


fix: improve default password policy to follow latest OWASP recommend…

…ations
fixes AM-526

I trying to apply the same pattern to our instance but I found "an issue".
The default PasswordValidation implementation validate if the password size is less or equal to 64: https://github.com/gravitee-io/gravitee-access-management/blob/491e8cc652650be1c0c21145a52a700d283f64b9/gravitee-am-service/src/main/java/io/gravitee/am/service/validators/password/impl/DefaultPasswordValidatorImpl.java#L49


I would like to create example for State Machine Design Pattern

please, let me know ur feedback , if you are ok, i can start it.

Seems awesome go for it

@owais4321 created PR - https://github.com/MLSA-Mehran-UET/Learn-to-code-java/pull/178, please help to review :bow:


Meteor not recognizing twbs:bootstrap?

Been sailing through most of the course heretofore without problem. Now, I added ian:accounts-ui-bootstrap-3 to my app, but for some reason, it doesn't seem to work. I get a console error:

"You have to add a Bootstrap package, i.e. meteor add twbs:bootstrap."

But I have the twbs:bootstrap package already added to my Meteor application, and can verify with meteor list. I've also removed accounts-ui, so there shouldn't be any conflict. The rest of my app's appearance is unchanged, which leads me to believe that - indeed - twbs:bootstrap is actually functioning fine!
Am I doing something wrong? Could this be some sort of bug?

Have you asked the author of the ian:accounts-ui-bootstrap-3 package?


 Only one goroutine has a write access to them go e.refreshLoop(). The goroutine does it without any synchronization. However the properites are read in many other places. So it's a kind of race.
Seems it's better to move these fields into a separate struct and add getters. The point is to use different syncs for Engine and the properties. It would be possible to read values in the most optimal way. Like atomic.LoadInt64 for Engine.Memory. Or we might try to use atomic.Value for the whole struct.
If it sounds good, I'd like to go for it.

Closing due to lack of activity. Please reopen if you wish to continue discussing it.
@dani-docker has lately done some work on this front, so please take a look at that.


Allow verification via //link[@rel='me'] in feed's website link

Thanks for building this, it's great!
I've got the feed available at https://codeandsupply.co/jobs birb'd via<EMAIL_ADDRESS>I've added //link[@rel='me'] tags to the site to indicate that RSS-parrot's profile is verified, like how other Mastodon and fediverse systems allow.
<link<EMAIL_ADDRESS>rel='me'>
<link href='https://rss-parrot.net/web/feeds/codeandsupply.co.jobs' rel='me'>

It doesn't look like RSS-parrot supports this right now. It'd be cool if it did.

I'm not familiar with //link[@rel='me'] tags... I'm very green when it comes to the whole ActivityPub universe!
What would be the expected behavior if this tag is present? (It's in the feed XML, right?)

The ideal behavior is that the service returning a Website link in a profile has verified that the HTML at the URL contains a <link rel="me" href="${activitypub_url}"/> tag where activitypub_url is the URL of the profile page.
That is, if https://rss-parrot.net/u/codeandsupply.co.jobs contains
{
	"@context": [
		"https://www.w3.org/ns/activitystreams",
		"https://w3id.org/security/v1"
	],
        "…",
        "attachment": [
		{
			"type": "PropertyValue",
			"name": "Website",
			"value": "https://codeandsupply.co/jobs"
		}
	]
}

then the HTML or HTTP headers returned in https://codeandsupply.co/jobs need to point back to the profile URL in some way, e.g. one of these:
<link<EMAIL_ADDRESS>rel='me'>
<link href='https://rss-parrot.net/web/feeds/codeandsupply.co.jobs' rel='me'>
<link href='https://rss-parrot.net/u/codeandsupply.co.jobs' rel='me'>

and then you can show something on the page that indicates that the target link has been verified.

To be more specific, this would actually be visible on https://rss-parrot.net/web/feeds/codeandsupply.co.jobs as something like this mockup:

with this simple HTML:
<p
  Site URL:
  codeandsupply.co/jobs
  ✅

Got it, thanks! Tagging this as an improvement for later.

The short story
Try using https://rss-parrot.net/u/codeandsupply.co.jobs as the "me" link, and the link may eventually be verified by your Mastodon server.  Nothing needs to change in RSS Parrot for it to be verified for Mastodon users.
... although admittedly ...
This is different from what this issue is actually requesting (RSS Parrot itself verifying the link to show verification status on its own pages), so this may be irrelevant to the person who created issue.  However, by its very nature content in RSS Parrot is in one sense always verified because it gets them from the feed provided by the website.  If what one wants is some verification that a bridge for some RSS feed is an "official" bridge, I would expect verification by Mastodon servers would be more desirable as it exposes the verification status to most users; verification status only on RSS Parrot's own pages won't be terribly useful for this purpose.
The long story
I wanted a verified link for my own account, and after a substantial amount of digging, I don't think anything absolutely needs to be changed in RSS Parrot.  Long story short, verified profile links in Mastodon servers are verified by each Mastodon server which reads the profile, not the Mastodon or ActivityPub server from which the profile originates.[^1]  RSS Parrot is not responsible for doing the verification.
[^1]: Each Mastodon server verifying profile links on their own means one Mastodon server does not have to trust what another Mastodon server says about verification of profile links.  This was actually something I noticed was touted as a strong point about Mastodon profile verification a very long time ago, although I had completely forgotten about it, only recalling this after I found mention of it in Bridgy documentation.
However, you may need to use the correct URL as the "me" link on your web page.  I had initially used<EMAIL_ADDRESS>which was never verified.  When I switched it to https://rss-parrot.net/u/blog.chungyc.org, I now have a verified profile link for<EMAIL_ADDRESS>I think this is because WebFinger returns the latter URL as the "self" link for the<EMAIL_ADDRESS>account:
wget --header="Accept: application/activity+json" -O -<EMAIL_ADDRESS>| jq
...
{
  ...
  "links": [
    ...
    {
      "rel": "self",
      "type": "application/activity+json",
      "href": "https://rss-parrot.net/u/blog.chungyc.org"
    }
  ]
}

I am not totally sure about this, since I don't use the URL returned by WebFinger for my main Mastodon account as the "me" link, and it still was verified on my Mastodon server.  There may be something I am missing.  But this was my Mastodon server verifying a link for an account on itself, so maybe I should update this "me" link as well.  I do know that the profile links for my RSS Parrot account is verified now when it was not before.
The only remaining issue is to make a Mastodon server verify a profile link it had already determined not to be verified.  The surest way is to publish an Update activity for UserInfo to followers, although I am not sure if this is supposed to be done with the account's outbox, the inboxes of followers, or the shared inboxes of the followers' servers.  This effectively tells the Mastodon servers following the account to queue up the link for checking again due to a profile update.  This is not absolutely necessary, though, since Mastodon servers appear to queue up links for checking again in other circumstances as well.  The documentation for Bridgy indicates one situation is when a profile is searched for.


Patch libwebsockets to fix errant disconnects.

I was having an issue where my IPv6 connections disconnected every hour.  Eventually tracked it down to a libwebsockets bug.  Libwebsockets maintains a cached route list and everytime there was a DHCP renew, it errantly deletes routes from its cache. In my case, a DHCP IPv4 renew every hour happend to delete the IPv6 local-link route.
This PR patches libwebsockets 4.3.2 in the cross-build script.  Adds -i all so we can listen to all interfaces again.  And upgrades zlib to 1.3, which is a duplicate of https://github.com/tsl0922/ttyd/pull/1193.
Submitted a PR to libwebsockets (https://github.com/warmcat/libwebsockets/pull/2970) but there are several outstanding already and there hasn't been a new release in over a year.

It's merged on upstream now.


Create logo for the ARNEIS project

We should develop a (non-copyrighted by others) logo for the ARNEIS project.
Basic requirements:

[ ] The logo should be an original artwork. The author must submit a Certificate of Authenticity as part of the Pull request
[ ] Alternatively, the logo could be a derivative work based on material licensed under either the CC0 or Public Domain licenses. If so, please make sure the upstream URL is mentioned in the CoA
[ ] The logo must not infringe third party trademarks and copyrights
[ ] The logo should convey the meaning of the "ARNEIS" acronym as described in section "Why the name 'ARNEIS'?" of the ARNEIS Phase1 proposal
[ ] The logo should be distinguishable even if reproduced in grayscale, black/white or scaled to 64x64 pixel bitmaps
[ ] The logo should render beautifully when scaled to the formats required by the following sites and/or apps:

GitHub
Twitter
Telegram
Facebook
Instagram
YouTube
LinkedIn
... others?

Suggested font: Arial Light
Suggested color: TODO (Giallo Paglierino)

Hi! Can I help you on creating the logo as I did for B-AROL-O? I have some ideas for ARNEIS too 😄
Here a sneak peek

Hi! Can I help you on creating the logo as I did for B-AROL-O?

That would be awesome @pitdagosti !

I have some ideas for ARNEIS too 😄
Here a sneak peek

This is an interesting concept for the overall logo.
Maybe we should restrict a little bit on the choice of colors and/or shades, in order to make sure the logo would be suitable for the social networks listed in the description.
I have also some doubt that the "ARNEIS" text around the oval will have enough contrast against the white background.
But it is only my first feeling, we could see it displayed  - for instance scaling the logo and placing on an Instagram profile.

I worked also on this one

I have worked also on this one

I appreciate the second version of the "Text LOGO".
In my opinion can also have some better feel with some litttle aesthetic corrections:

a little extension of the horizontal center line of the A
a connection between R and N by nearing the N and changing a little the R's leg.
some labels on bottle to give more "bottle feeling" (probably also a thicker border can be an upgrade)

The attached image is only to be used as an explanation of what I means.
If this idea is approved by the team, then this modifications must be done on the image source.

Let's verify whether the "A" may become a bottle. This might help cropping the logo to make it a square icon

Ok I can change the layout of the A, but in order to make it a rectangle overall it will be smaller

Rectangle will be done by only keeping a part of the text, I m thinking of using only the A and the connected + removing rneis.
Il 24 feb 2022, 14:51 +0100, pitdagosti @.***>, ha scritto:

Ok I can change the layout of the A, but in order to make it a rectangle overall it will be smaller
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.Message ID: @.***>

Ok I'll modify it and send the results!

Ok I'll modify it and send the results!

Thanks in advance for you PR under docs/images

What do you think?

The official ARNEIS logo is now available at https://github.com/B-AROL-O/ARNEIS/blob/main/docs/images/Arneis_logo_.svg


Update requests to interact with NVD API2.0

NIST deprecated their API1.0 in December 2023 and replaced it with API2.0. This change breaks line 144 of the get_cvss_score() method in vuln_analyzer.py.
Increase the wait time between requests to 5 seconds, since it seems that the rate limiting is harsher with the new API.
Changes to the API can be found here:
Announcement
API Docs

I approved another PR solving the same issue, thank you for being active member of the community and submitting this PR though, greatly appreciated!


Fixed ldapSpnegoClientAction parameter

Fixed ldapSpnegoClientAction to set the parameter to host as documented for the property cas.authn.spnego.ldap.searchFilter (https://apereo.github.io/cas/5.2.x/installation/Configuration-Properties.html#spnego-authentication)
instead of 0

 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.

Closing and reopening to allow travis-ci to run again as it failed for some other reason.


Git folder shows .VC.db* files as modified

VSCode Version: 1.0
OS Version: OS X Elcapitan
Steps to Reproduce:
Open a git repository
I have configured
$ git config --global core.excludesfile ~/.gitignore_global
and added them to .gitignore_global it does not work
.vscode, and .VC. files are shown as modified,
These files should be auto ignored
(Same as issue https://github.com/Microsoft/vscode/issues/5868)
Had to create this one since I did not get a response on the updates.

What does git status return on the command line?

$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working directory clean

Can you provide a screenshot?

I cannot repro the issue after the latest VS Code updates.
Can you assign this back to me, without closing it?

Will just close it. Feel free to reopen if it happens again.


SSh to github.com failing

Hi,
Can we change the spec file to have https endpoint for github source instead of ssh
source = {
url = "git://github.com/thibaultcha/lua-resty-mlcache",
tag = "2.6.0"
}
Example:
source = {
url = "https://github.com/thibaultcha/lua-resty-mlcache",
tag = "2.6.0"
}

the preferred URL format would be "git+https://", see https://github.com/luarocks/luarocks/blob/master/CHANGELOG.md#whats-new-in-luarocks-380


ddev ssh not working with ed25519 keys

Hello, running ddev auth ssh will return

Error loading key "/home/benny/.ssh/id_ed25519": invalid format
Docker command 'docker [run -it --rm --volumes-from=ddev-ssh-agent --user=1000 --entrypoint= --mount=type=bind,src=/home/benny/.ssh,dst=/tmp/sshtmp drud/ddev-ssh-agent:v1.16.0-built bash -c cp -r /tmp/sshtmp ~/.ssh && chmod -R go-rwx ~/.ssh && cd ~/.ssh && ssh-add $(file * | awk -F: "/private key/ { print $1 }")]' failed: exit status 1

I suggest it's a problem with the ed25519 format? Because my key is working normaly on git etc.
Latest ddev on WSL. Latest win version.

Did you create your key using Putty's Keygen? Putty comes with an propriotary key file format which can not be read by SSH. So you have to export your key to the correct format. There is a menu at the top to do this export, you also can load your existing key and export it to the correct format.

I am able to generate an ed25519 key and use it without errors, ssh-keygen -t ed25519 and then ddev auth ssh
Could you please try that exact technique?

@gilbertsoft  @rfay I created the key with ssh-keygen -t ed25519 -C<EMAIL_ADDRESS>given by
https://docs.github.com/en/github/authenticating-to-github/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent
I use putty but I converted the existing ssh key into putty-key.ppk which is also inside .ssh. But as the log says, ddev is using /home/benny/.ssh/id_ed25519

Oh maybe I am wrong, I am using wsl and generated the keys on the host machine and I thought I can also use this keys in ddev, but as I see, ddev want to load it from /home/benny/.ssh which is inside the wsl. Do I have to generate different keys for wsl?

Just copy your key to wsl. It doesn't have to be a different key. There are other ways, but that's what I do.

Ah okay, I must have done that already, the keys are the same. I can try to generate new ones but currently ddev isn't working at all (yesterday it just worked fine xd)

I guess if ddev isn't working at all maybe we should start there. Perhaps docker is broken? Please show the problems you're having, or open another issue, or join us in one of the more interactive support venues. https://ddev.readthedocs.io/en/stable/#support-and-user-contributed-documentation

I removed my wsl distro completely, re-installed Ubuntu LTS and ddev and now it's working fine with my copied keys. Thanks for help.

Glad it's working for you. No idea what that would have been.

My ddev worked fine, but after one night having my laptop in hibernate mode caused it to break. Dont know what this could have been...


Determining the static interface for calyx components

We should make a decision on exactly what the interface for the static component would look like. In particular, there are 3 options:

have a go signal that triggers for exactly 1 cycle. The component will be 'ready' to accept inputs again after n cycles (i.e., the static latency refers to the II). (No done signal)
have neither a go nor a done interface. The output ports hold the outputs relevant to the value on the input ports exactly n cycles ago. In this case the component will have to be 'ready' to accept inputs every cycle, since there's no way to distinguish between valid and invalid signals.
have a go signal that has to be continuously triggered until a done signal is up (the static latency refers to how many cycles have to elapse since the first cycle the go signal is triggered until the done signal is up).

Correspondingly, there are also two options to define the dynamic interface:

The classic calyx go-done interface with no pipelining.
a go-ready-done interface, where the go still has the same semantic meaning, the done means that a valid output is produced on the output ports, and the ready means that the component is now 'ready' to accept inputs (i.e., the component only 'accepts' inputs when go==1'd1 & ready==1'd1.

Thanks for writing this up, one small question on 2.:

have neither a go nor a done interface. The output ports hold the outputs relevant to the value on the input ports exactly n cycles ago. In this case the component will have to be 'ready' to accept inputs every cycle, since there's no way to distinguish between valid and invalid signals.

Is it necessary for the component to be ready to accept inputs every cycle? In other words, can't we just make it the Calyx programmer's responsibility to use the component correctly if the component's II is not 1? The only reason why I say this is that it seems like we wouldn't be able to represent a component that has an II of 2 or more in this case. Lmk if there's something I'm missing.
Another question:
Is there another option that is kind of a mix of 1. and 3.? More concretely,  the n in static<n> component_name in this option represents the latency of the component as in 3., but there is also no done signal for the component like in 1. This is just my opinion so feel free to disagree, but in some ways I feel it's the most intuitive option since it matches Calyx groups most closely (e.g., static <n> group_name means that the group's latency is n cycles, and it does not have a done signal).

I think (2) is not tenable because if your module has II > 1, then you cannot correctly use it because you have no way to know when it started its first execution.

Excellent summary. I think that's exactly where we stand. I guess the strawman plan here could be to just live with the asymmetry between components and groups... do folks know of bad problems with that? Maybe inlining?

Decision
Just going to update this with our synchronous discussion: we decided that the asymmetry between groups and components is (probably) acceptable, since there is an asymmetry in between how components and groups are used: components can be pipelined in their execution, while groups cannot. Therefore, we can (at least for now) try to implement the interface and we'll live with the asymmetry.
Question
One question that I just thought of: currently, we infer the latency of registers and multipliers by looking at the @static annotation on their go port, even though they have a done port. This @static annotation is just a way of saying "we know the output will be available after one cycle"; kind of like a hint for the compiler. Couple questions on this:

Should we keep this behavior, in light of our decision about the static interface components? If we do, there will be a distinction between two things: 1) the actual static<n> interface (which is to trigger go for one cycle, wait n cycles, no done signal) and 2) the @static(n) annotation, which is just a hint to promote to static.
What should we do about dynamic components whose entire control program we can infer the latency of? We probably won't be able to upgrade the component to a static<n> component (since that would involve getting rid of the done signal), but we may be able to attach the @static(n) annotation "hint" to its ``go'' port. This will help in the static-promotion of groups.

Thanks for following up on this @calebmkim! Thoughts on "definitely static" primitives like registers:

On the elegance front, I think it would be nice to say something like: all registers are completely static, a fact which is reflected in their primitive because use the static keyword. They do not have the done signal and the only way to use them is in the context of static groups. The Calyx compiler knows how to instantiate the done signal for such groups and will do the right thing.
On the pragmatic front: we can keep the done signal for the register and say, "well actually, because it is so common to use registers in either context, we have implemented a really efficient done signal for the register and the compiler is allowed to assume that the done interface works correctly and can be eliminated in static contexts".

My point in mentioning (1) & (2) is that, notionally, we should think of static primitives as truly static: they do not have need or have a done signal. The fact that they have a done signal is merely an optimization that's available for the compiler to leverage. It should be totally okay to ignore the done signal and instantiate a static group FSM to expose the done signal as well because first and foremost, std_reg is a static primitive.
Does this philosophy resonate?

@andrewb1999 agrees that the new "assert go for one cycle" interface is a good idea and so we should commit to implementing it. Once it lands, Andrew will update AMC to use the new interface and hopefully things will continue working.

My point in mentioning (1) & (2) is that, notionally, we should think of static primitives as truly static: they do not have need or have a done signal.

Right, this seems like the way to me! To put it another way, we want to have two nonoverlapping categories of components:

Dynamic components, which can only be used in a dynamic context (and have a done port).
Static components, which can only be used in a static context (and do not have a done port). (But you can wrap them to use them in a dynamic world!)

Then we might want to create a small third category for special cases:

Stuff like std_reg that can be used in either context, without wrapping. These have both a known static latency and a done port. When used in a static context, you just ignore the done port completely.

One could argue that we should eliminate category 3, and create two different primitives called static_reg and dyn_reg for example. But it doesn't seem too bad to have a small number of things in category 3, as long as we don't make that the common case!

Right! The argument for keeping category 3 is that name punning for very common things like registers is useful and we expect synthesis tools to remove the unconnected done register when used in static context anyways.

One more note: for static-promotion, it seems like we would be promoting some components from (1) to (3). Is this fine? I know we should probably keep (3) small; on the other hand, this could help with static promotion.

Hm, not sure I follow. If you promote something, it goes from 3 to 1 right? This is because we're saying that we definitely don't need to use the done signal

I think we have to rethink what the latency of a static component actually means, especially for pipelined components.
Writing a pipelined component would probably have a control program that looks something like this:
static par {
  static seq {// 1st stage of pipeline }
  static seq {// 2nd stage of pipeline }
  ... // etc.
}

But in this case, the latency of the control program would be the II, not the latency.
The reason we cannot represent a pipeline using a static seq is that we only have one fsm, which can only be at one value, which means we cannot represent multiple stages.

@paili0628 My understanding of the annotation is exactly the same! That is, for sequential components, the annotation represents both the II and the latency but for pipelined component, it tells you when you can re-invoke the module.
@calebmkim thoughts?

Yeah I agree with the above^. I think this all sounds good.

Yeah, that's exactly what I was thinking.

Should we add a new @latency(n) attribute to indicate the latency of a particular port? I was thinking something like this could be checked in the future and be useful to ensure that the pipeline is correctly balanced.

It's a pretty good idea. This would end up being, like, a super restrictive embedding of a subset of Filament types… as in, a Filament component with a simple signature something like this:
comp mycomp<'G: X>(
  go: interface['G],
  inport: ['G, 'G+X] 32,
) -> (
  outport: ['G+Y, 'G+Y+1] 32,
)

Could compile to a Calyx signature like this:
static<X> component mycomp(
  inport: 32
) -> (
  @latency(Y) outport: 32
)

Subsumed by #1754


implement initial heuristic for moving from empty slabs to free slabs

There are many ways to approach this, but for now it just needs to be a trivial implementation rather than trying to figure out and implement the best design choices for performance and security immediately.

This is now implemented by https://github.com/AndroidHardening/hardened_malloc/commit/6183d91c593990bed5a841ed02aeed209592b3d9.

This is now implemented by https://github.com/AndroidHardening/hardened_malloc/commit/0f5f2bf6c953a4b4243d2cb3952ab0494a57e025.

This is now implemented by https://github.com/AndroidHardening/hardened_malloc/commit/0f5f2bf6c953a4b4243d2cb3952ab0494a57e025.


Font awesome styles

Does the icon component allow using a different style than the one the app has been configured with? Say I have
app.use(Oruga, {
  iconPack: "fas",
  iconComponent: "vue-fontawesome",
  ...bulmaConfig,
});

How would I use an icon from @fortawesome/free-regular-svg-icons?

Sure, you can config it as icon pack far and use it in o-icon but keep attention to default icons, maybe far set doesn't cover all. Anyway you can ovveride them!

How would that look?
I have:
// main.ts
import { library } from "@fortawesome/fontawesome-svg-core";
import { faCheckCircle } from "@fortawesome/free-regular-svg-icons";
library.add(faCheckCircle);

app.use(Oruga, {
  iconPack: "fas",
  iconComponent: "vue-fontawesome",
  ...bulmaConfig,
});

// Comp.vue
<o-icon icon="check-circle" pack="far" />

But it's complaining that it can't find it: Could not find one or more icon(s) {prefix: 'far', iconName: 'check-circle'}.


fix: removed USER directive and added entrypoint to allow volume setup

/deploy-review

/deploy-review

/deploy-review

/deploy-review

/deploy-review

/deploy-review


Panel splitter (resizer) is quite difficult to drag on iPad

Let's keep an eye on this and see if we get any user reports - doesn't seem like an outright bug, although agree it can be tricky.


$firebaseArray $add/$remove doesn't update local copy immediately (angularfire 1.2.0 and earlier)

As mentioned in issue 829, $firebaseArray.$add and $remove do not update the local array immediately. In case of removing, the deleted item remains in the local $firebaseArray object until its is synced with the db. I've found the bug on angularfire 1.2.0 and earlier.

Re-opening the other issue.


Question about adding custom descriptor calculation method

Hello
Thank you for the wonderful package.
I would like to definitely make use of it for utilizing MLOps.
Is it possible to integrate a custom descriptor calculation library into this library?

Hello,
I have added some instructions as part of https://github.com/MolecularAI/QSARtuna/pull/18.
Please check the new 3.1.1 readme for instructions on custom calculation within QSARtuna: https://github.com/MolecularAI/QSARtuna/tree/3.1.1?tab=readme-ov-file#adding-descriptors-to-qsartuna

Hello
Thank you for responce.
I miss the documentation.
I try to add new representation.


Restyle Topology screen header

replaced custom header styling with Patternfly toolbar
added missing JS for clear button

Issue: #6054
Old

New

@miq-bot add_label ui, enhancement, providers/containers

@abonas @serenamarie125 -  Please review
@serenamarie125 - It's probably in the works, but we could use some additional styling options in the pf-toolbar. Currently, toolbar-pf-filter doesn't support pf-search styling (use of "has-clear" and search button, etc)

@abonas - if the plan is still to make Topology a View, rather than a tab, we can use the right side of the toolbar for the view buttons

@epwinchell, I am looking at the "before" screenshot, and something looks wrong - this is not how topology header usually looks like. Maybe your browser is zoomed in? Because the alignment problem is not that.
The issue with alignment is shown here: https://cloud.githubusercontent.com/assets/6277245/12220657/6630ddb0-b782-11e5-9a8e-6c69f8b6dd0c.png
I am not in favor of adding an additional toolbar, it takes some free screen space which will be valuable for visualizing large environments, and also looking forward when this screen will become one of the toggled views for entities and providers and not separate screen, the topology area will be even smaller, so any additional toolbar is an overhead.
It also seems that it requires quite a lot of js and css modifications and overrides just for this toolbar (especially the "clear" button extra logic and pf overrides)- I am concerned this large change is not needed.

@abonas - if the plan is still to make Topology a view, rather than a tab, we'll utilize the right side of the toolbar for the view buttons

yes, afaik, it is still the plan to move this to be a view rather than a whole screen

@abonas The view buttons would use the right side of the same toolbar - this change will not take up any additional space. Actually, the Topology legend is a bit closer to the top in the "new" screenshot . This change also reduces the total amount of css

@abonas The view buttons would use the right side of the same toolbar (https://rawgit.com/patternfly/patternfly/master/tests/toolbar.html) - this change will not take up any additional space. This change also reduces the total amount of custom css.

ok, now it's more clear. adding @zeari as he started working on the toggle view in #6115

@abonas  The JS - Hides the clear button if the search input is empty, shows the clear button upon entering text in the search input, and empties the entered text and hides the clear button when it's clicked. @h-kataria  will move it to a JS function and  call that function from the view, since we may use it elsewhere.

@abonas The JS - Hides the clear button if the search input is empty, shows the clear button upon entering text in the search input, and empties the entered text and hides the clear button when it's clicked. @h-kataria will move it to a JS function and call that function from the view, since we may use it elsewhere.

yes, I understand that, but correct me if I'm wrong, the same functionality existed in the search field prior to this PR too without the js?

Anyhow I'm really not clear what is our benefit moving to additional toolbar instead of keeping everything in the same line.

@abonas How would everything (search, checkbox w text, refresh button, view buttons and Legend) fit on the same line and how would it be responsive? Isn't the contents of the Legend variable?

@abonas, i verified on current master X button in Search text box is always visible on both Firefox & Chrome, with Eric's changes it will only be visible as user starts typing in the search box. I will try to move the JS code out to a JS method that can be reused from other place as well.

@abonas, i verified on current master X button in Search text box is always visible on both Firefox & Chrome, with Eric's changes it will only be visible as user starts typing in the search box. I will try to move the JS code out to a JS method that can be reused from other place as well.

but doesn't it mean it's a bug in patternfly?

@abonas it seems that you do need JS code locally to handle the clear button, see a sample here: https://www.patternfly.org/widgets/#search

@abonas re - keeping everything on the same line. On my screen, the legend wraps at 1016px, even without the search box, refresh button and checkbox.  There's going to be a toolbar anyway, I would think it makes sense free up space for more Legend items.

@abonas re - keeping everything on the same line. On my screen, the legend wraps at 1016px, even without the search box, refresh button and checkbox. There's going to be a toolbar anyway, I would think it makes sense free up space for more Legend items and avoid wrapping when possible.

ok

@abonas it seems that you do need JS code locally to handle the clear button, see a sample here: https://www.patternfly.org/widgets/#search

yep, thanks for the reference, I saw it now. I wonder if it is that necessary to handle that issue. seems to me too much code and effort for such a minor thing

@abonas AFAIK, this is ready. We moved the JS out of the view.


"Auto-update" support

Not a super important feature, but would be cool if:
Ghcid would also watch the file of its own executable, and when one stack installs a new version all running ghcids would restart into the newer version. :)
Note that for any IDE plugins that don't offer an explicit restart of ghcid this would help avoid needing to restart the IDE.

Closing, but if someone comes up with a patch that is very simple I might consider merging it (but personally don't consider it worth the effort to write, and given what I expect the patch to do, nor to maintain).


electron-fiddle: 0.31.0 → 0.32.1

Description of changes
Upgrade Electron Fiddle from 0.31.0 to 0.32.1. This version depends on Electron 22 rather than the now EOL’d Electron 20 (#215545).
https://github.com/electron/fiddle/releases/tag/v0.32.1
Things done

Built on platform(s)

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

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

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

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

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-ready-for-review/3032/1810


fix: default to leftToBeResolved, fixes #205

What is the purpose of this pull request?

Documentation update
Bug fix

What changes did you make? (Give an overview)

I fixed the issue of promise/no-native failing when using @typescript-eslint/parser.
I added myself to the list of contributors in package.json and the list of maintainers in README.md.
I ran npm audit fix to fix security vulnerabilities and npx browserslist@latest --update-db to update the browsers list.

So I love this, but really want some kind of test to verify this behavior continues to solve the problem. Any suggestions?

Merging for now. Please send a test as well :D

+<EMAIL_ADDRESS>

@xjamundx Sorry for the late reply. I created a new PR, #332, for the tests.

Thank you!


Update README.md

Description

Updates readme.md so it does not give a 404 error.
Checklist for all submissions

[x] Have you followed the guidelines in our Contributing document?
[x] Have you checked to ensure there aren't other open Pull Requests for the same update/change?
[x] Have you tested and reviewed your changes with confidence that everything works?
[ ] Did you branch your changes and PR from that branch and not from your master branch?

If not, why?: No need to.

LGTM! thank you.


Misc minor perf improvements

Some tentative changes to try improving performances after having looked at few recent jfr recordings; this is possibly related to https://issues.jboss.org/browse/RESTEASY-2000

If the changes are verified to be actual improvements, this could be backported to 3.7.


Invalid magic byte: 2 when updating kafka client protocol to 0.11

Version of Ruby: 2.5.1
Version of Kafka: 1.0.2
Version of ruby-kafka: 0.7.4

We updated to ruby-kafka 0.7.4 recently to allow us to upgrade the kafka client protocol to 0.11 (we had been running in 0.10 for a while).
When we updated the client protocol, however, we encountered crashes on one of our partitions with: Kafka::Error: Invalid magic byte: 2 magic_byte_crash.txt
After adding some debug logs, we were able to determine that we had a magic byte equal to 1 in the message set at fetch_response.rb, but that we were getting a magic byte equal to 2 in one of the messages of the message set at message.rb (in our case the fifth message of the set).
What's particularly strange is that according to the protocol records don't even have the magic byte like messages in the previous versions, but I suppose we might have ended up reading a byte by chance that decoded to 2.
We had to drop the kafka packet to keep treating data, and have not encountered the problem since.
Has anyone encountered something similar? Do you think this is just an issue that occurred while switching protocols that we hopefully won't see again?
Thanks!
Jeremy

@Kwisatx Hi, I used to encounter that issue before, when upgrading from message set format to record batch format. And the same as you, I have to drop some batches (like ~5 or something), then nothing weird happens again. I fetched the raw format of record and could not decode it myself (I'm the one who implemented the record batch format btw). At that time I was assuming that there are some message corruption during the transition. If you can share the raw package, I'll be able to re-investigate again to see what happened.

Hi!
Thanks for the information, we'll consider the problem a one-time issue with the upgrade then (and reopen the issue if it reappears).
Sadly we did not save the packet in question but in a few weeks we'll be doing the upgrade in a different environment, so if the problem reappears we'll make sure to save the new example and share it with you.


Stubs rendering default props

When rendering snapshots, stubbed components are actually being evaluated in order to apply the default props to the element.
For example if my component imports and contains the following code:
<Button
      ref="cancel-button"
      label="Cancel"
      :disabled="isLoading"
      icon="pi pi-times"
      @click="cancelClickHandler"
      class="p-button-text"
    />

And I stub out the Button component in my test
mountOptions = {
      global: {
        stubs: ["Button"]
      }
    }

My snapshot will render with
<button-stub label="Cancel" icon="pi pi-times" iconpos="left" loading="false" loadingicon="pi pi-spinner pi-spin" disabled="false" class="p-button-text"></button-stub>
iconpos="left" and loadingicon="pi pi-spinner pi-spin"  should not be rendered.
This is annoying for me because whenever I update my Button component my snapshots for anything using the Button component need to be updated. I already have my Button component covered with its own tests so this is unnecessary.

Where are loadingicon and iconpos coming from?
Snapshots + stubs are difficult to handle - seems like there are varying opinions on what should and should not be rendered. I wonder if we can provide a few different snapshot serializers, so people can choose the snapshot behavior they'd like. 🤔

They are defined on the actual "Button" component that I'm stubbing out. These specific props are defined with default values that are being rendered by the snapshot. (In this particular case they are defined in the PrimeVue component library I'm using)
I'm assuming that the actual Button component is being evaluated before the stubbing process takes place.

I'm assuming that the actual Button component is being evaluated before the stubbing process takes place.

I ran into another issue which leads me to believe this is the case and the stubbing process should be examined. In this new situation, one of my stubbed components has dependencies which are not accounted for in the context of the test. The test crashes... but it shouldn't matter because the component should be stubbed out.

What do you mean by "has dependencies"? As in it imports other modules? The stubbing VTU offers is just before the component is rendered; it will still get imported (as well as all its dependencies).
Assuming my understanding of your question is correct, if you want to completely and totally stub out a component (and the modules it imports) you could use jest.mock potentially.

Yeah I think you understood correctly. Your idea to use jest.mock sounds really interesting! I'll give it a go!

Cool, here is a basic example: https://lmiller1990.github.io/vue-testing-handbook/vue-router.html#workaround-for-large-render-trees-using-mount
We should still fix the stubbing bug for

You can define your own way how stubs are created by a plugin (plugins.createStubs). https://test-utils.vuejs.org/guide/extending-vtu/plugins.html#stubs-plugin


heading does not match contents at the end of the chapter (页眉）

The chapter heading seems to follow the section.  When I got to the end
of the chapter, say, 第1章 习题，the heading remained to be the last
section, which didn't match the content of the page.  (see the
attached.)  I'd appreciate it greatly if there would be a command to
switch off the heading or simply to the chapter title.
heading.pdf

The commit https://github.com/muzimuzhi/ElegantBook/commit/2d73515ddf54de5e1229f445d8d3e779cb0876c9 provides a possible solution that let problemset environment update the header. With this modification, left header of the only page of your file heading.pdf would be "1 习题".
You can change the header to any desired text by changing both arguments of \markboth.

I'd appreciate it greatly if there would be a command to switch off the heading or simply to the chapter title.

In oneside mode (default), every left header is the latest section title in the corresponding page.
If you add twoside to the class option (i.e. \documentclass[..., twoside]{elegantbook}), then right header of odd pages will show chapter title, and left header of even pages will show section title.

Maybe twoside is what you want.


Make changes

👷 Deploy Preview for isha-demo processing.
🔨 Explore the source changes: 0c5e5fba6d3f3b403e7f72abb6a1e17aff8f8c0b
🔍 Inspect the deploy log: https://app.netlify.com/sites/isha-demo/deploys/61c0176972fed900073beb1c


Make Select scrollable

Current Behavior
When an opened Select element extends beyond the bottom or top of the screen, the hidden options are not accessible, because scrolling is not possible. This makes the element unusable when there are a large number of included options.
Expected Behavior
Allow scrolling when elements are hidden, like in native dropdown menus.
Steps To Reproduce
Reduce the height of the browser window and open the Select element here, so that some options are hidden: https://www.shadcn-svelte.com/docs/components/select
Link to Reproduction / Stackblitz (reproduction template)
No response
More Information
No response

I think this should be better documented. After reading the component API I saw it has 'overflow-hidden' so I tried to apply 'overflow-scroll' without success.
It has to be configured in this combo for the scroll to work properly


Update Import hashes

Summary
Update Import hashes
Details
New hashes of imported stylesheets
Checks

[ ] In case of new feature, add short overview in docs/<corresponding file>
[ ] Tested changes

Python Version 3.6 with arch x64 not found in the check

Hi @Archef2000, Thanks for the PR! Could you give a little more information? What problem does this fix?

It fixes the wrong integrity hashes

@Archef2000 alright! Thanks. Did you also test it on a native system?
A seperate question using wikmd for a while how would aou like it if the would be a way that you could write Markdown and view it with a preview tab and having all files local so it even would work for an offline system.

@Archef2000, alright, no problem :smile:

A seperate question using wikmd for a while how would aou like it if the would be a way that you could write Markdown and view it with a preview tab and having all files local so it even would work for an offline system.

I'm not yet fully sold on this, the page needs to be rendered constantly which would take a lot of processing power and make the UI feel slow. Also, I find the code editor we use pretty good at giving a 'preview'. But be my guest to try something and I'll check it out!


WDI5 Installation Procedure Fails

Hello everyone,
as per the official documentation I've run the command:
npm init wdi5
and it copies wdio.conf.js into place, installs wdio+wdi5 and adds them as dev dependencies.
However there's a subsequent step which fails:
 adding wdi5 start command ("wdi5") to package.json...
with this output:
Usage: npm <command>
where <command> is one of:
    access, adduser, audit, bin, bugs, c, cache, ci, cit,
    clean-install, clean-install-test, completion, config,
    create, ddp, dedupe, deprecate, dist-tag, docs, doctor,
    edit, explore, fund, get, help, help-search, hook, i, init,
    install, install-ci-test, install-test, it, link, list, ln,
    login, logout, ls, org, outdated, owner, pack, ping, prefix,
    profile, prune, publish, rb, rebuild, repo, restart, root,
    run, run-script, s, se, search, set, shrinkwrap, star,
    stars, start, stop, t, team, test, token, tst, un,
    uninstall, unpublish, unstar, up, update, v, version, view,
    whoami
npm <command> -h  quick help on <command>
npm -l            display full usage info
npm help <term>   search for help on <term>
npm help npm      involved overview
Specify configs in the ini-formatted file:
    C:\Users\xxxx\.npmrc
or on the command line via: npm <command> --key value
Config info can be viewed via: npm help config
<EMAIL_ADDRESS>C:\Program Files\nodejs\node_modules\npm
Did you mean this?
    run-script
(node:17496) UnhandledPromiseRejectionWarning: Error: Command failed: npm set-script wdi5 "wdio run wdio.conf.js"
    at checkExecSyncError (child_process.js:760:11)
    at execSync (child_process.js:833:15)
    at C:\Users\xxxx\AppData\Roaming\npm-cache\_npx\28096\node_modules\create-wdi5\dist\index.js:41:38
    at Generator.next (<anonymous>)
    at fulfilled (C:\Users\paciucma\AppData\Roaming\npm-cache\_npx\28096\node_modules\create-wdi5\dist\index.js:5:58)

I have tried many times to no avail.
Can anybody help?

please make sure you're using a LTS version of node along with at least npm >= 7

Node v14.17.4,
npm {
'openui5-sample-app': '0.2.0',
npm: '6.14.14',
ares: '1.17.1',
brotli: '1.0.9',
cldr: '39.0',
icu: '69.1',
llhttp: '2.1.3',
modules: '83',
napi: '8',
nghttp2: '1.42.0',
node: '14.17.4',
openssl: '1.1.1k',
tz: '2021a',
unicode: '13.0',
uv: '1.41.0',
v8: '8.4.371.23-node.76',
zlib: '1.2.11'
}

That's now better however there's still an issue.
There's no such npm run test:ui5tooling
I've created a test folder into openui5-sample-app which contains wdio.conf.ts and tsconfig.json along with another subfolder specs containing sample.spec.ts
When I run wdio wdio.conf.js I get 'wdio' is not recognized as an internal or external command,
How can I move along?

I will open up a new issue then. That one can be considered closed


Can 1.18.2 Mohist use this plugin?

No easy usage guides for Hydraulic at present, so I asked here.

Hydraulic is not currently in a usable state as it's not updated to 1.21 (.1). Hence why there are no guides


Promise handling is "too optimistic" (url_path not existing in old entities)

Bug report
Describe the bug
Existing entities created before installing the url-alias plugin do not have the url-path column. After installing the plugin many api requests fail because of the preparePath service  Promise.all not handling any errors.
Checking out the code, most promises are  used in the async-await style, skipping any error handling, which is  a "too optimistic way" of managing  Promises.
Steps to reproduce the behavior

Install Strapi without plugins
Create and populate a couple of entities
Stop Strapi nd install url-alias plugin
See error:

error: Cannot
read properties of null (reading 'url_path')
TypeError: Cannot read properties of nul
l (reading 'url_path')

Expected behavior
No server errors when using the api directly (not using any url-alias).
System

Node.js version: 16.15.1
NPM version:  8.11.0
Strapi version: 4.3.3
Plugin version: 1.0.0-alpha.4
Database: Postgres
Operating system: Linux, Mac

Workaround
In file<EMAIL_ADDRESS>At the end of the Promise.al on line 18 (should be line 32), add a catch:
.catch(_err => { return; })

Hi @jsanta
Thanks for reporting the issue.
I'll take a look at this probably later this week :)

Hi @jsanta,
I believe this issue comes forward because url_path_id is null in this case of pre-existing records.
I've made the prepare-path service more strict to only rewrite the result if url_path_id is not null. See PR #12.
Could you test this out locally? You can install the PR like this:
yarn add strapi-community/strapi-plugin-url-alias#pull/12/head
npm install strapi-community/strapi-plugin-url-alias#pull/12/head

This was released with version 1.0.0-alpha.5 of the plugin.
If you're still experiencing the issue beyond this version feel free to re-open the GH issue or create a new one.

Why do you want to have the whole url_path entity? You’re just making use of the path field, not the other fields on the entity.
Storing the URLs in a seperate table makes it easy for you to query a record based on the URL regardless of the type. As you just query the url_path table and see what entity is related to the specific URL.
Also having them in a seperate table helps with requiring uniqueness of URLs.
So there are def some benefits as aposed to just having a url_path column on the different tables.

For eg a blog entry. /blog/fancy-title-here as the url alias
As a Strapi user (non dev) I would like to have as a response the whole entity, by simply using the url-alias as a parameter. No need to know the whole entity structure, neither how to build a populated Strapi query.
Building queries should be a developer's task.
But that's a particular use case, I guess I misunderstood the plugin's main goal.

I’m open to feature requests.
Though I’m not sure I fully understand. As there is a way to query the whole entity by using just the URL alias as a parameter.
Like this:
http://localhost:1337/api/url-alias/get?path=/blog/fancy-title-here

Just that. Without population params. I hot patched url-alias for that, using the strapi-deep code with some micro-optimizations for the recursion.
Had to add a exclude para though, because we have an entity that causes an infinite population.
Will try to make a pull request with these changes.

Sounds good! Looking forward to it.


cffi 2.0b1 does not compile on Windows using gcc and Tcl 9

cffi does not compile on Windows using gcc and Tcl 9, because it searches libtommath in wrong (cffi) directory.
When changing the line in files configure.ac resp. configure, cffi compiles.
Change:
TCL_TOMMATH_LIB=${libdir}/${TCL_TOMMATH_LIB_NAME}
to:
TCL_TOMMATH_LIB=${TCL_EXEC_PREFIX}/lib/${TCL_TOMMATH_LIB_NAME}
Running test suite generates lots of errors (but the failures are the same as for 8.6.15):
all.tcl:        Total   11476   Passed  11245   Skipped 45      Failed  186
Sourced 16 Test Files.
Files with failing tests: arena.test callback.test function.test interface.test memory.test pointer.test prototype.test struct.test type.test union.test varargs.test
Number of tests skipped for each constraint:
13      !structbyval
3       !structbyval packsupport
2       !win
1       disabled
25      dyncall
1       win32

What version of gcc and mingw is this ? Github MingW CI  shows no errors. I am admittedly somewhat confused by tommath in Tcl 9. As per my understanding it is possible to link against the system tommath library directly or via Tcl stubs. Could the error have something to do with how Tcl was built?
Regarding the failing tests, what version of libffi? Min required is 3.4.4 because of stack corruption bugs in libffi. Just want to make sure not chasing
/Ashok

Here is my mingw environment, the configuration of Tcl and cffi and the test suite output:
Windows 11, gcc 7.2.0, libffi 3.4.6
uname -r: 3.0.7-338
Tcl configuration:

LDFLAGS=' -s ' /C/BawtBuilds/TclDistribution/TclDistribution-9.0.0-9.0.0/Windows/x64/Release/Build/Tcl/win/configure
--build=x86_64-w64-mingw32
--prefix=/C/BawtBuilds/TclDistribution/TclDistribution-9.0.0-9.0.0/Windows/x64/Release/Install/Tcl
--exec-prefix=/C/BawtBuilds/TclDistribution/TclDistribution-9.0.0-9.0.0/Windows/x64/Release/Install/Tcl
--enable-64bit
--disable-symbols

cffi configuration:

CFLAGS='-IC:/BawtBuilds/TclDistribution/TclDistribution-9.0.0-9.0.0/Windows/x64/Development/include' LDFLAGS=-'LC:/BawtBuilds/TclDistribution/TclDistribution-9.0.0-9.0.0/Windows/x64/Development/lib' LIBFFI_LIBS=-llibffi /C/BawtBuilds/TclDistribution/TclDistribution-9.0.0-9.0.0/Windows/x64/Release/Build/cffi/configure
--enable-shared
--enable-threads
--prefix=/C/BawtBuilds/TclDistribution/TclDistribution-9.0.0-9.0.0/Windows/x64/Release/Install/cffi
--exec-prefix=/C/BawtBuilds/TclDistribution/TclDistribution-9.0.0-9.0.0/Windows/x64/Release/Install/cffi
--with-tcl=/C/BawtBuilds/TclDistribution/TclDistribution-9.0.0-9.0.0/Windows/x64/Release/Build/Tcl
--with-tk=/C/BawtBuilds/TclDistribution/TclDistribution-9.0.0-9.0.0/Windows/x64/Release/Build/Tk
--build=x86_64-w64-mingw32
--enable-64bit
--disable-symbols
--disable-staticffi

all.txt

The failing tests indicate it is not a libffi issue, I don't think. They all seem to have to do with pointers being NULL or function pointers not in executable page (ignoring the errors pertaining to German error messages).
I tested with gcc 9.4, 11.3 and 13.2  but I cannot imagine how gcc 7 would behave differently. Consider the very simple test pointer-isnull-2
        cffi::pointer isnull [makeptr 1]

This is returning 1 on your build when it should be 0. The test failures indicate all pointers are being seen as NULL.
That gives me hint where to look. Can you print the output of the following using the same compiler tool chain as above?
#include <stdio.h>
int main()
{
    void *pv = &pv;
   int i = sscanf("0x1^", "%p^", &pv);
   printf("%d, %p", i, pv);
    return 0;
}

I get the following with my gcc toolchain:
1,<PHONE_NUMBER>000001

I suspect you will get
1,<PHONE_NUMBER>000000

which would indicate different sscanf %p implementation in the C runtime.

Your sscanf idea was correct. I tested on various systems and compilers and it seems to be a Windows-only problem with older compilers (both gcc and VS):
MinGW gcc
gcc 7.2.0 (64-bit)
1,<PHONE_NUMBER>000000
gcc 7.2.0 (32-bit)
1, 00000000
gcc 8.1.0 (64-bit)
1,<PHONE_NUMBER>000000
gcc 11.2.0 (64-bit)
1,<PHONE_NUMBER>000001
gcc 12.2.0 (64-bit)
1,<PHONE_NUMBER>000001
gcc 13.2.0 (64-bit)
1,<PHONE_NUMBER>000001
gcc 14.2.0 (64-bit)
1,<PHONE_NUMBER>000001
Visual Studio
_MSC_VER 1500 (32-bit) VS2008
1, 00000000
_MSC_VER 1600 (32-bit) VS2010
1, 00000000
_MSC_VER 1800 (64-bit) VS2013
1,<PHONE_NUMBER>000000
_MSC_VER 1900 (64-bit) VS2015
1,<PHONE_NUMBER>000001
_MSC_VER 1916 (64-bit) VS2017
1,<PHONE_NUMBER>000001
_MSC_VER 1929 (64-bit) VS2019
1,<PHONE_NUMBER>000001
_MSC_VER 1941 (64-bit) VS2022
1,<PHONE_NUMBER>000001
Linux gcc versions
gcc 4.8.1 (32-bit)
1, 0x1
gcc 4.8.5 (64-bit)
1, 0x1
gcc 4.9.2 (64-bit)
1, 0x1
gcc 7.5.0 (64-bit)
1, 0x1
gcc 9.4.0 (64-bit)
1, 0x1
gcc 12.2.0 (64-bit)
1, 0x1
gcc 13.2.0 (64-bit)
1, 0x1
gcc 14.2.0 (64-bit)
1, 0x1
gcc 14.2.1 (64-bit)
1, 0x1
MacOS
gcc 4.2.1 (64-bit)
clang 16.0.0 (clang-16<IP_ADDRESS>) (64-bit)
1, 0x1

With current trunk all tests succeed on Windows using gcc 7.2.0.
Expect 24 tests using German output messages, which are equivalent to the English messages.

Thanks, closing.


Wrong channel selection for NCDIAG AMSUA variational

For example:
https://github.com/NCAR/MPAS-Workflow/blob/b13210ac8103f738133ff67ded1df8b129f08acf/config/ObsPlugs/variational/base/amsua_n19.yaml#L9
Previously we only assimilated a limited channel set for AMSUA instruments in PANDACArchive experiments.  We could remove some of the channels with filters similar to what is done in the filtersWithBias yamls.

For example:
#  Useflag check #amsua-n19
  - filter: Bounds Check
    filter variables:
    - name: brightness_temperature
      channels: *amsua_n19_channels
    test variables:
    - name: ChannelUseflagCheckRad@ObsFunction
      channels: *amsua_n19_channels
      options:
        channels: *amsua_n19_channels
        use_flag: [ -1, -1, -1, -1,  1,
                     1, -1, -1,  1, -1,
                    -1, -1, -1, -1, -1 ]
    minvalue: 1.0e-12
    action:
      name: reject

You are right @jjguerrette. It is my mistake. I forgot the channel differ from one set of observations to the other. I will open a small PR to fix this. Thanks for pointing it out.


feat: use babel support jsx

Why do we need it ?

@vue/compiler-dom cannot compile jsx
// @vue/compiler-dom

{hello}
  // as a normal element, work

{hello}
 // compile fail

So need to use babel

Hello, what do you think of this pr, Because I use jsx in my project,so I need this support

Hello, what do you think of this pr, Because I use jsx in my project,so I need this support

Thanks for the PR,I agree with supporting JSX, Can you add a example to help me review it ?


Error when disconnecting debug from LPC1768

OS: MacOS 10.14.5
Mbed OS: 5.13.1
Targets: LPC1768
When disconnecting a debug session from the LPC1768, an error is thrown and the debug session does not disconnect. This has not been observed on other targets.
0017315:ERROR:board:link exception during target disconnect:
Traceback (most recent call last):
  File "/Users/thegecko/mbed-studio-tools/python/lib/python2.7/site-packages/pyocd/board/board.py", line 96, in uninit
    self.target.disconnect(resume)
  File "/Users/thegecko/mbed-studio-tools/python/lib/python2.7/site-packages/pyocd/core/coresight_target.py", line 244, in disconnect
    core.disconnect(resume)
  File "/Users/thegecko/mbed-studio-tools/python/lib/python2.7/site-packages/pyocd/coresight/cortex_m.py", line 505, in disconnect
    self.resume()
  File "/Users/thegecko/mbed-studio-tools/python/lib/python2.7/site-packages/pyocd/coresight/cortex_m.py", line 958, in resume
    self.flush()
  File "/Users/thegecko/mbed-studio-tools/python/lib/python2.7/site-packages/pyocd/core/target.py", line 142, in flush
    self.session.probe.flush()
  File "/Users/thegecko/mbed-studio-tools/python/lib/python2.7/site-packages/pyocd/probe/cmsis_dap_probe.py", line 237, in flush
    self._link.flush()
  File "/Users/thegecko/mbed-studio-tools/python/lib/python2.7/site-packages/pyocd/probe/pydapaccess/dap_access_cmsis_dap.py", line 637, in flush
    self._read_packet()
  File "/Users/thegecko/mbed-studio-tools/python/lib/python2.7/site-packages/pyocd/probe/pydapaccess/dap_access_cmsis_dap.py", line 860, in _read_packet
    raw_data = self._interface.read()
  File "/Users/thegecko/mbed-studio-tools/python/lib/python2.7/site-packages/pyocd/probe/pydapaccess/interface/hidapi_backend.py", line 113, in read
    return self.device.read(self.packet_size)

What is the traceback for the F466ZE target? It will be different (assuming you're using STLink for it).

@flit, the target we saw this problem with was actually NUCLEAO_F446ZE (not 466 - apologies, my typo).
I've been unable to get this to crash with PyOCD 0.21.0, so have updated the ticket to reflect this is an LPC168 issue only.

Thanks for the update!

I've not been able to reliably reproduce this issue. I did see an exception once or twice on disconnect, but not exactly the same.
Can you provide a command sequence to reproduce this from the command line, starting from blank flash? Thanks.


OpenSSL 1.0.2h

Tests:

https://ci.appveyor.com/project/ingenue/hunter/build/1.0.415
https://travis-ci.org/ingenue/hunter/builds/128254429


Factor "maybeWrapInExistential" into builders

When decoding mangled names into types, a type may be optionally wrapped in an existential depending on the context (for example, if a protocol appears in a function signature's requirement it's only the protocol type, but if it appears as a type of a variable, it's an existential). This patch centralizes the logic of whether a type should be wrapped in an existential in a new "maybeWrapInExistential" in the builders.

@swift-ci smoke test

@swift-ci smoke test

@swift-ci smoke test


FEATURE - EXT - Connecting Product Filter with the Component Filter and vice versa

As a user, when I filter the Guided Answers list on a particular product I want to the component filter to only display the components that are appearing in my filtered product GA list so that when I filter on components my returned list is more meaningful
Description
All Guided Answers  are associated to Products and Components. When a user filters on a particular product they want to only want to see the Guided Answers associated to that product when they then further filter their list on the components they only want to see the Guided Answers associated to that Product and component.
The Product and Component filters are linked
When the user filters on a product only the components associated to the Guided Answers for that particular product should be displayed in the component  filter.
When the user filters on a component only the products associated to the Guided Answers for that particular component should be displayed in the Product filter.
Filtering  GA list on Product SAP Business Application Studio

Component Filter is updated to show the components associated to those 3 Guided Answers

Filter GA on Component

Product Filter is updated to show the the products associated to those 11 Guided Answers

Technical Design
Acceptance Criteria

Product and Component Filters are linked.

Notes
Tasks

[ ]
[ ] Unit Tests added
[ ] Test Cases defined

I noticed an issue when filtering on Component SV_PERF  the filter didn't work


pgbouncer log format >= 1.11 not supported

Hello. My setup:

badger version 11.1 (downloaded from https://github.com/darold/pgbadger/archive/master.zip)
bouncer 1.12.0

My Issue:
pgbadger  -I -O /tmp/bouncer /var/log/pgbouncer/pgbouncer.log
FATAL: unable to detect log file format from /var/log/pgbouncer/pgbouncer.log, please use -f option.

When I add -f option badger still not working as expected. Produces blank html.
My log formant was like:

2020-02-16 03:43:05.469 TIMEZONE [12528]

After I reformatted log myself (removed tz and brackets) all works fine.
I noticed that new logging format was added in
2019-08-27 - PgBouncer 1.11.0 - “Instinct for Greatness”
Originally posted by @dan-aksenov in https://github.com/darold/pgbadger/issues/558#issuecomment-587439408

Good catch, commit 98d4c99 adds support to this new log format. Thanks.


Integration with signal-struct

Hey @WebReflection I attempted to integrate usignal and/or signal into signal-struct, and found out that doesn't play well, unlike @preact/signals-core. Would you be open to in looking at possible obstacles? I suspect that can be due to conscious limitations, just curious to know if you'd be interested.

Not interested for signal, possibly interested for usignal. Signal is a bare implementation playground, not planning to make it any more complex than it is now


ktlint prints an error when running with JAVA_TOOL_OPTIONS

Expected Behavior

running ktlint with JAVA_TOOL_OPTIONS set should not produce an error

Observed Behavior

running ktlint with JAVA_TOOL_OPTIONS produces the following error
/usr/local/Cellar/ktlint/0.46.1/libexec/ktlint: line 5: [: Picked up JAVA_TOOL_OPTIONS: integer expression expected

Steps to Reproduce

download ktlint
export some JAVA_TOOL_OPTIONS
run ktlint
Your Environment

Version of ktlint used: 0.46.1
Relevant parts of the .editorconfig settings: n/a
Name and version (or code for custom task) of integration used (Gradle plugin, Maven plugin, command line, custom Gradle task): n/a
Version of Gradle used (if applicable): n/a
Operating System and version: macos 12.3
i have JAVA_TOOL_OPTIONS set

Investigation
This seems to be happening from these two lines in the ktlint start
# incorrectly retrieves version
JV=$(java -version 2>&1 | head -1 | cut -d'"' -f2 | sed '/^1\./s///' | cut -d'.' -f1)
echo $JV
# echoes 'Picked up JAVA_TOOL_OPTIONS:'
X=$( [ "$JV" -ge "16" ] && echo "--add-opens java.base/java.lang=ALL-UNNAMED" || echo "")
# this command fails because the version is not correctly parsed

Ktlint still runs okay, it just spits some errors in the beginning. This could be solved with a different way to get the java version. Perhaps something with sed or awk to search for the 'version' string instead of head.

https://github.com/pinterest/ktlint/pull/1544


BrowserWindow: Event listeners broken

Probably a regression. This
this.windowEl.on('resize', this.onSelectionPositioned, this)

no longer works. Stacktrace from Forms:

Tried to fix myself by delegating to the missing method, but this caused other troubles in converters. @oliver---- could you take a look?

Ok I think I fixed that issue, the converter trouble was due to a changed behavior convertDocument. Please review #1026


[Mod Request]: The Bumblezone

What does the mod do?
Adds many bee related things 🐝🐝🐝🐝🐝🐝 and a new dimension
Is this mod on Modrinth?
Yes
Link to the mod
https://modrinth.com/mod/the-bumblezone-fabric
Images

Tested and the dimension loads fine. Checked every biome + structure.
1 slightly weird issue with honey fluid as can be seen below but it's nothing game-breaking. you just can't see through the fluid properly.


scss autoprefixer problem

The SCSS inline style in  .vue   will use autoprefixer to add  -webkit- -moz- -o-
But the .scss file  in  assets  folder will not add .
What can be done to make the two behave same ?  Thx .

https://github.com/nuxt/nuxt.js/issues/996


ROX-26130: Make central notifier email library take report name param

Description
While we were testing a sample Compliance Report, we discovered that the filename contained the hard-coded string "Vulnerability_Report", from the original use-case of reports for CVEs only.
This change fixes that by using the actual user-specified Report Name from the Report configuration in place of that hard-coded string.
User-facing documentation

[x] CHANGELOG update is not needed
[x]  documentation PR is not needed

Testing and quality

[x] the change is production ready: the change is GA
[x] CI results are inspected

Automated testing

[x] added unit tests
[x] modified existing tests

How I validated my change

Updated existing automated test
Deployed this PR build, and sent samples of both kinds of reports and then inspected their filenames

Vulnerability Report named "Van3"

Compliance report named "van-scooby-1"

/test ocp-4-12-compliance-e2e-tests

/test gke-qa-e2e-tests

/test gke-qa-e2e-tests

/test ocp-4-12-qa-e2e-tests gke-qa-e2e-tests