Fix in msvcrt!mbstowcs_s to avoid to write null pReturnValue

Quick fix to the API to avoid the write if destination of converted pointer is null

is this an issue with the API handler or with emulated code that passes an invalid pointer to the API?

The handler. From MS docs at https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/mbstowcs-s-mbstowcs-s-l?view=msvc-170
If mbstowcs_s successfully converts the source string, it puts the size in wide characters of the
converted string, including the null terminator, into *pReturnValue (provided pReturnValue is not NULL)

So the NULL pointer seems to be valid.

ah, thanks!


Added propagation control functions.

I've added the ability to explicitly control propagation of data in DataFlowGraphModel through the use of a new virtual function canPropagate(ConnectionId), and another function propagate(NodeId) to request a propagation without having to update connections or input/output.
These functions are both virtual so that derivative dataflow models can specify their own control model, but this may go against the design of DataFlowGraphModel. Feel free to deny or change as you wish. As an example:
My project has nodes of text data ranging in the gigabytes. I use a global execution state to control when data is propagated along with a forking mechanism to copy the text data each time a node has multiple outputs, rather than copying the data on every node. All of this can be achieved with custom canPropagate and propagate functions:

PipedGraphModel::
PipedGraphModel(std::shared_ptr<NodeDelegateModelRegistry> registry) :
    DataFlowGraphModel(registry)
{
    executing = false;
}

PipedGraphModel::~PipedGraphModel(void)
{}

bool
PipedGraphModel::canPropagate(const ConnectionId conn)
{
    if (executing)
        return true;
    // data should only be passed on if the graph is being executed
    // or if the node is capable of performing the calculation in
    // such a negligible amount of time that it may as well calculate
    // immediately (think math or array nodes)
    Node *delegate = this->delegateModel<Node>(conn.inNodeId);
    return delegate->canInstantCompute();
}

void
PipedGraphModel::stopExecute(void)
{
    executing = false;
}

void
PipedGraphModel::execute(void)
{
    executing = true;
    for (NodeId id : this->allNodeIds())
    {
        // check each node for any inputs, and if it contains none, then
        // it must be an input node, from which we can propagate the rest of the
        // graph
        Node *delegate = this->delegateModel<Node>(id);
        if (delegate->numInputs() == 0 && delegate->numOutputs() > 0)
            this->propagate(id);
    }
    executing = false;
}

void
PipedGraphModel::propagate(const NodeId nodeId)
{
    unsigned int nPorts = nodeData(nodeId, NodeRole::OutPortCount).toUInt();
    for (PortIndex idx = 0; idx < nPorts; ++idx) {
        //onOutPortDataUpdated(nodeId, idx);
        std::unordered_set<ConnectionId> const &connected = connections(nodeId,
                                                                        PortType::Out,
                                                                        portIndex);

        QVariant const portDataToPropagate = portData(nodeId, PortType::Out, portIndex, PortRole::Data);

        unsigned int connum = 0;
        for (auto const &cn : connected) {
            if (canPropagate(cn)) {
                if (connum > 0)
                    portDataToPropagate = qvariant_cast<BaseNodeData>(portDataToPropagate).clone(); // fork additional connections
                setPortData(cn.inNodeId, PortType::In, cn.inPortIndex, portDataToPropagate, PortRole::Data);
                connum++;
            }
        }
    }
}

I've added another commit which surrounds strings that are present in headers with QLatin1String(...) because the library refuses to compile into my project if QT_NO_CAST_FROM_ASCII is defined. In a sense it optimises the code because strings are no longer being implicitly converted to QString at runtime, but I have not done the same for any of the source files.
Just thought it would be useful to add here rather than open another PR...


"Neighbors" doesn't work for CLLLocationCoordinate2D

When I use Geodesy as shown below:
<
let CurrentGeoHash = self.currentLocation.geohash(precision: 4)
let CurrentNeighbors = self.currentLocation.neighbors(precision: 4)
print("Geohash: ", CurrentGeoHash, " Geohash Neighbors: ", CurrentNeighbors)

I get "Value of type CLLLocationCoordinate2D has no member 'neighbors.'

I did update the extension locally and added the 'neighbors' functions to the CLLLocationCoordinate2D extension.
It successfully builds, but the returned neighbor array appears to be incorrect (see issue #12)


[philosophical] is the 'Employee.connection.should have_executed(:insert)' testing pattern a good idea?

This is really not a specific issue with your project, but I wanted to add a few thoughts:
I think that your idea for using a null object pattern to stub the DB layer is good. I agree that unit tests should have clearly isolate their concerns, and that interacting with external services (like a DB) is good example of introducing external dependencies that add lag and 'integration' type behavior to your alleged unit tests. Of course, I still believe that integration tests are mandatory when your unit tests are properly isolated, but I digress.
You say that:
'unit tests should be exercising only the business logic contained in your models, not ActiveRecord'.
But you provide the following example of how to test the SQL queries executed by ActiveRecord on your null adapter:
'Employee.connection.should have_executed(:insert)'
IMHO, this is actually worse then testing a round trip to the DB. Testing the SQL generated by ActiveRecord is a spec that, I believe, belongs in the ActiveRecord library itself. And furthermore, looking for the keyword 'insert' really doesn't tell us much about the query we're executing (to what table is it inserting?, what values?, etc).
Personally, I would use your adapter to stub the interaction with the DB, but not to test SQL statements at the adapter level. I'd still test interactions with ActiveRecord via RSpec::Mock(s) and Stub(s). I think that your project presents an excellent way to achieve this. Even if I was trying to do a 'persistence layer' test, I couldn't pull an object back out of the DB since the creation of that object is stubbed by your adapter.
Do you think it's better to test the SQL then to do a round trip test on your object? I feel that the following statement has less dependencies on ActiveRecord then testing the SQL at the adapter layer:
it "creates a user" do
Foo.some_method_that_creates_a_user('username')
User.find_by_username('username').should be_present
end
This way, it really doesn't matter what SQL was executed as long as the user was created (yeah, I have a dependency on ActiveRecord in my testcase but I think you get the idea). I believe that it is more maintainable and easier to read then asserting SQL. You can argue that this is more of an integration level test, and that it would add lag to your alleged 'unit' tests but at least it still doesn't care about 'how' the record was created. I realize that the purpose of your project is to get people away from that type of testing, so I think I already know how you would respond to this ;).
Anyway, I really enjoy talking about this stuff so I'm just interested in hearing your opinion. I'm really just trying to be pragmatic here.. not trying to defend 'religion' of any sort. Thanks for reading this.
-- Will

I can't remember the last time I used that feature. If ever. IIRC it was either an afterthought or something to test a very specific and obscure case.
I could see using it to test e.g. a caching layer, in which you want to make assertions that a certain action does NOT cause the DB to be hit. Using it to test business logic would be a pretty big smell.
It sounds like you understand that the main point of NullDB is to take the DB out of the picture while testing business logic. The adapter layer expectations are incidental to that.

Thanks for entertaining my question. It sounds like we're on the same page.


1.16.4 Compatibility (Very easy fix)

Hi there o/ Current BlockCarpentry cannot be installed via the CurseForge launcher in 1.16.4 instances. If you check the box for 1.16.4 in the file settings, it will be installable.

Thanks for the hint, I changed the file settings. Sadly, I can't verify right now if it really works for 1.16.4 due to much stress at my university, but I'll dedicate myself to that as soon as possible.
Regards, Manu

No worries and no need, it works on 1.16.4, we've been using it for weeks :)
Hope Uni goes well!

Thank you very much!


Jodd versioning

Is there currently a particular system behind Jodd's versioning?
Judging from the three-level versions one could assume it follow semantic versioning, but that doesnt seem to be the case.
This issue is not to suggest semantic versioning (it has become quite popular in recent years, but software did great before it too) but I'd just like to start a discussion whether Jodd should have a versioning concept (assuming there isnt one yet). If so, I guess the next step would be to decide on one (-> Jodd XP? ;-) )
Semver might be certainly an option, but considering that Jodd's codebase is quite dynamic (to avoid saying "agile" :) ) its major version would get bumped quite often and we'd be now probably at Jodd 23.x

Hello,
If I can add my 2 cents to this.
As a user of JODD (log, lagarto and core) within JMeter , I am very happy but really frustrated of lack of visibility on release contents unless I missed something.

http://jodd.org/release.html does not show anything unless I missed something.
There is no milestone in Github, except 3.8.5 ? why 3.8.5 and not 3.8.2 or 3.9 ?

This is a bit annoying as you don't know anything about backward compatibility and why you should upgrade .
It should be your marketing page to show all the great new features no ?
Am I missing something ?
Thanks

Agreed, the changelog stopped with 3.6.7 and it being missing is an issue. Though a different one than versioning :)

@neroux @pmouawad you are both very right - and I apology for this mess :( To be honest, last few releases were made faster then usual, so to push the changes for different users who needed them and lack of time was the only reason why we haven't release it properly. So far the versioning was done without any strong rule; it was loose semver I would say.
I am perfectly fine to make the next release 3.9 or 4.0 and start doing it properly :)))
The only issue I see is the modules. So far I keep version unique across all the libraries. This really make things easier for dependency management. I guess that this situation would break semver contract:

module A is not changed, version 1.1
module B significantly changed, requiring version 2.0

So what to do in this case?  Should we:

update module A to 2.0 because of B, although it does not depend on it; and there are no changes
update just modules B version to 2.0

I would go with the first as managing versions for 15 modules may be... well, though :)

I would tend to the second option. Versions could become meaningless if there is a mass bump just because one module had major rework. What would be your concern in regard to managing the version numbers? It would require individual version upgrades if they are justified for a module, but thats the point of it, isnt it?

