Offline- Import:exceeds ABAP 30-characters-name limit

Hi Team,
As i have some issues with online issues( i posted here), i thought to work with offline version.
I am getting an error message like  below where LEARNING is my package name and i could not import my ZIP file and any help will be appreciated,
Error: Package LEARNING_ZMONSTERS_P01_ENABLERS exceeds ABAP 30-characters-name limit

install into a package with shorter name

I tried it too but still have the same issues. Now package name is RAJ
Error: Package RAJ_ZMONSTERS_P01_ENABLERS_ZMONSTERS_C01_ECLIPSE exceeds ABAP 30-characters-name limit

Hi,
can you please have any suggestions for me to take it further?. I am not able to proceed either with online or offline approach and can help on it will make my long weekend fruitful.

no, will have to investigate, see https://github.com/larshp/abapGit/issues/2695
alternatively please provide more details on how to reproduce the error

try creating the repo with FULL folder logic

what do you mean by try creating  the repo with FULL Folder logic.
On Tue, Jun 11, 2019 at 11:54 AM Lars Hvam<EMAIL_ADDRESS>wrote:

try creating the repo with FULL folder logic
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/hardyp/AbapToTheFuture03/issues/13?email_source=notifications&email_token=AITAP2BF3XXVOTXC33QDMBDPZ7DEDA5CNFSM4HOXFGTKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXNTQ3A#issuecomment-500906092,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AITAP2EQ7TACHCREIRY65ATPZ7DEDANCNFSM4HOXFGTA
.

--
Regards,
Rajesh


[QUESTION] NoneType values in OpenApi example

Description
Trying to make correct documentation for FastApi service.
All responses have optional error field:
from typing import Generic, TypeVar, Optional

import uvicorn
from fastapi import FastAPI
from pydantic import BaseModel, Field
from pydantic.generics import GenericModel

DataT = TypeVar('DataT')

class Error(BaseModel):
    message: str
    code: int

class Result(GenericModel, Generic[DataT]):
    data: Optional[DataT]
    error: Optional[Error] = Field(None, example=None)

class Item(BaseModel):
    foo: str
    bar: int

app = FastAPI()

@app.get("/items", response_model=Result[Item])
async def get_items():
    return Result(data=Item(foo='bar', bar=1), error=None)

if __name__ == '__main__':
    uvicorn.run(app, host='<IP_ADDRESS>', port=8080)

But OpenApi renders Example Value  like this:
{
  "data": {
    "foo": "string",
    "bar": 0
  },
  "error": {
    "message": "string",
    "code": 0
  }
}

Is it possible to represent Example Value with null in error field? Like this:
{
  "data": {
    "foo": "string",
    "bar": 0
  },
  "error": null
}

I ran into the same type of issue with the Optional[]-> example=None pattern.

Hey there! You can probably do it explicitly defining the examples you want to use: https://fastapi.tiangolo.com/tutorial/schema-extra-example/

Sorry for the long delay! 🙈  I wanted to personally address each issue/PR and they piled up through time, but now I'm checking each one in order.


Modify root README code block language identifier from json to jsonc

Minor stuff, but currently the code block for "workspaces" option uses json for language identifier, which doesn't allow comments and leads to an eyesore (i.e. unintended text & background colors):
// in workspace root
{
  "workspaces": {
    "packages": [
      /* ... */
    ],
    "nohoist": ["**/solid-start"]
  }
}

// in project root of a workspace child
{
  "workspaces": {
    "nohoist": ["solid-start"]
  }
}

Simply changing the language identifier from json to jsonc makes that go away:
// in workspace root
{
  "workspaces": {
    "packages": [
      /* ... */
    ],
    "nohoist": ["**/solid-start"]
  }
}

// in project root of a workspace child
{
  "workspaces": {
    "nohoist": ["solid-start"]
  }
}

Thanks for pointing this out! Fixed it!


ci: add qodona

Pull Request Checklist

[ ] New code has 100% test coverage
[ ] (If applicable) The prose documentation has been updated to reflect the changes introduced by this PR
[ ] (If applicable) The reference documentation has been updated to reflect the changes introduced by this PR

Description

adds jetbrains' qodona

Close Issue(s)

Looks like CI is broken: https://github.com/litestar-org/litestar/actions/runs/5702668722

I will send a fix :)


Where is the outer-container mixin?

Hi.
I've installed Neat with yarn add<EMAIL_ADDRESS>When try to use the mixin outer-container with @include outer-container;, I get the following error:
No mixin named outer-container

Has this mixin been removed or do I need to margin: 0 auto; it? Many tutorials about Neat use this mixin, so I find it a little strange.
Cheers.
Technical details:

Neat Version: 2.1.0
Build Tool or Environment: webpack
Browser/OS: Chrome, W10

Hi @coffeeneed,
Neat 2.X has deprecated the outer-container mixin. You can switch to 1.X if that's what a lot of your tutorials and reference materials are using. They work quite differently so your millage may vary depending on your needs.
Many users of 2.X like to roll their own mixin to emulate the behavior. Depending on your needs, this could look something like the following. ⤵
@mixin my-outer-container() {
  @include grid-container;
  margin-left: auto;
  margin-right: auto;
  max-width: 1200px;
}

Fore more info on which mixins are available check out http://neat.bourbon.io/docs/latest/

Hi @whmii.
Thanks for your kind reply and help.
May I ask why you removed such an important feature in a grid system? Everyone need to center stuff and if it's a fact that people make their own mixin, why not keep it in?
Cheers. Will try out Neat in my next project.

Hi @coffeeneed - I had that same question, too: https://github.com/thoughtbot/neat/issues/568 - I don't think that mixin is important at all. You can just assign a max-width to the selector that requires it and you're good.
As noted in that link, it's a good thing to bring up in migration documentation or some other type of guide to help familiar users get up to speed.

Everyone need to center stuff

Not necessarily. Sometimes layouts simply extend the full-width of the viewport and centering is not required. We felt like the centering feature was not a need of the grid system, but rather a need of the project’s specific desires, therefore didn't make sense to have it always included in the grid container.
The grid never needed to be aware of its maximum width or whether it was centered horizontally, so let's entangle those into grid-specific mixins. It convoluted features and requirements.

You can just assign a max-width to the selector that requires it and you're good.

This is exactly what we realized. So, what we might have in v1.x:
.element {
  @include outer-container(70rem);
}

…would become something like this in v2.x:
.element {
  @include grid-container;
  margin-left: auto;
  margin-right: auto;
  max-width: 70rem;
}


cmd/link: memory reductions slowed down the linker

CL 173938, which switched to using mmap'd symbol name strings, made the linker 15% slower. Based on the profile, the reason appears to be completely silly: the new call to r.rd.Offset() in objReader.readSymName is remarkably expensive. The Seek call used to find the offset is roughly 20% of the profile.
@cherrymui suggested we could make bio.Reader directly use the mmap'ed backing store when we have it and simply track its own offset. We should also avoid the Offset call if we don't have the mmap'ed backing store, since we don't need it then.
Alternatively, we could continue using the underlying file, but track the offset ourselves in bio.Reader.
/cc @thanm @cherrymui

Good catch.  Your analysis makes sense...


Go to definition called on a destructor declaration goes to the class definition

If a class has an out of line defined destructor, triggering go to definition on the declaration inside the class goes to the class definition, rather than the destructor definition. The reverse of this also happens, calling go to declaration on the out of line definition will again go to the class, rather than the destructor declaration inside the class.
It's also observed that hovering over the destructor declaration returns hover info pertaining to the class rather than the destructor. Although given how comments on destructors typically aren't useful, I think that behaviour is acceptable.
System information
Output of clangd --version: clangd version 13.0.0 (git@github.com:llvm/llvm-project.git cf37d03e79d227a5f6a9526c914afd01bcb6aeec)
Editor/LSP plugin: vscode 1.52.1 / vscode-clangd 0.1.9
Operating system: ubuntu 20.04.1

#179 is related.
A workaround is to invoke the go-to-def in this position: Class::[^]~Class.

It looks like this has been addressed by #179; closing.


Update manpage and append -- to hstr calls

Aftercare on the 3.1 release fixes for no TIOCSTI:

Update the manpage with the fixed bash configuration
Append -- to hstr calls, in both the bash and zsh configurations

The latter so that typing --help [ctrl-r] searches history instead of
showing hstr help.
This fixes the feedback from @leapfrog on #485.

@jakedane good catch - thank you for the contribution!


#161255259 Users can bookmark articles

What does this PR do?
It implements the user can bookmark an article feature by creating a bookmarks app.
It also adds the following endpoints to the application

api/bookmarks/add/<slug>/
api/bookmarks/remove/<slug>/
api/bookmarks/mine/

Description of Task to be completed?

Allow users to bookmark articles of their choice
Allow users to undo bookmarks
Allow users to view their bookmarks

How should this be manually tested?

Clone the repo: git clone https://github.com/andela/ah-maps.git
cd into ah-maps
Create a virtualenv and activate it
Declare necessary environment variables
Install all dependancies: pip install -r requirements.txt
Run the tests: python3 manage.py test

What are the relevant pivotal tracker stories?
#161255259
Screenshots
Bookmark article

Unbookmark article

View logged-in users bookmarks

Pull Request Test Coverage Report for Build 366

74 of 91 (81.32%)  changed or added relevant lines in 5 files are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage decreased (-0.6%) to 92.275%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

authors/apps/article/models.py
4
5
80.0%

authors/apps/bookmarks/api/serializers.py
10
15
66.67%

authors/apps/bookmarks/api/views.py
29
40
72.5%

Files with Coverage Reduction
New Missed Lines
%

authors/apps/authentication/views.py
1
87.1%

Totals

Change from base Build 362:
-0.6%

Covered Lines:
1505

Relevant Lines:
1631

💛  - Coveralls


composer run serve EventDispatcher error

What steps will reproduce the problem?
I just ran composer create-project --prefer-dist --stability=dev yiisoft/app app
And then composer run serve
What is the expected result?
Start development webserver
What do you get instead?
PHP Fatal error:  Uncaught Yiisoft\Factory\Exceptions\NotFoundException: No definition for Psr\EventDispatcher\EventDispatcherInterface in <removed>/vendor/yiisoft/di/src/Container.php:222
Additional info
Unsure what about my system setup is wrong here, couldnt find anything regarding this on google or obvious packages I needed to install. What am I missing?

Q
A

Version
1.0.?

PHP version
7.4.11

Operating system
Ubuntu 20.04

I fixed this by adding the event-dispatcher provider to config/providers.php. However now I am getting
GET / - Uncaught Yiisoft\Injector\MissingRequiredArgumentException: Missing required argument "event" when calling "collect" in "/home/julian/yiisoft/app/vendor/yiisoft/yii-debug/src/Collector/WebAppInfoCollector.php" at line 32. in /home/julian/yiisoft/app/vendor/yiisoft/injector/src/Injector.php:147
Any ideas?

