Do not show inactive product variants in bonus products

Description
Please describe your pull request:

Why is it necessary?

Inactive product variants can be selected and added to the cart in the bonus product section of the cart.
I think this should not be the case. If you show the customer a bonus product and allow to add it to cart the product has to be available.

What does it improve?

To achieve this I removed inactive variants from the selection and additionally added a template variable of the stock value to make it possible to hide variants that have no stock.
Given the fact that not every store will manage stock levels, I did not add the stock check to the database query, but added the template variable. This way we can hide variants without stock with a template overwrite if desired.

Does it have side effects?

I do not know any.

Questions
Answers

BC breaks?
no

Tests pass?
yes

Related tickets?
none found

How to test?
setup demo store. Configure a bonus product with variants like the T-SHIRT LOGO TEE CHARCOAL. Set one variant to inactive. Fill your cart to match the bonus product criteria. validate that the inactive variant is not listed in the options. To check the template variable you need the shopware-profiler plugin. I will not go into details here.

Hello,
thank you for creating this pull request.
I have opened an issue on our Issue Tracker for you. See the issue link: https://issues.shopware.com/#/issues/SW-17471.
Please use this issue to track the state of your pull request.

Hi @jhit, thanks for your PR.
We think that adding the stock to the template is unnecessary and does not add a overall benefit to the product. But, we want to implement the active condition.
Please remove the stock information and create a new PR targeting 5.3 because this will introduce a break.

Hallo und danke für Ihre Nachricht!
Ich bin erst ab dem 24. April wieder im Büro.
Mein Kollege Michael Wamser<EMAIL_ADDRESS>hilft Ihnen gerne bei Ihrem Anliegen.
Danke für Ihr Verständnis!

Thats odd. You want to remove disabled products from the bonus products, but not allow to remove the ones without stock?
Also why is there no benefit to the product (Shopware) by adding the stock value to the template variables? How can I hide bonus products without stock without having this variable available?
I really need a way to hide bonus products that have no stock.


[BUG] copy-in command is failing on pot 13

Describe the bug
The copy-in command is failing on pot 0.13.0
To Reproduce
file: flavor
copy-in -s /usr/local/etc/pot/flavours/flavour.d/local -d /root/.pot_local

try build an image with a potbuilder script, fails with error
cp: /tmp/copy-in.V4IhQ7Iz: No such file or directory
jail: /bin/cp -a /tmp/copy-in.V4IhQ7Iz /root/.pot_local: failed
###>  Source /usr/local/etc/pot/flavours/flavour.d/local NOT copied because of an error

Expected behavior
The directory local and contents are copied in to /root/.pot_local
System configuration - if possible

/usr/local/etc/pot/pot.conf

POT_NETWORK=<IP_ADDRESS>/10
POT_NETMASK=<IP_ADDRESS>
POT_GATEWAY=<IP_ADDRESS>
POT_EXTIF=vtnet0

Additional context
This works fine on pot 0.11.6

Fixed in #176

See also #174


Missing quote line 207 of cis_5.3.x.yml

Describe the Issue
Missing quote line 207 of cis_5.3.x.yml
Expected Behavior
Line should start with quote or have no quote at the end. I don't see why you're matching the commented line either, although that's just my opinion.
Actual Behavior
This regex is not matching causing the line "HostbasedAuthentication no" to be added every time the tasks is run.
Control(s) Affected
What controls are being affected by the issue
Environment (please complete the following information):

Ansible Version: 2.9
Host Python Version: Python 2.7.5
Ansible Server Python Version: Python 3.6.8
Additional Details:

Additional Notes
Example result of current version:
grep ^HostbasedAuthentication /etc/ssh/sshd_config
HostbasedAuthentication no
HostbasedAuthentication no
HostbasedAuthentication no
HostbasedAuthentication no
HostbasedAuthentication no
Possible Solution
According to Anisble Module Doc a single quote on either end of the line or no quotes is the correct syntax. I test both and agree.

@mballon,
Thanks for the issue, I have the fix in a new branch and PR process going.
-George


"thank you for using SuperheroLeague" should be changed

@ErkanKanden So we need to change the message to the "Thanks you for using Superhero Meet" if Jitsi is inside an iframe and standalone as well? Or only when it's inside the Superhero.com?

meet.aepps and superhero/meet should be essentially the same service (regardless iframe or not)

I think this can be set in the configuration
Thanks. Yes, it will be nice to have such value in config.

I mean this option IS already existing in the config, just need to be setup per server

That was fixed in the server config


added privado.ai and PubMatic in company list

Congratulations on making a pull request!
Please make sure you check all the items.

[x] The numbering of the company that you added starts with 1.
[x] You have increased the Total Companies Added count.

Great 😊👌


Is there a way to customize the font size and colors, on my small screen font is super small

Also I prefer the standard white background and black font console, thank you

Found easy_config, the colors are still weird though


[ENH] Allow the player to set Height and Width for the Sequence Viewer window

Is your feature request related to a problem? Please describe.
It's currently possible (in the Options) to set a default value for the Sequence Editor Height and Width.
It would be handy to be able to do the same for the Sequence Viewer as well.
Describe the solution you'd like
Could you please consider adding "input boxes" to type the Height and Width for the Sequence Viewer?
Mock-up

By "Sequence Viewer" I mean.. the main GSE window, where there's the list of macros.

This is nice to have but it doesnt do anything for functionality.  Might come back to it later but for the moment if it aint broke dont fix it.

I slightly disagree with you. 😉
Functionality wise, it would allow the player to see more macros at first sight. The player would not be obliged to scroll down the Sequence Viewer that often.
For owners of Full HD monitors, I understand your point of view, it wouldn't change their life that much. But for owners of 4K monitors (like me), it would allow to see much more macros without the need to scroll down.

But in the scope of it translating spells into french and being able to
edit things easier - its importance is a lot lower.  It might be slightly
inconvenient but it doesn't impact much your ability to do things.
On Thu, 8 Jul 2021 at 13:22, xan2622 @.***> wrote:

I slightly disagree with you. 😉
Functionality wise, it would allow the player to see more macros at first
sight. The player would not be obliged to scroll down the Sequence Viewer
that often.
For owners of Full HD monitors, I understand your point of view, it
wouldn't change their life that much. But for owners of 4K monitors (like
me), it would allow to see much more macros without the need to scroll down.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/TimothyLuke/GnomeSequencer-Enhanced/issues/946#issuecomment-876102300,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAEMCFIHSDQOAZBTHQZP7HLTWUOHNANCNFSM4755YIXA
.

--
Timothy Minahan**M 0406 413 680  |  E @.**

And its about 2-4 weeks of work to do that without doing anything else.
On Thu, 8 Jul 2021 at 13:29, Timothy Minahan @.***> wrote:

But in the scope of it translating spells into french and being able to
edit things easier - its importance is a lot lower.  It might be slightly
inconvenient but it doesn't impact much your ability to do things.
On Thu, 8 Jul 2021 at 13:22, xan2622 @.***> wrote:

I slightly disagree with you. 😉
Functionality wise, it would allow the player to see more macros at first
sight. The player would not be obliged to scroll down the Sequence Viewer
that often.
For owners of Full HD monitors, I understand your point of view, it
wouldn't change their life that much. But for owners of 4K monitors (like
me), it would allow to see much more macros without the need to scroll down.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/TimothyLuke/GnomeSequencer-Enhanced/issues/946#issuecomment-876102300,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAEMCFIHSDQOAZBTHQZP7HLTWUOHNANCNFSM4755YIXA
.

Happy for it to sit open its just a priority