Hi,
How do other similar proceed?
As a user, the first option is easier for me.
But I agree with @neroux opinion.
Regards

But second option means clear release notes and how will your proceed for issues on github ? one milestone id per lib?

I am ok with the steady major version increments; Jodd was always like that.
However, to be completely honest: I am bit afraid to go with separate versions at the moment...  I am aware this is the proper way to do it, but this might give more work on the infrastructure that I simply might not be able to support. In fact, if we go this way, the proper way would be to split Jodd repo into multiple repos, and work on each completely individually - right?
So how about this: to put this to backlog for version 3.x. I would really like to upgrade documentation and to work more on examples instead, many things there are pending. Then for version 4 (that can be later this year) we can really split Jodd into multiple, separate repos, and progress with each one individually.
Sounds good?

I mentioned the major version because I has stayed on 3.x now for the past eight years (pre-3 is not even mentioned) and if semantic versioning was to be properly implemented we'd jumped up a couple of versions only in the past few weeks (the refactoring of the email classes for example) and Jodd could quickly reach. That would be simply my concern about Semver.
I quickly checked and couldnt find specific version information for the individual modules.

That us exactly my concern for semver on global level. Thats why I guess we should split into more repos.

So you suggest to version only the individual module in that scenario, but not the full package (like now, Jodd 3.x) anymore, right?
That would be a solution, it would probably not even require separate repositories.

yes @neroux

If we add proper semver, then versions of the modules would be separate. True, this can be done without repository split.
The 'global' version of Jodd as it is now is gone and replaced with e.g. 1702 (based on date) Note that we still need to build a bundle version, as ppl are still using it :)

Sounds like a fair approach :+1:

my 2 cents:
I see jodd as "one library" that is all modules should have the same version.
case "modules have separate versions":
Does every module have its own release procedure?
After release of module x , does a new global jodd version will be released, too?
If not, i have to exclude module x in pom.xml and add explicit dependency for module x? correct?

@moh-sushi yes, that is always been my concern, so to answer the questions:

every module would have its own release procedure and versioning.
After single release of module X, Jodd global version would not change, until certain amount of changes get collected - the same it is now.
There is always going to be a latest bundle pom, with versioning going up crazy (probably using date stamp).

I guess at the end you will have the same behavior as before, except you can track modules individually if you wish.
In other words, you would have two versioning:

each modules has its own versioning
bundle == Jodd version == date stamp

Something like that... but again, have to think it through one more time :)

btw, hope you like the changelog

I love it :-) Thanks !

Hi @igr ,
I wonder if you know about this :
http://www.yegor256.com/2014/08/19/how-to-release-to-maven-central.html
I once read you were annoyed by release process and artifacts publication.
Once implemented on your project, release will be a matter of one chat with a bot :
"@rultor release, tag is X.X.X" :-)

@pmouawad How would that fix the versioning of the different modules and Jodd as a whole?

It would not, it was just a note related to release process. Maybe not the correct issue for that comment.

Hello, everyone!
I've decided to postpone this decision. Simply put, don't have enough capacity to proceed with this now.
Please note that I'm not saying that you are not right - you are, and I also don't like bumping version on the code that is not changed - but at the moment, it is incredibly easy to maintain just one number.
The question about versioning goes bit further. As you know, Jodd contains a bunch of frameworks and when talking about versioning I can't stop wondering if it makes sense to have it all. Maybe it's time just to split into 3-4 libraries. Maybe not. Anyway, that is a different story.
I know this doesn't sound too cool, but just to save my sanity, I will keep versioning as it was before. Meanwhile, I will put the effort in properly managing the project on GitHub, writing release notes and to upgrade the documentation (much needed). This is a temporal decision and I hope things will change in the future and we will find a way to organize things better.
I hope you understand.


fix: Project build (PR included)

🐛 The bug
The project does not build properly due to merging https://github.com/danielroe/vue-sanity/pull/220
Fix: https://github.com/danielroe/vue-sanity/pull/222

Fixed by https://github.com/danielroe/vue-sanity/pull/224


Joystick: Skipping Update Buttons if no buttons are registered.

Also changed the if condition from != to <

related #967


Feature Request: Merge two encrypted backups

Before having encrypted backups Signal did not allow proper transition from an old phone to a new one, it only allowed the text export and import and media were lost.
So I kept the old phone until Signal introduced the encrypted backups. In the meantime I have used Signal on the new phone. Now that Signal has proper backups, I made an encrypted backup from my old phone. Now I would like to merge my old backup with the backup of my new phone.
I guess this request is related to #44.
Would be great if you could manage to do that, I would consider a donation.

I'm in exactly the same situation and would also donate. Is there a BountySource page somewhere?

I also am in need of this function.

I don't want to hijack this thread or the users of this program, so please forgive me and delete this message at will.
For those interested I have implemented this feature in my tools: https://github.com/bepaald/signalbackup-tools. It is highly experimental and as of yet untested, so expect errors. Instructions are here: https://github.com/bepaald/signalbackup-tools/issues/4#issuecomment-531755387. Feel free to open an issue asking for help on my github if something is not clear or not working.
note
I was holding of posting the above message since the code is (as far as I know) currently untested in the wild, and several people were planning to try it out. However, after looking at the code changes in Signal 4.48 (currently in beta), my merging code will definitely not work after updating to its new database scheme. So if this is important to any of you, and you are brave enough, give it a try before the update comes out and you install it!
(I do plan on adding support for the new database format, but it might take a long time. Also, merging old databases into new ones seems, at first glance of the new format, very difficult, so that would take even longer)


Dependency upgrades: yarn upgrade should happen first

What package(s) are you using?

[X] Carbon for IBM Products (or Carbon for IBM Cloud & Cognitive)
[ ] Legacy/CDAI
[ ] Legacy/Security

Detailed description

Describe in detail the issue you're having.

After the latest dependency upgrade action failed, it appears that the yarn upgrade (yarn upgrade:dependencies:yarn) should occur first otherwise GitHub Actions seems to pull in the yarn version specified in .yarn/releases which ends up being different if there is an upgrade available for yarn. This mismatch in versions will cause build issues as seen here.

What did you expect to happen? What happened instead? What would you like to
see changed?

Dependency upgrade should not crash with yarn upgrades.

^ I had a PR for this but it started failing yesterday even after changes to stopped so I can investigate again. (Could be cache??)


Perfect Vision hides scene padding boundaries

As shown -
Without Perfect Vision

With Perfect Vision

I would like to be able to see the boundaries of the map as a DM, particularly when building maps out of tiles instead of static background images. Seems like it happens regardless of settings or the GM Vision option being toggled on or off.

Thanks for the report. Fixed in 3.5.7.