That last one I (temporarily) 'fixed' by disabling debug.

Apparently we tried that out at the same time haha, so at least im not the only one with the issue. Guess we will wait for fixes then, you guys can close this if it is a duplicate.

Likely is this case: https://github.com/yiisoft/di/pull/185

Fixed.


Switch deploymentId of clasp undeploy to optional

If you do not enter deploymentId, the latest deploymentId will be used.
This PR follows the design of https://github.com/google/clasp/pull/372#issuecomment-435435683 .

[ ] npm run test succeeds.
[x] npm run lint succeeds.
[x] Appropriate changes to README are included in PR.

Thanks @takanakahiko!


Short solution needed: "Rust lang struct" (rust)

Please help us write most modern and shortest code solution for this issue:
Rust lang struct (technology: rust)
Fast way
Just write the code solution in the comments.
Prefered way

Create pull request with a new code file inside inbox folder.
Don't forget to use comments explain solution.
Link to this issue in comments of pull request.

Rust struct as trait
Rust struct associated type
How to use struct as parameter in Rust
Rust struct of any type example
Anonymous field in Rust struct
Rust struct as u8
Rust struct with all public fields
Example of array of structs in Rust
Rust struct of bytes example
Example of bit field in Rust struct
Example of constant struct in Rust
How to copy struct in Rust
How to clone struct in Rust
How to compare structs in Rust
How to create struct in Rust
How to add comments to struct in Rust
How to set default value in Rust struct
How to extend struct from another struct in Rust
How to embed struct in Rust
How to create struct from hashmap in Rust
Rust struct getter example
How to get struct value in Rust
How to get struct fields in Rust
How to iterate over struct in Rust
How to write struct to json file in Rust
How to serialize struct to json in Rust
How to generate struct from json in Rust
How to get struct length in Rust
How to map struct in Rust
Rust struct with one field example
Example of struct of structs in Rust
Example of struct private field in Rust
Example of struct public field in Rust
How to pretty print a struct in Rust
How to sort a struct in Rust
How to convert struct to bytes in Rust
How to convert struct to protobuf in Rust
How to update struct in Rust
How to join structs in Rust
Example of struct with vector field in Rust
Rust struct without fields
Example of Rust struct with closure
How to serialize struct to xml in Rust
How to init zero struct in Rust


Angular Material components inside custom-cell

Hi guys,
I have a mdt-table and I want to render inside angular-material components. The rendering isn't happening correctly. I only see flat objects without any dynamic interaction capability. let me know if you face the same issue.
To recreate:

Create a table
Add a custom cell with the following content:

 <mdt-custom-cell column-key="id">
        <md-button class="md-raised md-fab  md-mini"><ng-md-icon icon="edit" /></i></md-button>
      </mdt-custom-cell