Oh, I agree with you about the fact that it's a very low priority. I do.
I just like brainstorming about features that I think the GSE user might find useful (for me too) and about small UI improvements that could make his/her life easier.
If you want to keep this issue closed, close it Timothy. 👍  I am not here to tell you what you have to do nor how to manage your Github repository (I hope you don't feel it this way).

No Not at all - its how discussion works - someone makes a good argument
(like its bad for a 4k monitor) it proves the need.
On Thu, 8 Jul 2021 at 13:57, xan2622 @.***> wrote:

Oh, I agree with you about the fact that it's a very low priority. I do.
I just like brainstorming about features that I think the GSE user might
find useful (for me too) and about small UI improvements that could make
his/her life easier.
If you want to keep this issue closed, close it Timothy. 👍 I am not here
to tell you what you have to do nor how to manage your Github repository (I
hope you don't feel it this way).
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/TimothyLuke/GnomeSequencer-Enhanced/issues/946#issuecomment-876114757,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAEMCFP4I2KMO7YOOIQNJZ3TWUSJXANCNFSM4755YIXA
.

--
Timothy Minahan**M 0406 413 680  |  E @.**


Redmine 1.3 repository visual branch

The visual branch in redmine 1.3 isn't showing the graph on a descent way.

Oh, I hadn't noticed a Redmine 1.3. I'll take a look.
What OS and browser do you see the issue in? Do you have a screenshot of how it looks?

http://imageshack.us/photo/my-images/403/71493589.png/
I use Windows 7 with chrome got the same problem with firefox and internet explorer

Unfortunately, the way the new revision graph has been implemented in Redmine 1.3 makes it difficult to style from themes.
I have submitted a patch to Redmine http://www.redmine.org/issues/9832 that at least makes the graph assume the correct height as indicated in whatever theme it is running. When that gets accepted into Redmine and released, at least the revision dots on the graph will align with the revision rows.
I have also created a new branch to track work done towards making the graph look good in Pepper, revision_graph. For now it just resets some of the existing styles.
Until Redmine changes the implementation of the graph, I am not sure there is much we can do about the look of it.

My patch to Redmine has now been applied and should make it into Redmine 1.3.1 - hopefully making the revision graph look at least a bit better.
I'd love to be able to style the graph, but unfortunately that's not possible nor is it an easy fix at the moment.
Closing this issue for now as I don't think there's more that can be done from our side.


Add a -public-linkage-for-metadata-accessors IRGen flag for LLDB.

In LLDB expressions, references to private metadata accessors may be
emitted and need to be bound to symbols available in the attached
program, even if these symbols are only supposed to have private
visibility within the program.
Also rdar://problem/48018240

@swift-ci test

This feels a bit arbitrary. What about all the other accessor functions IRGen emits, or even just private methods? Maybe instead do a post-processing pass on the LLVM module to make everything public?

Or have IRGen's linkage computation understand that private things from the execution context aren't actually object-file-private when running in the debugger.  We do something similar with private declarations when building for LTO.

Build failed
Swift Test Linux Platform
Git Sha - 95c96e83abd11aa36d1cc9d86247ca189b3f0bdd

This feels a bit arbitrary. What about all the other accessor functions IRGen emits, or even just private methods? Maybe instead do a post-processing pass on the LLVM module to make everything public?

Or have IRGen's linkage computation understand that private things from the execution context aren't actually object-file-private when running in the debugger. We do something similar with private declarations when building for LTO.

Can you elaborate on this a bit? So, still have an IRGen flag that specifies that this is for the expression evaluator, but have it apply to more kinds of symbols? What's a reasonable boundary?
A quick grep for LTO in IRGen didn't find any results, what should I be looking for?

Sorry, I meant for WMO.  See getIRLinkage in GenDecl.cpp.

Sorry for the delay.
@rjmccall Is this closer to what you had in mind? The option to communicate that we are in the LLDB expression evaluator is still there, but it is now localized to getIRLinkage().

@adrian-prantl LLDB defines a method named SwiftASTManipulator::MakeDeclarationsPublic(). Is it not getting called anymore? Or its not doing the right thing?

@adrian-prantl LLDB defines a method named SwiftASTManipulator::MakeDeclarationsPublic(). Is it not getting called anymore? Or its not doing the right thing?

IIUC the problem I'm trying to solve here is that Swift metadata accessors particularly are transparent to the AST and only injected/created by IRGen.

@adrian-prantl The linkage of a metadata accessor is computed from the access level of the nominal type. So if the type is public the accessor should be public too. Is this not happening in some cases?

@adrian-prantl The linkage of a metadata accessor is computed from the access level of the nominal type. So if the type is public the accessor should be public too. Is this not happening in some cases?

The type in the example was private.
For context, the expression is printing a global variable

private struct FixedContainer {
  var s = S() // S is a resilient struct and defined in a different module
}
private var g_main_c = FixedContainer()

@swift-ci test

@swift-ci test

The type in the example was private.

Right, but doesn't SwiftASTManipulator::MakeDeclarationsPublic() make everything public? That's the part I'm confused about.

As far as I understand the type in question is not part of the AST walked by SwiftASTManipulator::Publicist. It walks the expression source file, but our type is part of the swiftmodule that is being debugged.

Note that just because I merged this, doesn't mean we shouldn't still replace this with something better if we find it, but this is blocking all the resilience support.

@adrian-prantl No worries.
If the Decl is part of the swiftmodule being debugged, why is lldb emitting the type metadata accessor?

It's emitting a reference to the existing accessor (a declaration rather than a definition).

@jrose-apple I see. Perhaps it makes more sense to elevate private linkage to internal when emitting code with -g?


Updated instructions to get Mold linker working in MacOS

Objective

It'd be nice to have the Mold linker working in MacOS. These instructions update the installation instructions to make it so.

Solution

Updated instructions show how to use Brew / MacPorts to install Mold binaries; then how to update the rustflags annotations to ensure the linker binaries are found.

Neat! I don't have a mac myself; are there links to other docs you can pass on so I can attempt to give this a cursory verification?

Hey, @alice-i-cecile –
The closest I can get is from the horse's mouth: https://github.com/rui314/mold/blob/main/README.md
See the sections "If you are using Rust" and its qualifier "On macOS", which explain the need for the bin to be ld64.mold and not just mold.

@alice-i-cecile –
Note there's a tag-along PR: https://github.com/bevyengine/bevy-website/pull/472

Thanks, that's good enough for me. I'll give my approval once the typo is fixed, then wait for a mac user to try it out.

mold/macOS is available as an alpha version.

I would rather wait for mold to be ready before documenting it in Bevy

Yeah, let's wait until this is out of alpha.

Hmm. I wonder if it's just that the docs on that page haven't been updated?
1.6.0 is the latest release. In both Brew and MacPorts the build is also 1.6.0.

version is 1.6.0 as it's the base version of the code, but it's still alpha on macOS

Ah, yep: Author says it'll be 2.0 for MacOS: https://news.ycombinator.com/item?id=31769699
Thanks, @mockersf & @alice-i-cecile. I'll revisit this ticket once it's out. 👋🏻

looking forward to having mold being ready for macOS!


Generate job information on-the-fly

Currently a blob of JSON is saved into a job struct when the job is enqueued. There's no particular reason to do this, since it effectively serializes logic into the database before it's used.
This PR:

Moves non-formula keys required to generate a formula into an intent object
Adds a generate_formula which takes an intent
Upgrades /next to save & return the formula at the moment of launch.

LGTM.


can't change value of snmp_com2sec (and potentially some other variables)

I've tried t change value of snmp_com2sec to something like "notConfigUser  <IP_ADDRESS>     public".
Problem is that's not passing check_array.
So effectively you can't change it to a string you need.
here is error log:

Error: Could not retrieve catalog from remote server: Error 400 on SERVER: "notConfigUser  <IP_ADDRESS>     public" is not an Array.  It looks to be a String at /etc/puppet/blah-blah-blah/snmp/manifests/init.pp:319 on node test

Maybe it's not a best idea to use check_array for some of these variables.

@MaDYeTTi check_array is doing it's job.  Try setting the value to an array:
snmp_com2sec = ['notConfigUser <IP_ADDRESS> public']

Looks like this is not really a bug. Data typing has been put in place.


[IR] Automatically insert .cache calls

We would like to insert .cache calls in three cases:

a val or var is referenced more than once
a var is being assigned
a val or var is being referenced inside a loop that doesn't contain the definition of this val or var

I'm thinking about whether to do this on DSCF or on control-flow primitives.

Trivial in both cases.
Trivial with control-flow primitives, also relatively easy with DSCF (we have to detect when it's being referenced in the argument list of a call to a def that is the body of a loop)
Seems easy with control-flow primitives: we create an inherited attribute that tells the innermost enclosing loop, and then an accumulated attribute builds a map that shows for each ValDef which is the innermost loop that contains it. And then when we see a ValRef, we check whether the current innermost enclosing loop is the same as the innermost enclosing loop of the definition (which we get from the map). However, on DSCF it gets messy: we don't see the loops, but we see some DefDefs that were created from loops. But these DefDefs cannot be directly used the same way as the loops in the control-flow primitives representation, because the suffixes of the loops are also inside these DefDefs, and we don't want to insert a .cache call when the DataBag is used only in the suffix.

The easiest way that I can think of to do 3. on DSCF is to instead of maintaining just the innermost enclosing loop, we maintain the number of enclosing DefDefs that represent loops minus the number of enclosing suffix$ DefDefs. And then if this number is not the same for a ValRef as for its corresponding ValRef, then insert .cache. (I hope this works, but I'm not 100 sure.)

I'll try to reformulate 3 with the help of some imaginary API for the sake of further discussion.

[...] we create an inherited attribute that tells the innermost enclosing loop, [...]

// returns the innermost enclosing loop (if `t` is inside a loop)
def enclLoop(t: u.Tree): Option[u.TermSymbol]

[...] and then an accumulated attribute builds a map that shows for each ValDef which is the innermost loop that contains it [...].

// for a symbol represending a Scala `u.ValDef` or `u.VarDef`,
// returns the innermost enclosing loop (if `s` is defined inside a loop)
def inLoop(s: u.TermSymbol): Option[u.TermSymbol]

And then when we see a ValRef, we check whether the current innermost enclosing loop is the same as the innermost enclosing loop of the definition (which we get from the map).

I think if we should match BindingRef here.
case t@BindingRef(s)
  if inLoop(s) != enclLoop(s) && ... =>
  // ???

I'm not sure what to do in ??? other than store the information that s needs to be cached.
val x = /* some DataBag term */
// ...
f(x)

should be replaced with
val x = /* some DataBag term */
val y = x.cache()
// ...
f(y)

@joroKr21 The algorithm makes sense but a few things have to be revised in order to cover some corner cases.
R1. The check in (2) will not match the following
val xs = ???
for (i <- 1 to N) {
  if (i % 2 == 0) f(xs)
  else g(xs)
}

R2. I don't see how the sketched transformation will identy xs to be cached in the original motivating example:
val xs = ???
if (???) f(xs)
else g(xs)

This will have refCount = 2 and will be cached. To catch such cases, conceptually we have to

track the number of uses of a TermSym per block;
compute sets of independent blocks;
compute different possible refCount sums picking one element of each independent block set;
insert cache if a refCount > 1 exists.

Yes, indeed. The problem in R1 can be solved with this predicate (assuming we track the complete owner chain): owners.takeWhile(_ != ref.owner).exists(isLoop)
R2 poses an interesting question. If we generalize the refCount as a kind of score, how much is worth a ref within a branch? 0.5? Imagine that a ref can be nested in several layers of branching.

Closed via #305.


Weather app ionic

Added an Ionic 2 version of the Weather App Sample project. Can someone check it out (test it) and approve the PR if it's OK?

Hi @johnwargo, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!

It looks like you're a Microsoft contributor (John Wargo). If you're full-time, we DON'T require a Contribution License Agreement. If you are a vendor, please DO sign the electronic Contribution License Agreement. It will take 2 minutes and there's no faxing! https://cla.microsoft.com.

TTYL, MSBOT;

Looks good - I just see two changes to make:

Icons are missing for the Find button and the back button when looking at forecast details
Update to the Ionic 2 RC.4 bits - using the new Ionic 2 RC templates as a guide (https://blogs.msdn.microsoft.com/visualstudio/2016/12/20/create-great-looking-fast-mobile-apps-using-javascript-angular-2-and-ionic-2/) - namely, there are new version numbers for dependencies in package.json and new NPM build scripts.

Jordan, I upgraded the project to the latest template. I'm not sure what you mean about the buttons. The find button has the search icon in all of my testing and the forecast details is showing the back arrow (you can see examples in the screen shots in the project's readme). Can you share an image showing what you're seeing?


Use OpenDevin to fix MathAgent

There are a few typos and factual mistakes in math_agent/agent.yaml and math_agent/prompt.md. How many can you find? I see at least four:

agent.yaml L16: output -> outputs
2099-01-01 is Thursday, not Saturday
integral of sin(x^2) evaluated from -1 to 1 is 0.620537, not 0.603848
prompt.md L2: follwoing -> following

One can fix them manually, but it would be cool to use OpenDevin to find those problems and fix them by itself. Don't feed this issue to OpenDevin - that would be cheating XD.
https://github.com/OpenDevin/OpenDevin/blob/319b9ac0f341b4433fd2c8ab78340813d4e85bff/agenthub/micro/math_agent/agent.yaml#L1-L25
https://github.com/OpenDevin/OpenDevin/blob/319b9ac0f341b4433fd2c8ab78340813d4e85bff/agenthub/micro/math_agent/prompt.md?plain=1#L1-L23

Microsoft's wizardlm-2-8x22b fails! 😢

just random finds:
https://github.com/rakutentech/MathSensei
https://github.com/microsoft/autogen
https://github.com/microsoft/FLAML
https://microsoft.github.io/FLAML/blog/2023/06/28/MathChat/

@tobitege very interesting findings! Have you tried gpt-4o?

I think I did just before WizardLM 2, but didn't make screenies then, but it also failed iirc.


Struggling on setup Evercookie like dummy example

Hey,
i have some problems to setup a simple evercookie site pretty similar to the example dummy App.
If i start the Sever on Localhost:3000 i get the Index site and if i try to get oder set a Cookie, it fails. For example if i try to set a Cookie and sumbit the form i have some error in the console. (500 Internal Server Error - for etag, cache, auth, png)
Furthermore i can see, that the set.js file does not contains any information from <%= @data[:key] -%>', '<%= @data[:value] -%> and this leads to ec.set('', '')
Versions:
rvm - 1.29.4 (set rails as default)
gem - 2.7.7
rails - 5.2.1
bundler - 1.16.2

Are you using rails5 branch?

I wrote down the versions which I use for my testing. So , yes I using rails 5.

@Frige1 I asked if gem was installed from rails5 git branch. Published version doesn't work on rails 5. Add this to your Gemfile
gem 'evercookie', github: 'daddyz/evercookie', branch: 'rails5'

My setup is the following. After successful signup page view has:
set_evercookie(:uid, current_user.id)

Registration form view has:
check_evercookie(:uid)

And controller action handling registration has:
ever_value = evercookie_get_value(:uid)

After signup I am setting signed up user ID. Since it's stored on client side on registration form I include helper that adds JS for fetching evercookie value and pass it to controller in order to save in session. And registration controller action checks session for value that was set in previous step.
Hope it helps


Allow subclass node of equivalent type to override the lexical default node

currently I use all the lexical package except lexical-playground to build my editor, and as the product requirement, I need to store html string and pass the value to lexical editor, and thus I will use the html---lexical api to init my editor value.
however, the importDom api in TextNode and ParagraphNode do not satisfy all scenarios, such as, inline style not work for TextNode, can refer to #3558 and #3017
Then I found a way to overwrite the TextNode

class CustomTextNode extends TextNode {
    static importDOM(): DOMConversionMap | null {
        // custom logic
    }
}

const PlaygroundNodes: Array<
  | Klass<LexicalNode>
  | {
      replace: Klass<LexicalNode>;
      // eslint-disable-next-line @typescript-eslint/no-explicit-any
      with: <T extends { new (...args: any): any }>(node: InstanceType<T>) => LexicalNode;
    }
> = [
  {
    replace: CustomTextNode,
    with: (node: TextNode) => {
      return new CustomTextNode(node.__text);
    },
  },
  HeadingNode,
  ListNode,
  ListItemNode,
  ...
]

in this way, I can rewrite importDOM function to fix the deserialization problem in my case. But it will cause error as the snapshot below

So I submit this pull request to fix it. If not, do you have any idea how to solve this deserialization problem gracefully? thank you for your time.

You also need to register your CustomTextNode before you do the replacement.

You also need to register your CustomTextNode before you do the replacement.

Yeah, I pass the PlaygroundNodes which contains my CustomTextNode to LexicalComposer, and it works.
But it will causes the following error. So I submit this pull request to fix it. If the node with the same type to the default lexical Node and is the subclass of the original lexical Node, will not cause the below error.

Your CustomTextNode also needs a static getType() method that returns a different type than text.

I understand what you're trying to do, but you should never duplicate types. The standard TextNode in core is the only node that can have the type of text. Given you've replaced the base with your custom one, that should suffice. You shouldn't need to also have the same type anywhere. If you find there are differences then that's a bug we need to fix separately.

This doesn’t make sense to me. Why can’t you just give the subclass a different type, as dominic suggested? What breaks when you do that?


requires a peer of unibeautify@>= x.x.x but none is installed

Unfortunately, I still haven't managed to actually format a file using the cli :-/ It doesn't manage to find the formatters I installed, or I didn't manage to install them properly.
$ sudo npm install --global unibeautify-cli
/usr/local/bin/unibeautify -> /usr/local/lib/node_modules/unibeautify-cli/dist/cli.js
+<EMAIL_ADDRESS>added 3 packages from 3 contributors and updated 2 packages in 5.195s

$ sudo npm install --global @unibeautify/beautifier-prettydiff
npm WARN<EMAIL_ADDRESS>requires a peer of unibeautify@>= 0.9.1 but none is installed. You must install peer dependencies yourself.
npm WARN<EMAIL_ADDRESS>requires a peer of<EMAIL_ADDRESS>but none is installed. You must install peer dependencies yourself.

+<EMAIL_ADDRESS>updated 1 package in 3.976s

$ sudo npm install --global @unibeautify/beautifier-clang-format
npm WARN<EMAIL_ADDRESS>requires a peer of unibeautify@>= 0.15.0 but none is installed. You must install peer dependencies yourself.

+<EMAIL_ADDRESS>updated 1 package in 1.48s

$ echo | unibeautify --language JavaScript
(node:18459) UnhandledPromiseRejectionWarning: Error: Beautifiers not found for Language: JavaScript
    at Unibeautify.beautify (/usr/local/lib/node_modules/unibeautify-cli/node_modules/unibeautify/dist/src/beautifier.js:69:35)
    at Socket.process.stdin.on (/usr/local/lib/node_modules/unibeautify-cli/dist/cli.js:43:25)
    at Socket.emit (events.js:182:13)
    at addChunk (_stream_readable.js:283:12)
    at readableAddChunk (_stream_readable.js:264:11)
    at Socket.Readable.push (_stream_readable.js:219:10)
    at Pipe.onread (net.js:635:20)
(node:18459) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 2)
(node:18459) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

$ echo | unibeautify --language C
(node:18541) UnhandledPromiseRejectionWarning: Error: Beautifiers not found for Language: C
    at Unibeautify.beautify (/usr/local/lib/node_modules/unibeautify-cli/node_modules/unibeautify/dist/src/beautifier.js:69:35)
    at Socket.process.stdin.on (/usr/local/lib/node_modules/unibeautify-cli/dist/cli.js:43:25)
    at Socket.emit (events.js:182:13)
    at addChunk (_stream_readable.js:283:12)
    at readableAddChunk (_stream_readable.js:264:11)
    at Socket.Readable.push (_stream_readable.js:219:10)
    at Pipe.onread (net.js:635:20)
(node:18541) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 2)
(node:18541) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

Running on MacOS.
Is there something special about those @ packages?

Yea, it's the scoped package names.  find-global-packages does not find them, nor does any other global package finder.  If you would like to try a working version out, pull the ci-fixes branch and install that.  It's not pretty right now, I'm using Node's spawn process to run npm ls -g --depth=0 --json and retrieving them that way.  @Glavin001 is going to look into better ways.
I have it working with eslint and @unibeautify/beautifier-eslint installed globally and running
unibeautify -l JavaScript --config-json '{"JavaScript": {"beautifiers": ["ESLint"],"quotes": "double"}}' <<< "const test = 'test';"

which outputs const test = "test"; as I expect.

Closed by #28


[MonorepoBuilder] Add suggest to section_order

Add suggest to section_order to avoid it to be moved at the top of the composer.json file.
Related to #1406

Great :+1:


Request: Allow running commands as user

This would be useful for sending messages to programs like polybar, which are running for the user. Another useful feature would be the ability to pass the config file from an arbitrary location rather than in /etc/keyd.

commands are discouraged for such use cases --- keyd is meant to simulate a keyboard, not be a hotkey manager, and this inherently needs elevated privileges. Putting the configuration in /etc/keyd also communicates this: you don't want the configuration to be editable by any other program.
See also #211, #229, #243.
That said, you can already run a command as another user using su (though you would likely also need to pass some environment variables to make it work in general).


No horizontal scrollbar when increasing width of columns

SQL Operations Studio Version: 0.28.6
SQL Agent extension Version: 0.28.1
Steps to Reproduce:
Increase the width of a column, like Name, Last Run,...
You can't see the last one(s) anymore. But you also don't have any scrollbar to scroll...

@abist do you know if this is fixed in the latest round of agent changes?

Fixed in https://github.com/Microsoft/sqlopsstudio/pull/1335


Mesh instantiated from .blend file is shown as broken when viewing from specific angle

Godot version
v4.0.3.stable.mono
System information
Windows 10 22H2 Nvidia GTX 1060 Ti
Issue description
Mesh from .blend file it is displayed as broken when viewing from specific angles. I have enabled .blend file import feature in Project Settings -> Blender -> Enabled. I can instantiate exported .glb file properly, but instantiating auto imported .blend file produces glitchy mesh.
Steps to reproduce
https://github.com/godotengine/godot/assets/8630984/53381f61-8d91-4f06-9b39-a6bda5eee89c
Minimal reproduction project
.blend file that I used Wizard.zip

This is caused by automatic mesh LOD. As a workaround, disable LOD generation in the Import dock when selecting the .blend file in the FileSystem dock.


fix queryBuilder NullRefException

Wow! How come this was not seen and not captured. Thanks for this.

Wow! How come this was not seen and not captured. Thanks for this.


openstack: use OpenStackInstance in TeuthologyOpenStack

The setup() function of TeuthologyOpenStack creates an OpenStackInstance
datamember to cache results and avoid running numerous duplicate
commands.
Signed-off-by: Loic Dachary<EMAIL_ADDRESS>

Awesome!


make test agnostic to initial conditions

note that this test is not effective for values of '- none -' for
these settings

@jlantz @davidhabib @njjc feel free to review


PYIC-1391 kms key for core front

Proposed changes
What changed
PYIC-1391
Implemented kms key for dynamodb table for core-front - this was missing
the CKV mentioned PYIC-1391 - although I believe this was for core-back.

        modified:   template.yaml

Why did it change
PYIC-1391
Implemented kms key for dynamodb table for core-front - this was missing
the CKV mentioned PYIC-1391 - although I believe this was for core-back.

        modified:   template.yaml

Issue tracking

PYIC-1391

Checklists
Environment variables or secrets

[ ] No environment variables or secrets were added or changed

[ ] Documented in the README
[ ] Added to deployment repository
[ ] Added to local startup repository

Other considerations

[ ] Update README with any new instructions or tasks

This is now being handled in: https://github.com/alphagov/di-ipv-core-front/pull/515


add initial files

http://docs.fineuploader.com/branch/master/api/options.html#session
the session options seem not working
const uploader = new FineUploaderTraditional({
    options: {
        chunking: {
            enabled: true,
            concurrent: {
                enabled: true
            },
        },
        session:{
            endpoint: 'http://localhost:8080/list'
        },
        request: {
            endpoint: 'http://localhost:8080/uploads'
        },
        resume: {
            enabled: true
        },
        retry: {
            enableAuto: true,
            showButton: true
        },
        callbacks: {
            onComplete: (id, name, response) => {
                console.log(id,name,response)
                // handle completed upload
            }
        }
    }
})

<Gallery uploader={ uploader } />

Please explain what "not working" means. What are you seeing in the console? What does the HTTP request sent by Fine Uploader look like? How about the response?

@rnicholus
[{"name":"small.mp4", "uuid": "da7276a8-15ca-4150-858e-2048d20e9a37"}]

Oh, yes, React Fine Uploader does not currently listen for the response to the session request. Furthermore, there is not a simple way (yet) to generate a <Gallery /> tile for a non-file (in this case, a file record already stored on the server).
I haven't given this a lot of thought yet, but I think this feature can be rather easily added to React Fine Uploader simply by listening for onStatusChange callbacks/events in <Gallery /> and focusing on qq.status.UPLOAD_SUCCESSFUL statuses. If a file's status comes through as qq.status.UPLOAD_SUCCESSFUL and it doesn't yet exist in the gallery, then it is a canned/initial file and should be rendered as s tile.
I'd be happy to offer guidance if you're willing to work on a pull request to add this support.

@rnicholus
I would like to ask one more related question.
I use addInitialFiles() to add initial files that items previously uploaded and store all information in database..
http://docs.fineuploader.com/branch/master/features/session.html
let list = [{
    id: 0,
    name: "Lighthouse.jpg",
    size: 561276,
    thumbnailUrl: "htt:/localhos:888/101/77eb5865-ac03-407c-93c5-592b6e9977bd/Lighthouse.jpg",
    uuid: "77eb5865-ac03-407c-93c5-592b6e9977bd"
}, {
    id: 1,
    name: "Penguins.jpg",
    size: 777835,
    thumbnailUrl: "http://localhost:8888/101/99877149-53a2-41ac-bf6a-931c1ec1ff40/Penguins.jpg",
    uuid: "99877149-53a2-41ac-bf6a-931c1ec1ff40"
}];

uploader.methods.addInitialFiles(list);

But <Gallery /> can't display thumbnail image.
I want to use <Gallery /> to manage previously uploaded image.
Do you have any suggestion ?

By the way,
if i use <Thumbnail /> to display image.
It will show below svg image for each items.

It seem to drawThumbnail method in <Thumbnail /> only pass three parameter.
// https://github.com/FineUploader/react-fine-uploader/blob/master/src/thumbnail/index.jsx
// line 33-38
this.props.uploader.methods.drawThumbnail(
            this.props.id,
            this.refs.canvas,
            this.props.maxSize
        )

Actually, i found out drawThumbnail can support more parameters.
if fromServer is null, fileOrUrl will be replaced by getFile() function
drawThumbnail: function (fileId, imgOrCanvas, maxSize, fromServer, customResizeFunction)
{
  //....
  if (!fromServer && qq.supportedFeatures.imagePreviews) {
        fileOrUrl = this.getFile(fileId);
  }
  //....
}

Therefore, i try to pass extra-parameter fromServer : true in drawThumbnail
It's workable for me.  :smile:
But i think it will impact <Gallery /> component, because of  <Gallery /> generate image from file directly (not URL).
This parameter should be managed carefully.

I'd be happy to offer guidance if you're willing to work on a pull request to add this support.

Re-opening as it seems this is still needed & there is still work to be done here.

I have followed the suggestions on this thread to use onStatusChange event and fromServer parameter to process the initial files, have a look at these changes and let me know if you want me to create a pull request.
https://github.com/truztee/react-fine-uploader/commit/9370c66da06db75185db7226c44db5f6285b4958

Looks good except for a couple things:

Array.prototype.findIndex is not supported in any version of IE.
docs will need to be updated, at least for Thumbnail.
updated or new unit test should be considered.

Please do open up a PR.

I'm struggling using this feature and following @smilejos solution, would anyone be so kind and point me to where I could find some docs about this?
Or maybe someone could give me a hand: My ImagesUploader component is as this:
const ImagesUploader = props => {
  const uploader = new FineUploaderTraditional({
    options: {
      debug: true,
      multiple: false,
      request: {
        endpoint: endpoint(props),
        method: method(props)
      },
      validation: {
        itemLimit: 1
      },
      deleteFile: {
        enabled: true,
        endpoint: endpoint(props)
      },
      cors: {
        expected: true
      },
      callbacks: {
        onComplete: (id, name, response) => {
          if (response.success) {
            console.log("UPLOAD SUCCESS");
          } else {
            console.log("problem uploading stuff");
            inspect(response, "response");
          }
        }
      }
    }
  });

  const list = [
    {
      id: 0,
      name: "prima foto",
      size: 561276,
      thumbnailUrl:
        "http://localhost:5000/uploads/item/image/14/533352.jpeg",
      uuid: "77eb5865-ac03-407c-93c5-592b6e9977bd"
    },
    {
      id: 1,
      name: "foto",
      size: 777835,
      thumbnailUrl:
        "http://localhost:5000/uploads/nikele/item/15/185941.jpeg",
      uuid: "99877149-53a2-41ac-bf6a-931c1ec1ff40"
    }
  ];

  uploader.methods.addInitialFiles(list);
  list.forEach(element => {
    // function(fileId, imgOrCanvas, maxSize, fromServer, customResizeFunction)
    uploader.methods.drawThumbnail(element.id, {tagName: "img"}, 300, true);
  });

  return (
    <div id="upload-area">
      <Gallery uploader={uploader} />
    </div>
  );
};

It shows the select files button, the drop files area, but no thumbnails, the uploads work fine, but I see no thumbnails of the files just uploaded either.
Thanks in advance :)

I am facing a problem, with this issue. I used this component in a form, and when I open the form I already have the files uploaded data. So I prefer not to send a new request to the server for what I already have in the client.
I used the model that @smilejos is presented above. But it does not work.
let list = [{
    id: 0,
    name: "Lighthouse.jpg",
    size: 561276,
    thumbnailUrl: "http:/localhost/101/77eb5865-ac03-407c-93c5-592b6e9977bd/Lighthouse.jpg",
    uuid: "77eb5865-ac03-407c-93c5-592b6e9977bd"
}, {
    id: 1,
    name: "Penguins.jpg",
    size: 777835,
    thumbnailUrl: "http://localhost/101/99877149-53a2-41ac-bf6a-931c1ec1ff40/Penguins.jpg",
    uuid: "99877149-53a2-41ac-bf6a-931c1ec1ff40"
}];

uploader.methods.addInitialFiles(list);

<Gallery uploader={ uploader } />

It this supposed to work? I tried to debug addInitialFiles method and I found that it goes to file-uploader.core.js and fires this._uploadData.addFile method. But in the end no thumbnail is rendered.
What am I missing? can some one guide how to do add initial files correctly in react-fine-uploader.
I use the following versions.
  "react-fine-uploader": "^1.1.0"
  "fine-uploader": "^5.16.2",
  "fine-uploader-wrappers": "^1.0.1",

Thanks


[FR] display links as clickable in table views (links for line items of POs etc)

Please verify that this feature request has NOT been suggested before.

[X] I checked and didn't find a similar feature request

Problem statement
when adding links to supplier parts, those links were previously rendered as clickable html links in table views like purchase order line items etc. In the PUI interface, the whole table row now has the same link action (which is generally very consistent and appreciated compared to the old interface) - but especially in PO line items it is very useful to be able to directly click on those links when assembling a shopping cart for purchasing parts

Suggested solution
table fields containing URLs should be excluded from the current "boundary box link" and the URLs should be rendered as <a href...>html links instead like this:

Describe alternatives you've considered
Depending on UI consistency considerations this could instead be implemented with a small icon next to the URL as a "action button" - but I think a traditional link with the classic underline should be conventionally recognized by users
Examples of other systems
No response
Do you want to develop this?

[ ] I want to develop this.

@simonkuehling thanks, this is a simple fix, we already the column rendering functions in place - https://github.com/inventree/InvenTree/pull/8072


docs: fix C examples in blas/ext/base/dsumkbn

Description

What is the purpose of this pull request?

This pull request:

update the N parameter in C examples.

Related Issues

Does this pull request have any related issues?

No.
Questions

Any questions for reviewers of this pull request?

No.
Other

Any other information relevant to this pull request? This may include screenshots, references, and/or implementation notes.

No.
Checklist

Please ensure the following tasks are completed before submitting this pull request.

[x] Read, understood, and followed the contributing guidelines.

@stdlib-js/reviewers

As the CI failure is expected, I'll go ahead and merge.


bug: Startsh allow empty RLN_PASSWORD and fix docker-compose command

It should allow empty string for RLN_PASSWORD
Instead of docker-compose we need docker compose

You can check here to get some inspiration

Lets merge the fix into #51 branch

Closed with #65


Add support for passing replace parameter

I need to be able to pass the replace argument into the VM extension
I have a release that always recreates a VM and adds it to a deployment group via an ARM template, and it fails the second deployment with this error:
VM has reported a failure when processing extension 'TeamServicesAgent'.
The Extension failed to execute: Agent Configuration failed with error - DeploymentGroup 45 already contains a machine with name VM1-DG.

@chshrikh for deployment group question.

@sachinma can you check this

We will add to our backlog. For now, as a workaround, can you delete the target from the deployment group first as part of your workflow using REST APIs.


add password option fixes

This PR adds the option of true to the else if statements in the password option function.

The true option in the if else statements are not needed as the last else in the statement would assume the variable is true.


Can be redirected to Home page even after Signout

Even On Signout, if we try to visit home page I am able to do so. Put a check here

assigned to @admirerr

The PR by @JainendraDwivedi  is for a different Issue

assigned to @rahulm682


Restriction transaction

I'll recommit this PR after update<EMAIL_ADDRESS>

Pull Request Test Coverage Report for Build 212

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

Totals

Change from base Build 201:
0.0%

Covered Lines:
101

Relevant Lines:
110

💛  - Coveralls

Moved RestrictionType builders to a separate service RestrictionService and added some more tests and validators.


Taskbar reappears randomly on Windows 11

Not really expecting support on this, but figured I would make an issue regardless for when Window 11 gets official full release. I am currently running the insider build of Windows 11 and after a few minutes the taskbar randomly reappears. I don't believe anything specifically triggers it to happen and happens with or without any interaction. Toggling work mode on and off re-hides the taskbar, but then after some time the taskbar will pop back up.

I found that enabling the option Personalization -> Taskbar -> Taskbar behaviors -> Automatically hide the taskbar is a temporary workaround for this issue.


nixos/switch-to-configuration: replace Net::DBus with busctl

Description of changes
Call dbus by using $cur_systemd/busctl --json=... and core modules JSON::PP and IPC::Cmd, instead of using Net::DBus, to try to slim down dependencies for baseSystem.
perlPackages.NetDBus pulls in quite a few other dependencies, like XML::Twig, XML::Parser, LWP, and HTTP::Daemon, etc. These are not really necessary for s-t-c, and updates to them have caused issues with cross builds.
For example https://github.com/NixOS/nixpkgs/pull/181632 that caused:

https://github.com/NixOS/nixpkgs/issues/182287
https://github.com/NixOS/nixpkgs/issues/182502
and more

Things done

Built on platform(s)

[ ] 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
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
22.11 Release Notes (or backporting 22.05 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

[ ] Fits CONTRIBUTING.md.

@GrahamcOfBorg test switchTest

oh boy

Test:

[X] nixos.switchTest
[X] cross build of sd-image-aarch64

does not contain perlPackages.LWP and its deps

[ ] dogfood on local installs


Commands are not extracted from robotframework.zip

Describe the bug
Commands from robot framework are not extracted when a new robot version is created.
To Reproduce
Steps to reproduce the behavior:

Go to http://<IP_ADDRESS>:8000/sources/robot/
Click on '+' to add a new robot item
Fill all fields with valid data. (to get a valid zip file https://pypi.org/project/robotframework/#files)
create on create
Move to commands http://<IP_ADDRESS>:8000/commands/
Search for a valid command from a extracted library (e.g. Evaluate)

Expected behavior
commands from each extracted library from the robot.zip should be displayed
Screenshots
The newly created version and its libraries are displayed

Desktop (please complete the following information):
OS: macOS 10.15
Browser chrome
Version 83.0.4103.116
Additional context
Add any other context about the problem here.

This is also affecting the "M-Extract" functionality

The zip file was invalid. The valid one is here:
http://robotframework.org/robotframework/#standard-libraries
Downloading the zip file here, the libraries are extracted correctly.

working on, Need to  verify mExtract.
There is already a workaround documented in trouble section,
Need a redesign? Need to be more explicit in the User Documentation, wizard?

M-Extract seem to work well too. I searched a command and it didn't appear with a source. Then, when I clicked "+" -->  M-extract --> "get commands from local server", and searched the same command, it appear's an "Ubuntu 18.04" source.

@raaul19 with mExtract it didnt appear if you import the valid libraries from this link http://robotframework.org/robotframework/#standard-libraries?

It's pretty the same, it only appear more "sources" when you try to edit one command. (including the source "Ubuntu -18.04"


feat: Add caution note about executing AI generated code.

Closes #19
/claim #19

@mobley-trent appreciate it, could you please style it accordingly as it can't be on the same level of importance as other sections, this is a caution note.

@nkkko updated the background colour and the header text

@mobley-trent I will add a 10$ tip but please style it more subtly and show it only after the devcontainer.json is generated. Currently this is a sore eye. And could deter people from using it.

@nkkko I added rounded edges to the div as well as a caution emoji to make it less jarring

Sorry, can't accept this, looks terrible:

It rendered a lot differently on my machine. I'm happy to open another PR


 I keep getting permission issues when updating apt. I am calling the role with sudo as well, but that doesn't seem to propagate down.
I am running Ubuntu 14.04 trusty64
ansible <IP_ADDRESS>
ansible-playbook <IP_ADDRESS>

When I get to the Add Docker repository and update apt cache step I get the following:
TASK: [docker.ubuntu | Add Docker repository and update apt cache] ************
<<IP_ADDRESS>> ESTABLISH CONNECTION FOR USER: vagrant
<<IP_ADDRESS>> REMOTE_MODULE apt_repository state=present repo='deb https://apt.dockerproject.org/repo ubuntu-trusty main'
<<IP_ADDRESS>> EXEC ssh -C -tt -vvv -o UserKnownHostsFile=/dev/null -o IdentitiesOnly=yes -o ControlMaster=auto -o ControlPersist=60s -o ControlPath="/Users/george/.ansible/cp/ansible-ssh-%h-%p-%r" -o StrictHostKeyChecking=no -o Port=2222 -o IdentityFile="/Users/george/personal/GeorgeMac/web2/.vagrant/machines/default/virtualbox/private_key" -o KbdInteractiveAuthentication=no -o PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey -o PasswordAuthentication=no -o User=vagrant -o ConnectTimeout=30 <IP_ADDRESS> /bin/sh -c 'mkdir -p $HOME/.ansible/tmp/ansible-tmp-1453055707.24-233988419299979 && echo $HOME/.ansible/tmp/ansible-tmp-1453055707.24-233988419299979'
<<IP_ADDRESS>> PUT /var/folders/lz/sycggpkn1ws6kj4jgs4p_jqm0000gn/T/tmpZvOzpI TO /home/vagrant/.ansible/tmp/ansible-tmp-1453055707.24-233988419299979/apt_repository
<<IP_ADDRESS>> EXEC ssh -C -tt -vvv -o UserKnownHostsFile=/dev/null -o IdentitiesOnly=yes -o ControlMaster=auto -o ControlPersist=60s -o ControlPath="/Users/george/.ansible/cp/ansible-ssh-%h-%p-%r" -o StrictHostKeyChecking=no -o Port=2222 -o IdentityFile="/Users/george/personal/GeorgeMac/web2/.vagrant/machines/default/virtualbox/private_key" -o KbdInteractiveAuthentication=no -o PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey -o PasswordAuthentication=no -o User=vagrant -o ConnectTimeout=30 <IP_ADDRESS> /bin/sh -c 'LANG=en_US.UTF-8 LC_CTYPE=en_US.UTF-8 /usr/bin/python /home/vagrant/.ansible/tmp/ansible-tmp-1453055707.24-233988419299979/apt_repository; rm -rf /home/vagrant/.ansible/tmp/ansible-tmp-1453055707.24-233988419299979/ >/dev/null 2>&1'
failed: [default] => {"failed": true}
msg: [Errno 13] Permission denied: '/etc/apt/sources.list.d/.apt_dockerproject_org_repo.list-HW7gKA'

FATAL: all hosts have already failed -- aborting

Short of messing with the role source to add sudo permissions. Could anyone give me some advice?
Cheers!

So, I don't know what's happening since I've not experienced this before, but I'd definitely validate that you're doing the following:

using sudo
supplying a sudo password (like via --ask-sudo-pass, or in inventory somewhere, or config, or whatever)

And if that doesn't work, try this out:

Upgrade to the latest 1.9.x series (if you're using pip, pip install --upgrade 'ansible<2')
You're using vagrant, so spin up a vagrant box, SSH in, and run the steps manually to add the repository and then run the apt cache.

Cheers @angstwad I will get on that. I am sure I am messing this up :)


Auto-upgrade to <IP_ADDRESS>

Base PullRequest
default branch (https://github.com/http4k/http4k-connect/tree/master)
Command results

Details:

add path
/home/runner/work/_actions/technote-space/create-pr-action/v2/node_modules/npm-check-updates/bin

./upgrade_http4k.sh <IP_ADDRESS>

Changed files

Changed file:

gradle.properties

:octocat: Repo | :memo: Issues | :department_store: Marketplace

Codecov Report

Merging #74 (ae3929d) into master (9f2ddae) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master      #74   +/-   ##
=========================================
  Coverage     61.44%   61.44%
  Complexity      620      620
=========================================
  Files           374      374
  Lines          3997     3997
  Branches        265      265
=========================================
  Hits           2456     2456
  Misses         1379     1379
  Partials        162      162

Continue to review full report at Codecov.

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


updated author field in android run 2017

There was an error while validating job e14e4208-a7ea-4854-8b60-c54ad892c067 Message:
Result status: Failed
There was a problem accessing Github repository 'https://github.com/Microsoft/cordova-docs.git'.
Details:Microsoft.LightweightJobEngine.Core.Language.ContextCommandBase+ContextCommandException:
Result status: Failed
There was a problem accessing Github repository 'https://github.com/Microsoft/cordova-docs.git'.
---> System.AggregateException: One or more errors occurred. ---> System.ArgumentException: Error clonning repository ---> LibGit2Sharp.NotFoundException: Branch 562 not found. Available branches: origin/master
at Microsoft.DPS.Services.LibGit2SharpSourceControlProvider.GetBranch(Repository repo, String name)
at Microsoft.DPS.Services.LibGit2SharpSourceControlProvider.<>c__DisplayClass47_2.b__5(KeyValuePair2 branch)    at System.Collections.Generic.List1.ForEach(Action1 action)    at Microsoft.DPS.Services.LibGit2SharpSourceControlProvider.<>c__DisplayClass47_1.<CloneRepository>b__2()    at Microsoft.Practices.EnterpriseLibrary.TransientFaultHandling.RetryPolicy.<>c__DisplayClass1.<ExecuteAction>b__0()    at Microsoft.Practices.EnterpriseLibrary.TransientFaultHandling.RetryPolicy.ExecuteAction[TResult](Func1 func)
at Microsoft.Practices.EnterpriseLibrary.TransientFaultHandling.RetryPolicy.ExecuteAction(Action action)
at Microsoft.DPS.Services.LibGit2SharpSourceControlProvider.CloneRepository(String url, IDictionary2 branches)    --- End of inner exception stack trace ---    at Microsoft.DPS.Services.LibGit2SharpSourceControlProvider.CloneRepository(String url, IDictionary2 branches)
at Microsoft.DPS.Services.LibGit2SharpSourceControlProvider.CloneRepository()
at Microsoft.DPS.Services.LibGit2SharpSourceControlProvider.GetVersionAsync(String path)
at Microsoft.DPS.Commands.IdentifyDocumentsToPublish.CheckExternalServicesCommand.Do(IDictionary2 context)    --- End of inner exception stack trace ---    --- End of inner exception stack trace ---    at Microsoft.LightweightJobEngine.Core.Language.ContextCommandBase.ThrowIfErrorsLogged()    at Microsoft.DPS.Commands.IdentifyDocumentsToPublish.CheckExternalServicesCommand.Do(IDictionary2 context)
at Microsoft.LightweightJobEngine.Core.Language.JobWorkflow1.RunCommands(Guid jobId, IDictionary2 context, CancellationTokenSource cancelSignal)

:white_check_mark: Validation status: passed
For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Xml radon and linting

Added docstrings (fixs lint warnings)
Removed a couple of unnecessary ifs (radon -0.0666)
Fixed an issue with comment skipping if no space between !-- and comment text

Don't use startswith, it came in python 3.8, it's a bit too recent. I would use
if '<!--' in data:

It seems to be available in 3.6 (and further back) - https://docs.python.org/3.6/library/stdtypes.html#str.startswith ?
But totally happy if you'd rather change it. The check needs to be that it starts with, rather than has, so something like data.index("<!--") == 0 would work.


ENH: Speed up topo plots

So far only _plot_evoked_topo has been sped up, but anything else using mne.viz.topo._plot_topo could benefit from the same treatment. That means mne.time_frequency.tfr.AverageTFR.plot_topo and mne.viz.topo.plot_topo_image_epochs.
The transition involves taking what was formerly e.g. 306 individual axes and making it one single axes object, where data are plotted with offsets to be in the correct locations. Take a look at how _plot_timeseries and _plot_timeseries_unified work to see the types of changes that need to be made.
Now that we are unifying plotting in this way, iter_topography actually is not a great way to do the plotting. For the unified methods, plotting them directly in a for loop would allow construction of Collections, which should further speed up plotting. It would also make the code a little bit easier to follow I think.

This would be great to have! The plotting functions are pretty slow

If you have any particular slow plotting functions identified, if you could paste the timing of the draw call, with an example or a few lines to reproduce it, it would help the next time one of us gets bored and wants to work on it.


Work around JuliaLang/julia#9232

I believe this should behave identically. Of course it would be better to fix the underlying issue in Base.

Bump. I'm pretty sure the test failures here are from changes to handling of Integers and Float32 in Base, not from this PR. I can look into that as well, but right now this is breaking intermittently breaking some uses of GLM, which is bad.

Seems that JuliaLang/julia#9232 is closed. Is this still an issue?

I'm pretty sure this is fixed.


Could not find configtx.yaml

I am using first-network application(https://github.com/hyperledger/fabric-samples).
When i run the command to generate(./byfn.sh -m generate) the channel artifacts it gives me following error.

However i already exported FABRIC_CFG_PATH, but it still gives me this error.
FABRIC_CFG_PATH is already printed in screenshot as "/c/apps/fabric-samples/first-network"
Attached the other files
configtx.yaml.txt
crypto-config.yaml.txt
Can anyone please help me in this?

marbles is not the appropriate repo for this question. please try Hyperledger's Jira.


Modify README to run search_cli and rank_cli

@googlebot I signed it!

This has landed, thanks for your contribution.


Improve accessibility

Pull Request
Related issue
Fixes #487
What does this PR do?

Improved accessibility by using proper aria and working upon the suggestions of lighthouse

PR checklist
Please check if your PR fulfills the following requirements:

[x] Does this PR fix an existing issue, or have you listed the changes applied in the PR description (and why they are needed)?
[x] Have you read the contributing guidelines?
[x] Have you made sure that the title is accurate and descriptive of the changes?

Thank you so much for contributing to Meilisearch!

Hello @developer-diganta 👋
This is a great addition, thanks a lot for your suggestion and your PR! It's really appreciated 🥳
bors try


32 bit builds made with MSYS2 require dlls to be present in the Project 64 folder/have make_w32.cmd default to MSYS2 as the default compiler

Compiled 32 bit builds made with MSYS2 require 2 dlls to be present in the main Project 64 folder or else the program cannot detect or use the compiled rsp plugin. Both dlls can be found in C:\msys64\mingw32\bin, assuming the default install location of MSYS2 is used. The dlls are:

libgcc_s_dw2-1.dll
libwinpthread-1.dll

This behavior is not true for the 64 bit version built with MSYS2. Using 64 bit builds made with MSYS2 with Project 64's 64 bit version does not require the dlls and can be used as is by simply putting the rsp plugin in Project 64's RSP plugin folder. Is this intended behavior or is there something wrong here? I built the 32 bit version by replacing "set MinGW=C:\MinGW" with "set MinGW=C:\msys64\mingw32" in make_w32.cmd like the comment in said file states to. I have made no other modifications to source or the build scripts.
Rather than make two issues I'll just quickly add this here since it's related to the subject. Can make_w32.cmd default to MSYS2? I don't see a good reason to be using older software that isn't really updated when MSYS2 achieves the same result, is updated regularly, and is also the default for make_w64.cmd.

Did not actually put any comments in make_w32.cmd saying to switch from original MinGW to MSYS...that was just a commented-out thing I left behind so that people could toggle it for themselves if they wanted to for some reason.  I only ever tested the Windows port of the plugin by using the official MinGW.
Are you reporting that those extra DLL files are being required when the plugin is linked by MinGW, or are you reporting that they're a requirement when changing the 32-bit version to set MinGW=C:\msys64\mingw32?

Sorry if my wording was weird, I never meant to imply you wanted to switch from MinGW to MSYS. I was just referring to the commented out setting. Yes when changing the line to set MinGW=C:\msys64\mingw32 in make make_w32.cmd the extra dll files become required.
I was requesting you at least consider switching the 32 bit build to use MSYS2 by default since MSYS2 is kept much more up to date compared to MinGW.

Nah, no worries.  It was more the way I worded it in the CMD script ("the only line you should need to change" (but shouldn't necessarily (have to))).
I suppose MSYS fork can be defaulting to a different static/dynamic linker flag for libgcc_s for 32-bit targets vs. when targeting 64-bit.  Normally GCC has a flag you can toggle to link the DLL statically for dynamically.  It used to not matter because until recent versions of MinGW (which caused someone else to have to submit a pull request to fix my script a year back) I was able to just call ld directly at the very end of the CMD file, not gcc.
So you could try changing
gcc --shared -e _DllMain@12 -o "%obj%\rspdebug.dll" -L %lib% %OBJ_LIST% -lmsvcrt

to
ld --shared -e _DllMain@12 -o "%obj%\rspdebug.dll" -L %lib% %OBJ_LIST% -lmsvcrt

...which used to work back when I had Microsoft Windows installed myself to test development on but some years later I guess either they (or MSYS fork of them) broke that.  If that works then you would avoid implicit linkage of irrelevant libraries like winpthread that I never intended as dependencies of my RSP code.  If that doesn't work then, well, such is life on an OS I gave up testing years ago I guess.  I do not have time to figure much Windows stuff out.
More to the point of your post, is there any benefit to switching from MinGW to MSYS for the 32-bit build?

Changing
gcc --shared -e _DllMain@12 -o "%obj%\rspdebug.dll" -L %lib% %OBJ_LIST% -lmsvcrt

to
ld --shared -e _DllMain@12 -o "%obj%\rspdebug.dll" -L %lib% %OBJ_LIST% -lmsvcrt

did not work as the plugin failed to compile. However I believe using the -static flag will work. I compiled the plugin with the flag and tested it out and it seemed to no longer require the dlls to be present in order for Project 64 to use the plugin. I myself have very little experience with this stuff though so feel free to correct me here.
Source I used to find the flag:
https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html
I don't know why the 64 bit build script does not require any flags to be statically linked but maybe it should also be added to make_w64.cmd as future proofing?
As for switching the default compiler to MSYS2 for make_w32.cmd I believe the main benefit would be convenience. Most projects I've come across use MSYS2 for both it's ability to build 64 bit Windows programs and it's ability to compile 32 bit programs as well. There really isn't a need to have two programs to compile 32 bit programs when you have one program to compile both 32 bit and 64 bit programs. MSYS2 also has more packages, afaik, and is more up to date in general. It seems MinGW is only at GCC version 9.2 while MSYS2 is at 10.3.
https://osdn.net/projects/mingw/releases/
https://packages.msys2.org/base/mingw-w64-gcc

Changing the gcc to ld would not have actually any effect on compilation.  By the time it gets to that line at the bottom, compilation to the x86 asm files has already long completed.  The problem is that MSYS began requiring additional dependencies to be auto-linked into simple DLLs that MinGW did not force dependencies with (such as I remember winpthread being one of them indeed).  They probably don't use pthreads for 64-bit builds because 64-bit Microsoft Windows already implies multi-threading support.  (This plugin never does anything with multi-threading anyway or let alone takes advantage of that....)
I am sure that -static would work as you say to remove the external DLL dependencies; however all that does is statically link the portions of the needed DLL files into the file size of rsp.dll and just make the plugin larger.  One good reason I used to call ld directly rather than gcc was to eliminate unintended dependency generation altogether (rather than statically link it / make it invisible as a growth to the file size of my plugin) and that if it failed to link the plugin without those dependencies, it would not create the plugin with the problems hidden, but throw a link-time error so that I could be aware of the issue and find a different solution to not generate them in the first place.  So I will never accept defaulting -static as a solution.

As for switching the default compiler to MSYS2 for make_w32.cmd I believe the main benefit would be convenience. Most projects I've come across use MSYS2 for both it's ability to build 64 bit Windows programs and it's ability to compile 32 bit programs as well. There really isn't a need to have two programs to compile 32 bit programs when you have one program to compile both 32 bit and 64 bit programs. MSYS2 also has more packages, afaik, and is more up to date in general. It seems MinGW is only at GCC version 9.2 while MSYS2 is at 10.

OK.  So to me it sounds like most of the reason is to have newest versions of GCC for more liklihood of up-to-date function optimizations (by being a little bit closer to the version numbers of GCC available natively on the GNU platform).
Some internal drama happened that caused MinGW 64-bit to split off and recede over to MSYS2 and I can't remember much about that.  I did not like how they did it.  As far as I'm concerned MinGW is still the official port of GCC to Windows and MSYS2 should only be required when building the 64-bit version of the plugin because that responsibility was taken away from the upstream MinGW project through some sort of political egocentricity that I can't remember well at all now.  I know you are mostly debating on the side of convenience and not political technicalities, but at the same time I have to consider what about 32-bit builds is more convenient than 64-bit builds.  Nothing about the 32-bit plugin should ever be faster than the 64-bit build, so if the reason for using the newer GCC ports/MSYS2 is convenience, I am not even sure why worry what the 32-bit build script does.  Not saying some reasons couldn't exist, just saying how I see it until I find time into looking at a compromise for this.

Why use the 32 bit version:
Project 64 32 bit only supports 32 bit plugins. Project 64 64 bit version only supports 64 bit plugins. Currently Project 64 64 bit version only supports the interpreter core and has minor GUI issues when applying settings. GUI changes to an older theme that I'm not 100% positive on exactly what, probably aero. The GUI issues don't actually effect the usage of the program however being stuck with interpreter can be a performance decrease on older hardware. I am also not 100% positive if there are any other issues with the 64 bit version of Project 64 however there shouldn't be.

Regarding the -static flag:
I never wanted to force you to do anything. However if nothing else can be done can a comment to the build script for the 32 bit version be added to let users of MSYS2 know to add it to the end? This leaves your original script untouched and lets users decide to use it if they so choose. As a follow up question, why does the 64 bit build made with MSYS2 not have the dll dependency problem, is it automatically statically linking them or is it doing something else? Because 32 bit builds also need a dll for what I believe is the gcc compiler.

Switching to MSYS2 as the default for make_w32.cmd:
Again, don't want to force you to do anything. I am perfectly fine with it being just an option and not a default. I just added that to this issue just to not make two issue reports for similar topics.

Using ld instead of gcc:
For both make_w32.cmd and make_w64.cmd I can provide said error when compiling with MSYS2. Will only include the relevant part of the output as everything else works as expected.

make_w32.cmd
Linking assembled object files...
ld: cannot find -lmsvcrt

make_w64.cmd
Linking assembled object files...
ld: C:\msys64\home\yershi\test\rsp\obj\module.o:module.c:(.text+0x27): undefined reference to `__mingw_vsprintf'

I think this goes over everything in your reply. Sorry if I missed anything.

I have an idea.  Perhaps unconditionally compile with official MinGW if and only if the user chose to install it (normal installation always goes to C:\MinGW\)?  All I have to do is check via Windows shell conditional statements if that directory exists or not.  If it doesn't, it's safe to assume the user either doesn't know about MinGW or just chose not to install it--in which case, MSYS2 will be the fallback search path to try.
So if I implement this, all you have to do is choose not to install MinGW, and MSYS2 will get used?

ld: C:\msys64\home\yershi\test\rsp\obj\module.o:module.c:(.text+0x27): undefined reference to `__mingw_vsprintf'

Yes, correct; that is the reason why I found I was forced to change the line from ld to gcc.  My point is that it is not a compilation issue.  For it to get that far up to that error, all compilation has succeeded, but the linkage of the binary is what has failed because gcc calls the linker ld implicitly while passing all the required library search paths, while making a direct call to ld as I was doing earlier will fail to upload standard search paths unless I explicitly list them all (which I was too lazy to figure out which one was missing, so I changed to gcc as a hot-fix).
Matter of fact, that reminds me I forgot it was actually you who brought that issue to my attention some time ago.
https://github.com/cxd4/rsp/issues/28 (Just for reference.)
I knew I could fix it without changing the ld to gcc but the problem is I have to figure out which CRT/library search path specified by the -L command-line flag is missing in the call to ld, that simply changing to gcc implicitly adds and figures out for you anyway.  I had to settle for the quick fix because I just do not have a Microsoft operating system I can test on anymore.
Having said that, the odds of changing it back to directly call LD.EXE while fixing your old linker failure the hard way (correct way) removing the extra DLL dependencies being generated for pthreads and libgcc are not 100% guaranteed, so it's probably not worth the time and effort to revisit that issue.  I'm merely saying all of this to reflect on decisions I forgot that I made.

Some follow-up stuff that's not quite to the chase here --

As a follow up question, why does the 64 bit build made with MSYS2 not have the dll dependency problem, is it automatically statically linking them or is it doing something else? Because 32 bit builds also need a dll for what I believe is the gcc compiler.

64-bit ISA guarantees multi-threading support, so libpthreads must not be a meaningful dependency on 64-bit builds.  That's the only explanation I can think of but don't know much about the process-threading arena; that is probably why I didn't do a good job of explaining that explicitly enough in my earlier follow-up so you missed that.  For some reason, MinGW does not add dependencies for 32-bit software being able to multi-thread, but MSYS2 links them in "just in case".  I cannot say why; all I can tell you is that the 64-bit kernel unconditionally supports that feature all on its own, in case that is what pthreads on Win32 is supposed to be about.
The second half of your question seems to be talking about the libgcc_s DLL.  That is a dependency I removed years ago by using the -e DllMain flag to direct the entry point to the DLL to a low-level offset (since Project64/N64 emulators are not really looking for a DllMain to call anyway).  This removes a lot of CRT startup code that never gets executed which depended on extra C run-time code from libgcc_s.  However, because MSYS2 is defaulting to multi-threaded coverage with pthreads library, it re-adds that dependency I took out by adding different code I never even conceived of having to remove.  So, that's an entirely separate problem that was born after I stopped having Windows partitions to test on anyway.  Don't know if that fills in any holes for you.

The GUI issues don't actually effect the usage of the program however being stuck with interpreter can be a performance decrease on older hardware.

I think last time I checked they were spreading some myth around Project64 comments that the 64-bit build can't be endorsed due to interpreter-only.  I'm not really sure why people say that or what that has to do with anything.  VR4300/CPU dynamic re-compiler vs. interpreter core is highly non-sequitur in today's LLE environments.  That maybe was an issue on 0.5-GHz CPUs that ran N64 emulators that just HLE'd the entire console.  Nowadays, the RDP is required to be built in 64-bit to have better performance since there is no reason to have an RDP recompiler anyway.  So yes, probably Project64 does not support a recompiler for 64-bit yet, but that's probably because there is no benefit to having a recompiler...what they need to do if they want speed is optimize the RCP.  The RSP should have a 64-bit dynarec probably, yes, but the CPU is trivial.

Project 64 64 bit version has a buggy GUI and no re-compiler support. Now whether or not interpreter is a major performance hit is irrelevant as currently no work is being done on this and won't until Project 64 has accuracy improvements. It won't be until Project 64 version 5.0 that the 64 bit build will have either of these issues fixed.
https://www.pj64-emu.com/support-project64.html
Because of this only 32 bit builds are uploaded by the build bot on Project 64's website. So the most accessible builds of Project 64 will be 32 bit and as such, require 32 bit plugins. You can build 64 bit builds of Project 64 yourself or get them from AppVeyor, but most people will be on the 32 bit build due to these reasons.
Having MinGW be the default and MSYS be the automatic fallback is a good idea. Saves time by having people not need to edit the script in a text editor. Also, when I compiled the 32 bit builds with the original MinGW after you pushed the pull request that closed the original issue I made, I never needed any dlls or external dependencies. I don't remember if using ld post pull request would cause linkage to fail as I never tested it. I assume it would still fail though.
I also found while testing using ld with make_w32.cmd that the lib and inc variables would need to be changed if using the MSYS2 version of MinGW 32 to:
lib=%MinGW%\i686-w64-mingw32\lib
inc=%lib%\..\include

This fixes the following error when using MSYS2 with make_w32.cmd
Linking assembled object files...
ld: cannot find -lmsvcrt

and instead makes the error:
Linking assembled object files...
ld: C:\msys64\home\yershi\test\rsp\obj\module.o:module.c:(.text+0x1d): undefined reference to `__mingw_vsprintf'

Which at least is the same as the make_w64.cmd error.
If you were to make make_w32.cmd choose to use MSYS2 only if MinGW is missing then this makes most of the comments regarding MSYS2's MinGW 32 in make_w64.cmd redundant as make_w32.cmd would now handle this. If you were to use make_w64.cmd and use MSYS2's MinGW 32 it would still technically be "wrong" as make_w64.cmd uses DllMain instead of _DllMain@12 anyways.
So if you do decide to have make_w32.cmd fallback to MSYS2 if it does not detect MinGW installed, I propose the following changes when it does switch to MSYS2:

Change lib=%MinGW%\lib to lib=%MinGW%\i686-w64-mingw32\lib.
Change inc=%MinGW%\include to inc=%lib%\..\include.
Add -static build flag. I know this isn't something you would want to do however considering this would only be used for when falling back to MSYS2 and would not affect the original build script when using the original MinGW I feel this an acceptable compromise until a proper solution is found regarding using MSYS2.

If the proposed changes are made to make_w32.cmd I would also propose the following changes to make_w64.cmd. Basically this removes the unnecessary comments regarding MSYS2 MinGW 32:

Remove:

REM The following two variables are irrelevant, unless you set a 32-bit target.
set mingw32=%mingw64%\..\mingw32
set lib=%mingw32%\i686-w64-mingw32\lib

If you do decide to accept these changes I would also suggest either leaving this issue open or making a new one regarding the errors ld generates so that you don't forget the unwanted dependencies are being generated and can resolve them whenever you can.

You can build 64 bit builds of Project 64 yourself or get them from AppVeyor, but most people will be on the 32 bit build due to these reasons.

Should not have anything to do with the fact that using 64-bit is relevant for the importance of optimizing the RCP, not having a CPU dynarec.  Moreover last time I used 64-bit version of Project64 was years ago and it was in WINE on GNU and there were no problems obtaining it or running it.

If you were to make make_w32.cmd choose to use MSYS2 only if MinGW is missing then this makes most of the comments regarding MSYS2's MinGW 32 in make_w64.cmd redundant as make_w32.cmd would now handle this.

There are no comments regarding MSYS2's MinGW 32-bit in make_w64.cmd so not sure what you mean.
There are a couple demonstrative/legacy variables that illustrate comparing the switch to 32-bit MinGW paths in make_w64.cmd if that is what you mean.  Not so much comments, but making the change you request to fall back on MSYS2 32-bit only if MinGW install cannot be found does not make either of them any more or less redundant before or after that change.

If you were to use make_w64.cmd and use MSYS2's MinGW 32 it would still technically be "wrong" as make_w64.cmd uses DllMain instead of _DllMain@12 anyways.

It uses whether the entry-point-labeling produces for how to refer to DllMain, not what you or I tell it to use.

So if you do decide to have make_w32.cmd fallback to MSYS2 if it does not detect MinGW installed, I propose the following changes when it does switch to MSYS2:

None of these are changes that are relevant to the primary change you are asking that I make.  The script was always designed to be interchangeable to target either the MinGW directory or the MSYS2 directory for choice of how to do the build, so your suggestions to change the parameters MSYS2 build do not require checking if MinGW is not installed first.
So there is no reason to make additional suggestions contingent upon whether I make an unrelated change.  It sounds as if you are trying to imply that making the Windows shell scripts auto-detect (rather than expect manual reconfig by the user) whether to choose MSYS2 over MinGW-32 somehow changes whether the parameters outlined for building by either one are important to consider.  It does not.

I know this isn't something you would want to do however considering this would only be used for when falling back to MSYS2 and would not affect the original build script when using the original MinGW I feel this an acceptable compromise until a proper solution is found regarding using MSYS2.

The acceptable solutions are for you to a) not delete the DLL files needed by the MSYS2 build but rather keep them so the plugin requiring them will work, or b) not use MSYS2 if you prefer not having two more dependencies, or c) use your access to Microsoft Windows (which I do not have) to research how to get MSYS2 to not link in the pthreads dependency, or d) contact MSYS2 to fix the problem with their fork of your favorite compiler, or e) consider using the native GCC compiler by not using Windows or building and running the plugin in a non-Windows emulator on a faster operating system (for which these dependencies do not exist), or f) throw the -static build flag in yourself if you personally find the external DLL files that inconvenient, because I am never forcing everyone to use f) as their solution just because you are willing to accept the spike in file size to the plugin from statically linking does not mean everyone else is.  So do whatever you want in the script as far as the dependency issue on Windows but I am not imposing your preference on everyone else.  The external DLL files are fine as-is for those who would rather use MSYS2's extra dependencies.

If you do decide to accept these changes I would also suggest either leaving this issue open or making a new one regarding the errors ld generates so that you don't forget the unwanted dependencies are being generated and can resolve them whenever you can.

I am sure anyone preferring to use MSYS2 over MinGW and seeing the two required DLL files (from not passing -static if they don't personally want to do so as you do) would not have any problems remembering to investigate it so I doubt that they would need this issue to stay open for them to not forget.  Remember I don't have Windows nor do I have any way of using Windows like you seem to expect me to just to test your favorite compiler so this is not my job to investigate MSYS2; it's yours.  This door was not opened by me.
On a related note, I've run out of time to try to research how Windows shell script syntax works for checking if a directory exists on an operating system I cannot test since I burned up that time by using it to reply to your extra philosophical additions in this ticket (none of which were pertinent to the organized issue of having it auto-detect which compiler to switch to or check if a file path does not exist for such), so I am afraid we're out of time and if you want that changed you'll need to test it on your Windows and submit the pull request for me.  Thanks.


Section popups

PR includes

[x] Refactor
[x] Feature

Related issues
Resolve #802

https://github.com/user-attachments/assets/df90cc81-3680-4fcf-929b-e52496edcc86

https://github.com/user-attachments/assets/d2157d6f-7de9-4ef9-9286-230247fa9833
https://github.com/user-attachments/assets/d88e2f27-7255-4325-96c1-3a37807931ec


Requirements added

closes #3
Affects-

Includes a new file requirements.txt with required dependencies to run this project
Adds Installation Instructions in README.md

@Samyak2 Changes made. Please review!

Thank you for your contributions!


[1.11] Remove cudnn pin to favour global pin

Checklist before submitting

[x] Did you read the contributor guide?
[ ] Did you update any affected documentation?
[ ] Did you write any tests to validate this change?

Description
Copied fix from 1.10 to 1.11:
https://github.com/open-ce/jaxlib-feedstock/pull/11
Review process to land

All tests and other checks must succeed.
At least one maintainer must review and approve.
If any  maintainer requests changes, they must be addressed.

https://github.com/open-ce/open-ce/issues/1175


Could not find enough inliers in imagePoints and worldPoints

Hi! does anybody meet the weird error when doing extrinsic calibration? I struggled with extrinsic calibration.
The same picture and the same intrinsic parameter; however, whenever I label the 4 points of coordination, the error comes randomly. So I did intrinsic calibration again to ensure the intrinsics were normal(error <0.15 pixels).
Sometimes it works well, and the result of doing Lablel3D is ok; sometimes, everything is failed. Appreciate any suggestions.

here is my intrinsic matrix: (all camera are the same type, but not sure why camera3 have different parameters)

Below is the Label3D abnormal result, even though there is no error in the extrinsic calibration.

Hi @yuan0821 About the camera3 being different, does it have a different crop factor than the other cameras? Or is the ROI after cropping too far away from the true center of the camera view? Cropping and translation can change intrinsics.
As for the extrinsic calibration failing randomly, that could be due to a variety of reasons. But, keep in mind that under the hood, the estimateWorldCameraPose uses a MSAC algorithm to determine inliers, which is a stochastic algorithm. So, I would expect the output to vary slightly and maybe with only 4 labels a sufficient overlap may not be feasible. I would suggest trying to increase the number of labelled points.


Spec: Time is not reported accurately

Bug Report
Basically the crystal spec command reports a time that seems unreasonably low. Maybe it's not counting build time and only runtime for the tests. If that's the case, I think only counting runtime is a mistake, since the tests always have to be built anyway.
$ time crystal spec
..........

Finished in 4.76 milliseconds
10 examples, 0 failures, 0 errors, 0 pending

________________________________________________________
Executed in    6.72 secs    fish           external
   usr time    2.99 secs  191.00 micros    2.99 secs
   sys time    0.94 secs  594.00 micros    0.94 secs

$ crystal -v
Crystal 1.11.1 [0aa30372c] (2024-01-11)

LLVM: 15.0.7
Default target: x86_64-apple-macosx

Yeah the reported time is the time it took to run the specs. Without upfront build time. I think this is fine and expected.
A spec program is just a regular Crystal program. And it can build and execute in different ways.
crystal spec is just a convenience feature of the compiler that combines the build and run steps into a single command.
If you want the entire time it takes to run crystal spec, using time as a separte command seems quite reasonable.

If we showed both the build and run time for this command, I think it would be less confusing. I know at work the test suite for our Ruby monolith shows both file load time and spec runtime separately. That's sort of what I have in mind here.
Other than that maybe the message can be improved somewhat. Finished in X... doesn't indicate what is being measured. Maybe Finished running specs in X... would make more sense here.


Are text type fields working?

I'm seeing the list-item in the customizer DOM but no input being generated.  When I change to textarea, code, slider... it works.  I haven't tested all types.  v2.0.3
This only happens when defining 'type' => 'text' but I found if I elect to provide a type (which text is default) the field works.

Using this it seems to be working fine... https://github.com/aristath/kirki/blob/master/demo-theme/functions.php#L116-L125
What code are you using that doesn't render the input?

Thanks for checking.  I just tested using the following but nothing shows up until I comment out:
'type' => 'text',

Must be something with my setup/theme or another plugin as the following code is my test base but I just wanted to be sure it was on my end only.
This is my test page using a require_once line in my themes functions.php
/**
 * Include Kirki toolbox
 */
if ( ! class_exists( 'Kirki' ) ) {
    include_once( dirname( __FILE__ ) . '/includes/kirki/kirki.php' );
}

/**
 * Add config for types
 * use wp_options table, key 'pmitheme'
 */
Kirki::add_config( 'pmi_theme', array(
    'capability'    => 'edit_theme_options',
    'option_type'   => 'option',
    'option_name'   => 'pmitheme',
) );

/**
 * Add panels
 * create "Theme Options" panel
 */
Kirki::add_panel( 'pmi_frontend', array(
    'priority'    => 10,
    'title'       => __( 'Theme Options', 'pmi-opts' ),
    'description' => __( 'Edit theme options', 'pmi-opts' ),
) );

/**
 * Add sections
 * Create "Test Section"
 */
Kirki::add_section( 'pmi_test_section', array(
    'title'          => __( 'Test Section' ),
    'description'    => __( 'Test test', 'pmi-opts' ),
    'panel'          => 'pmi_frontend',
    'priority'       => 160,
    'capability'     => 'edit_theme_options',
    'theme_supports' => '',
) );

/**
 * Add fields
 * add "text" type field to "Test Section"
 */
Kirki::add_field( 'pmi_theme', array(
    'type'        => 'text', //this only works if I remove this line
    'settings'    => 'text_demo',
    'label'       => esc_attr__( 'Text Control', 'pmi-opts' ),
    'help'        => esc_attr__( 'This is a tooltip', 'pmi-opts' ),
    'default'     => esc_attr__( 'This text is entered in the "text" control.', 'pmi-opts' ),
    'section'     => 'pmi_test_section',
    'default'     => '',
    'priority'    => 10,
) );

I just pasted the code above in a blank theme and it seems to be working fine so there must be some kind of conflict...
Do you have the theme available on a github repository perhaps so that I may download it and debug?
Have you tried deactivating all other plugins to see if perhaps there's a conflict there?

Hmm, must be something server side, tested with twentyfifteen theme and no plugins active, no caching.
-When I comment out the 'type' option it works but I get errors in my php log about a missing type parameter.
-When I set it to anything random like 'type' => 'some-type' it works but I get a generic input vs the kirki styled one.
-When I set 'type' => 'kirki-text' it works as I would expect it to with just 'text' defined and no php errors so this is what I'm using now.
I'll shoot you an email with the creds.  This really isn't a big deal for me I just wanted to help if it was something others may run into.

@pingram3541 are you still having an issue with this if you use the latest develop branch? (not master)

@aristath works perfectly thank you.

Great! Closing this one. :+1:


Hour overflow in tz-aware datetime conversions

Comparison of tz-aware timestamps fails across DST boundaries. The comment in tslib.pyx:3845
# TODO: this assumed sortedness :/

perhaps implies this is a known problem that was never resolved, so apologies if a new issue is not appropriate.
 What exactly is the issue?

Sorry for being unclear, the output is wrong - these timestamps are not an hour apart.

maybe the example is not clear. Can you show something and have an expected which is obvious.

The expected output is the correct timedelta - updated to reflect that.

In [36]: df = DataFrame(
{'A' : pd.to_datetime(['2008-05-12 13:50:33',
                       '2008-12-12 14:50:35',
                       '2008-05-12 13:50:32']).tz_localize('US/Eastern'),
'B' : Timestamp('2008-05-12 13:50:33',tz='US/Eastern')}
)

In [37]: df
Out[37]:
                          A                         B
0 2008-05-12 13:50:33-04:00 2008-05-12 13:50:33-04:00
1 2008-12-12 14:50:35-05:00 2008-05-12 13:50:33-04:00
2 2008-05-12 13:50:32-04:00 2008-05-12 13:50:33-04:00

In [39]: df.dtypes
Out[39]:
A    datetime64[ns, US/Eastern]
B    datetime64[ns, US/Eastern]
dtype: object

In [40]: df.B-df.A
Out[40]:
0       0 days 00:00:00
1   -215 days +22:59:58
2       0 days 01:00:01
Name: B, dtype: timedelta64[ns]

So we are not converting to UTC somewhere. Should be a straightforward fix. want to do a pull-request?
In [41]: df2 = df.astype('M8[ns]')

In [42]: df2
Out[42]:
                    A                   B
0 2008-05-12 17:50:33 2008-05-12 17:50:33
1 2008-12-12 19:50:35 2008-05-12 17:50:33
2 2008-05-12 17:50:32 2008-05-12 17:50:33

In [43]: df2.B-df2.A
Out[43]:
0       0 days 00:00:00
1   -215 days +21:59:58
2       0 days 00:00:01
dtype: timedelta64[ns]

Please look at the second half of my comment. The (perhaps known?) bug is in tz_convert() itself, whose implementation assumes the array is sorted.

@dlpd you are reaching into the implementation. So not really sure what you are doing. You would have to demonstrate a bug using the public API which you did for the case above but not for anything else.

@jreback Thanks for the comments. You wrote:

So we are not converting to UTC somewhere

My point is that the bug is in the tz-conversion itself, not lack thereof.
If pandas.tslib.tz_convert() is not considered public, I'm happy to reproduce with DatetimeIndex.tz_convert() which I assume is. If you trace the execution of the timedelta computation, you will see that these two examples are actually the same.

well if you'd like to submit a pull request would be great


ALLRAP and AllRAD HOA Renders?

Was wondering if we should/could add the Graz Ambisonics rendering techniques sometime:
ALL-ROUND AMBISONIC PANNING: ALLRAP
All-Round Ambisonic Decoding: AllRAD
from
[Zot12a] Zotter, F.; Frank, M. (2012): “All-round ambisonic panning and de-
coding.” In: J. Audio Eng. Soc., 60(10):807–820.
It seems that cinema and e-music people like this stuff more than other HOA.
Implementation holds also for the SSR...

Would be very nice to have some "normal" Ambisonics as well as at the moment nobody cares about NFC-HOA. Have you some experience with using/testing/implementing it?

Hi Hagen, Frank
for an AllRAD implementation, you might want to check out  github.com/polarch/Higher-Order-Ambisonics

Hi Nils,
thanks for the hint, I'll check this out.
On 14.06.2016 17:59, Nils Peters wrote:

Hi Hagen, Frank
for an AllRAD implementation, you might want to check out  github.com/polarch/Higher-Order-Ambisonics

You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
https://github.com/sfstoolbox/sfs/issues/91#issuecomment-225928934

github.com/polarch/Higher-Order-Ambisonics

It seems that cinema and e-music people like this stuff more than other HOA.

It's a secret weapon for seasoned immersive audio producers and perfect for soundscapes. A spherical projection of sound coming towards the listener with the ability to render to various channel configurations (orthodox with AIRAD or unorthodox with AIRAP), so it's also transferable to other formats down the pipeline, like channel-based surround and binaural stereo. It's also a hit with audio/radio dramas and immersive podcasts.


Remove grain_rate from media_profile_audio.json

Could we sneak in an audio example?

Please link #22 which should close with this PR :)