Update ListApps.php to fix a syntax error (#15)

Fix a syntax error
close #15

@shuanzia Thank you for your contribution and fix. Could you please sign the CLA?


disp_arr.npy?

Hi,
Where does disp_arr.npy come from in your notebook? Are you using StereoBM or SGBM?

@tomasz-lewicki
I'd like to second this open issue. This file just seems to be completely missing.
disp_arr = np.load("../disp_arr.npy")
This line in 07_calculate_depth.ipynb throws a FileNotFoundError because there is no disp_arr.npy file.


RestClient is not responding at all

When i clicked the send button, restclient is not responding for all methods.  I have tried to install the plugin again and again.  Can you please let me know what was the issue?  I am using ubuntu 13.10 operating system.

Just now i got the solution.  Now Rest client is working.  Please follow the below steps
Hello, I recently experienced this issue. very frustrating. I dug enough and found a fix.
-In the the Firefox address bar, type in "about:config", then search on the text "RestClient".

-For each RESTClient result returned, right click and press "reset".
-Restart Firefox
This action should remove any cached data for the client and the button should start working again.


Document how to reference a label in GitHub-flavored Markdown

Code of Conduct

[X] I have read and agree to the GitHub Docs project's Code of Conduct

What article on docs.github.com is affected?
https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax
What part(s) of the article would you like to see updated?
#referencing-issues-and-pull-requests
I propose adding a new section here, "Referencing Labels". This feature is not directly supported by Github, but it is possible in a standard manner with a feature provided by shields.io. For example:  is created with image link:
![label: Content](https://img.shields.io/github/labels/github/docs/content)
Documentation: https://shields.io/category/issue-tracking -  See and click topic 'GitHub labels'.
Because this is dynamically generated, the color of the image is always accurate at the time of rendering/viewing, not just at the time of text entry. The alt text covers for missing images or communications issues.
As this is a useful and requested feature, I think it would be helpful to add the suggestion to the doc, even if the feature is not built-in to Github itself. If the shields.io service goes away, Github will have much greater issues than this one feature, and the doc can be modified as required.
TY
Additional information
On approval, I'll submit a PR for the new content.
Someone may suggest adding notes about shields for milestones and other features supported by shields.io. I suggest we process this one request first and consider other such requests on their own merits.

I don't think this is allowed because shields.io is a third-party service.

I don't think this is allowed because shields.io is a third-party service.

Thanks for the challenge...

There's no reason not to reference another site. Other sites are mentioned in these docs for similar purposes.
In particular, shields.io site is not competitive with Github or Microsoft.
There is no endorsement or implication of affiliation with a reference to that site.
That site is non-commercial, publicly supported, and entirely based on the badges/shields FOSS hosted here at Github.
It's not a volatile link. There are 5.7 million instances in Github public repo code where shields.io is already used for dynamic and static badges. The suggestion here is simply to document the established standard for what people already do, and change it later in the almost certain never to happen scenario where the site changes.
This doc page documents how to add a dynamic badge for workflow, using data from this site as the source. Because this site doesn't document how to use other dynamic data that is readily available, people in the FOSS community filled the gap. That saved Github/Microsoft some effort and should be rewarded with a reciprocal gesture of recognition. Let's document how to get the data from github.com directly, if it's possible, or, let's document where we know people can use this existing functionality. It's just data.

Ref functionality supported by the Github API, implemented in the badge/shields project FOSS (source for shields.io).
See also the badges/shields PR for this.
Ping @pfaion @calebcartwright

@TonyGravagno let me be clear, the issue is describing it enough that it seems to be official. I was thinking something that would be acceptable could be a sentence that just reads "Third-party services like shields.io allow dynamically creating images of repository labels."

I agree that would be ideal and I will ensure it's presented like this if the enhancement is approved. Thanks.

👋 Thanks so much for opening an issue and clearly explaining your reasoning @TonyGravagno! Since this isn't a GitHub feature and is a totally optional thing that users can choose to add if they're interested, we're not going to add it to the docs 💛
Thank you for your interest and passion in improving the GitHub docs! ✨

It seems like GitHub must have a native way to do this because I'm seeing it in this PR: https://github.com/nodejs/node/pull/43310

I'm not seeing this feature documented however so perhaps its beta? 🤔

It seems like GitHub must have a native way to do this because I'm seeing it in this PR: nodejs/node#43310

I'm not seeing this feature documented however so perhaps its beta? 🤔

Oh it's simple, just put in a normal link to the label. For example:
https://github.com/github/docs/labels/content

-> https://github.com/github/docs/labels/content

Cool! I don't see that documented though.
Perhaps it should be added to Autolinked References and URLs

Maybe open a different issue for that?

is my job application to glassdoor successful?
On Fri, 10 Jun 2022, 20:52 Tony Gravagno, @.***> wrote:

Code of Conduct

I have read and agree to the GitHub Docs project's Code of Conduct
https://github.com/github/docs/blob/main/CODE_OF_CONDUCT.md

What article on docs.github.com is affected?
https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax
What part(s) of the article would you like to see updated?
#referencing-issues-and-pull-requests
https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax#referencing-issues-and-pull-requests
I propose adding a new section here, "Referencing Labels". This feature is
not directly supported by Github, but it is possible in a standard manner
with a feature provided by shields.io. For example: [image: label:
github/docs/labels/content]
https://camo.githubusercontent.com/88ffd2affeb1676fb3f37ddf2e141ad01eaa1cb31f16ab7acf168fcb6c10f642/68747470733a2f2f696d672e736869656c64732e696f2f6769746875622f6c6162656c732f6769746875622f646f63732f636f6e74656e74
is created with image link:

Documentation: https://shields.io/category/issue-tracking - See and click
topic 'GitHub labels'.
Because this is dynamically generated, the color of the image is always
accurate at the time of rendering/viewing, not just at the time of text
entry. The alt text covers for missing images or communications issues.
As this is a useful and requested
https://github.com/isaacs/github/issues/305 feature, I think it would
be helpful to add the suggestion to the doc, even if the feature is not
built-in to Github itself. If the shields.io service goes away, Github
will have much greater issues than this one feature, and the doc can be
modified as required.
TY
Additional information
On approval, I'll submit a PR for the new content.
Someone may suggest adding notes about shields for milestones and other
features supported by shields.io. I suggest we process this one request
first and consider other such requests on their own merits.
—
Reply to this email directly, view it on GitHub
https://github.com/github/docs/issues/18537, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AV73JDUVKJGMCHRJUZYWLR3VOOFH3ANCNFSM5YOROTBA
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

I created #18704


mage Deploy should update our kubeconfig

Describe the bug
When we run mage Deploy it should configure the kube config so we can run kubectl commands without having to mess with the configs. :)
To Reproduce
Steps to reproduce the behavior:

Run mage Deploy
kubectl get pods
:(

Expected behavior
When mage deploy finishes successfully, we should be able to interact with our cluster via kubectl.
Operator execution and Output
kubectl get pods
E0816 21:43:33.333941   23626 memcache.go:265] couldn't get current server API group list: Get "http://localhost:8080/api?timeout=32s": dial tcp [::1]:8080: connect: connection refused

If I go grab the kubeconfig from kind, and then put it in the expected area (~/.kube/config) everything works

https://github.com/getporter/magefiles/pull/30 PR should do it but I'm trying to do some magic to import it (maybe go.work) to settle the test case for this issue.


Deleting a non existing Identity Provider returns 204 as the status code

Describe the issue:
When try to delete a non existing identity provider with REST API https://localhost:9443/t/carbon.super/api/server/v1/identity-providers/identity-providers/{invalid-identity-provider-id} does not gives expected 404 as response. Instead it gives 204.

How to reproduce:
Send a DELETE request to  https://localhost:9443/t/carbon.super/api/server/v1/identity-providers/identity-providers/{invalid-identity-provider-id}. Here replace invalid-identity-provider-id with a invalid identity provider id.
Expected behavior:
Delete a  non existing identity provider gives 404 as the status code.
Environment information (Please complete the following information; remove  any unnecessary fields) :

Product Version: IS 6.0.0-m1
OS: MacOS 12.4
JDK: Oracle JDK 11.0.15

Hi @AnjanaSamindraPerera,
The APIs in IS are designed as below,

First DELETE: resource is deleted -> 204
Subsequent DELETEs: resource is already deleted or does not exist -> 204.
Rationale: DELETE should be idempotent. If you return 404 on a second DELETE, your response is changing from a success code to an error code. The client program may take incorrect actions based on the assumption the DELETE failed.

Therefore we can consider this as the expected behavior.


feat: save stability artifacts to DIAL file storage

Fixes #29

/deploy-review

/deploy-review

/deploy-review

/deploy-review


Renamed WorlData to GlobalData

closes #6

Thanks for your contribution :)

No Problem! Keep up the good work!

@all-contributors please add @puf17640 for code, tests and doc

@all-contributors please add @puf17640 for code, test and doc

@all-contributors please add @puf17640 for code, test and doc

@all-contributors please add @puf17640 for code, test and doc


[Feature Request]: microsoft/graphrag support？

Feature Description
https://github.com/microsoft/graphrag
Do you support Microsoft's GraphRAG, a recently open-sourced project?
Reason
No response
Value of Feature
No response

looking forward to


maximumNumberOfLogFiles&logFilesDiskQuota of DDLogFileManagerDefault is not KVO