```>

@cirix you need to use a directives

@gerome0123 So, I need to wrap my every material element in a directive and then use it?

@cirix @gerome0123 I made it work by adding 'md-button' as a class and using simple button tag.

I dont know, this might not solve the real problem but I got the Material design UI atleast


quartata: Watch ravioli ravioli what's in the pocketoli

quartata requests the watch of the watch_keyword ravioli ravioli what's in the pocketoli. See the Metasmoke search here and the Stack Exchange search here.

!!/approve

ravioli ravioli what's in the pocketoli has been seen in 0 true positives, 0 false positives, and 0 NAAs.

Coverage remained the same at 65.485% when pulling c3adeb0467238b97eadeb19b60be490cdbf927ab on auto-blacklist-1525998928.486516 into 555828a3337fccb83542425235a1fbf8b368318e on master.

!!/approve


Formalize left-to-right volatility allocation rules

RAX -> RBX -> RCX -> RDX -> ....

RAX is going from "most volatile" to the right is "less volatile". If a value needs to be preserved, then push it to the right (sort of like a stack). This should deterministically prevent clobbering efficiently while still being decidable from a local reference frame.

By creating both a right-to-left and left-to-right version of each function it would be possible to do binary operations without readjustment of any registers.
Mega Super Ultima Supremo Fastcall Calling Convention

San Francisco Zipper Calling Convention

https://github.com/andrew-johnson-4/-/pull/142
Fastcall calling convention is simpler and comparable performance with less code bloat.
Left-to-right register volatility is still a good idea.


add dict compression and sync in titan proptest

What is changed and how it works?

Issue Number: Ref #16259

What's Changed:
add dict compression and sync in titan proptest

Related changes

[] PR to update pingcap/docs/pingcap/docs-cn:
[ ] Need to cherry-pick to the release branch

Check List
Tests

[x] Unit test
[ ] Integration test
[ ] Manual test (add detailed scripts or steps below)
[ ] No code

Side effects
Release note

None

/merge


run this https://genomebiology.biomedcentral.com/articles/10.1186/s13059-019-1795-z

using pbmcbench at least


OpenEBS is unable to delete SPC, SCP, SP, BlockDevice

Description
I created EKS with Terraform.
I mounted some EBS to some EC2 instances, then use Terraform to increase the number of nodes (old EC2 instances were terminated and new EC2 instances were added to the EKS cluster ,then I also enabled iSCSI client manually on nodes). So, previous EBS were unattached, but theirs BlockDevices still existed with Status Active.
I try to remove above BlockDevices by running kubectl delete blockdevice blockdevice-xxxx -n openebs. It said blockdevice-xxxx is deleted but it still there, nothing is deleted.
I do the same with other resources such as kubectl delete spc,csp,sp --all, it returns the same issue above.
However, when now I attach new EBSs, create new SPC with new BlockDevice, these new resources are removable.
Expected Behavior
Successfully delete SPC, SCP, SP, BlockDevice
Current Behavior
Command returns DELETED but nothing is deleted.
 I had a similar issue: I don't think your issue is the same (I did not have an issue deleting any CRs other than blockdevices), but wanted to point you to those logs.
OpenEBS installed via Helm. Block device manually created (with ndm.io/managed: "false"). Deleting the blockdevice CR with kubectl reported success, but the block device remained (or immediately remained). Did not have an issue with deleting blockdevices automatically discovered by NDM (after updating e.g., vendor-filter to stop NDM recreating the device).
NDM operator logs had Error while cleaning blockdevice-ssd-2: Node "" not found and indeed I had not specified node.nodeName on the blockdevice. A quick kubectl edit to add that and another delete successfully deleted the device.

I have a similar issue.
Any recommendation ?
I uninstalled the

I created a guide
https://github.com/openebs/openebs-docs/issues/900
tell us if it works

@survivant it works. thank you very much!


"SQL Format" function doesn't work in SQL Editor

System information:

Operating system (distribution) and version Win10
DBeaver version 7.0.4 EA

Describe the problem you're observing:
"SQL Format" function doesn't work in SQL Editor
Steps to reproduce, if exist:

Write a query in SQL Editor in one line (e.a. for PostgreSQL: SELECT * FROM public.actor where actor_id >40 order by actor_id DESC;)
select the query
Apply "SQL Format" using SQL Editor context menu

Actual result: no visible changes.

Opened by a mistake


NaN is printed as null on JS challenge output

Describe your problem and how to reproduce it:
Running console.log(NaN) on any JS challenge outputs null on the console output instead of NaN.
Related forum topic: https://www.freecodecamp.org/forum/t/325273
User reported seeing [null] when it actually should be [NaN] with the following code:
function bouncer(arr) {
let meh = [];
for (let i = 0; i < arr.length; i++) {
  if (arr[i] !== false && arr[i] !== null && arr[i] !== 0 && arr[i] !== "" && arr[i] !== NaN && arr[i] !== undefined) {
    meh.push(arr[i]);
  }
}
return meh;
}

console.log(bouncer([false, null, 0, NaN, undefined, ""]));

Add a Link to the page with the problem:
https://www.freecodecamp.org/learn/javascript-algorithms-and-data-structures/basic-algorithm-scripting/falsy-bouncer
Tell us about your browser and operating system:

Browser Name: Firefox
Browser Version: 70.0
Operating System: Kubuntu 19.04

If possible, add a screenshot here (you can drag and drop, png, jpg, gif, etc. in this box):
Screenshot of bug in a different challenge:

@ojeytonwilliams

I don't know anything about this part of the code, but I do see JSON.stringify being used in test-evaluator.js and if you stringify NaN you get back "null".
JSON.stringify(NaN)
"null"

JSON.stringify(): Description
The numbers Infinity and NaN, as well as the value null, are all considered null.

Again, not sure if this is related or not just thought I would post it anyway.

Yeah, that's exactly the issue.  My current plan is to use toString() if it exists and stringify if not.  I'm just not sure how to make sure this doesn't create any weirdness.

What about using the replacer parameter function?
function replacer(key, value) {
  if (value !== value) return 'NaN';
}

console.log(JSON.stringify(NaN, replacer));
// "NaN"

Would that be less likely to not cause any weirdness?

@lasjorg that sounds way better.  Do you think you'll have time to put that in a PR?


Posts are no longer listed since 3d9a1277a82ded759843395024e531c64437b91c

Hello,
It seems posts are no longer listed when we go to : http://localhost:1313/post/
Bisect reveal this issue appears with 3d9a1277a82ded759843395024e531c64437b91c
Regards,

Thanks for reporting this @anayrat !


Registeration

registeration.txt
This issue is detailed in attached file

Done with this from the file you sent.


User authentication

Login with GitHub, restricted to members of the @ministryofjustice organisation

Links:

https://github.com/pennersr/django-allauth
https://python-social-auth.readthedocs.io/en/latest/


Double Cursor

During Edit I have got a "Double Cursor", which allows to add text in both positions at the same time.

This is a VS Code feature. It activates if you Alt + click in the source text. To deactivate just click without Alt anywhere in the source.

Thx


Meter related refactoring and minor fixes

Refactors meter related code and minor fixes:

match cooling/heating ThresholdTemperature value range to avoid warnings.
avoid undefined values for temperature and humidity.
fix RotationSpeed value which was being set to CurrentFanSpeed.

@mrlt8 I had to resolve a conflict after merging #790. I am going to merge this. Please open another PR if anything looks weird.


Update _waterfall.py

Unable to set show=False for waterfall plots. The issue is that matplotlib.pyplot is imported as pl and not plt.

Thanks so much! Sorry for slow review, was out after parental leave for a while. I merged an earlier fix of the same painful problem.


OnMembersAddedAsync isn't hit when someone is added to chat in GroupMe channel

I've got a simple Echo Bot sample running in Azure, connected to the GroupMe channel. This is the code in the main bot class:
    public class EchoBot : ActivityHandler
    {
        protected override async Task OnMessageActivityAsync(ITurnContext<IMessageActivity> turnContext, CancellationToken cancellationToken)
        {
            await turnContext.SendActivityAsync(MessageFactory.Text($"Echo: {turnContext.Activity.Text}"), cancellationToken);
        }

        protected override async Task OnMembersAddedAsync(IList<ChannelAccount> membersAdded, ITurnContext<IConversationUpdateActivity> turnContext, CancellationToken cancellationToken)
        {
            foreach (var member in membersAdded)
            {
                if (member.Id != turnContext.Activity.Recipient.Id)
                {
                    await turnContext.SendActivityAsync(MessageFactory.Text($"Hello and welcome!"), cancellationToken);
                }
            }
        }
    }

When a new person joins or is added to the group, the OnMembersAddedAsync method is never hit, but instead, the OnMessageActivity method is hit - the bot simply echos out the message about the new user being added. Am I wrong to think that the Bot Framework should be treating these join messages as something to be handled by OnMembersAddedAsync?

Closing the issue here as the user has opened the issue on Stack Overflow.

@anusharavindrar, why does opening a Stack Overflow question mean that this issue is ready to be closed? While I'm open to workarounds from the Stack Overflow community, this appears to be a clear defect with the bot service, and should be a valid issue for this Github - I'd appreciate it being reopened until it's addressed or resolved.

Hello @sphanley. Our support team monitors both Stack Overflow and our repos here for user requests for assistance. We address "how to" issues in Stack Overflow while problems with the framework and associated services/components are handled here in their respective repos. @anusharavindrar will assist you here as in reviewing this it does appear to an issue and not a "how to" request (my mistake).

@CoHealer thanks for reopening! I agree - I'm open to how-to type workarounds from anyone on Stack Overflow, but I definitely think that this is a Microsoft-side issue that needs investigation/remediation. I'll be happy to provide any other info needed, but I believe it reproduces using the out-of-the-box sample bot, so hopefully it should be straightforward to reproduce.

Hello @sphanley . I tried to repro your issue and I am getting the same response as you got. When someone joins a group or I add someone to the group, the bot should respond back with 'Hello and welcome!' but it is just echoes back with the message that a new member has been added or has joined. This particular channel(GroupMe) is typically less used in comparison to other channels(Teams, Messenger,etc.) and hence one can't find much issues reported for this channel. I have raised an issue in the same repo and will follow up until its resolved. You could also track the progress of the issue in the link attached. I will reference the fix to this issue once its resolved.

Thanks for the update, @anusharavindrar.  I'm looking forward to a fix for this issue! For what it's worth - I've also opened another question on Stack Overflow for a piece of seemingly missing functionality in the GroupMe channel - if there's anyone looking into this on your side who's especially versed in connecting the Bot Framework to GroupMe, I'd really appreciate any advice assistance that may be available.


ci: fix codecov report on main

Currently codecov behaves strangely because cov reports on main is missing. It's because we do squash merge and do not run unit tests on main.
As mentioned here, one solution is:

Save down the coverage report sent to Codecov using the -q option.
Save that file as an artifact (GitHub Actions has upload-artifact)
Trigger CI on merge, but only to download the above artifact and upload with the -z 11 option.

But I don't know how to do the artifact passing trick yet since we are using buildkite. Need some investigation. 🤪
Additional info: A previous different tiny attempt didn't seem to work https://github.com/risingwavelabs/risingwave/pull/6253.

cc @huangjw806 any ideas?

The above method seems to be effective, buildkite supports uploading and downloading of artifacts, but buildkite does not seem to support triggering CI like github actions when PR is closed or merged, I will try to consult the official to see if there is any solution .

Hi @huangjw806, is there any update from their side?

Unfortunately, Buildkite currently does not trigger CI steps when merging or closing a PR. I wonder if I should put unit-test back into the main pipeline, which seems to be cheap.

Unit-test takes about 7 job minites. How much does it additionally cost? 🤔

Well, what about using GHA to run unit tests on main and upload codecov reports? 😄

Unit-test takes about 7 job minites. How much does it additionally cost? 🤔

Our current buildkite service is free, and the main cost is in aws ec2. We use spot instance, so the cost will not be too much.

Well, what about using GHA to run unit tests on main and upload codecov reports?

If we use the GHA machine to run the unit-test, I guess it should be slow.


Update URL of "ESPLogger"

Resolves (partially) https://github.com/arduino/library-registry/issues/1557

The validation failure is expected, caused by the name change done at the same time as the URL change. That will be resolved by https://github.com/arduino/library-registry/pull/1560.

@ArduinoBot

The ArduinoLint check is expected to fail since it checks the current library_index.json which needs an engine run to be updated

Solved in https://github.com/arduino/library-registry/pull/1560#issuecomment-1178711002


Can someone explain Login flow for apache Superset and the files involved

Make sure these boxes are checked before submitting your issue - thank you!

[ ] I have checked the superset logs for python stacktraces and included it here as text if any
[ ] I have reproduced the issue with at least the latest released version of superset
[ ] I have checked the issue tracker for the same issue and I haven't found one similar

Superset version
Expected results
Actual results
Steps to reproduce

Authentication and authorization is implemented by flask app builder.


org-mode: align list items in mixed-pitch-mode

This pull request fixes the alignment of list items in org-mode when using mixed-pitch-mode or similar modes like doom's zen mode. It does so by giving the space characters before the list bullet item and the single space after the bullet item the org-indent face.
Org buffer with standard fixed-pitch font:

Org buffer with doom's zen mode activated before the patch:

Org buffer with doom's zen mode activated after the patch:

Makes sense to me. Thanks for your help!


'MistralConfig' object has no attribute 'num_local_experts'

I have the Transformers from git and also installed vllm from git. I am trying to get the model up and running: https://huggingface.co/DiscoResearch/DiscoLM-mixtral-8x7b-v2
2023-12-11 10:12:18 | ERROR | stderr |   File "/project/vllm_git/vllm/worker/model_runner.py", line 36, in load_model
2023-12-11 10:12:18 | ERROR | stderr |     self.model = get_model(self.model_config)
2023-12-11 10:12:18 | ERROR | stderr |   File "/project/vllm_git/vllm/model_executor/model_loader.py", line 117, in get_model
2023-12-11 10:12:18 | ERROR | stderr |     model = model_class(model_config.hf_config, linear_method)
2023-12-11 10:12:18 | ERROR | stderr |   File "/project/vllm_git/vllm/model_executor/models/mixtral.py", line 469, in init
2023-12-11 10:12:18 | ERROR | stderr |     self.layers = nn.ModuleList([
2023-12-11 10:12:18 | ERROR | stderr |   File "/project/vllm_git/vllm/model_executor/models/mixtral.py", line 470, in
2023-12-11 10:12:18 | ERROR | stderr |     MixtralDecoderLayer(config)
2023-12-11 10:12:18 | ERROR | stderr |   File "/project/vllm_git/vllm/model_executor/models/mixtral.py", line 416, in init
2023-12-11 10:12:18 | ERROR | stderr |     num_experts=config.num_local_experts,
2023-12-11 10:12:18 | ERROR | stderr |   File "/usr/local/lib/python3.10/dist-packages/transformers/configuration_utils.py", line 265, in getattribute
2023-12-11 10:12:18 | ERROR | stderr |     return super().getattribute(key)
2023-12-11 10:12:18 | ERROR | stderr | AttributeError: 'MistralConfig' object has no attribute 'num_local_experts'

The model linked above was a preliminary implementation. Use the weights at https://huggingface.co/mistralai/Mixtral-8x7B-v0.1 instead. While I am working on making the DiscoLM version compatible, it is not the official implementation.

DiscoLM compatible version https://github.com/0-hero/vllm-mixtral/tree/main

Please use the official version of Mixtral like Mixtral-8x7B-v0.1 instead.


Fix(Revit) : add curtain panel class with ToNative implementation to avoid converting as displayable object

⚠ WARNING
This PR and #2912 fix the same issue in different ways. Only one of them should be merged

In the case of receiving curtain walls, where the parent wall (1) is convertible and (2) has panel and mullion objects inside the elements property that should not be created, we needed a way to skip the conversion of these elements in the connector.
This implementation includes:

a new RevitCurtainWallPanel object that is just a RevitElement
implements PanelToNative which just skips converting to native

Updated the PR description to clarify this is option 2 of 2

⚠ WARNING
This PR and #2912 fix the same issue in different ways. Only one of them should be merged

Set as "Ready for Review" as per our conversation yesterday. @teocomi feel free to check it out and leave any extra comments if need be.


nodeobservability: use controlled ownerref for daemonset

DaemonSet's owner reference now has the controller set to true which allows to trigger the reconciliation. This helps with the cases when the daemonset was removed.

/lgtm

/retest
/label docs-approved
/label px-approved
/label qe-approved


Update to the new lightweight aws-lambda-java-events release

Update to the new lightweight aws-lambda-java-events release
This PR updates the aws-lambda-java-events library to the latest 2.0 version. The 1.0 release series ends up including full parts of the AWS Java SDK (e.g. all of S3 SDK, all of Dynamo, etc) just so you can get some of the event types in. This is really unfortunate if you are building a lambda that doesn't even process events, or events from those specific AWS sources. AWS corrected this with the 2.0 release to help us make our lambda Jar's smaller.
No code change needed by users of this library - they just might have to import certain AWS sdks' themselves now. See: https://github.com/aws/aws-lambda-java-libs/tree/master/aws-lambda-java-events#aws-lambda-java-events-v20
FYI: The old event library was importing the org.apache.http.HttpStatus path - which is why I had to remove that and just provide a static 500 value instead. Hope you don't mind - this is all in the name of saving some latency time on lambdas by reducing the final jar size!
Thanks for this sweet library!

Thanks @rmmeans for taking time to make this PR! Of course I don't mind getting rid of org.apache.http.HttpStatus.


Documentation site using Hakyll

Desired content structure

Guides - each guide gets an independent page

Chapters - each chapter gets an independent page

Sections - each section gets an independent page

Sub-sections - subsections do NOT get an independent page

Possible ways of filling out this content structure:

GUIDE Comparing DB libraries in Haskell

CHAPTER Setting up basic DB mappings

SECTION Opaleye

SUBSECTION Creating the DB
SUBSECTION Strange polymorphic records
SUBSECTION Different types for reads and writes

SECTION HRR
SECTION Persisten

CHAPTER Setting up advanced DB mappings

SECTION Opaleye
SECTION HRR
SECTION Persisten

CHAPTER Inserting rows

SECTION Opaleye
SECTION HRR
SECTION Persisten

GUIDE Comparing UI libraries in Haskell

CHAPTER Basic "Hello world" app

SECTION Reflex-FRP
SECTION Purescript+Pux
SECTION Reflex-React

CHAPTER Creating form elements

SECTION Reflex-FRP
SECTION Purescript+Pux
SECTION Reflex-React

CHAPTER Form validations

SECTION Reflex-FRP
SECTION Purescript+Pux
SECTION Reflex-React

GUIDE Comparing Web libraries in Haskell
GUIDE Building a webapp using X

Desired sitemap

Homepage - will have some static introductory content, and a list of guides.
Guide pages - will have some static introductory content, and the list of chapters, along with each chapter's section. Each chapter's section will actually be a separate webpage. However, subsections will be second-level headings within the section page (and not separate pages in their own right).
Section pages - complete content of the section (including all subsections), along with:

breadcrumbs
quick switcher to jump between various chapters & sections. Reference Guides index on http://guides.rubyonrails.org

Other requirements

Ability to include content of any other partial inside markdown posts. Ref: http://stackoverflow.com/questions/40712920/how-to-use-partials-inside-markdown/40713294#40713294 We will be putting complete code snippet in separate HS files and compiling them as part of the site build process to ensure that they compile properly.
An extra command, say stack exec site builcode which builds all the referenced/included HS files to ensure that they compile correctly.
Import the following Jekyll theme to Hakyll: TODO

@meditans @mgmeier @wz1000 @sras looking for some feedback here. Planning to kickstart the documentation process and finishing off documentation for what we've done till now, before moving on to the next set of things.


Features in TGit -> TGit doesn't work when is no active document`s tab.