maximumNumberOfLogFiles&logFilesDiskQuota of DDLogFileManagerDefault is not KVO, I find they are disabled intentionally. Is it means we should do the KVO in our customized subclass as the default one is not exposed as an api?(In such case, no KVO code is needed as it's of no use) And I think KVO is not clearer than setter.

@wizzardchao could you create a PR with this fix?

The KVO notifications on those 2 properties were explicitly disabled by #463 to fix a crash in the tests.


New version: RichardsonSoftware.RazorSQL version 9.4.10

[X] Have you signed the Contributor License Agreement?
[X] Have you checked that there aren't other open pull requests for the same manifest update/change?

[x] Does your manifest conform to the 1.0 schema?

Microsoft Reviewers: Open in CodeFlow

/azp run


"Holidays" is too specific a name for events in time.

There are only two hard things in Computer Science: cache invalidation and naming things.

-- Phil Karlton
I made a package for creating regressors for forecasting using the forecasting package in R.
https://github.com/republicwireless-open/foregen
I use the word "events" instead of "holidays" so I am not prescriptive with how they are perceived.

@wjhrdy This is a good point.  It was definitely a result of our internal use-cases.  I'll add this name change to the 0.2 release milestone and we'll work on making it backward compatible by accepting both.
Nice job on your package!  If I had known about it we would have used it!

@seanjtaylor I'd favor leaving this as holidays in the code, and just updating the documentation to describe that this component is for 'holidays and other recurring events', or something along those lines. I certainly agree that events would have been a more appropriate choice, but maintaining support for both just seems like a pain. I'm guessing the typical usage for this feature is actual holidays, and people with non-holiday events would be able to tell from the documentation that this is the right interface. We also now have the add_regressor method which provides a more general interface, with a more general name.

I think with the add_regressor method there is now the more generally-termed interface for handling these types of things, and since it would be a pretty big disruption to remove/rename the holidays argument, I'm going to go ahead and not make this change unless anyone has any further objections.


explore: tab component

Implement the Tab component for Explore. I added placeholders for the other components of the Explore block. The component is at the bottom of the location page.

Mocks

Desktop

Mobile

 explore: implement tab component


[CPDEV-100676]_kubernetes.pods_for_pods_in_CrashLoopBackOff

Description
The change involves modifying the command used to retrieve non-running pods in a Kubernetes cluster. Instead of using kubectl get pods -A --field-selector status.phase!=Running, which fetches all pods except those in the "Running" state, the revised command kubectl get pods -A | grep -v Running is proposed. This new command fetches all pods and then filters out those that are in the "Running" state.
Fixes # [CPDEV-100676]
Solution
Adjusting the Command:
Replace kubectl get pods -A --field-selector status.phase!=Running with kubectl get pods -A | grep -v Running in the shell command.
This change ensures that all pods are retrieved first, regardless of their status, and then filters out only the pods that are in the "Running" state using grep -v Running.
Test Cases
TestCase 1
Steps:

Run kubemarine check_paas --tasks kubernetes.pods on a cluster where some of the pods are in CrashLoopBackOff state in system_namespaces

Results:

Before
After

Fails to show pods which are in CrashLoopBackOff
Considers pods which are in CrashLoopBackOff  aswell

Checklist

[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] Integration CI passed
[ ] Unit tests. If Yes list of new/changed tests with brief description
[ ] There is no merge conflicts

Unit tests
Indicate new or changed unit tests and what they do, if any.

@vlar0816


Should :Neotree source=example work?

I'm trying to implement my own custom source and thought I could base it off of the sources/example source.  However, :Neotree source=example gives me the error below.  I'm literally just getting started with this codebase today so it's likely I'm doing something wrong.  Should I not try to use the example source?
E5108: Error executing lua ...ker/start/neo-tree.nvim/lua/neo-tree/sources/manager.lua:39: attempt to index local 'state' (a nil value)
stack traceback:
	...ker/start/neo-tree.nvim/lua/neo-tree/sources/manager.lua:39: in function 'create_state'
	...ker/start/neo-tree.nvim/lua/neo-tree/sources/manager.lua:111: in function 'get_state'
	...packer/start/neo-tree.nvim/lua/neo-tree/command/init.lua:79: in function 'execute'
	...packer/start/neo-tree.nvim/lua/neo-tree/command/init.lua:140: in function '_command'
	[string ":lua"]:1: in main chunk

Edit to add some further context: I did add "example" to the source list in setup/init.lua and a dummy config for example in defaults.lua

It doesn't work, sorry about that! Looks like I haven't maintained it through some breaking changes. I'll update it.
You may want to start with the buffers source as the example. It's pretty simple and it actually works.
One other thing you'll need to do when creating a new source is to add it to this table:
https://github.com/nvim-neo-tree/neo-tree.nvim/blob/8613c458cd04ddd14135060179bc2bca01e2d2f9/lua/neo-tree/setup/init.lua#L14
BTW - What source are you going to add?

Actually, it's still a relevant question. I'm planning on creating:

bookmarks source (likely piggybacking on ezbookmarks.nvim)
a "workspace" source, I put that in quotes because it's actually something specific to internal VCS tooling we use at my job

I did manage to get something working for the "workspace" source (no actions yet though) by copying the filesystem source.
I'm still trying to grok all the parts of the codebase though (e.g. rendering), so I'm sure I'd benefit from a fix to the example source or any other documentation on how to add a source.

I'm still trying to grok all the parts of the codebase though (e.g. rendering),

The good news is that you do not really need to grok rendering to add a new source. Treat it as a black box that just works. Everything you need to add is within the sources folder. If you want to customize the display of something, add a new component.

The example source was fixed in 4e6592670dcac51cc2d0ea97e9e33792ac5b132d, which is in main right now.
When you have questions about how to do things, head on over to the Discussion section and start a conversation in the Internal Development category.


Couldn't scan the drives: An unknown error occurred (With a twist)

Etcher version:
1.1.2

Operating system and architecture:
Win7 Ultimate 64 Bit

Image flashed:
N/A

Do you see any meaningful error information in the DevTools?

{"stack":"Error: Couldn't scan the drives: An unknown error occurred","message":"Couldn't scan the drives: An unknown error occurred"}

So, turns out Etcher spits the dummy if there is a bitlocker volume not yet decrypted.
Confirmed by having the volume decrypted, then proceeding to lock the volume again. the instant I do I get the error again.
Etcher needs to gracefully handle bitlocker volumes.
Was pulling my hair out trying to figure it out.

Hey, this should've been fixed in #1692 and will ship in the next release

Duplicate of #1687


[Autocomplete] options are displayed even if loading is true

[x] The issue is present in the latest release.
[x] I have searched the issues of this repository and believe that this is not a duplicate.

Current Behavior 😯
When you have options available and you set loading to true, the options and the 'Loading..." message are visible at the same time.
Expected Behavior 🤔
I think the options can be hidden while loading is set to true.
Steps to Reproduce 🕹
Steps:

codesandbox.io reproduction
Type a letter.
Check that Loading message and options are visible at the same time

Context 🔦
I'm working on an autocomplete that calls an API on every keystroke using throttle as in the Google maps demo and I want to show the 'Loading...' message while the API is been queried.
I've found a workaround but maybe the options has to be hidden when loading by default?
Workaround:
options={!loading ? top100Films : []}

Your Environment 🌎

Tech
Version

Material-UI
v4.7.0

React
v16.10.2

Browser
All

@sclavijo93 This is related to #18450. What do you think of the opposite, we don't display the loading text in the popup if options are available?
diff --git a/packages/material-ui-lab/src/Autocomplete/Autocomplete.js b/packages/material-ui-lab/src/Autocomplete/Autocomplete.js
index f236baa0e..bd6f52c52 100644
--- a/packages/material-ui-lab/src/Autocomplete/Autocomplete.js
+++ b/packages/material-ui-lab/src/Autocomplete/Autocomplete.js
@@ -378,7 +378,9 @@ const Autocomplete = React.forwardRef(function Autocomplete(props, ref) {
           open
         >
           <PaperComponent className={classes.paper}>
-            {loading ?
{loadingText}
 : null}
+            {loading && groupedOptions.length === 0 ? (
+
{loadingText}

+            ) : null}
             {groupedOptions.length === 0 && !freeSolo && !loading ? (

{noOptionsText}

             ) : null}

@oliviertassinari In my case I would like to show when the options are been loading. It's a way to say "Hey, the options that you're seeing aren't updated, just wait a minute please until the querying is finished". Or do you think that's not necessary?

I think that in your case, I would use the CircularProgress demo we have, with the above changes.

Hmm, didn't noticed that. Ok, I'll try with that solution. Thanks!
Do you want me to send a PR with the code you mentioned above?

If you have the time to send a pull request, that would be awesome :)


OpenFolderDialog freezes the program

Here is a simple example with a OpenFolderDialog which freezes the program. Originally I tried it without the Task.Run() and instead used await for the result but that had the same issue. So I switched to this code after taking a look at https://github.com/AvaloniaUI/Avalonia/issues/1837
 public void SelectFolder()
        {
            var task = Task.Run(() =>
            {
                var dialog = new OpenFolderDialog()
                {
                    Title = "Select Folder...",
                    InitialDirectory = Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData)
                };

                var result = dialog.ShowAsync(Application.Current.MainWindow);
                if (result == null)
                {
                    return "Canceled";
                }
                else
                {
                    return "Selected";
                }
            });

            this.statusUpdate = task.GetAwaiter().GetResult();
        }

I am running on Win7 with .net core 3.0 (I also tested .net core 2.1)

It's not the dialog freezing the program, it's task.GetAwaiter().GetResult(); causing a deadlock. Use async/await. For more details see TAP.docx.

It's not the dialog freezing the program, it's task.GetAwaiter().GetResult(); causing a deadlock. Use async/await. For more details see TAP.docx.

My first approach was using async/await which didn't work. I also tried commenting out the task.GetAwaiter().GetResult(); and it still froze.
public async void SelectFolder()
        {
            var dialog = new OpenFolderDialog()
            {
                Title = "Select Folder...",
                InitialDirectory = Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData)
            };

            var result = await dialog.ShowAsync(Application.Current.MainWindow);
            if (result == null)
            {
                statusUpdate = "User canceled request";
            }
            else
            {
                statusUpdate = "User selected";
            }
        }

@tommaier123 A bit late.. But for anyone who is also stuck with this.
What worked for me is adding .ConfigureAwait(false)
dialog.ShowAsync(GetWindow()).ConfigureAwait(false);

For anyone that was like me trying to do this in a non-async method if you put it in a async method then you can just use ShowAsync without needing to do anything else.


Does not work in next js app

I curious why the library doesnt work in my next js home page. Scripts are loading before page is interactive and is visible but not actually rendered squircles.

@demidmalyanov did you figure out the solution? I am facing a similar issue.

@demidmalyanov did you figure out the solution? I am facing a similar issue.

Yes, I just add Script component from next/script on my index page.
Just like this
`

`

Turns out it was an issue my next version, updating to latest 12 fixed this for me.


[android-messaging] NPE on deleteToken

Since I use authentication in my app, I want token change callback to be called only when user is signed in.
I'm using the following:
messaging.onToken(null);
await messaging.deleteToken();

When I call deleteToken after I set onToken as null, I receive the following error:
Error: java.lang.NullPointerException: Parameter specified as non-null is null: method kotlin.jvm.internal.Intrinsics.checkNotNullParameter, parameter callback

fixed in https://github.com/NativeScript/firebase/commit/d1b8533864211c243dffc8d8ce0d1dd7b572ef8b


Vizualization

For one dimensional unputs make

[x] skatter plot
[x] line plot
[x] comparison plot with different regulators

comparison plot with different regulators is in example_notebook:
example_notebook.ipynb


Rules page

[ ] Index page
[ ] Rules page

Some work underway on a branch

Pushing this down the road, and filling the gap with an advanced tutorial for MVP.

Rising in importance. Need a concise text-based representation of the rules, accessible both as a standalone page and ideally from the in-game menu as a lookup.


bug([mat-table]): mat-tab-group messes up expandable rows in table

Reproduction
Stackblitz project: https://stackblitz.com/edit/github-itepdn
To see the bug, just open the app, switch to the second tab and go back to the first one.
The bug only shows with enabled Ivy compiler.
Expected Behavior
Switching tabs in mat-tab-group shouldn't affect the expanded rows in the table.
Actual Behavior
All rows in the table are expanded after switching to the second tab and back. This shouldn't be possible as normally the table allows only for one expanded row at a time.
Environment

Angular: 9.1.0
CDK/Material: 9.2.0
Browser(s): Chrome
Operating System (e.g. Windows, macOS, Ubuntu): Windows and Ubuntu
Enabled Ivy

Known workarounds

Disable Ivy

{
  ...
  "angularCompilerOptions": {
    "enableIvy": false,
    ...
  }
}

Lazy load tab

    <mat-tab label="Table">
       <ng-template matTabContent>
         <app-table></app-table>
       </ng-template>
    </mat-tab>

Is there any other clean solution without disabling ivy or lazy loading tabs?