When i try to use features from TGit -> TGit occurs an error "Object reference not set to an instance of an object". It's not happen if there is active document`s tab.

All those menu items are file specific operations and can not work without an active document. The new release 4.7 now correctly disables those items when no file is opened


Add cohorts to sample_metadata()

resolves #94
Adds cohorts_analysis parameter to sample_metadata(), defaults to latest cohorts analysis. This adds the cohort metadata columns to the sample_metadata() output.
PR also adds tests.

Nice one :snake:


Fill/truncate data to fit with width/height given

This prevents from someone not giving enough data, then crashing at runtime because non existent data was accessed.
In the future possibly we could make this crash in debug mode, but keep working in release.

I would strongly prefer just returning Option or Result rather than enabling bad behaviour

Okay, should I roll back and send a new pr or just append to this?

Either is ok. The caller can then implement this kind of code if required

Okay, it's done.

Cool, thanks


daemon: Skip devices without hardware address during device detection

We need NodePort and direct routing devices to have a MAC address. If they don't, init.sh fails with the following error:
level=warning msg="+ for NATIVE_DEV in ${NATIVE_DEVS//;/ }" subsys=datapath-loader
level=warning msg="++ cat /sys/class/net/lo/ifindex" subsys=datapath-loader
level=warning msg="+ IDX=1" subsys=datapath-loader
level=warning msg="++ ip link show lo" subsys=datapath-loader
level=warning msg="++ grep ether" subsys=datapath-loader
level=warning msg="++ awk '{print $2}'" subsys=datapath-loader
level=warning msg="+ MAC=" subsys=datapath-loader
level=error msg="Error while initializing daemon" error="exit status 1" subsys=daemon
level=fatal msg="Error while creating daemon" error="exit status 1" subsys=daemon

Thus, we need to skip auto-detected devices that don't have a MAC address. This commit implements that and was tested by injecting a loopback interface with an IP address in the code, in the dev. VM:
loAddr, err := netlink.ParseAddr("<IP_ADDRESS>/32")
if err == nil {
    loAddr.LinkIndex = 1
    addrs = append(addrs, *loAddr)
}

Fixes: #12228
Fixes: #12304
Fixes: #11894
/cc @brb
Fix failure to start agent when detected devices don't have hardware addresses

test-me-please

Coverage increased (+0.005%) to 36.94% when pulling 29f5e313bf903e376d27c6332d5408e3f1d0eb07 on pr/pchaigno/device-detection-skip-no-hw-addr into 48f8e7996d7d3031410877326267b6650bf7fbb4 on master.

Were you able to reproduce this locally to validate the fix?

Were you able to reproduce this locally to validate the fix?