Seems like this is the same issue as https://github.com/angular/components/issues/11765 which has a pending PR.


Loading times enormously long followed by timeout (BUG?)

I run checks on more than 600 services and have around 2500+ instances. Now that is a lot of checks. When I try to open cabot.localhost.com I need to wait for a good few minutes because of all these being loaded on a single page. Currently Cabot only supports javascript pagination on checks.html only and that occurs after all checks are being loaded. Anyone else experiencing this?

There is a pull request available to fix this #294

@iliyanotlioneberia Is there a fix for this?


Update Alpine Linux to new netboot images

Update Alpine Linux to new netboot images and add signature checks to Alpine.

Just tested it, booted straight up and fast but noticed during install it skipped the part to select the disk to install but that might be a alpine related thing.
Thanks for adding it


Who uses ghz?

Hey everyone, I'm curious to hear which companies or projects are using ghz and how? It would be inspiring and interesting to hear how are people finding this project useful.
Thanks!

Hi There,
Here in The Netherlands we are using for a (small) Master Engineering research project. I intend to use ghz for our experimentations, and find it a neat tool - thank you for it!
David

Hi @bojand, I am kenju from Tokyo, Japan. I am a software engineer & a tech lead of Cookpad.
We have used ghz last year (slide) and it was really great helpful. We needed a gRPC load testing tool against a TV-CM burst RPS for live video applications.
Now, we are considering to use ghz again in a new project, advertisement servers.
Though I am the only person who is using ghz in our company, but I hope I can help to develop & add more documentation & use-cases for ghz.

Hi @bojand, I'm Arinto from Singapore, working as software engineer in Traveloka. Currently we're using ghz as our load testing tool for gRPC services in my team. We spawn several ghz processes using Kubernetes job in our staging cluster to emulate the clients of our gRPC services.
Really appreciate ghz as it's pretty neat and do the job well :)

At @jobteaser we use it, thanks for the tool ❤

I used ghz to run a load test on AWS DynamoDB pushing 500k requests per second. It used 290 c5n.xlarge EC2 instances on ECS running 200 ghz containers against 200 consumers.

Hello 👋
Here at Seed-X we've used ghz to get capacity estimates for our inference infrastructure.
We're currently researching options for extending ghz into a locust.io like distributed benchmarking tool.


Staging next gnome python

Motivation for this change
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.05 Release Notes (or backporting 21.11 Release notes)

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

[ ] Fits CONTRIBUTING.md.

Are import checks needed when there are tests? Those should already check that libraries can be imported.

Are import checks needed when there are tests? Those should already check that libraries can be imported.

Yeah, we added them for simplicity and to check if checkInputs shadows some imports.

@jtojnar I just saw your comment in the other thread and I am going to plug you in. I hope that is fine for you. I also found a bug in cffsubr which breaks the build which I am also to fix.


Fix create ao table set parallel_workers doesn't take effect

closes: #131

Change logs
create table ao(c int) using ao_row with(parallel_workers=3) doesn't take effect because only storage options are taken care of in reloptions_gp.c:transformAOStdRdOptions. This PR fixes this by add code processing parallel_workers.
The default value of parallel_workers (-1) is taken from reloptions.c:intRelOpts. There're no #define-ed constant for parallel_workers's name and default value so I hard-coded them.
transformAOStdRdOptions actually reads WITH clauses before reads StdRdOptions. In the comment they say this is to preserve the order of options because some tests rely on it. I take the value from StdRdOptions w/o examining WITH clause and I see no necessity in doing so. Don't know if this could go wrong :-/
Does this PR introduce any user-facing change?
Yes. It fixes a user-perceptible bug.

A test case has been added. I've verified that before this fix the test would fail.


Fix pin issue on non super groups

Make message pin as optional feature.
Because of following error:
elegram.Bot.Exceptions.ApiRequestException: Bad Request: not enough rights to pin a message
   at Telegram.Bot.TelegramBotClient.MakeRequestAsync[TResponse](IRequest`1 request, CancellationToken cancellationToken)
   at UltraMafia.Frontend.Telegram.TelegramFrontendExtensions.CreateOrUpdateRegistrationMessage(ITelegramBotClient bot, GameSession session, TelegramFrontendSettings settings) in /tmp/src/UltraMafia/Frontend/Telegram/TelegramFrontendExtensions.cs:line 143
   at UltraMafia.Frontend.Telegram.TelegramFrontend.<>c__DisplayClass33_0.<<OnGamerJoined>b__0>d.MoveNext() in /tmp/src/UltraMafia/Frontend/Telegram/TelegramFrontend.cs:line 562
--- End of stack trace from previous location where exception was thrown ---
   at UltraMafia.Frontend.Telegram.TelegramFrontendExtensions.LockAndDo(ITelegramBotClient bot, Func`1 action) in /tmp/src/UltraMafia/Frontend/Telegram/TelegramFrontendExtensions.cs:line 171

As https://github.com/TheDevs-Network/the-guard-bot/issues/25#issuecomment-333514098 group should be a super group to allow message pinning.

This issue fixed in 1.0.1, now bot will check access to pin messages before pinning it.


controller-runtime version compatibility with dependencies

What happened:
Dependencies of EKS Anywhere that use newer versions of https://github.com/kubernetes-sigs/controller-runtime cannot be used. For example Rufio, uses v0.15.0. This causes issues across the code base and we cannot use the latest version of Rufio.
Also, controller-runtime's latest release is v0.16.2. We should upgrade to it.
What you expected to happen:
How to reproduce it (as minimally and precisely as possible):
Anything else we need to know?:
Environment:

EKS Anywhere Release:
EKS Distro Release:

I have discussed this a bit internally and for the Rufio changes I'm wanting to make i will investigate copying the API/types over instead of dealing with versions of controller-runtime. I am working on this in this branch https://github.com/jacobweinstock/eks-anywhere/tree/rufio-apis will open a PR when i have things working.

PR opened: https://github.com/aws/eks-anywhere/pull/6721

PR merged


Replace go-gomail/gomail with wneessen/go-mail in email utility

The gomail/gomail library was replaced with the go-mail library for sending emails. This change involved updating the go.mod, go.sum, and email.go files. The email.go changes include a new method of setting TO and FROM addresses, and a new way to dial and send the email. This switch to go-mail provides better error handling and more customization options.
This PR resolves https://github.com/labring/sealos/issues/4840

@wneessen
After the merger, I tested that I couldn't send the email successfully. The email sending action was hung and there was no response. But after switching back to the original implementation, it could be sent instantly.
func TestSMTPConfig_SendEmail(t *testing.T) {
	c := &SMTPConfig{
		ServerHost: "smtp.feishu.cn",
		ServerPort: 465,
		FromEmail:  "xxx",
		Passwd:     "xxx",
		EmailTitle: "【 xxx 】",
	}
	err := c.SendEmail("xxxxxxxxxxxxxxxxxxxxx"<EMAIL_ADDRESS>	if err != nil {
		t.Errorf("SendEmail() error = %v", err)
	}
	t.Logf("send email success!")
}

Please fix this

Twenty minutes later, an error message was displayed: SendEmail() error = dial failed: EOF

I'll have a look


tiny gradcheck

Hi there, my attempt for gradcheck. It is really simple: it computes the approx. of the Jacobian with Finite-Differences and checks if it is close to the one computed using .backward(). (It should also work with Conv2d when it will be ready...not sure though).
Confidence: 70% :smile: it was funny.

I think we can get this whole PR below 50 lines :)

Ahh, sorry. I merged the test PR. Rebase? It looks good

Done. Now we have:

jacobian() (analytical) and numerical_jacobian() as extracted functions
better and refactored tests
interface aligned with Pytorch. One difference here is that pytorch can compute Jacobian and gradcheck of functions of multiple tensors  (i.e: func(ta, tb, ...)) while this version does not (for this reason the parameter is named input rather than inputs). Seems an easy extension: just compute the current Jacobian (e.g: analytical) of the output of func(ta, tb, ...) w.r.t. each tensor individually while collecting the Jacobians in a list. I will do it soon, pytorch example as reference:

>>> t1 = torch.tensor([1., 1., 1.], requires_grad = True)
>>> t2 = torch.tensor([2.], requires_grad = True)
>>> func = lambda x, y: (x*y)
>>> torch.autograd.functional.jacobian(func, (t1, t2))
(tensor([[2., 0., 0.],
        [0., 2., 0.],
        [0., 0., 2.]]), tensor([[1.],
        [1.],
        [1.]]))
>>> torch.autograd.functional.jacobian(lambda k: func(k, t2), t1)
tensor([[2., 0., 0.],
        [0., 2., 0.],
        [0., 0., 2.]])
>>> torch.autograd.functional.jacobian(lambda k: func(t1, k), t2)
tensor([[1.],
        [1.],
        [1.]])

PS: comma will win ;)


Balance in Dawid Skene is obsolete.

https://github.com/JieyuZ2/wrench/blob/6d8397956533fc6c2fe50e93fcfe0a2303bdd05f/wrench/labelmodel/dawid_skene.py#L55
I realized this balance variable is used nowhere in this file. If it is intended, I think it should be removed from input parameters.

Actually the following three parameters are not used. - I think it could be better to remove them to prevent confusion?
dataset_valid: Optional[Union[BaseDataset, np.ndarray]] = None,
y_valid: Optional[np.ndarray] = None,
balance: Optional[np.ndarray] = None,


Handle queries that touch several tables

Handle JOINS and multiple tables in FROM statement.
SQL SELECT /* Elecena\Models\Product::newFromIds */ prod_id AS id,code,products.name AS name,products.description AS description,producers.producer_id AS producer_id,producers.name AS producer,extra,parameters,url,price AS price_original,price *  currencies.value / (currencies.multiply * 100) AS price,last_price,price_history,products.multiply AS multiply,prices,min_amount,currency,currencies.name AS currency_name,shops.shop_id AS shop_id,shops.internal_code AS shop_code,shops.name AS shop_name,img,img_width,img_height,img_src,added,products.updated AS updated,last_seen FROM products LEFT JOIN shops ON shop_id = shop LEFT JOIN producers ON producer_id = producer LEFT JOIN currencies ON currencies.symbol = currency WHERE prod_id IN ("43672","1234827","752637","2568089","2966413","367950","5014492","3814059","1671966","5123458") ORDER BY prod_id LIMIT 10

https://github.com/andialbrecht/sqlparse/issues/157

https://grisha.org/blog/2016/11/14/table-names-from-sql/

Will be handled by https://github.com/macbre/sql-metadata/issues/1


Fix network logs missing entity body

Purpose
Fix network logs missing entity body
Fixes https://github.com/ballerina-platform/ballerina-lang/issues/18593
Approach

Describe how you are implementing the solutions along with the design details.

Samples

Provide high-level details about the samples related to this feature.

Remarks

List any other known issues, related PRs, TODO items, or any other notes related to the PR.

Check List

[ ] Read the Contributing Guide
[ ] Required Balo version update
[ ] Updated Change Log
[ ] Checked Tooling Support (#)
[ ] Added necessary tests

[ ] Unit Tests
[ ] Spec Conformance Tests
[ ] Integration Tests
[ ] Ballerina By Example Tests

[ ] Increased Test Coverage
[ ] Added necessary documentation

[ ] API documentation
[ ] Module documentation in Module.md files
[ ] Ballerina By Examples

Codecov Report

Merging #18610 into next-release will increase coverage by 0.02%.
The diff coverage is 0%.

@@               Coverage Diff                @@
##           next-release   #18610      +/-   ##
================================================
+ Coverage         15.09%   15.11%   +0.02%
================================================
  Files                48       48
  Lines              1259     1257       -2
  Branches            198      197       -1
================================================
  Hits                190      190
+ Misses             1055     1053       -2
  Partials             14       14

Impacted Files
Coverage Δ

tool-plugins/vscode/src/trace-logs/traces.ts
21.05% <0%> (+2%)
:arrow_up:

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 ef93ad5...5143058. Read the comment docs.


Annotation on Video Call

I have read all of the README

I have searched existing issues and this is not a duplicate.

Bug report
There is no documentation of how to implement annotation on a video call but this blog reports this feature.
https://tokbox.com/blog/introducing-the-annotation-widget-in-beta/
This is more like a feature request if not available.

@maikthomas  Can you please help here?

Hi @rosygupta I'm looking into this, I'll get back to you as soon as I have an answer!
Thanks,
Mike

Hey @rosygupta Unfortunately, we don't have any documentation on implementing annotations on a video call. We've classified the annotation widget as an OpenTok Labs project because TokBox does not officially support this repo.

does someone how to implement it

Did you got any documentation for this @rosygupta

@RamyaAshika please read the contributors comment above.

ooh fine, but is it possible to add annotation in the video call? I'm struggling for this a week. Do you get any solution for this? @rosygupta


please release new version

Since May 10th, there are many changes, but the releases page has no the new version.

@gexgd0419 Not to put any pressure on you to have the updated engine released, but is there an easy way to try your latest changes? Since this needs an installation to work, I assume we can't simply copy/paste the altered files, but I might be mistaken. Thanks.

@amirsol81 This project is made using Visual Studio 2022. C++ and ATL is required.
The NaturalVoiceSAPIAdapter.dll can be installed by just using regsvr32 (with administrator's privilege). The installer does just that, and provides a user interface for changing some settings stored in the registry.
Also, Visual Studio will automatically try to register the DLL file after each successful build.

@gexgd0419 Thanks for your explanation. It's, of course, complicated for a non-developer like me, so I'd rather wait for the next release.

下面这几个项目不论我选什么 c++ 版本和 c 版本都无法正常编译： Installer, SpeechSDKPatcher, SpeechSDKShim
他们都有类似下面的错误提示：
E0135. 命名空间 "std" 没有成员 "make_unique"
C2039. "unique_ptr": 不是 "std" 的成员
C7568. 假定的函数模板“unique_ptr”后面缺少参数列表
请教这几个项目应该如何配置呢？谢谢！

@qt06 The Installer project is not finished, and the submitted code on GitHub is not ready for compiling yet.
Many of my projects use the Visual Studio 2017 - Windows XP (v141_xp) toolset to be compatible with Windows XP.
You should choose to install C++ Windows XP Support for VS 2017 (v141) tools [Deprecated] (对 VS 2017 (v141) 工具的 C++ Windows XP 支持 [已弃用]) in the Visual Studio Installer.
SpeechSDKPatcher and SpeechSDKShim cannot be built because of the incorrect NuGet package settings. But they also exist as a standalone project. You can try building using the VS solution inside the AzureSpeechSDKShim folder.
However, the main NaturalVoiceSAPIAdapter project should be able to compile. It uses the newest toolset and C++ version, and uses YY-Thunks to be compatible with Windows XP. The installer isn't really needed, as you can use regsvr32 to register the DLL.

ok, thank you.

A new version v0.2 has been released!

@gexgd0419 Thanks!Message ID:
@.***>


Apple TV Plus streaming

Would you be able to add Apple TV + streaming support?
Thanks

@ElectroBot does this have an actual app?

@ElectroBot does this have an actual app?

On settop boxes, yes, but it can be streamed from the site as well.

@ElectroBot I already added it in both desktop and plugin versions as well


DirectRestServices don't allow string return values

As it stands now, methods in a DirectRestService can't use "normal" strings as a return value.  The only way this works is if the string returned from the server is valid JSON, but if this is the case then they should probably be using a more well defined complex type anyway.
The cause of this deficiency starts in the DirectRestServiceInterfaceClassCreator, which always uses MethodCallback regardless of the type being returned.  As a result, other classes which inspect the callback type and parse the response text based on it try to convert the text to a JSONValue rather than just passing along the string.  Detecting the return type and requiring a TextCallback if String is found should fix this.

not sure if this is the whole answer. probably needs to look at the Prodcues annotation. the default to text with your PR is probably the right choice.
will keep this one open for now

Are you saying that inspection of the @Produces annotation would dictate which of the MethodCallback interfaces need to be used?  This is something that had I had considered, but I figured that if someone wanted JSON or XML then they should be either using a JsonCallback or XmlCallback to get a JSONValue or Document.  Looking into it a little further, I see now that those types that are client-side only classes.
That being the case, JsonCallback and XmlCallback are out because the server can't return those types.  A plain MethodCallback won't work with a string return value because it will always attempt to convert the string to a JSONValue and then to the type specified as the generic parameter.  OverlayCallback is also out because the type must extend JavaScriptObject.
This means that there is no other option for the callback type except TextCallback, right?  Or do you mean to say that if text/plain is used with a MethodCallback that we should vary the behavior of the parsing?

It sounds like the same that https://github.com/resty-gwt/resty-gwt/pull/262 fix.
Try to add this to your module XML:
<set-property name="restygwt.autodetect.plainText" value="true" />

I had some time to check the changes. The result is, it breaks #262.
With #314 i added tests for DirectRestService and revert the changes from #297.

in order to use auto-detection on strings you need to set in your XZY-gwt.xml
<set-property name="restygwt.autodetect.plainText" value="true" />

I guess we can close this issue now.


SNAFUed linefeeds between 2.3 and master

I tried to transplant some changes from master to branch and got nasty linefeed conflict through the whole file. I guess that bd13f67058fa4e247 is the culprit. Carlos, can you clarify what's going on?
In particular:

what you was trying to fix?
why the file ended up with mixed linefeeds?
and why did you choose to have different linefeeds for master and for branch?
and why did you choose CRLF linefeeds for master?

I am pretty concerned about that, because the history is messed up, it spoils the blame and gives me a headaches with version control system that's already complicated enough.
The perfectionist in me prefers that we rewrite/rebase the history to use unix linefeeds while importing to git.
Ping @ccordoba12.

I think we have 2 options:

Make the git global config use a default independent on what spyder does on different OS (devs would need to ensure this setup..)
Have an option to force spyder use only a fixed line ending version id DEV mode (assuming people are developing spyder using spyder)

It is true that something changed at some point recently...

Or support https://github.com/spyder-ide/spyder/issues/2336, require that Spyder files are all LF and add a hook script that checks this.

I'm sorry for the troubles @techtonik. I don't know exactly what happened there, I just remember that when I opened that file in Spyder (after the previous changes of @SylvainCorlay), all line endings were fixed by Spyder itself.
Given that I develop Spyder with Spyder, I thought I didn't have other alternative than re-committing the whole file again.
Sorry, I didn't give too much thought about it because the same thing had happened a few other times before.

@goanpeca and @techtonik, I think at this point we can't move to support only one line-ending type. Else we'll have to recommit all files again (like the case cited by @techtonik), and that will be a terrible headache for all our current contributors.
So the only thing to do is to instruct git to follow us :-)

I am concerned about the merges from stable 2.3 to master https://github.com/spyder-ide/spyder/wiki/Dev:-Github-Workflow doesn't describe maintenance of stable branches and sync with new development at all. What is the merge strategy?

There are not going to be more releases of the stable (2.3) branch, but the strategy is this:

While on maintenance, I develop on the stable branch and merge that branch with master every certain number of commits (between 5 and 10).
People is encouraged to make PRs against master and not to the stable branch. If I consider new code is not going to make Spyder unstable, or it's about an important bug fix, I backport it to the stable branch (either manually or by merging master with stable).
Translations are committed to the stable branch

I think that's all :-)

I'd vote for sticking to LF and adding editorconfig instead of messing with Git.
What is the current merge process? Do you merge features from stable to master? Does it work ok for you? If not, then I'd again, think about removing those line changing commits from history. Considering that we have 60 forks, I think it should be accompanied by a blog post that clarifies why people should care about line endings, what happens:

stop point or bump on the blame history road that needs vauluable time to pass through
screwed merges between branches

These two are significant roadblocks, so considering that Spyder is still young on GitHub, I'll still vote for purging the history for linefeed changes (archiving current repo for those who have forks) and also move all big files out of it to https://github.com/blog/1986-announcing-git-large-file-storage-lfs

@ccordoba12 I do not know if need to go as far as @techtonik suggests, but it is a concern that needs to be solved ASAP.
I think it would be best to make spyder used a single line feed for development (DEV) and people should be (strongly) encouraged to develop using spyder itself (The latest dev version...). Even if it is a minor annoyance for contributors, they can always rebase to master, and it would any problem.
I think this is important

My thoughts:
I agree with encouraging to use only one type of line endings and making that default for DEV.  (@goanpeca, could you make a PR for that?). However:

We can't force people to develop Spyder with Spyder. For example, @SylvainCorlay uses Vim :-)
Github doesn't report if line-endings have changed in PRs, so that would make much harder to check that. And making people to rebase their PRs just for line-endings seems not good policy to me.
The case reported by @techtonik happens like one or twice a year, so I don't think we should overreact about it.
I don't know what line-endings use GH for their online editor (with which users can create a PR in a matter of minutes). So that's another uncontrollable factor.
I don't see much bigger projects, like IPython, using or recommending a unique line-ending (see here), so I don't see why we should worry too much about that.

I don't agree with re-commiting all files with a different and unique line-ending, and worst, with creating a new repo just for that. That simply is not going to happen :-).

:+1:

Will start the PR soon, @SylvainCorlay uses linux most of the time, so that should be fine :-)