Yes, I reproduced by adding a bit of code to inject a loopback device with an IP address such that it would be selected by the device detection (see tested by injecting a loopback interface with an IP address in the code, in the dev. VM in OP). I got the same error as reported by users. With this fix applied, the loopback device is excluded from detection, enp0s8 selected instead, and there is no error.
If preferred, I think I would be able to reproduce without adding code now that I understand the different steps of the device detection (I need to set a specific IP address to an interface with an index higher than enp0s8 I think; otherwise it's overwritten).

LGTM, we can revisit adding support by adding a all-zero HW address later (plus checking that redirect does the right thing).

One thing that's important to note here is that I expect Cilium will still fail to start if a user explicitly configures a device without a HW address. This PR only fixes the detection.
My rationale is that excluding devices without HW addresses is a good way to avoid corner cases. If a user purposely wants to use a device without a HW address (common case is WireGuard), they should set it explicitly and we will need to provide a proper fix such as the all-zero HW address you mention.
There's a bit more work required for that fix (in particular, need to reproduce and maybe document) and I wanted to get the device-detection fix out quickly since a lot of users seem to be hitting that. Maybe I should also exclude devices explicitly set by users if they don't have a HW address now? Unless we expect to have a fix for that soon and it's not worth it?

I agree with fixing the auto-detection for most users where they're just incidentally hitting this without explicitly specifying devices, hence why I'm happy to get this in as-is.
In a lot of cases today, Cilium will fail out early to help signal to users that the configuration is wrong. In this case, I think the detection is actually too late and the log messages uninterpretable so at the minimum it'd be nice to add such a check to the --devices side of this to explicitly check and fail out with a clear message. It could certainly be argued that we could instead warn loudly in the logs and push through without configuring on such devices, I guess it depends on how explicitly we expect users to be specifying such devices.


Commit b1935c97

I'm having issues with 'ap.save_wav(wav, out)' on line 117 of TTY.py with commit b1935c97 from my initial research, it looks like the import for scipy in b1935c97 is scipy.io and not scipy.io.wavfile which throws an error when trying to generate an audio file.  Any suggestions?
It appears to be related to this: https://github.com/mozilla/TTS/pull/478

I ended up forking TTS, fixing the imports and then updating the docker file to point to my fixed commit.


[Snyk] Security upgrade react-dev-utils from 10.2.1 to 11.0.3

Snyk has created this PR to fix one or more vulnerable packages in the `npm` dependencies of this project.
Changes included in this PR

Changes to the following files to upgrade the vulnerable dependencies to a fixed version:

package.json
package-lock.json

Vulnerabilities that will be fixed
With an upgrade:

Severity
Priority Score (*)
Issue
Breaking Change
Exploit Maturity

482/1000  Why? Proof of Concept exploit, CVSS 7.5
Prototype Pollution SNYK-JS-IMMER-1019369
Yes
Proof of Concept

(*) Note that the real score may have changed since the PR was raised.

Commit messages

Package name: react-dev-utils
    The new version differs by 169 commits.

f92c37a Publish
cce32fa Update CHANGELOG
f710976 Prepare 4.0.3 release
6947896 update immer to 8.0.1 to address vulnerability (#10412)
18b5962 Upgrade eslint-webpack-plugin to fix opt-out flag (#10590)
9722ef1 Bump webpack-dev-server 3.11.0 -> 3.11.1 (#10312)
3f5dea9 tests: update test case to match the description (#10384)
9c75260 Publish
32c06e6 Prepare 4.0.2 release
b9963ab Add opt-out for eslint-webpack-plugin (#10170)
8fa0a26 Add support for new BUILD_PATH advanced configuration variable (#8986)
6a39607 appTsConfig immutability handling by immer (#10027)
d229676 Fix CI tests (#10217)
c9a24db docs: add missing override options for Jest config (#9473)
0f6fc2b Update using-the-public-folder.md (#10314)
a504e9d fix(react-scripts): add missing peer dependency react and update react-refresh-webpack-plugin (#9872)
282c03f Remove references to Node 8 (#10214)
3968923 Revert "Update postcss packages" (#10216)
e039ad3 Move ESLint cache file into node_modules (#9977)
6dce3f4 Upgrade sass-loader (#9988)
54ad467 Recovered some integration tests (#10091)
580ed5d Update postcss packages (#10003)
8f2413e Improve vendor chunk names in development (#9569)
723224f Upgrade @ svgr/webpack to fix build error (#10213)

See the full diff

Check the changes in this PR to ensure they won't cause issues with your project.

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open fix PRs.
For more information:
🧐 View latest project report
🛠 Adjust project settings
📚 Read more about Snyk's upgrade and patch logic

I will trigger a new batch of security fixes from Snyk dashboard


Improve handling of boolean properties

var {icon,, ...others} = this.props;

    if (spin) {
      others['spin'] = true;
    }

is not enough, for example if i have <icon spin /> and an <icon />, react does its change algorithm and sees no changes for real, so what we actually have to do is something like that:
componentDidUpdate() {
    super.componentDidUpdate();
    var node = ReactDOM.findDOMNode(this);

    if (!this.props.spin && node.hasAttribute('spin')) {
      node.removeAttribute('spin');
    }
  }

I guess this solved by doing
others.spin = spin || null;

yeah or using the Util functions, just a reminder that i will need to
refactor.
2016-05-03 13:38 GMT+09:00 Andreas Argelius<EMAIL_ADDRESS>
I guess this solved by doing
others.spin = spin || null;
—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
https://github.com/OnsenUI/react-onsenui/issues/10#issuecomment-216433553


SAMZA-1183: Fix flaky tests in TestAsyncRunLoop

Changes:

Moved all states locally within the test methods(no global state, since tests can be run parallely).
Increased the timeout waiting for all task threads to finish.
Changed message chooser mock to return null at the end(When EOS message is used a final msg, during some runs task.process gets invoked more than once for it. This is due to test setup, other tests within this test class also do the same.)

How was it verified:
Ran the test class repeatedly to check for failures(there were none) using following script.
 while [ $i -lt 30 ] do     sleep 3;     i=expr $i + 1;     ./gradlew :samza-core:clean :samza-core:test -Dtest.single=TestAsyncRunLoop  done

@xinyuiscool @navina
Please take a look when you get a chance.

(When EOS message is used a final msg, during some runs task.process gets invoked more than once for it. This is due to test setup, other tests within this test class also do the same.

Why does the test setup invoke task.process more than once when EOS message is used?
Isn't SAMZA-1183 supposed to address testProcessInOrder test as well that was commented out?

@navina

Isn't SAMZA-1183 supposed to address testProcessInOrder test as well that was commented out?

Ideally, sync commit tests(testProcessInOrder) shouldn't be affected. Code associated with them aren't modified for ages. @xinyuiscool can correct me here, if i'm wrong. Despite that we're seeing failures. Success/Failure of individual tests depends upon proper initialization of shared global state in before method.  In parallel execution of tests, assignments can get interleaved leading to race conditions.
As a fix I've moved object hierarchy construction to individual test methods & local build's green.

Why does the test setup invoke task.process more than once when EOS message is used?

I should have phrased that better.
There's a lag between processing last message & shutting the executor down in tests(This was allowed since in some runs executor is shutdown before task threads complete). Due to which, the last value returned by the mock will be the value it returns throughout the lag period(this is how mocks work). So it keeps on hitting task.process method with that EOS message. When chooser returns null as last value, AsyncRunLoop doesn’t hit task instances(hence the change).

Build is successful here : https://builds.apache.org/job/samza-pr-checks/171/
When we restart it, git-jenkins plugin doesn't update here properly.

As a fix I've moved object hierarchy construction to individual test methods & local build's green.

Whether the test has been modified recently or not, a failure is something we need to fix. By moving the object hierarchy construction, are you also addressing the testProcessInOrder failures? That is my question.

There's a lag between processing last message & shutting the executor down in tests(This was allowed since in some runs executor is shutdown before task threads complete). Due to which, the last value returned by the mock will be the value it returns throughout the lag period(this is how mocks work). So it keeps on hitting task.process method with that EOS message. When chooser returns null as last value(instead of EOS), AsyncRunLoop doesn’t hit task instances(hence the change).

I have tried to condense your verbose comment into what I understand - Basically, the mock consumer used was causing the EOS to be delivered more than once, when the executor was shutdown before task threads complete.
Hence, my follow-up question is - Why is the executor shutdown before the tasks complete? Is that the expected behavior?

@navina
Discussed with you offline.

By moving the object hierarchy construction, are you also addressing the testProcessInOrder failures? That is my question.

Code & tests associated with it are unchanged for very long time, hence surprising to see failures. Yes, it will fix it(no common global state shared by test methods which is potential cause).

Why is the executor shutdown before the tasks complete? Is that the expected behavior?

Yes, task threads might take more time to finish. Shutting down executor before it, will cause assertion failure(depending upon the timing of events). The change I want to test is AsyncTaskState state transition, however everything within AsyncRunLoop(AsyncTaskState) is private(Changing that would be harder) and all other tests follow the same pattern. Modifying them would be a harder & bigger change(may be we can create a JIRA for it to work in future)

@xinyuiscool  Removed physical wait(Thread.sleep) from TestAsyncRunLoop. Build is red due to  TestJmxReporter failures(unrelated to this change)

@shanthoosh This doesn't remove the wait, only the Thread.sleep(). I still see callbackExecutor.awaitTermination(600, TimeUnit.MILLISECONDS);.

@prateekm
You're right.
Removing callbackExecutor.await from all tests & testing just the behavior, if i understand right would involve the following changes.

Changing access specifier for testable internal class/methods to protected.
Changing all tests(which do this) in TestAsyncRunLoop to achieve uniformity.

Is it okay to create JIRA & solve it later.

Is it okay to create JIRA & solve it later.
The goal of the JIRA is to fix the tests (flaky or not) in TestAsyncRunloop. I don't see a lot of value in postponing this task in yet another "fix test" JIRA. I would rather implement the right fix now rather than later, while we have context on what the correct implementation is.

@navina

The goal of the JIRA is to fix the tests (flaky or not) in TestAsyncRunloop. I don't see a lot of value in postponing this task in yet another "fix test" JIRA.

The goal was to actually fix the flaky test as described in the JIRA.
However, it makes sense to remove awaitTermination(physical wait) here(since it will wait 'x' seconds every time, even though all the task threads finishes before that within the test).
I've an idea(which I think will work), will discuss it with xinyu(since it will touch all tests in this class) and update it here.

I've an idea(which I think will work), will discuss it with xinyu(since it will touch all tests in this class) and update it here.

Sounds good. Let's not carry over tech-debts. Thanks 👍

@navina
Please take a look when you get a chance.


Update CHANGELOG.md

Updates the changelog for PRs that were merged before we instituted the PR-must-update-the-changleog policy :)

@beckjake also merging this one... finally


Using locust to query Cassandra

Hi,
I'm trying to run queries on Cassandra using locust but get blocking issues when locust tries to connect to the cluster. It works well when I do it without locust. Any reason why locust would make it fail ?  Any workaround ?
https://pastebin.com/QxuiEpu6
https://pastebin.com/BJFkdE2q

What does "blocking issues" mean?
The only thing I can think of on top of my head is if gevent's monkey patching somehow messes with the Cassanda drivers (though this seems to indicate that the cassandra lib should work fine with gevent: https://github.com/datastax/python-driver/pull/46)
What happens if you add the following to the top of the non-locust python file?
from gevent import monkey
monkey.patch_all(thread=False)

@heyman, by blocking I mean the locust web interface can't refresh  for instance. Adding your snippet doesn't help.

@cscetbon The snippet was not intended to fix the problem. I wanted you to add it to the top of the non locust version that's currently working, to see if that would cause the same problem as you have when using the Cassandra client with Locust. Then we would know that the problem is related to gevent's monkey patching.
Does the web interface load at all? Are there other issues (since you write "for instance")? For me to be able to understand the issue, you really need to be as specific as possible.

@HeyHugo I don't have any non locust file. Are you talking about the python module I use ? I have only one locust file, the one I sent you.
The interface loads, it's when I start the load with 4 users in my case and Hatch of 1 that it starts blocking. Reloading the app doesn't work anymore, I think if I wait I'll get a timeout error instead

@cscetbon I meant this one: https://pastebin.com/QxuiEpu6
To me it sounds as if this could be related to issues with the minkey patching not being used, e.g. if the Cassandra drivers doesn't use the builtin python socket lib for IO.
Do you see any exceptions/other output from Locust? What happens if you add some print statements to your code. Where does it block?

okay, so adding it to the non locust file doesn't have any impact.
Locust blocks on self.session = cluster.connect("demo")
The only output messages I get  are :
[2017-04-03 10:44:14,284] ELIA.local/INFO/cassandra.policies: Using datacenter 'datacenter1' for DCAwareRoundRobinPolicy (via host '<IP_ADDRESS>'); if incorrect, please specify a local_dc to the constructor, or limit contact points to local cluster nodes
[2017-04-03 10:45:44,482] ELIA.local/WARNING/cassandra.connection: Heartbeat failed for connection<PHONE_NUMBER>) to <IP_ADDRESS>
[2017-04-03 10:47:14,530] ELIA.local/WARNING/cassandra.connection: Heartbeat failed for connection<PHONE_NUMBER>) to <IP_ADDRESS>
[2017-04-03 10:48:44,558] ELIA.local/WARNING/cassandra.connection: Heartbeat failed for connection<PHONE_NUMBER>) to <IP_ADDRESS>
[2017-04-03 10:50:14,587] ELIA.local/WARNING/cassandra.connection: Heartbeat failed for connection<PHONE_NUMBER>) to <IP_ADDRESS>

So I suppose that something in locust prevents it to connect.

I'm having the same problem. Using the same code on the same host in a python script outside of locust, it connects fine. Using it inside locust gives me the exact same errors @cscetbon is seeing on the connect call. I can't figure out what's different about using the cluster client inside locust.

Same issue here :|

I'm having some problems with connection to other database. This commit https://github.com/gemius/locust/commit/a705ba489272cba1856e504a3dfe82c8ebd887a0 fixed my issue, bu it does not guarantee that it is the same case.

Hi,
Same issue here. With locust any cassandra operation that requires connection to DBMS hangs the whole interpreter (sometimes it needs to be killed with -9). Without locust it works just fine. Also, adding the code snippet from @heyman to non-locust version doesn't affect the cassandra driver.

The patch from @grucin doesn't work for me.

Also, running:
from gevent import monkey
monkey.patch_all(thread=True)

does fix the issue. Why Locust doesn't patch threads? What are the implications of overriding this?

@rslota when I use it tests are executed but statistics are not updated. Is it better for you ?

@cscetbon ,
Yeah, when I patch at least threads (but currently in my code I just patch everything - monkey.patch_all() everything works great. No stability issues and all statistics seem to be just fine. But... I don't load test HTTP, I have my own "drivers" to load several DBMS, so I fire success and failure events in locust manually (with my own time measurements), so maybe that's the reason I don't have issue you are seeing.

I really don't remember if there was a good reason for not patching threads (I should have left a comment). It was made in the very early days of the development, and it's very possible that we just simply didn't use any threads at the time. Therefore I suggest that we change it to patch everything since people have reported that it seems to work fine.

I've now changed so that we also patch threading. It's released in the latest version on PyPI (0.8a4).


Glitch hosting

Hey there, I saw you moved this to Glitch, perhaps after seeing me do so on https://github.com/mbrock/telegroam/pull/31.
We've made a change that is going to make these projects unhostable on Glitch for the time being - I'm going to look for a solution that will still be Glitch-hostable.
Apologies for the inconvenience!

Yeah I just saw there was some issues with my glitch hosting. I'm curious, what changed?

Hello! We made an overbroad change to some automated processes, but we discussed this today and agreed on an alternative - i believe you also heard from Support about it - your project should be all set again!
Sorry for the bother!


Cloudflare will automatically re-verify all the time

Hi,
Version 1.9.2
I've got a issue.
Cloudflare will automatically re-verify all the time
Example Websites
https://www.dcard.tw/

Hello.
Regarding the Cloudflare bug, where in CSLT is it occurring?
I would appreciate a screenshot if you don't mind.

Thanks for the info.
CSLT does not interfere with dcard.tw at all so it does not appear that this extension is causing the Cloudflare challenge.
CSLT only works with twitter.com.

Maybe I misunderstood the plug-in. Sorry.

Don't worry about it.
I live in Japan and when I accessed dcard .tw I got a Cloudflare challenge, so I think the service itself is restricting access.


feat(utils): enable language checkpoint

see https://cq-dev.slack.com/archives/C07198KKQ07/p1725350425871959

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

v2.28.0
v2.28.0
GitHub release

Your semantic-release bot :package::rocket:


Consider evaluating cloud-agnostic PubSub alternatives

We currently use PubSub GCP service as our delivery transport, but it may be an issue for developers that do not use GCP at all. Maybe we should consider looking at cloud-agnostic PubSub alternatives.
Here is one of the products that look promising: PubSub+ Platform by Solace. (here is their datasheet)
It's possible to use their platform both on-prem and as a SaaS. Maybe using them as our default delivery transport will make the framework more attractive to non-GCP developers.

I don't think we'd make them our default transport. But it does look like a good integration solution for non-GCP or multi-cloud systems.

Here is one another alternative we may want to take into account: https://pulsar.apache.org/

Closing as irrelevant to the framework. We do not provide any default implementation at the moment and hardly will.


Using conda-build-all for building the master branch

Hi Phil,
My use case here is to have a git repo full of dev recipes where the repo is set up with circleci and conda-build-all to compare the dev recipes in the aforementioned git repo with the conda packages on my dev channel on anaconda.org and only build ones with commits in master (and therefore new version numbers).
However, if I use any of the GIT_* info in a conda-recipe, conda-build-all is unable to correctly interpret the version string to compare against the built packages on anaconda.org/user_name.
The following recipe is a relevant snippet from a master branch meta.yaml:
package:
  name: metadatastore
  version: {{ environ['GIT_DESCRIBE_TAG'] }}.post{{ environ['GIT_DESCRIBE_NUMBER'] }}

source:
  git_url: https://github.com/NSLS-II/metadatastore.git
  git_rev: master
  # use a local url and leave rev blank to have conda build current head, currently
  # requires master branch of conda-build to work
  # git_rev: ?

build:
  string: {{ environ.get('GIT_BUILD_STR', '') }}_py{{ py }}
  number: 0
--snip--

which conda-build-all interprets as
Resolved dependencies, will be built in the following order:
	metadatastore-.post-_py27 (will be built: True)
	metadatastore-.post-_py34 (will be built: True)
	metadatastore-.post-_py35 (will be built: True)

Is it within the scope of conda-build-all to be able to recognize a meta.yaml has GIT_* info inside it and attempt to figure out what the build string should be?  As this is a feature that would make my life loads easier, I am happy to work on adding this to conda-build-all.  I would imagine that it would have to go something like:

check recipe for presence of GIT_* env vars
clone git repo from source.git_url
check out source.git_rev
git describe to get the exact version string
Interpret the git describe in the context of the meta.yaml
Check to see if that version exists on anaconda.org/channel-of-interest and then build or don't depending on if the version exists already on anaconda.org

This is non-trivial and is certainly not guaranteed to work in all situations, but would potentially let conda-build-all be used for continuous delivery.

but would potentially let conda-build-all be used for continuous delivery.

Since these are Python packages, have you taken a look at using the setup.py information for versioning? For instance, the conda-build-all recipe does allow building from git, but only because conda-build-all's version is computed by versioneer (which itself inspects git for clones).

In principle, I have no problem with supporting the GIT variables, but as you say, it may very well get complex quick, so I'm interested to learn if the GIT_ approach allows functionality that isn't already possible with conda.

Turns out that this can be solved by adding two lines to conda-build.
$ git diff HEAD~ HEAD
diff --git a/conda_build/main_build.py b/conda_build/main_build.py
index 88888c7..5c17142 100644
--- a/conda_build/main_build.py
+++ b/conda_build/main_build.py
@@ -361,6 +361,10 @@ def execute(args, parser):
                     print("%s is already built, skipping." % m.dist())
                     continue
             if args.output:
+                source.provide(m.path, m.get_section('source'))
+                # Parse our metadata again because we did not initialize the source
+                # information before.
+                m.parse_again()
                 print(build.bldpkg_path(m))
                 continue
             elif args.test:

Now let's see if I can get this (or something similar) merged into conda-build master!

This is conda/conda-build#750 if you want to follow the discussion there


Rust: Use rayon and better performance

This PR introduces a bunch of changes that target at better performance and higher code quality.

Rayon
Rayon doesn't always result in better performance than manual thread management (see https://github.com/rayon-rs/rayon/issues/1124), but changes in this PR do result in higher performance.
There are many great benefits to rayon though in the way it is used:

safe API, previous thread pool usage was either unsound or sound by accident (comments were claiming things like:

// Bypass 'lifetime limitations by brute force. It works,
// because we explicitly join the threads...

Which while worked by accident, was a lie (nothing was actually joined in most cases, but worked in practice due to use of channels to send work back to the parent thread), fundamentally unsound API (parent thread panic would result in worker threads accessing undefined memory location) and generally a major foot gun for anyone who would try to change the code in any way.

support for customizing number of threads using environment variables

support for customizing number of threads and their pinning to CPU cores depending on thread pool from which operations are called (by default global thread pool is used and default behavior is equivalent to old code)

avoid conflicting/overlapping with other threads if used from within parallel code that already uses rayon

no need to special-case platforms like WASM, if specific WASM environment supports threading, blst will now enjoy it automatically

Various cleanups
I changed all but one channel usage with a cleaner code using Mutex, Arc usage was removed as unnecessary and some other bookkeeping was cleaned up after understanding what code does and rewriting intention in more idiomatic Rust code (see fn from for example). The only place where channel still remains is fn mult, but it is quite difficult code and I didn't have the will to decipher what it tries to do to get rid of channel, but hopefully examples in this PR will prompt someone to clean it up at some later point.
Some unsafe blocks with vec.set_len() are moved after memory is actually initialized and some questionable in terms of soundness places were refactored such that they are quite obviously sound now. Some remaining places can also be fixed, but require pointer arithmetic that might require newer versions of Rust, so I left TODOs there.
I also took liberty to refactor things like &q[0] to q.as_ptr() since while both result in the same pointer, the former is deceptive because it suggests to the reader that only the first element is used, while in practice the whole q is used by the function that is being called later (documentation is almost non-existent, so it wasn't obvious at first and I hope this improves readability).
no-threads
no-threads was a hack and non-idiomatic because it violates "additivity" assumptions of Rust features. Thankfully it is no longer necessary and can be safely removed, but since this is a breaking change (the only one in this PR to the best of my knowledge), I bumped crate version from 0.3.11 to 0.4.0.
How to review this PR
This PR is split into self-contained logically structured commits and it is recommended to review commits one by one instead of the complete diff, this way it is much easier to understand what was changed and why.
Let me know if there are any questions, happy to explain each line change in detail.

The issue with Rayon or any dependencies is that it brings a lot of new dependencies that need to be audited or at least vetted. This is very undesirable in a cryptographic product securing billions of assets. It is especially critical when supply chain attacks are increasing in appeal.
Furthermore, a simple threadpool written with cryptographic/security application in mind and fully control by the dev is significantly easier to maintain and update if there is a security issue.

The issue with Rayon or any dependencies is that it brings a lot of new dependencies that need to be audited or at least vetted. This is very undesirable in a cryptographic product securing billions of assets. It is especially critical when supply chain attacks are increasing in appeal.

rayon is a well known established library with short list of mandatory dependencies and it used by Rustc itself, so it is not like you're adding a lot of new stuff here.

Furthermore, a simple threadpool written with cryptographic/security application in mind and fully control by the dev is significantly easier to maintain and update if there is a security issue.

I generally agree with you on this one. However, as I have shown in the description already, there were some questionable decisions from soundness point of view around thread pool as it was used and performance was lower than it could have been.
You 100% can rewrite original code and make it faster without rayon, achieving rayon's features in a safe misuse-resistant way is non-trivial and I'd rather use something that it maintained by Rust experts for this purpose (check top contributors to rayon project, they are literally working on Rust itself) than seeing every library invent their own a bit flawed version of the same features that doesn't integrated as well with the rest of Rust ecosystem.
I would estimate risk of relying on rayon as very low, but decision is up to blst maintainers of course.

Just confirmed that performance improvements here translate to performance improvements downstream in our usage usage of https://github.com/sifraitech/rust-kzg (uses blst) in https://github.com/subspace/subspace, both of which also take advantage of Rayon as well.

Just confirmed that performance improvements here translate to performance improvements downstream in our usage usage of https://github.com/sifraitech/rust-kzg (uses blst) in https://github.com/subspace/subspace, both of which also take advantage of Rayon as well.

I don't know whether commitment, proof generation or verification is the bottleneck for your use-case but @sauliusgrigaitis might be able to point you on how to best use rust-kzg, i.e. either through native BLST or reimplemented+parallelized BLST (i.e. using their own multithreading strategy).
Also they've been working on a new set of benchmarks. I have my own in https://github.com/mratsim/constantine/pull/304#issuecomment-1844795359, but I don't cover parallel BLST.

@dot-asm is there something I can do to interest you reviewing this?

This os honestly frustrating. There are merge conflicts again and not review for clear performance and API improvements in half a year :confused:
@dot-asm any chance you can look into this any time soon? Any feedback at all would be nice.

As correctly suggested by @mratsim the threadpool was chosen for having minimum dependencies. Another important reason is that the parallelization pattern is used in both Rust and Go bindings. As a way to minimize the maintenance cost. I mean we only need to understand one pattern and solving problems applies to both implementations. It also gives better control by being more predictable. For example consider
use std::sync::atomic::*;

fn main() {
    rayon::spawn(move || {
        loop {}
    });
    let counter = AtomicUsize::new(0);
    rayon::scope(|scope| {
        scope.spawn_broadcast(|_, _| {
            println!("{}", counter.fetch_add(1, Ordering::Relaxed));
        });
    });
    println!("Hello, {} cpus!", counter.load(Ordering::Acquire));
}

The keyword is that scope.spawn_broadcast never finishes here. In other words the invocations in question are dependent on the progress being made by independent threads. Which is unsustainable in real-life application context.
As for benchmark performance. It appears to be system-dependent and even circumstantial. On some systems I failed to note significant improvements. On some it's indeed better, but only marginally. On some systems I can observe significant variations from run to run with either approach, with the original occasionally outperforming the suggested approach on some points. It ought to be because of unfortunate interplay with the OS scheduler and power management... Either way, it made me dive till my eardrums ruptured and found that if modified, the threadpool can perform way better on larger systems.  In some points the difference is not as significant, in others is... If you want to test it on your system add
[patch.crates-io]
threadpool = { git = "https://github.com/dot-asm/rust-threadpool", branch = "scheduling-agility" }

to your .cargo/config.toml. It needs more work and testing before bringing it to maintainers' attention, but one can test... I mean do test :-)

As correctly suggested by @mratsim the threadpool was chosen for having minimum dependencies.

I understand the appeal of minimal dependencies, but as described above rayon is a well know library maintained by very experienced and respected engineers, so I don't think there is a huge concern in terms of either security or compilation time or other issues that are typically attribute to larger number of dependencies.

Another important reason is that the parallelization pattern is used in both Rust and Go bindings. As a way to minimize the maintenance cost. I mean we only need to understand one pattern and solving problems applies to both implementations.

This makes sense as well, but I should note that this shouldn't be a hard requirement since languages are in fact substantially different and translating code directly from one language to another can and does often lead to awkward ergonomics and even performance issues. Not to say that tricky unsafe code that only works correctly by accident is not good for maintenance, it is much easier to deal with safe code that can't lead to safety violation by definition, which is especially true during refactoring.

The keyword is that scope.spawn_broadcast never finishes here. In other words the invocations in question are dependent on the progress being made by independent threads. Which is unsustainable in real-life application context.

That code contains literally an infinite loop. It is a problem one way or another. The whole point is that those are NOT independent threads, they are specific threads on a fixed size thread pool that is context-dependent.
It is a much more flexible approach as I have described in the original post than assuming library can use all of the cores and let OS scheduler figure out where to run it or forcing all usages to use a single CPU core with nothing in between.

As for benchmark performance. It appears to be system-dependent and even circumstantial. On some systems I failed to note significant improvements. On some it's indeed better, but only marginally. On some systems I can observe significant variations from run to run with either approach, with the original occasionally outperforming the suggested approach on some points. It ought to be because of unfortunate interplay with the OS scheduler and power management...

I consider this as a good thing. Because it didn't regress and provides substantial flexibility without changing the library that are not possible otherwise. I do notice large improvements in performance from pinning threads to cores on Threadripper/Epyc and even Ryzen 7/9 CPUs in many cases (crossing chiplets and sockets is very costly sometimes), yet currently because the library uses its own independent thread pool I can't do anything about it without forking.

Either way, it made me dive till my eardrums ruptured and found that if modified, the threadpool can perform way better on larger systems. Here is a sample from a 128-core one:

Very nice! Changes make a lot of sense to me, for sensitive contexts channel is not the most efficient data structure and simple Mutex/Condvar pair is all you really need. I wouldn't be surprised if similar gains can be made in rayon as well.

The keyword is that scope.spawn_broadcast never finishes here. In other words the invocations in question are dependent on the progress being made by independent threads. Which is unsustainable in real-life application context.

That code contains literally an infinite loop.

Come on, just imagine say a socket listener instead of the infinite loop. Or replace it with sleep for a second and perform signature verification in the spawn_broadcast. Are you ok with the signature verification taking a full second? I'm not. A library simply may not bring this upon the user.

Come on, just imagine say a socket listener instead of the infinite loop.

You misunderstand what rayon is and what are the use cases for it. I'll quote the first line of their readme:

Rayon is a data-parallelism library for Rust. It is extremely lightweight and makes it easy to convert a sequential computation into a parallel one.

If you use it for socket listener you're using it wrong. Rayon is for compute-intensive work, for I/O you'll be using a regular thread or a dedicated I/O thread pool (that can in fact use rayon as well, you can run a piece of code in the context of a custom thread pool with Rayon in contrast to what blst currently does with its unconditional uncontrollable embedded thread pool). For example in our software we create custom dedicated rayon thread pools with at most 32 threads for I/O purposes even on machine with 256 hardware threads available.

Or replace it with sleep for a second and perform signature verification in the spawn_broadcast. Are you ok with the signature verification taking a full second? I'm not. A library simply may not bring this upon the user.

This is another great example of how to use the wrong tool for the job. Neither of these examples are directly applicable to what this PR does. Yes, rayon will use global thread pool by default, but you also have an option to create a custom one as described in the very first post, such that random sleeps and I/O in other parts of the app are not fundamentally blocking any work that is being done by blst. The power is in the hands of the user of the library, the power that currently released blst doesn't expose.

The examples were obviously exaggerated to illuminate the thesis that scope.spawn_broadcast is considered an inappropriate choice for this library. Because we don't make the assumption that the application makes calls from the same thread and the trouble is that faster operations get serialized by slower ones. In case you say that the current approach serializes operations too, well, not if you have say a 30-thread operation and a 2-thread operation on a 32-core system.

The examples were obviously exaggerated to illuminate the thesis that scope.spawn_broadcast is considered an inappropriate choice for this library.

Every single example you provided was a literal misuse of the library for things that it is not designed to be used for, while this PR uses it exactly for its direct purpose: relatively short-lived parallelizable compute that doesn't have sleeps or I/O, etc. I have no idea how you came to conclusion "considered an inappropriate choice for this library", I can't connect the dots :confused:
rayon is a great choice for this exact purpose and used widely from Rust compiler itself to numerous libraries in Rust ecosystem. Yes, it is probably not the way you do things in C or Golang, but Rust is not C or Golang, so why not make experience for Rust developers better?

rayon is not a generic thread pool on which you spawn random blocking tasks, it is a thread pool of a fixed size (size which you control as an application developer) in which you can control affinity of threads and other things (again as application developer) that is used to parallelize compute-intensive operations.
Being afraid that someone uses it for sockets or puts useless sleeps in rayon threads and use that as justification for using of uncontrollable internal thread pool instead is simply absurd :man_shrugging:

To give you very specific example we use blst as indirect dependency in https://github.com/autonomys/space-acres. In this desktop app we have an option to limit CPU usage to just half of the cores so user can keep the app running and not experience sluggish desktop due to high CPU utilization even though the app is still making a decent progress. Right now we use blst from a fork with this PR included so we can reduce thread pool size and pick to a specific set of cores depending on CPU topology to ensure a great user experience.
Out of probably a thousand of Rust dependencies blst is the only unique one in that it uses internal thread pool for CPU-intensive operations that we have zero control over without this PR.
If PR is not accepted we will either have to switch to upstream and affect user experience or maintain a repeatedly diverging fork with this change set in it ourselves. Neither of these options are ideal, which is why I opened a PR and tried to not only keep the performance the same, but even improve it in some cases as well as improve code quality.

Once again, if you don't assume that all calls to this library are made from the same thread, which we don't, then a spawn_broadcast call [made by this library], that otherwise takes a pair of threads and 1 ms, made 1 ms after a 5-ms otherwise 30-thread one [also made by this library] will finish in 4+ ms.
As for affinity, threadpool does take into consideration the process' affinity mask upon instantiation.

Once again, if you don't assume that all calls to this library are made from the same thread, which we don't, then a spawn_broadcast call [made by this library], that otherwise takes a pair of threads and 1 ms, made 1 ms after a 5-ms otherwise 30-thread one [also made by this library] will finish in 4+ ms.

What you're writing makes sense hypothetically in a vacuum. I already explained in this thread a few times why this is a hypothetical issue. If you really have designed an app where you have literally no idea what is running, how and where (in which case I'm really sorry), you can still create an explicit thread pool and call bslt under it to ensure no unexpected overlap with other operations:
let thread_pool = rayon::ThreadPoolBuilder::default().build().unwrap();
thread_pool.install(|| {
    // Do blst stuff on a dedicated thread pool here
});

Read the docs about it here: https://docs.rs/rayon/latest/rayon/struct.ThreadPool.html#method.install
I hope a very specific example helps to understand that you can have guaranteed dedicated thread pool if you really want it and let kernel decide what tasks to run and when.

As for affinity, threadpool does take into consideration the process' affinity mask upon instantiation.

That is not a replacement for what I'm asking, not even close. To give you another example in https://github.com/autonomys/subspace we also check topology of CPU and split work into multiple thread pools, each pinned to a specific NUMA node (mostly Intel Xeon) or CCX (on AMD Threadripper/Epyc) to ensure threads do not do expensive migration, which results in significant performance wins. All this is possible with the changes I'm proposing and impossible with the stock blst. And for some use cases we have another collection of thread pools that do kind of the same, but only utilize half of the cores in each NUMA node/CCD, so depending on use case we call .install() on one thread pool or the other.
You just can't make those decisions at the process level. You know about compute performance way more than I do, not sure why I have to explain this in so much detail.

Just to give you perspective to my claims I did benchmarks of this PR on AMD 7970X (32C64T 4 CCD).
Using all CPU cores (at the mercy of default thread scheduling):
verify_multi_aggregate/verify_multi_aggregate/8
                        time:   [1.0208 ms 1.0286 ms 1.0358 ms]
verify_multi_aggregate/verify_multi_aggregate/16
                        time:   [1.1221 ms 1.1282 ms 1.1345 ms]
verify_multi_aggregate/verify_multi_aggregate/32
                        time:   [1.3031 ms 1.3095 ms 1.3171 ms]
verify_multi_aggregate/verify_multi_aggregate/64
                        time:   [1.6318 ms 1.6447 ms 1.6579 ms]
verify_multi_aggregate/verify_multi_aggregate/128
                        time:   [2.2720 ms 2.2791 ms 2.2865 ms]

Limiting to just 1 CCD (8C16T):
verify_multi_aggregate/verify_multi_aggregate/8
                        time:   [1.2282 ms 1.2297 ms 1.2311 ms]
verify_multi_aggregate/verify_multi_aggregate/16
                        time:   [1.3055 ms 1.3060 ms 1.3067 ms]
verify_multi_aggregate/verify_multi_aggregate/32
                        time:   [1.9418 ms 1.9446 ms 1.9470 ms]
verify_multi_aggregate/verify_multi_aggregate/64
                        time:   [3.1277 ms 3.1311 ms 3.1354 ms]
verify_multi_aggregate/verify_multi_aggregate/128
                        time:   [5.7414 ms 5.7647 ms 5.7878 ms]

As you can see, depending on benchmark there is potential to do 1.5x-3.5x more work with this PR in the same app by strategically pinning CPU cores for different thread pools, which is not possible with current master.
Is there any chance this PR can be merged or am I wasting my time here?


conv2d crashes when compute gradient

Click to expand!
Issue Type
Bug
Source
source
Tensorflow Version
tf 2.9
Custom Code
Yes
OS Platform and Distribution
Linux Ubuntu 20.04
Mobile device
No response
Python version
3.9
Bazel version
No response
GCC/Compiler version
No response
CUDA/cuDNN version
No response
GPU model and memory
No response
Current Behaviour?
Session crashes when computing gradient for `tf.nn.conv2d`. For the inputs in the example below, `tf.nn.conv2d` can generate a correct (empty) output tensor with shape `(1, 16, 0, 1)`. However, when I compute gradient with GradientTape, the program crashes with error message (core dumped).

Standalone code to reproduce the issue
import tensorflow as tf
filters = tf.random.uniform([3, 3, 1, 1], dtype=tf.float32)
strides = 2
padding = "VALID"

input = tf.random.uniform([1, 34, 1, 1], dtype=tf.float32)

with tf.GradientTape(persistent=True,) as g:
  g.watch(input)
  res_backward = tf.nn.conv2d(input, filters, strides=strides, padding=padding)
print(res_backward)
grad = g.gradient(res_backward, input) # this will crash

Relevant log output
tf.Tensor([], shape=(1, 16, 0, 1), dtype=float32)
core dumped

@VictoriaGriffith I tried to replicate the issue on colab and it crashes on gpu runtime. Could you please find the gists of cpu and gpu runtime here? Please confirm the issue ?
Thank you!

@sushreebarsa yes, thanks for replicating this issue!

This could be due to the different check implementation for both CPU and GPU, could you please refer the comment here.


Some shortcuts are not working

From<EMAIL_ADDRESS>on 2015-01-26T04:29:06Z
Spyder Version:  2.3.2
Python Version:  2.7.6
Qt Version    :  4.8.6, PyQt4 (API v2) 4.10.4 on Linux
pyflakes >=0.5.0:  0.8.1 (OK)
pep8 >=0.6      :  1.4.6 (OK)
IPython >=0.13  :  2.3.1 (OK)
zmq >=2.1.11    :  14.4.1 (OK)
pygments >=1.6  :  2.0.1 (OK)
pandas >=0.13.1 :  None (NOK)
sphinx >=0.6.6  :  1.2.3 (OK)
psutil >=0.3    :  1.2.1 (OK)
rope >=0.9.2    :  0.9.2 (OK)
matplotlib >=1.0:  1.3.1 (OK)
sympy >=0.7.0   :  None (NOK)
pylint >=0.25   :  1.1.0 (OK)
What steps will reproduce the problem?

put the cursor on some line on editor and press Ctrl + 1 for comment the line (work)
after the line is in the comment press Ctrl + 5 and this doesn't work

What is the expected output? What do you see instead?
press Ctrl + 5 should be uncomment the comment line What version of the product are you using? On what operating system? linux kubuntu 14.04
more shortcuts that doesn't work is:
Ctrl+Alt+Shift+Left | last edit location
Ctrl+Alt+Right      | next cursor position
Ctrl+Alt+Left       | previous cursor position
Original issue: http://code.google.com/p/spyderlib/issues/detail?id=2140

From ccordoba12 on 2015-01-30T14:19:55Z
Summary: Some shortcuts are not working  <span class="oldvalue"> (was: some shortcut doesn't work) </span>
Labels: MS-v2.3.4 Cat-Settings

Ctrl+5 is used to remove block comments, i.e. comments of the form
#==============================================================================
#
#==============================================================================

Ctrl+1 is used to comment and uncomment a line, so there is no problem here. The other shortcuts you suggest are going to be added in pull request #2217.


Mask http core in gradle build file.

This used to be done in maven, otherwise we get conflicts between jenkins plugin and jenkins http lib versions during runtime.

Coverage remained the same at 90.646% when pulling 6c2c11598d3c9bd60855a91b8513a607c87d1a98 on mask-http-core into 6d8b44615b8112d401dc109c4bd67396a1f6de27 on master.


Seeding now follows .NET Core 2.0 best practices

Updated Main function to follow .NET Core 2.x best practices. Also changed it to async Task since it is now supported by C# 7.0+

You rock! 🙏
Much appreciated!


Respect primitve mapping on type and format attributs of 1.2 spec

Respect primitve mapping on type and format attributs of 1.2 swagger spec: https://github.com/swagger-api/swagger-spec/blob/master/versions/1.2.md#431-primitives

Thanks. This needs tests and a passing build, please.

All known problem fixed.

It would be nice to extend tests to all primitive mappings, but I would merge without. Can you squash the commits, please?

Squash and plural done.

Merged, thanks.


fix(collection): deundefined/null value when deleting array

Fixes #24

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


When working with spi again, a delay of at least 4 seconds is required.

The first time "device.transfer(message, cb)" works well, when called again "device.transfer(message, cb)" is not read or written.
I tried changing the parameters: microSecondDelay: 10 - 10000, etc.
Does not help! The only solution is to wait 4 seconds before repeating "device.transfer(message, cb)".
Cannot be used while device is polling.

device.transfer(message, cb) works fine for me. The stress test tmp.js calls device.transfer(message, cb) successfully over 500 times a second to determine the temperature using a TMP36 analog temperature sensor wired to an MCP3008 SPI A/D converter on a Raspberry Pi 2.
Here is an example of the output from tmp36.js:
pi@raspberrypi:~/test/node_modules/spi-device/test/stress $ time node tmp36
606 606 223 21.935483870967744
556 1162 223 21.935483870967744
581 1743 223 21.935483870967744
585 2328 223 21.935483870967744
585 2913 223 21.935483870967744
582 3495 223 21.935483870967744
583 4078 223 21.935483870967744
592 4670 223 21.935483870967744
592 5262 223 21.935483870967744
590 5852 223 21.935483870967744
585 6437 223 21.935483870967744
595 7032 223 21.935483870967744
599 7631 223 21.935483870967744
584 8215 223 21.935483870967744
587 8802 223 21.935483870967744
588 9390 223 21.935483870967744
588 9978 223 21.935483870967744
586 10564 223 21.935483870967744
^C

real	0m19.077s
user	0m2.968s
sys	0m2.102s

I would suggest carefully studying the datasheet of the SPI device that you wish to use to confirm that it is being used correctly.

Thank you very much for your quick response!
When cs1 is manually controlled, the second poll passes without errors.
I'm still researching the problem. I'm using a custom cs1 overlay.
My  board nanoPi Neo/
Thanks for your hard work.


feat: Implement Task Dependencies

Description
Add new fields id and blocked by
Motivation and Context
#463
How has this been tested?

Add new tests
Exploratory testing

Screenshots (if appropriate)
Types of changes

Changes visible to users:

[ ] Bug fix (prefix: fix - non-breaking change which fixes an issue)
[x] New feature (prefix: feat - non-breaking change which adds functionality)
[ ] Breaking change (prefix: feat!! or fix!! - fix or feature that would cause existing functionality to not work as expected)
[x] Documentation (prefix: docs - improvements to any documentation content for users)
[ ] Sample vault (prefix: vault - improvements to the Tasks-Demo sample vault)
[ ] Contributing Guidelines (prefix: contrib - any improvements to documentation content for contributors - see Contributing to Tasks)

Internal changes:

[ ] Refactor (prefix: refactor - non-breaking change which only improves the design or structure of existing code, and making no changes to its external behaviour)
[x] Tests (prefix: test - additions and improvements to unit tests and the smoke tests)
[ ] Infrastructure (prefix: chore - examples include GitHub Actions, issue templates)

Checklist

[x] My code follows the code style of this project and passes yarn run lint.
[x] My change requires a change to the documentation.
[x] I have updated the documentation accordingly.
[x] My change has adequate Unit Test coverage.

Terms

[x] My contribution follow this project's contributing guide
[x] I agree to follow this project's Code of Conduct

Just to say that I haven't forgotten about this... Getting sort by function good enough for release is taking much longer than I naively expected...

Having asked for this to be created with only a minimal, I've now added some info to the PR description.

Awesome work @DanielTMolloy919 - huge thanks!
❤ 🙏 🎉

Thank you so much @claremacrae!. If there's anything I can help with in the remaining work checklist, just let me know 🙂

Thank you so much @claremacrae!. If there's anything I can help with in the remaining work checklist, just let me know 🙂

Hi Danny, thank you. Two specific things that would help a lot:

if you could separate out the two new modal widgets in to a component or components. It would make the code a lot easier to maintain.
If you could review the modal-related  CSS classes added to styles.css for consistency with existing class names. Like, was there a prefix for the modal?

Those are areas outside my comfort zone, which will make it easier for me to maintain the code going forward - and I can then concentrate on the other things needed for the next release.

Yes absolutely


Bump .travis.yml to Rust 1.4.0

I'm keeping the explicit Rust version at the lowest version of Rust that nix supports. That way, dropping support for an older version of Rust is explicit.


Cannot Create Wallet

Description
Cannot Create new wallet

[X] Can you reproduce the issue?

Steps to reproduce

Try to create wallet
Get to password/pin entry

Expected behavior:
It works
Actual behavior:

Link to an example: [optional]

Versions

Mark Text version: 1.2.6
Operating system:

Just released a new version to patch this bug. v1.2.7 should allow you to create a wallet now.

yes...i have the same problem like this..

Please check that you are on the latest version. https://github.com/mymonero/mymonero-app-js/releases/tag/v1.2.7
The issue was introduced in v1.2.6 and corrected in v1.2.7


Formatted request log lines include parameters

These parameters are often fairly important, for example the
userAgent and any safe marked component in conjure definitions.
==COMMIT_MSG==
Formatted request log lines include parameters
==COMMIT_MSG==
Possible downsides?
Request log lines may be longer

:+1:

I'm getting 401s running tests locally attempting to hit packages.jetbrains.team, hopefully CI can manage :-s

Released 2.9.0


Rebase SQL 2022 02 01 dev branch

MSFT employees can try out our new experience at OpenAPI Hub  - one location for using our validation tools and finding your workflow.

Use 'Git rebase' to sync the SQL dev branch to the latest main branch.
Did not change any code.
Changelog
Add a changelog entry for this PR by answering the following questions:

What's the purpose of the update?

[ ] new service onboarding
[ ] new API version
[ ] update existing version for new feature
[ ] update existing version to fix swagger quality issue in s360
[ ] Other, please clarify

When are you targeting to deploy the new service/feature to public regions? Please provide the date or, if the date is not yet available, the month.
When do you expect to publish the swagger? Please provide date or, the the date is not yet available, the month.
If updating an existing version, please select the specific language SDKs and CLIs that must be refreshed after the swagger is published.

[ ] SDK of .NET (need service team to ensure code readiness)
[ ] SDK of Python
[ ] SDK of Java
[ ] SDK of Js
[ ] SDK of Go
[ ] PowerShell
[ ] CLI
[ ] Terraform
[ ] No refresh required for updates in this PR

Contribution checklist:

[ ] I commit to follow the Breaking Change Policy of "no breaking changes"
[ ] I have reviewed the documentation for the workflow.
[ ] Validation tools were run on swagger spec(s) and errors have all been fixed in this PR. How to fix?

If any further question about AME onboarding or validation tools, please view the FAQ.
ARM API Review Checklist

Applicability: :warning:
If your changes encompass only the following scenarios, you should SKIP this section, as these scenarios do not require ARM review.

Change to data plane APIs
Adding new properties
All removals

Otherwise your PR may be subject to ARM review requirements. Complete the following:

[ ] Check this box if any of the following appy to the PR so that the label "ARMReview" and "WaitForARMFeedback" will be added by bot to kick off ARM API Review.  Missing to check this box in the following scenario may result in delays to the ARM manifest review and deployment.

Adding a new service
Adding new API(s)
Adding a new API version
-[ ] To review changes efficiently, ensure you are using OpenAPIHub to initialize the PR for adding a new version. More details, refer to the wiki.

[ ] Ensure you've reviewed following guidelines including ARM resource provider contract and REST guidelines. Estimated time (4 hours). This is required before you can request review from ARM API Review board.

[ ] If you are blocked on ARM review and want to get the PR merged with urgency, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.

Breaking Change Review Checklist
If any of the following scenarios apply to the PR, request approval from the Breaking Change Review Board as defined in the Breaking Change Policy.

[ ] Removing API(s) in a stable version
[ ] Removing properties in a stable version
[ ] Removing API version(s) in a stable version
[ ] Updating API in a stable or public preview version with Breaking Change Validation errors
[ ] Updating API(s) in public preview over 1 year (refer to Retirement of Previews)

Action: to initiate an evaluation of the breaking change, create a new intake using the template for breaking changes. Addition details on the process and office hours are on the Breaking change Wiki.
Please follow the link to find more details on PR review process.

this rebase PR is same as current 2022-02-01 dev branch commit history: https://github.com/Azure/azure-rest-api-specs/compare/main...dev-sql-Microsoft.Sql-2022-02-01-preview

/azp run

/azp run

/azp run

@akning-ms , can you force merge this PR as it rebase the change from main? The errors are not related to SQL.


Is the manual included in the compiled package for Windows?

Hello, I've downloaded the windows package for the latest release but I can't find the compiled manual in the doc/ folder, only a stylesheet.css file. Not really a big issue since it's easily available online, but was wondering if this is intended.
Thank you for this incredibly useful software!

You're right. It's missing. I'll make sure this is fixed for the next release. Thanks for bringing it to my attention!


Order of seed words.

The order should be down first then left. So 1,2,3 in the first column and 4,5,6 in the second. Same for the next screen

The order while recovering should also be down first then next column

Verified this issue on dev app v2.0.75(477)