@ccordoba12 would not it be easier if we just add this .gitattributes to our repo? It would make git always use a consistent line end per repo and users would not have to change anything.
https://help.github.com/articles/dealing-with-line-endings/#per-repository-settings

http://stackoverflow.com/questions/170961/whats-the-best-crlf-carriage-return-line-feed-handling-strategy-with-git

@ccordoba12 What would be the problem with renormalizing the repo with a fixed line ending?

.gitattributes looks good, but it will require to recommit all files.

It will be once... and it will solve once and for all inconsistencies...

Some data (You have to use a shell that support recursive globbing or enable it in bash [it has side-effects]):
$ awk -v RS='\r\n' 'END{print NR}' **.py
49590
$ awk -v RS='\n' 'END{print NR}' **.py
99609

So about half of the lines are have windows style endings, and the other half have linux style endings.
Now by files (remove the grep to see file names):
find . -not -type d -name "*.py" -exec file "{}" ";" | grep CRLF
116
joseph@wdemr314z /d/p/spyder.git> find . -not -type d -name "*.py" -exec file "{}" ";" | wc -l
318

That's a lot of files to change ! If we do such a big change, we should also remove trailing whitespace everywhere. But is it woth it ?
Is it possible to add checks in travis to enforce style rules like this ? We could also add line length checks.

It is all relative, but is better now than later (or never...).
I would say, yes it is worth it:
Yes we also should remove trailing whitespace, yes we should make all of spyder code pep8 and yes we should change the line ending for good.

Travis suggestions seems like a good idea to make sure things are consistent, and sure, we could add line length check, no biggie there

We can not be fully compliant to pep8 because of the names in Qt, but we could follow most of it.

Yes my dear @Nodd... exlcuging that...

I have an entry on the wiki for this
https://github.com/spyder-ide/spyder/wiki/Dev%3A-Coding-Style

This seems a bit excessive to me because it'll make impossible to merge the work of the (62) people that have forks at this moment. And as I said before, it will only cover very sporadic cases (like the one mentioned by @techtonik).
I'd like to call for a vote here from all @spyder-ide/core-developers to make a final decision about it.
My vote is -1 on this change.

just in case you want a data point from an outsider, I am part of a team with a big repo with developers of all OSes (and line styles), and we previously ran into the same problem - .gitattributes is the way to fix this, as already proposed above.

also, @ccordoba12, for the issue of spoiling PRs, the renormalize option for git merge helps with that.

Well, let's take a decision: @goanpeca, @Nodd, @SylvainCorlay and @blink1073, what do you think about this issue? Should we move to use .gitattributes?

I would do it, even if it is messy now, it will save us from trouble in the future... when it might become even messier

;+1:

After some thoughts about it I'm :+1: on the change, if we normalize many things at the same time (and not line endings only). This could include:

line endings
trailing spaces
line length < 79 (I think we don't have anything to change here actually)
add all above as pep8 checks to travis
use .gitattributes

To facilitate the work, we can use tools like autopep8 and/or yapf. yapf is quite young (yet already well known) but autopep8 is stable, well tested and by default enables only safe checks.
To ease the transition, the amount of opened PRs should be at a minimum, but that's rather obvious.

@SylvainCorlay and @blink1073?

I agree with all of @Nodd's suggestions.

I agree with normalizing things with the .gitattributes. Although, I would not go as far as @Nodd on forcibly coercing line length. I would rather keep it as a loose constraint.
I think that there are legitimate cases where having very long lines is the most elegant way.

We could enforce that checks should be specifically disables for long line, to show that it's intentional. But I don't know how to to that other than by adding a comment at the end of the line, which would make it even longer... Anyway this point can be decided (and added) later, it is a detail.

@nodd, agreed
Is it something we could do after the new icon theme gets in? My branch here has over 60 modified files. Rebasing after something like this is going to be very very long.

I am against doing PEP8 normalization all at once. The merge tools can ignore linefeed changes, but more changes can break the merges again.
Also, I haven't seen the answer on merge strategy and how are you merging stuff. Is it from stable to master? How do you handle linefeed differences ATM? I am only concerned about the merges ATM.

@ccordoba12 already explained the merge strategy before in this thread (https://github.com/spyder-ide/spyder/issues/2335#issuecomment-94197832). If you want more precisions you'll have to ask them more specifically.
About pep8 I agree that we shouldn't normalize everything everywhere at once, but currently in each PR the pep8 errors are left, so things will never improve this way. For example a new startegy would be that when a file is comitted, all its trailing whitespaces should be removed, this way things will improve little by little. I know it's harder to spot the changes on review, but it could be a separate commit to help keep things clean.

So, we all agreed on this right @spyder-ide/core-developers?, now... the more time we let pass by... the more forks will be made and the harder it will become to make changes.
On my side I will finish with the corrections on my active PRs and stop making new ones, until this situation is solved.
Can we all agree on this?

Sounds good to me.

I agree for waiting before creating more PRs (except if they are very simple), but what about pep8 corrections ?

I think we should do the gitattributes thing first, then after that is done, remove trailing spaces and empty lines and then we can start fixing pep8 little by little...

There are reports that automatic linefeeds can corrupt binary files if detects them incorrectly. http://stackoverflow.com/questions/170961/whats-the-best-crlf-carriage-return-line-feed-handling-strategy-with-git I tend to agree that it is not a job of version control system to mess with the content. I'd prefer that Spyder repository just had a hook script so that people were aware of linefeed problem existence. It also a good test for Spyder itself.

Yes it can, but we're using only very common binary files that are recognized without any problem by git (.png, .mo, ...). We can also activate this for .py, .rst and .txt files only to be on the safe side.

This brings additional complexity to the issue. I'd better use http://editorconfig.org/ to control new files and convert old ones manually, because it is more explicit and less magical. Also, add a Travis to detect linefeeds problem, which may be a problem with Spyder itself.
Also, the link above says that Eclipse and alternative Git implementations (hg-git / dulwich) may not support this feature, so if we're to integrate Python plugin for Git into Spyder, the problem will manifest itself again. Somebody will commit the CRLF file and then somebody else will get the conflict. Travis is the best as for me.

We can also add a Travis test in case someone uses an alternative git implementation to be on the safe side. But for those who use vanilla git, line edings are manages automatically and they don't have to worry about it at all, while Travis just warns you afterwards. Why should we do something manually if it can be automated ?
Also a .gitattribute file is quite explicit.

I think the decision on using gitattributes is already made, it will offer way more advantages than disadvantages, it is explicit and will care for most of Spyder devs/maintainers needs.
The travis check can be added as a safety net for those corner cases.
I prefer to have a couple of disgruntled spyder users because something does not work in their specific setup, that having to tell the users/casual-devs to enforce some configuration that could have been transparently handled on their behalf.

On the spyder plugin for git.... when we get to that stage, then that plugin should make sure this is not a problem, and if it is, it should then solve it.

But for those who use vanilla git, line edings are manages automatically and they don't have to worry about it at all, while Travis just warns you afterwards. Why should we do something manually if it can be automated ?

Because you're writing editor, and the line ending should be controlled be editor, and not by your version control system.

I think the decision on using gitattributes is already made, it will offer way more advantages than disadvantages, it is explicit and will care for most of Spyder devs/maintainers needs.

Well, I am not a developer anymore, but I disagree with you. It is implicit, the advantages/disadvantages are not completely clear, and in context of editor development, the editorconfig alternative is not even addressed.

Anyway, I probably don't need to be so interested in long-term maintenance. =) I am just interested that you fix the repository so that merge of https://github.com/spyder-ide/spyder/pull/2400 from 2.3 to master is possible.

gitattributes will only affect the Spyder repo... When Spyder supports git via a plugin, each repo and each user will decide what they wish to do with their personal/public repos and git.
This change will make spyder development and maintenance easier in the long run cause it will remove both a burden on the developer and the maintainer.

For reference:

Mercurial has the same problem and the same kind of fix (via an extension):
http://mercurial.selenic.com/wiki/FAQ#FAQ.2FTechnicalDetails.What_about_Windows_line_endings_vs._Unix_line_endings.3F
SVN has svn:eol-style : http://svnbook.red-bean.com/en/1.7/svn.advanced.props.file-portability.html

Supporting EditorConfig would be nice, but this is a separate issue. Not all spyder developer and contributor use editors or IDEs supporting this extension, while all of them have to use git.
@techtonik Could you create a PR which adds a Travis check for line endings ?

@Nodd let me see..

Instead of messing with linefeeds in 2.3, it is better to #2469


CLI: orchestration commands

Description
CLI: orchestration commands
Changes proposed in this pull request:

Changed auth model of KEB /orchestrations and /upgrade endpoints to be based on OIDC JWT verification
Implemented kcp orchestrations and kcp upgrade kyma commands
Fixed immediate and maintenance windows schedules of upgrade operations

Related issue(s)
Resolves #239
Resolves #240

/test pre-master-kcp-development-artifacts

/test pre-master-kcp-development-artifacts

/retest


channel: Attempt to fix flaky doctest

https://github.com/crossbeam-rs/crossbeam/runs/7479566226?check_suite_focus=true

bors r+

bors r+


Move registering routes to boot method of IgnitionServiceProvider

According to Laravel docs, registering routes should never happen within the register method, as only binding should happen there. In practice, this causes a problem when trying to override/extend the base Laravel FilesystemServiceProvider, which combined with registering this package triggers an Illuminate\Contracts\Container\BindingResolutionException with message Target class [files] does not exist..
Therefore, moving the registering of routes to the boot method looks like a more robust approach to me. See also the example from the Laravel docs on the loadRoutesFrom method.

Hi @jnoordsij,
You're absolutely right. It was an oversight on our end. Sorry about that!


Multiline TextField fullWidth is not working

Current Behavior 😯
When I set the "fullWidth" on a multiline TextField it is not taking the fullWidth. If I add a normal (non-multiline) TextField it takes the fullWidth.
Expected Behavior 🤔
The multiline TextField should take the fullWidth like a normal (non-multiline) TextField takes.
Steps to Reproduce 🕹
https://codesandbox.io/s/pensive-wright-3xqnjy

Hi @cliedeman assign this to me


Fix kernel search on unix machines

For #11360
We're looking for kernels in same directory where python executable is.
This needs to be the sysPath & not executable.
On linux executable is in bin directory.
Kernels are in a directory above, but we're looking for them inside bin

Codecov Report

Merging #11361 into master will increase coverage by 0.00%.
The diff coverage is 0.00%.

@@           Coverage Diff           @@
##           master   #11361   +/-   ##
=======================================
  Coverage   60.96%   60.96%
=======================================
  Files         608      608
  Lines       33499    33512   +13
  Branches     4739     4738    -1
=======================================
+ Hits        20424    20432    +8
- Misses      12048    12052    +4
- Partials     1027     1028    +1

Impacted Files
Coverage Δ

...client/datascience/kernel-launcher/kernelFinder.ts
62.24% <0.00%> (ø)

src/datascience-ui/react-common/arePathsSame.ts
75.00% <0.00%> (-12.50%)
:arrow_down:

src/client/common/utils/platform.ts
64.70% <0.00%> (-11.77%)
:arrow_down:

src/client/linters/pydocstyle.ts
86.66% <0.00%> (-2.23%)
:arrow_down:

src/client/datascience/debugLocationTracker.ts
76.56% <0.00%> (-1.57%)
:arrow_down:

src/client/common/process/proc.ts
14.49% <0.00%> (-0.73%)
:arrow_down:

src/client/datascience/constants.ts
99.72% <0.00%> (+<0.01%)
:arrow_up:

...client/datascience/raw-kernel/rawJupyterSession.ts
71.21% <0.00%> (+1.37%)
:arrow_up:

src/client/datascience/jupyter/jupyterServer.ts
9.70% <0.00%> (+2.77%)
:arrow_up:

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 55841b4...9411132. Read the comment docs.


Add a few more exclusions to the minimal footprint tests

Add a few missing flags to the minimal tests:
no-rmd160 no-ocb no-ct no-async

Is it worthwhile considering the OPENSSL_SMALL_FOOTPRINT define as well?

Yes, OPENSSL_SMALL_FOOTPRINT is already included.

Sorry, missed it.  Thanks for the clarification.

Absolutely no problem, I am still looking for more options to get a smaller footprint...

I used 1.1.1-stable:
$ ./Configure linux-generic32 no-shared no-dso no-pic no-autoload-config no-engine no-comp no-cms no-dh no-dsa no-ec2m no-srp no-des no-mdc2 no-md4 no-rc2 no-rc4 no-bf no-camellia no-cast no-idea no-seed no-whirlpool no-ocsp no-sm2 no-sm3 no-sm4 no-ssl3 no-ssl3-method no-psk no-heartbeats no-nextprotoneg no-sctp no-srtp no-asm -DOPENSSL_SMALL_FOOTPRINT -Os -fno-asynchronous-unwind-tables
$ make
$ ls -la *.a
-rw-rw-r-- 1 ed ed 2978156 Sep 24 21:51 libcrypto.a
-rw-rw-r-- 1 ed ed  722120 Sep 24 21:51 libssl.a
$ ls -la apps/openssl
-rwxrwxr-x 1 ed ed 1924372 Sep 24 21:51 apps/openssl
$ ./config no-shared -Os -fno-asynchronous-unwind-tables
$ make
$ ls -la *.a
-rw-rw-r-- 1 ed ed 4547874 Sep 24 21:54 libcrypto.a
-rw-rw-r-- 1 ed ed  796440 Sep 24 21:54 libssl.a
ed@w-ed:~/OPC/openssl$ ls -la apps/openssl
-rwxrwxr-x 1 ed ed 2848984 Sep 24 21:54 apps/openssl

That is not too bad, but someone should give me 130K back
that 1.0.2 was smaller.

What size size say?  Symbol tables counted in the ls command.

Yes, but no debug symbols, and no unwind tables, by the config options.
Nevertheless one can see a difference, and I wish it was possible to configure
openssl more to match our needs here.
FWIW openssl 3.0.0 goes completely in the wrong direction, being larger and slower at
the same time. Coincidentally the openssl speed command is broken on master as well,
so you cannot get correct numbers at all.

FWIW openssl 3.0.0 goes completely in the wrong direction, being larger and slower at the same time.

If you are concerned about that (me too), you might want to open a separate issue for that.

#9801 was an attempt to start conditioning out code, but wasn't all that well received.
In theory a provider could be made that only contains the desired implementations and the default provider omitted.  This ought to get the size down.  Calls that rely on missing functionality would fail at run time rather than causing a link time error.

I am curious about the speed impact, since crypto algorithms didn't change.  The fetch() overhead is now noticeable?  It should be possible to avoid that with some tuning/caching. (right @paulidale? :)
I guess we need profiling and speed testing to see where the slowdown is.

Regarding the performance regression, see:
https://github.com/openssl/openssl/pull/9674#issuecomment-524356954
https://github.com/openssl/openssl/pull/9674#issuecomment-524488000
I have not tried if the numbers changed recently, but I would be surprised if...
I am quite busy with other things as openssl, so something might have
changed, in the mean time @slontis ?.

@slontis identified the problem that causes the slow down: EVP_CIPHER_CTX_block_size isn't a cheap call anymore.  We need to implement some form of caching of constants to get this back.  We've a fair idea how this needs to be done, it is now a question of finding time to do it properly.
As @richsalz wrote, there will be more overhead on the fetch/setup but the algorithms themselves should run just as fast.

Reopened, to see if this still builds

issue was resolved recently


test: add BluetoothEmulation based tests for bluetooth.requestDevicePromptOpened

This PR adds a test for bluetooth.requestDevicePromptOpened permissions API
using the new BluetoothEmulation CDP domain commands.
Please give it a review, and once in reasonable shape we can add tests for any
additional APIs.

I can reproduce the timeout on gLinux.

The error is TypeError: Cannot read properties of undefined (reading 'requestDevice')

I think on Linux it does not work without --enable-experimental-web-platform-features. @reillyeon are the plans to make web-bluetooth not experimental on linux? (not sure what is the status on Windows).

Alternatively, is there a way to enable Bluetooth without enabling the rest of experimental web features?

Alternatively, is there a way to enable Bluetooth without enabling the rest of experimental web features?

You can use --enable-features=WebBluetooth (same as enabling chrome://flags#enable-web-bluetooth).


⚠ Jenkins Plugins Artifactory has degraded performance

In d6de634, Jenkins Plugins Artifactory (https://get.jenkins.io/plugins/artifactory/) experienced degraded performance:

HTTP code: 200
Response time: 1222 ms

Resolved: Jenkins Plugins Artifactory performance has improved in 5255ae3 after 13 minutes.


Validation Rules

CMDT can have Validation Rules.
One example is that the Object on the Indicator Item must match the object on the Indicator Bundle when adding a Bundle Item.
What other Validation Rules should we have?

Indicator Bundle
The sObject of the Bundle Item must match the sObject of the Bundle

If Show when False or Blank has been checked, ensure an Icon or Image is entered.


Can I parse tables?

I wonder if I can use this lib in its current state to parse a pdf with texts in a table.

But yeah, this project is super useful! There are places that still use pdf to share information and, in many cases, parsing it is the only way to automatically gather information. I hope you complete the implementation someday :)