Blocked from JSBin (for a few hours) after sending ~30 people to bin

Hi! I've been using JSBin for my highschool courses for some time now. Recently I had a problem where my class couldn't access JSBin anymore halfway during the lesson. JSBin remained blocked for a few hours, and then became accessible again. I'm wondering if JSBin has some automatic DoS protection that kicks in when joining a bin and updating it a lot with about 30 students, all at once. I've seen this in two separate occasions.
On monday 14 september, 29 students joined the bin at http://jsbin.com/vopoquroyo/1/edit?js,output and started editting. In about 5 to 10 minutes, JSBin became inaccessible on all computers, with a 'cannot connect to server' error. It seemed that the browser couldn't successfully complete a TCP handshake. Using a different network/IP address showed to me that JSBin was working fine for the rest of the world.
On both tuesday 15 september, 31 students joined the bin at http://jsbin.com/jafubutici/3/edit?js,output and were blocked in less than 10 minutes. Same story as with monday.
If there is any automatic blocking, would it be possible to whitelist the school IP address? I unfortunately haven't recorded the IP address, and can't look it up until monday.
Thanks a lot for making JSBin possible, it's really a great educational tool!

More than happy to whitelist, just either post your IP here, or send a DM to js_bin on twitter (DM's are open, so that might be better for privacy) and I'll whitelist.

The school uses multiple IP addresses. One of them is <IP_ADDRESS>. I'll get the other ones soon enough.
Thanks again for working on this! I've setup a weekly donation on Gratipay out of the student fund.

Pretty sure this is happening to me currently. Regardless of a fix, could I at least get some information on what the factors are for being blocked?

Factors: fail2ban
If you're running a workshop or class you can be whitelisted. Either reply
here or DM @js_bin on twitter
On Mon, 26 Oct 2015 20:36 jonjohnjohnson<EMAIL_ADDRESS>wrote:

Pretty sure this is happening to me currently. Regardless of a fix, could
I at least get some information on what the factors are for being blocked?
—
Reply to this email directly or view it on GitHub
https://github.com/jsbin/jsbin/issues/2552#issuecomment-151276945.

Ah thanks @remy!

@remy can you please whitelist <IP_ADDRESS>?
We're a code school out of New Orleans called Operation Spark that was just blocked. Thank you!


Timestamp

I wanted an option to have a message added with a timestamp, to keep track of when kommit messages were added. Added -t option. Cheers

i wouldn't be nicer to have -t as an option than a parameter like kommit -t -m "msg" or kommit -mt "msg" ?

I kind of wanted it as a default for my purpose and did not always want to write -t -m ... however, I see your point. Can rewrite this if you think it is useful to have.

yes, it's good to have a timestamp on the message, to tracking time between messages. @vigo should decide which one is better. both ways is good for me. thanks mate 🍺

Ok I will wait. No worries. Thanks for the tool. very useful.

this is awesome! great idea @sschmeier. We'll merge it! <3


add form_fields to Customer

Form fields exist on Customer but are missing from the customer resource object.
Schema definition:
  $ curl https://developer.bigcommerce.com/api-reference/store-management/customers-v2/BigCommerce_Customers_API.oas2.json \
   | jq '.definitions.Customer.properties.form_fields'

  {
    "description": "Array of custom fields. This is a READ-ONLY field; do not set or modify its value in a POST or PUT request.",
    "type": "array",
    "items": {
      "title": "Form Fields",
      "type": "object",
      "properties": {
        "name": {
          "description": "Name of the form field",
          "type": "string",
          "example": "License Id"
        },
        "value": {
          "description": "Value of the form field",
          "type": "string",
          "example": "123BAF"
        }
      }
    }
  }

Hi all! Is this something worth considering including in main?

@bc-chaz @johnhebron looking to get this merged please

@j05h is there anything preventing this PR from being reviewed & merged?

@j05h is there anything preventing this PR from being reviewed & merged?

Nope. Looks good to me. Let me do some quick checks and I'll get this merged.


[ISSUE #525][operator] refine svc creations

What changes were proposed in this pull request?

generate headless svc for coordinators and pass this service to shuffle servers
makes RPCNodePort/HTTPNodePort optional for coordinators
remove service creation for shuffle servers.

Why are the changes needed?
This fixes #525
Does this PR introduce any user-facing change?
No
How was this patch tested?
It has already been manually verified, and will add more UTs.

Codecov Report

Merging #530 (8c7ad99) into master (cf9afab) will increase coverage by 0.80%.
The diff coverage is 96.15%.

@@             Coverage Diff              @@
##             master     #530      +/-   ##
============================================
+ Coverage     59.69%   60.50%   +0.80%
+ Complexity     1795     1567     -228
============================================
  Files           213      191      -22
  Lines         12414    10528    -1886
  Branches       1050      886     -164
============================================
- Hits           7411     6370    -1041
+ Misses         4594     3793     -801
+ Partials        409      365      -44

Impacted Files
Coverage Δ

...pkg/controller/sync/shuffleserver/shuffleserver.go
85.78% <0.00%> (+24.55%)
:arrow_up:

...bernetes/operator/pkg/controller/controller/rss.go
35.36% <100.00%> (+0.22%)
:arrow_up:

...tor/pkg/controller/sync/coordinator/coordinator.go
97.87% <100.00%> (+31.89%)
:arrow_up:

...y/kubernetes/operator/pkg/webhook/inspector/rss.go
59.25% <100.00%> (+0.61%)
:arrow_up:

...storage/handler/impl/DataSkippableReadHandler.java
83.78% <0.00%> (-2.71%)
:arrow_down:

.../apache/uniffle/coordinator/ClientConfManager.java
91.54% <0.00%> (-1.41%)
:arrow_down:

.../hadoop/mapreduce/task/reduce/RssBypassWriter.java

...n/java/org/apache/hadoop/mapreduce/MRIdHelper.java

...preduce/task/reduce/RssRemoteMergeManagerImpl.java

...g/apache/hadoop/mapred/SortWriteBufferManager.java

... and 19 more

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Decide what to do about including identical messages in the same block

Per these initial comments https://github.com/celestiaorg/celestia-app/pull/216#discussion_r809625701 https://github.com/celestiaorg/celestia-app/pull/216#discussion_r815541273
If two identical messages are submitted, then a block producer has the option to

include two copies of the messages in the square, and both PayForMessages
include one copy with only one of the PayForMessages
include one copy with both of the PayForMessages, each of the PayForMessages pointing to the same data

With the mechansim introduced in #216, we are currently rejecting proposed blocks that include both identical messages, which forces either option 1 or option 3, but we still need to make a formal decision over what we want block producers to do in this scenario.

I think we should not forbid including the same data multiple times.
Also, on the long run, one PFD should be able to pay for multiple messages anyways. Hence, including the same message multiple times should be valid as long as the PFD pays multiple times (i.e. the paid fee covers all messages).

I think we should not forbid including the same data multiple times.

this is now the case since we implemented the non-interactive defaults and #692


Local gulp not found

Hi,
Trying to automate the sass compilation but I get this message :
Running on save commands...
*** cmd start: gulp --no-color sass
[14:59:42] Local gulp not found in C:\Program Files (x86)\Microsoft VS Code
[14:59:42] Try running: npm install gulp

gulp --no-color sass works fine when done manually.
Gulp is installed globally

If I had to guess vscode may not be aware of whatever environment variables make it globally visible. You could try where gulp to find the full path of the executable and then attempt using that.

where is a linux command no ? I'm on windows

which is the linux command. I believewhere has been available on Windows for quite some time.

Closing as this seems to be an environment specific issue.


HTM-733, HTM-736, HTM-739 and HTM-740

Description:

(The receiver should not process voice command through orbsessioncallback) removed in HTM-740
Send data directly to orbsession
Renaming the voice command function
Update onVoiceSendKeyAction to dispatch key event
Remove dispatchKeyPressEvent and notifyKeyUp
Move voice service receiver to TIS (as well as mainactivity in mockapp)
Create interface default method for consoleLog in session callback

The image is #259
http://<IP_ADDRESS>:8080/job/Android_Emulator/job/emulator_orb_android_11_builder_dvbi_client/259/

Finish review.

Change pull request to merge into OpenRedButtonProject/master.

close, check https://github.com/OpenRedButtonProject/orb/pull/251


Passwd aging on CentOS

Provisioning CentOS ends with message:
Password change required but no TTY available

This patch pretends that password was changed today (day of building image).

Merged, thanks!

Oops, this contained the fix integer comp patch, which is under discussion in a different PR... Reverted that part for now.


Frontend/rest interfaces

Implemented BaseRestInterface, AccountRestInterface and SequenceRestInterface

Tagging @Kr0nox to review this aswell

before merging we should diguss how error handling works in the frontend. Do these methods catch the errors or do they get given through to the views?

Do these methods catch the errors or do they get given through to the views?

I say let the errors pass on to the views, since they might need to react differently based on different errors - e.g. 404 vs 401, and letting these methods handle errors would make the return types a lot more difficult

My suggestion would have been throwing an error with that information. for example that the user did not have the authorization. this would have the advantage that the rest interface is more Abstract and exchangable

I guess so - should be enough to surround the function calls inside of BaseRestInterface with a try-catch and throw new errors (probably loernwerkErrors) based on status code?

with a try-catch and throw new errors (probably loernwerkErrors) based on status code?

Will these loernwerkErrors have an enum that identifies the error that accoured or will they be written as a string in the message? If we choose the seccond option we would need to define these as public constants to check against somewhere.

Will these loernwerkErrors have an enum that identifies the error that accoured or will they be written as a string in the message? If we choose the seccond option we would need to define these as public constants to check against somewhere.

In the node standards, error codes are usually strings different from the message, we can define them as constants inside loernwerkUtilities where the LoernwerkError is defined aswell

Actually, we can kinda do both, if we define an enum like
export enum LoernwerkErrorType {
    NOT_FOUND: 'NOT_FOUND'
}

inside loernwerkUtilities I think

Doing both is possible. we would have do decide if we wanna do that

I prefer enums over "random string constants", so I'd go with that - that way we also comply with the NodeJS standard of string error codes

@gh-phobion Just noticed your entire files are in the wrong folder. they need to be inside the src folder


SQLSTATE[42000]: Syntax error or access violation: 1071 Specified key was too long; max key length is 1000 bytes

Laravel Version: 5.4
Voyager Version: Latest
PHP Version: 5.6.x
Database Driver & Version:
MySQL 5.7.11

Description:
Event I put the following code in service provider root() function.
Schema::defaultStringLength(191);
Steps To Reproduce:

Do you using homestead?

I can vouch, I am getting the error even after adding the lines:
Schema::defaultStringLength(191);
and use Illuminate\Support\Facades\Schema;
in app\Providers\AppServiceProvider.php
PHP Version: 5.6.19(from WAMP package)
Laravel Version: 5.4
Voyager: ^0.11.12
MySQL Version: 5.7.11(from WAMP package)

This solution is for i dont remember exacly but for error 768 bytes? Maybe try set defaultString on 200 or more, i don't have idea...

This code Schema::defaultStringLength(191); is not working with 1000 bytes
so you need to Alter your table Collation to utf8_general_ci  or alter the database Collation to it.
then try to  migrate again

Was reading a discussion on Laracasts
A user suggested to change the 'engine' => null', to 'engine' => 'InnoDB ROW_FORMAT=DYNAMIC', in config/database.php
I tried it and nothing else and it worked fine.


Native Array.from and polyfilled Set on Firefox 32-36 without Symbol.iterator support

Current Set conformance check forces polyfill for Set, but will keep original Array.from in Firefox 32-36. These versions use set["@@iterator"] instead of set[Symbol.iterator] which leads to Array.from(new Set("a")) to be [], although native implementation would return correct result.
I don't know whether

Whether it is a concern at all (I think it is even that Firefox 32-36 quite rare they have better feature set than IE11 and probably shouldn't have broken experience)
We should expose @@iterator in Set polyfill
We should lookup @@iterator in Array.from
Other options I haven't thought of

I assume that this can affect other collections and methods that expect iterator.

I would expect the polyfill for Set to pull-in Symbol.iterator since it has 'require es6/symbol';. But, Firefox < 36 does not support Symbol.iterator.

What language level output are you using? That version of Firefox may not support it.

I think language_out it is ECMASCRIPT5


Test API Feedback

re https://github.com/microsoft/vscode/issues/122208
This is a bit of a potpourri of API feedback regarding testing. Some are nit, some are about "firsts" 🥇, but also some bigger concerns 💭.
💭 Lacking "Run Options/Configs"
Two things have been modeled so far: "runnable" and "debuggable" (via TestItem#{runnable,debuggable} and TestRunRequest#debug). However, there is no notion of "run in safari" (playwright, vscode-selfhost use-case), "run with coverage", "run and profile" etc. As far as the UI is concerned we want to show commands and the flexible alternative is commands, menus, and context keys.
This concerned has been shelled out to https://github.com/microsoft/vscode/issues/127096
💭 TestItem#id
A test item needs to have a unique identifier. It is not clear what this is used for because the id isn't "referenced" anywhere, instead the TestItem is used. E.g test results are collected by item instance ((TestRun#setState), not by id. The same for appendMessage etc. My understanding is that I can dispose a test item and re-create it with the same id and its results are kept (re-associated). Assuming that's correct, it should be modeled more explicit. Also, todays design makes me wonder why there isn't just TestItem.setState(runRequest, runResult), esp. in the presence of TestItem#invalidateResults?
💭 TestItems everywhere
TestItem is a recursive and lazy data structure that represents everything: file, suite, test etc. I understand the desire for lazy test containers, like files, but I doubt the usefulness for recursive laziness. Like, you can identify something as containing suites and tests and analyzing that something will take time but I doubt that the analysis itself will be lazy. My dummy extension does the following (and I bet non-sample extensions do the same):

Each file is lazily parsed to detect tests. The file and each test is a managed object
When typing occurs, I dispose all existing test objects and re-create new managed objects (just to dispose them on next type).

This feels cumbersome and I assume it is also why recursive disposal of test items was "invented". I would prefer a simple setter on a managed container object, like testContainer.items = [pojoTestItem1, pojoTestItem2]. I also doubt that any extension manages and updates existing items. Sample: when inserting a newline in a test file each item must get a new range property. Unless the test items are kept as AST-like incremental data structure it will all be "fake";  meaning some process (reflection, ast-traversal, execution) produces a set of new items and we now ask extensions to do the diffing. It is much more friendly when extensions can "throw new items over the fence" and VS Code does the diffing (e.g by test item id)
🥇 Firsts

TestItem#dispose is recursive - I understand why this was done but it does violate the create/dispose balance.
TestItem#children brings es6-maps & iterables into the API - I am a big fan of iterables and I know plenty of places in the API where they should be introduced. Still, I doubt if children is a justified "first case" and wonder what we loose if readonly TestItem[] is used. What would be the recommendation for furture map vs iterable vs array questions and what should happen to existing APIs?

TestController#root is not a test item
That smells like implementation detail making it to the API... I don't even wanna think about TestController#root.dispose() or TestRun.setState(ctrl.root, ...)

My understanding is that I can dispose a test item and re-create it with the same id and its results are kept (re-associated)... Assuming that's correct, it should be modeled more explicit.

Yea. Or, in another common case that every extension hits, the user reloads the window. If we use object identity, we have no way to re-associated the results. In the initial API, before I had ID's, I used a "path of labels" but this was just a less well-specified ID, so I changed that.
Is modelling it more explicitly done by having a custom string type with documentation as you suggested in PM, or are you thinking of something more here?

Also, todays design makes me wonder why there isn't just TestItem.setState(runRequest, runResult), esp. in the presence of TestItem#invalidateResults?

To me it reads better as run.setState(item, runResult) to say that the item is given a result in the context of a certain test run. However we can cover this in #127096.

I would prefer a simple setter on a managed container object, like testContainer.items

This is somewhat tricky right now. In the current API, items have an unchanging parent from the moment of their creation. With an array of items, we give that control over to extensions, so items could have multiple parents, change parents, or duplicated within an array. These are errors we could check against and throw at runtime, but they're also errors which it's not possible to make in the current set of APIs.
(I think we could actually deal with changing parents pretty easily internally by deleting and re-creating the item, but allowing multiple parents would be a large change for dubious benefit.)
That said I see how items = [] is attractive as a way to clear all children.
However, we have seen some extensions adopt the incremental updates like the samples. Just glancing at code, Java and Playwright are doing partial updates.

TestController#root is not a test item

It is slightly special in that disposing it is invalid, but I think its utility outweighs its specialness:

Setting the label, error state, debugability/runnability, and accessing its children are things that need to exist in some way. Setting its state is valid, too, which a test extension could do if global setup or teardown fails. If there is not a root test item, these need to be duplicated elsewhere somehow in other APIs.
Removing it means we need to introduce new semantics for how we indicate that all tests need to run in a request. Right now we simply say to extensions "run the tests we pass you and all their children."
Having it there makes tree-transversal logic easier in general. Extension authors don't need to deal with having special cases for the 'not a root element' at the top of the tree.

FWIW I'm much happier with the API now that "data" was moved out to a separate optional mapping implementation and all the generics can be pulled out.
I like that TestItem interface is a "catchall" for any test tree item, and I can define any "metadata" I need for a test in my separately managed data object (or dynamically pulled, whatever I want). It should always be just that, a conduit/representation of an object in the UI, and not dictate to me how I run my tests or how I gather the data for my tests. If it were broken out by the vscode API into suites, groups, etc. then you are dictating to me how I organize my tests.
I agree run.setstate makes more sense on the context, though it could be run.setTestState maybe to be a little more clear, but this could also be covered in the JSDoc.
I think the root is fine and having it be a test item means my interface or unions don't have to include some other "random" type.

I think #127096 is valid, however today that could be controlled by extension settings or an extension contributed "options" window with checkboxes and whatnot, though that interface should probably be standardized to the Test API, maybe a dropdown where additional configurations can be supplied by the extension similar to how the Debug dropdown works.

I added a proposal in here which you might like: https://github.com/microsoft/vscode/issues/127096#issuecomment-868839093

This is somewhat tricky right now. In the current API, items have an unchanging parent from the moment of their creation. With an array of items, we give that control over to extensions, so items could have multiple parents,

In a way we wouldn't care too much. For us, only the assignment to items would count. It is the place for minimal validation and from then on we consider the data "dead" because we have taken the necessary pieces and applied them to the UI. It would be enough that test items have children pointer and that they are eventually contained in a "container". In "pseudo API"
// used to represent a "snapshot" like suites and tests for a certain document version
interface TestItem {
  id: string;
  location: Uri | Location;
  label: string;

  children?: TestItem[];

  // more...
}

// managed object with lifecycle, like a file
interface TestContainer {

  dispose(): void;

  readonly id: string;
  readonly uri: Uri | undefined;

  // get/set to update test items
  items: TestItem[]

  // more...
}

function createTestContainer(id: string): TestContainer

interface TestController {
  // get/set
  tests: TestContainer[]
}

For me the appeal is in the simplicity for extensions: a test container would represent a "source of truth" like a file or live document and extensions can simply extract data from them and set it onto the corresponding container. No need for cleanup or object updates

Yea. Or, in another common case that every extension hits, the user reloads the window. [...] Is modelling it more explicitly done by having a custom string type with documentation as you suggested in PM, or are you thinking of something more here?

I don't actually know. There is one part that makes me think test id are like uris and then they would deserve a type. And that type should be used. However,  they are also different because they only allow for identification, but not locating, of items. Looking at the use-cases you have listed I wonder how mandatory the id is or if something like a version id is missing (this touches on invalidateResults). E.g when a test changes, like adding/removing assertions, should its id change so that old results are dropped? At runtime there is the invalidate-function but what happens after reload? As a side note: as a user, I am often puzzled that I have results before running any test.

To me it reads better as run.setState(item, runResult) to say that the item is given a result in the context of a certain test run.

I like that too but I don't like invalidateResults because it somehow breaks the nice decoupling. Maybe, the aforementioned version id would help


Pass headers to backend

Instead of using apikey viewer things, I want to pass my cookie each request in header to backend, just pass ALL Cookie, any resolution? thx

Hi! Sorry for the late response. I believe this is possible using the requestOptions (to pass the cookie) and viewer (to remove viewers) options.

See an example here.
const { schema } = await openapiToGraphql.createGraphQlSchema(oas, {
  viewer: false,
  requestOptions: {
    headers: {
      cookie: 'access_token=abcdef'
    },
    url: undefined
  }
})

The requestOptions directly exposes the Request.js options used by the resolvers to call the REST API. You can find other options here.

@Alan-Cha Thanks for your response. In fact I want to pass different header in each request to backend, I have read the source code, it seems that it is unachievable.
Is it possible to add a requestOptions to allow user to transfer some fields in header for each request? such as
requestOptions: {   penetrateHeader: ['cookie'] }
in resolver builder:
if (penetrateHeader.length > 0) { 	penetrateHeader.forEach(fieldName => { 		options.headers[fieldName] = ctx.headers[fieldName] 	}) }

@YifengWong Happy to help! So you want the user to be able to change the header in each request? If so, it should just be a matter of defining header parameters in the OAS. Then, OtG will automatically create an interface such that each operation (requiring header parameters) will have additional arguments that the user can use for header parameters.
Is this what you mean?

Here is an example of a query that has arguments for passing cookie values.
Here is the OAS.
Let me know if this is what you're looking for!

@Alan-Cha If I define a parameter cookie in OAS, I should set it in my GQL query request body, instead GQL query headers. WAHT I want is to penetrate the GQL request header field in each request to source backend.

I have the same need.  Multiple consumers each with their own API key.  I need their key passed through to the REST API (viewerApiKey) but I would prefer to send the key as a header (perhaps via an axios interceptor for example)  and keep the schema a bit cleaner.
While it doesn't appear possible I think there is a somewhat reasonable solution.  If you allow the headers (and or requestOptions) opts to be an object or function:
const { schema } = await openapiToGraphql.createGraphQlSchema(oas, {
  viewer: false,
  headers: (req) => {
    return {
      ...req.headers
    }
  }
})

then in getResolver change where your passing them on to something like:
// Headers:
let additionalHeaders = data.options.headers;
if(typeof data.options.headers === 'function') additionalHeaders = data.options.headers(ctx);

for (let header in additionalHeaders) {
      options.headers[header] = additionalHeaders[header];
}

Only 1/2 baked but that's the gist

@PalmerEk I think this makes sense. This also give us a reason to keep the original header option, which for a long time seemed to be redundant thanks to the new requestOptions option.

@Alan-Cha Yes, having the headers option be a function as opposed to a static object would be super useful.
I am attempting to use tokenJSONpath -- as a workaround -- to pass a token, but it adds the Bearer <token> prefix, which I understand is the OAuth way of doing things (I am working with an API that requires Basic instead). Is there any way to edit the header value before the request gets sent?
The viewer "pattern" functionally works, but I do not enjoy the experience of nesting and duplication of queries and mutations for viewerApiKey and viewerAnyAuth.

@Alan-Cha  @ErikWittern
Are there any news about this one?
I can see that multiple there are multiple discussions related to this topic and there is even a PR which hasn't been accepted yet. However, there seem to be no result..
Passing custom headers to each request would be user useful. One use case is transparent authentication. I would need to pass a token and username to authenticate the request, but this doesn't seem to be possible right now.
Another use case is debugging: A unique ID could be attached to each request, so we can track them in the logs later.
Yet another use case would be request "grouping": Since a GraphQL request may results in several REST calls, I need to be able to identify this "group" later, for debugging purposes. So attaching a group-id header to each request generated by a given GQL query would be very useful..
Besides, this not only about headers. We could pass query string params in a similar way, or attach arbitrary data to request body etc.
Also, currently there seem to be no API for writing custom Viewers, which might be another solution.
Anyway, here is my use case:
Right now, I just need to implement transparent authentication by passing 2 custom headers to each request. How can I achieve this with the currently available functionality?
I can understand that one way to accomplish this is via OpenAPI schema (header parameters).
Is this the only way? I might not be able to change the OAS. So it would be easier for me to do this programmatically.
Thanks in advance!

Our app generates the GQL schema only once (on startup).
Therefore I need a way to inject those headers without calling the createGraphQlSchema() function again.

@gtamas Actually there is a PR in the works right now #270, filed by @yoonslee. I believe all that is missing are some test cases. I can try to add them in later today.
What would your ideal solution be in regards to requestOptions?

@Alan-Cha
Yes this is the PR I mentioned. It would be great to add something like this.
But maybe it would be even better if we could modify other parts of the request too, such as the body, query params, url (route) params etc.
I'm not sure yet what's the best way to achieve this, I need to look more into the OtG  code, it's still kinda new to me :).
All I'm saying is that probably it would best to extend this PR / idea a bit further and provide a more general solution which covers all the important request attributes.

With version v2.2.0, headers can now be dynamically set using a function. I believe we can finally close this issue.


get error immediately when i import

i got an error after i import the component
did anyone got same error??
https://imgur.com/05jKbXR
Unhandled JS Exception: Cannot read property 'string' of undefined
Unhandled JS Exception: Module AppRegistry is not a registered callable module (calling runApplication)

error because react 16 not have Proptypes  but this lib use PropTypes from react-native.
You can edit lib and Replace Proptype with prop-type  ("(https://www.npmjs.com/package/prop-types") and worked find.

thank you !! it's works
but another error shows
Unhandled JS Exception: Error: The  component cannot contain children. If you want to render content on top of the image, consider using aboslute positioning.
error only shows when i use CreditCardInput

i solved by change CardView.js
switch Image to ImageBackground


[charts/karavi-observability] Adjust PowerScale polling enable and frequency

Is this a new chart?
No
What this PR does / why we need it:
Adjust new enable and frequency for PowerScale as below:
capacityMetricsEnabled: "true"
performanceMetricsEnabled: "true"
clusterCapacityPollFrequencySeconds: 30
clusterPerformancePollFrequencySeconds: 20
quotaCapacityPollFrequencySeconds: 30
Which issue(s) is this PR associated with:

#377: https://github.com/dell/csm/issues/377

Special notes for your reviewer:
Checklist:
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[ ] Chart Version bumped
[ ] Variables are documented in the chart README.md
[x] Title of the PR starts with the chart name (e.g. [charts_dir/mychartname]) if applicable

@baoy1 your commit is not signed yet

@baoy1 your commit is not signed yet

Thanks for reminding. Signed commit.


Unable to use Advanced config

Description
I'm trying to use the advanced config but I'm getting an error:
PHP Fatal error:  Uncaught yii\base\ErrorException: Attempt to read property "enabled" on null in /root/craft/vendor/yiisoft/yii2/log/Dispatcher.php:187
Steps to reproduce
Add the app.php config:
use craft\helpers\App;

return [
  '*' => [
    'components' => [
      'log' => [
        'targets' => [
          'sentry' => function() {
            if (!class_exists(SentryTarget::class)) {
              return null;
            }

            return Craft::createObject(
            [
              'class' => SentryTarget::class,
              'enabled' => true,
              'anonymous' => false,
              'dsn' => App::env('SENTRY_DSN'),
              'levels' => ['error', 'warning'],
              'exceptCodes' => [403, 404],
              'options' => [
                'max_value_length' => 2048,
              ],
            ]);
          },
        ],
      ],
    ],
  ],
];

Additional info

Plugin version: 1.3.3
Craft version: 3.8.13
PHP version: 8.1
Configuration method: Advanced

Hi @pixelmachine,
Try without the * array because the app.php is not an environment-aware config file.
Also you must import the class at the top of the file with this use diginov\sentrylogger\log\SentryTarget;.

Hi @pixelmachine
I think you are mixing the Craft 3 and Craft 4 advanced configuration syntax, please check this configuration example:
https://github.com/diginov/craft-sentry-logger/tree/craft-3#craft-36-or-later
Also try without the * array because the app.php is not an environment-aware config file:
<?php

use craft\helpers\App;

return [

    'components' => [
        'log' => [
            'targets' => [
                '__craftSentryTarget' => function() {
                    if (!class_exists('diginov\\sentry\\log\\SentryTarget')) {
                        return null;
                    }

                    return Craft::createObject([
                        'class' => 'diginov\\sentry\\log\\SentryTarget',
                        'enabled' => true,
                        'anonymous' => false,
                        'dsn' => App::env('SENTRY_DSN'),
                        'levels' => ['error', 'warning'],
                        'exceptCodes' => [403, 404],
                        'exceptPatterns' => [],
                        'options' => [
                            'max_value_length' => 2048,
                        ],
                    ]);
                },
            ],
        ],
    ],

];

Thanks again, all good now:


chore: clear todo

Summary by CodeRabbit

Refactor

Simplified the function to return module account addresses without intermediate processing.

Tests

Updated test functions by removing unnecessary module verification steps.

Chores

Removed several TODO comments across various files to clean up the codebase.

mg


Let users debug even if local.settings.json can't be parsed

I discovered parse errors in telemetry for a very small number of users and figured we could handle this better. For C# we currently block debugging, but I tried it out and the func cli will still work (for the most part).

This parse error is the first and only "unexpected" error I've seen from preDebugValidate, but yes theoretically if the func cli doesn't work the error will be seen in the terminal


Add naaative theme

Naaative is based on steeef with a few minor changes:

Adapted to look best with the 'Oceanic Next Dark' theme, but will look nice with almost any theme
Use the Terminal theme colors instead of absolute (256) colors
Displays the same Git indicators as a lot of custom prompts do (! for untracked changes, + for uncommitted changes, ? for untracked files)
Adds a stash indicator ($)

Cheers :)

I would refrain from accepting PRs for new themes (mainly customized versions of already existing ones) until we migrate to the zimframework organization.

... Which, if you'll be around this weekend @ericbn, I'd like to do.

Any updates on this?  I was considering adding a customized version of steeef myself but this might be just what I'm looking for...

I still think that the themes that come with zim, alongside our git-info module, provide a good basis for users to customize their own themes, and that we should not include variations of the already existing themes to our repo.

I agree with @ericbn, and would be happy to include this as an external module if @jorvi would like to maintain this in a separate repo.


Charged Pierce Shot doesn't Break Glass

gonna close this at least until we get the chance to investigate this further (can't reproduce it in various environments)


2 OSRS Monsters

I think it would be great to add two different monsters into BSO...
Alchemical Hydra: I think it would make it a bit easier for Irons (and normal accounts) to obtain ferocious gloves and Dragon Hunter Lance.
Spiritual Mage: Again, would make it easier for everyone to obtain Dragon Boots.

Both of these are locked behind slayer and I'm sure will be released with slayer


notification feature

Is your feature request related to a problem? Please describe.

currently, there is no notifications feature

Describe the solution you'd like

creating a notification model
adding getNotifications route that will fetch all the notifications for a particular user

Do you want to work on this issue - [Yes/No] - Yes

Redirect :- #436


workshop/forms.py: change some fields' widgets to TextInput

This fixes #559 by changing default widgets to TextInput for these
fields:

admin_fee
attendance
latitude
longitude.

Unfortunately the admin_fee field's declaration is more important
than Meta.widgets content so the widget for admin_fee had to be
overwritten in the declaration.
Let me just add that the reason for this change is that under MacOS the HTML5 widgets can change value upon scrolling over them. This is not the case for Linux, and certainly not for Windows, but our admins use MacOSX so…

I'll try to get to this, but we need to find someone else who can review
these from now on - I have to focus on instructor training.

On Mon, Jan 04, 2016 at 02:20:02PM -0800, Greg Wilson wrote:

I'll try to get to this, but we need to find someone else who can
review these from now on - I have to focus on instructor training.

I'm fine just leaving it to @pbanaszkiewicz to push PRs like this, and
then merge them himself after a few days of quiet (if he feels happy
with them).  Especially for small changes like this, if it works for
him, it's probably fine to merge.  The only areas that need other
feedback are issues (where AMY users have been chiming in).  As long
as we agree on what AMY should be doing, how it goes about doing it
doesn't need consensus building unless there are more folks than Piotr
frequently interacting with the code.

I'm fine just leaving it to @pbanaszkiewicz to push PRs like this, and then merge them himself after a few days of quiet (if he feels happy with them). Especially for small changes like this, if it works for him, it's probably fine to merge.

That's what I was doing and that's what I'm going to do for this issue.


Update 2 screenshots

https://docs.microsoft.com/en-us/azure/hdinsight/hadoop/media/apache-hadoop-linux-tutorial-get-started/hdinsight-linux-get-started-open-cluster-dashboard.png
https://docs.microsoft.com/en-us/azure/hdinsight/hadoop/media/apache-hadoop-linux-tutorial-get-started/hdinsight-delete-cluster.png
Current UX looks different from what we see in an article. Please update it.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 6593c2a0-76bc-47e0-519e-d653ab435fdd
Version Independent ID: 17c83e2b-3fe4-97ad-1bce-923dd3e900e6
Content: Quickstart: Get started with Hadoop and Hive in Azure HDInsight using Azure portal
Content Source: articles/hdinsight/hadoop/apache-hadoop-linux-create-cluster-get-started-portal.md
Service: hdinsight
GitHub Login: @hrasheed-msft
Microsoft Alias: hrasheed

@SychevIgor
Thanks for the feedback! We are currently investigating and will update you shortly.

Thanks @SychevIgor. There have been a number of portal changes that will require widespread document edits. We have a few user stories in our backlog to update all of the affected docs, but it will take some time to redo all of the screenshots.

#please-close


Optionality in schemas

This PR introduces a fairly substantial change to the semantics of schema's and selections. I'll try to describe the behavior before and after these changes as well as my rationale.
The current state
Currently, schemas disregard any non-specified keys in the input map and return only what's been specified. Selections further filter this input set in order to return a limited set of keys. This code should demonstrate the idea:
user = schema(%{name: spec(is_binary())})
%{name: "chris"} = conform!(%{name: "chris", age: 31}, user)

Furthermore, all of the schema's keys are required in the input map.
The problems
By removing unspecified keys from the input we make it impossible to support dynamic user input or arbitrary middlewares. This example should demonstrate what I mean:
def env_s, do: schema(%{content_type: spec(is_binary()), method: spec(& &1 in ["POST", "GET"]})

def user_middleware(env) do
  # The env should contain the specified values
  conform!(env, env_s())
  Map.put(env, :user_id, "User ID")
  env
end

def run(middleware \\ []) do
  # Magically get the env. We could pull the values from a plug conn or some other location.
  env = build_env()
  env = Enum.reduce(middleware, env, fn m, prev_env -> m.(prev_env) end)

  # We still want to ensure that our data is there but we don't want to discard the users data.
  env = conform!(env, env_s())
end

run([&user_middleware/1])

In our example the user's function can add arbitrary fields to the env map. Once the middleware has run we want to ensure that we haven't lost our specified fields, but we don't want to remove the other fields the user has added. The current design limits our ability to handle this case.
The other problem is around optionality. There's not a good way to say that a key is optional in a given context. Selections don't help us here since they only limit the conformed output. In practice this means that users end up having to specify a number of different schemas for different use cases instead of being able to re-use existing schemas.
Solutions
I've thought about these problems for a while and I think I've arrived at a good path forward. After this PR schema and selection will return the entire input payload so long as any specified keys conform correctly. This makes Norm much more open to growth and supports the specific problems I described above.
In order to support optional keys, all the keys in a schema will now be optional. That means that all of these scenarios would be considered valid:
user_schema = schema(%{
  name: spec(is_binary()),
  age: spec(is_integer()),
  email: spec(is_binary())
})
iex> valid?(%{}, user_schema)
true
iex> valid?(%{name: "chris"}, user_schema)
true
iex> valid?(%{name: "chris", age: 31}, user_schema)
true
iex> valid?(%{age: 31, other_key: "other"}, user_schema)
true

In order to mark certain fields as required we can use selection. Selection's will ensure that at least the keys specified are present.
user_schema = schema(%{
  name: spec(is_binary()),
  age: spec(is_integer()),
  email: spec(is_binary())
})
iex> valid?(%{}, selection(user_schema, [:name])
false
iex> valid?(%{name: "chris"}, selection(user_schema, [:name]))
true
iex> valid?(%{name: "chris", age: 31}, selection(user_schema, [:name]))
true

If you want to mark all fields in all schema's as required, recursively, I've also provided a shorthand. Instead of specifying lists of keys you can use the single arity version of selection like so:
schema = schema(%{
  a: spec(is_binary()),
  b: spec(is_binary()),
  c: spec(is_binary())
})
iex> valid?(%{}, selection(schema))
false
iex> valid?(%{a: "a", b: "b", c: "c"}, selection(schema))
true

Since selections no longer limit the returned values this effectively solves the optionality problem I described above. These semantics should allow us to support many more use cases and should increase the usability of schema's and selections.
Future work
After these changes I'm beginning to think that the name selection no longer makes sense. Maybe something like required would be more meaningful. I'm going to think about that a bit more.

I like this. Perhaps out of scope (and maybe even a bad idea) but have you thought about providing nested required fields? For example if I want to say that my function takes a user with an address that has a street?

Yup, you'll be able to do that with selection now.


Add support for connection-less presentation requests

The pull request includes changes necessary to support presentation requests that do not rely on an existing agent-to-agent connection.
A use case for this is when vc-authn-oidc creates a presentation request to allow users that hold credentials that satisfy it to access a protected resource.
In this case, the presentation request does not require a connection between the vc-authn-oidc agent and the user's agent to exist and be active: any user holding appropriate credentials should be able to receive the same presentation request and be authenticated when they respond with the correct credential claims.
Tagging @andrewwhitehead for review.

Codecov Report

Merging #296 into master will decrease coverage by <.01%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #296      +/-   ##
==========================================
- Coverage   81.64%   81.63%   -0.01%
==========================================
  Files         232      232
  Lines       10785    10782       -3
==========================================
- Hits         8805     8802       -3
  Misses       1980     1980


Platform: add sys_xattr module for Android

This module was left out from the modulariation pass. The declarations here are required for building swift-foundation for Android.

@swift-ci please test

@compnerd could you also include it from SwiftAndroidNDK.h?

Sure, though could you explain why that is needed?

@swift-ci please test

I haven't tried building the new swift-foundation lately, but I will apply this NDK header addition natively on Android and test to make sure it doesn't break anything.

I've tested the android build locally, and this is needed to make progress on the swift-foundation builds for Android. Additionally, the introduced module is an explicit module which was previously not included, so I do not expect this to cause any regressions.

I don't either, just running the compiler validation suite with it natively on Android now.

Alright, ran the full compiler validation suite natively on Android with this pull and am building a full trunk toolchain with it now, don't see any issues.

Okay, merging this for now. We can address any issues subsequently. Hopefully we can get to the point where we can get swift-foundation android builds via cross-compilation in CI as well.

Okay, would be nice to merge this for now. We can address any issues subsequently.

If you need it to build swift-foundation, seems fine to me.

Hopefully we can get to the point where we can get swift-foundation android builds via cross-compilation in CI as well. Or would you rather report back quickly @finagolfin?

I don't understand: what do you want me to report back about?

Oh, I thought you were doing more tests. Going to merge!


Added NullRouteFilter to use predicates/filters on a route without backend

Codecov Report

Merging #196 into master will increase coverage by 0.21%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #196      +/-   ##
==========================================
+ Coverage   71.88%   72.09%   +0.21%
==========================================
  Files          87       88       +1
  Lines        1860     1874      +14
  Branches      119      121       +2
==========================================
+ Hits         1337     1351      +14
  Misses        459      459
  Partials       64       64

Impacted Files
Coverage Δ

...cloud/gateway/config/GatewayAutoConfiguration.java
100% <100%> (ø)
:arrow_up:

...ramework/cloud/gateway/filter/NullRouteFilter.java
100% <100%> (ø)

Continue to review full report at Codecov.

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

I needed that filter to use predicates and filters without a backend for a use case. I'm not sure if that kind of thing go directly into the framework or not. If not or you have a better solution to do something like this, just refuse my pull request. Happy to share code!

Yeah, not sure this is something we need. I'll keep it and Mark it waiting for votes.

@jphilippeplante I've seen the need for knowing when a route will never reach a routing filter. Turns out, you can just use something like no://op as the uri and let the other filter (RedirectTo or the cloud foundry one) handle the response.


Removes unnecessary logging flags

This PR removes unnecessary logging flags that were added as part of
integrating "glog" into odo.
Instead of the following:
Global Flags:
      --alsologtostderr                  log to standard error as well as files
      --log_backtrace_at traceLocation   when logging hits line file:N, emit a stack trace (default :0)
      --log_dir string                   If non-empty, write log files in this directory
      --logtostderr                      log to standard error instead of files (default false)
      --skip-connection-check            Skip cluster check
      --stderrthreshold severity         logs at or above this threshold go to stderr (default 2)
  -v, --v Level                          log level for V logs. Level varies from 0 to 9 (default 0).
      --vmodule moduleSpec               comma-separated list of pattern=N settings for file-filtered logging

Only these flags are now available:
Global Flags:
      --skip-connection-check   Skip cluster check
  -v, --v Level                 Log level for V logs. Level varies from 0 to 9 (default 0).
      --vmodule moduleSpec      Comma-separated list of pattern=N settings for file-filtered logging

Thus making odo --help / odo help a lot cleaner.

[odo]  ✗  waited 4m0s but couldn't find running pod matching selector: 'deploymentconfig=mycomponent-myapp'

/retest

/approve

/lgtm Code looks and works for me but let's wait for the tests to pass

@mik-dass your /lgtm didn't take

/lgtm


Added function setModelForClass to allow models to be overwritten

Hi Akos,
thank you for your great project.
Since we use Typegoose both in our core module and in the respective project modules, we need the possibility to overwrite existing models.
For example, we have a rudimentary user model in the core and would like to replace it with a more complex user model from the respective project. Since the behaviour in the core should change, the model must be able to be overwritten in the core.
This was not possible before, because only a reading function was available, which only created a new model if it did not exist before.
Best regards
Kai

Coverage increased (+0.09%) to 86.557% when pulling 2bed8f57356679641423cbba39c498ba984a7f91 on kaihaase-wd:master into 591a9f95b4d1bfd9f1074cb90cc507f27eda4b9b on szokodiakos:master.

As discussed, can you please extend the documentation with the new feature?
Thanks!

Coverage decreased (-0.6%) to 85.902% when pulling b2d30c9f0eed48d1872631890a0b51d2bc8e8939 on kaihaase-wd:master into 591a9f95b4d1bfd9f1074cb90cc507f27eda4b9b on szokodiakos:master.


feat( ):

Need
How to download the data and do my own analyses/graphing on Seurat, ScanPy, and other popular single cell analysis toolchains
Approach
I think it would be super helpful for the community to have a white paper/user guide that provides step by step instructions on how to do so
Definition of Done

thanks @bryan3t!

There is documentation for downloading datasets in the AnnData or Seurat formats from CELLxGENE Discover. Please see https://cellxgene.cziscience.com/docs/03__Download Published Data.
The related toolchains offer step by step tutorials such as https://scanpy.readthedocs.io/en/stable/tutorials.html or https://satijalab.org/seurat/articles/get_started.html.


Documentation for working with dynamic ports

As per the comment in https://github.com/adamw/elasticmq/issues/88#issuecomment-278941474 i've added some documentation about working with dynamic ports

Thanks!


shard retention looks broken

Bug report
System info:
Rhel 7.3
influxd version
InfluxDB v1.2.0 (git: master b7bb7e8359642b6e071735b50ae41f5eb343fd42)
Steps to reproduce:

create retention policy. capture data.
shrink retention policy to lower shards count.
wait for retention to finish

Expected behavior: [What you expected to happen]
all useless shards will be deleted
Actual behavior: [What actually happened]
only first shard have been deleted
Additional info: [Include gist of relevant config, logs, etc.]
https://gist.github.com/freeseacher/26f4311d4ae1cff6204d17f6f9314889

ok. it seem if you will wait long enough sometime it will delete data from disk.
currently several more shards was deleted
Feb 06 07:27:55 db04 influxd[4936]: [I] 2017-02-06T04:27:55Z Snapshot for path /var/lib/influxdb/data/noc/default/255 written in 15.192388996s engine=tsm1
Feb 06 07:28:55 db04 influxd[4936]: [I] 2017-02-06T04:28:55Z compacted level 2 group (0) into /var/lib/influxdb/data/noc/default/255/000000133-000000003.tsm.tmp (#0) engine=tsm1
Feb 06 07:28:55 db04 influxd[4936]: [I] 2017-02-06T04:28:55Z compacted level 2 2 files into 1 files in 1m40.394133203s engine=tsm1
Feb 06 07:29:33 db04 influxd[4936]: [I] 2017-02-06T04:29:33Z Snapshot for path /var/lib/influxdb/data/noc/default/255 written in 15.658590087s engine=tsm1
Feb 06 07:29:33 db04 influxd[4936]: [I] 2017-02-06T04:29:33Z beginning level 1 compaction of group 0, 2 TSM files engine=tsm1
Feb 06 07:29:33 db04 influxd[4936]: [I] 2017-02-06T04:29:33Z compacting level 1 group (0) /var/lib/influxdb/data/noc/default/255/000000134-000000001.tsm (#0) engine=tsm1
Feb 06 07:29:33 db04 influxd[4936]: [I] 2017-02-06T04:29:33Z compacting level 1 group (0) /var/lib/influxdb/data/noc/default/255/000000135-000000001.tsm (#1) engine=tsm1
Feb 06 07:30:31 db04 influxd[4936]: [I] 2017-02-06T04:30:31Z compacted level 1 group (0) into /var/lib/influxdb/data/noc/default/255/000000135-000000002.tsm.tmp (#0) engine=tsm1
Feb 06 07:30:31 db04 influxd[4936]: [I] 2017-02-06T04:30:31Z compacted level 1 2 files into 1 files in 57.688220584s engine=tsm1
Feb 06 07:31:09 db04 influxd[4936]: [I] 2017-02-06T04:31:09Z Snapshot for path /var/lib/influxdb/data/noc/default/255 written in 15.418628037s engine=tsm1
Feb 06 07:32:04 db04 influxd[4936]: [I] 2017-02-06T04:32:04Z compacted full group (0) into /var/lib/influxdb/data/noc/default/255/000000129-000000005.tsm.tmp (#0) engine=tsm1
Feb 06 07:32:04 db04 influxd[4936]: [I] 2017-02-06T04:32:04Z compacted full 2 files into 1 files in 5m33.70154279s engine=tsm1
Feb 06 07:32:44 db04 influxd[4936]: [I] 2017-02-06T04:32:44Z beginning level 1 compaction of group 0, 2 TSM files engine=tsm1
Feb 06 07:32:44 db04 influxd[4936]: [I] 2017-02-06T04:32:44Z compacting level 1 group (0) /var/lib/influxdb/data/noc/default/255/000000136-000000001.tsm (#0) engine=tsm1
Feb 06 07:32:44 db04 influxd[4936]: [I] 2017-02-06T04:32:44Z compacting level 1 group (0) /var/lib/influxdb/data/noc/default/255/000000137-000000001.tsm (#1) engine=tsm1
Feb 06 07:32:44 db04 influxd[4936]: [I] 2017-02-06T04:32:44Z Snapshot for path /var/lib/influxdb/data/noc/default/255 written in 14.041984959s engine=tsm1
Feb 06 07:33:26 db04 influxd[4936]: [I] 2017-02-06T04:33:26Z compacted level 1 group (0) into /var/lib/influxdb/data/noc/default/255/000000137-000000002.tsm.tmp (#0) engine=tsm1
Feb 06 07:33:26 db04 influxd[4936]: [I] 2017-02-06T04:33:26Z compacted level 1 2 files into 1 files in 41.897953571s engine=tsm1
Feb 06 07:33:26 db04 influxd[4936]: [I] 2017-02-06T04:33:26Z beginning level 2 compaction of group 0, 2 TSM files engine=tsm1
Feb 06 07:33:26 db04 influxd[4936]: [I] 2017-02-06T04:33:26Z compacting level 2 group (0) /var/lib/influxdb/data/noc/default/255/000000135-000000002.tsm (#0) engine=tsm1
Feb 06 07:33:26 db04 influxd[4936]: [I] 2017-02-06T04:33:26Z compacting level 2 group (0) /var/lib/influxdb/data/noc/default/255/000000137-000000002.tsm (#1) engine=tsm1
Feb 06 07:34:26 db04 influxd[4936]: [I] 2017-02-06T04:34:26Z Snapshot for path /var/lib/influxdb/data/noc/default/255 written in 14.826337699s engine=tsm1
Feb 06 07:34:48 db04 influxd[4936]: [I] 2017-02-06T04:34:48Z compacted level 2 group (0) into /var/lib/influxdb/data/noc/default/255/000000137-000000003.tsm.tmp (#0) engine=tsm1
Feb 06 07:34:48 db04 influxd[4936]: [I] 2017-02-06T04:34:48Z compacted level 2 2 files into 1 files in 1m22.2959044s engine=tsm1
Feb 06 07:35:05 db04 influxd[4936]: [I] 2017-02-06T04:35:05Z retention policy shard deletion check commencing service=retention
Feb 06 07:36:12 db04 influxd[4936]: [I] 2017-02-06T04:36:12Z beginning level 1 compaction of group 0, 2 TSM files engine=tsm1
Feb 06 07:36:12 db04 influxd[4936]: [I] 2017-02-06T04:36:12Z compacting level 1 group (0) /var/lib/influxdb/data/noc/default/255/000000138-000000001.tsm (#0) engine=tsm1
Feb 06 07:36:12 db04 influxd[4936]: [I] 2017-02-06T04:36:12Z compacting level 1 group (0) /var/lib/influxdb/data/noc/default/255/000000139-000000001.tsm (#1) engine=tsm1
Feb 06 07:36:12 db04 influxd[4936]: [I] 2017-02-06T04:36:12Z Snapshot for path /var/lib/influxdb/data/noc/default/255 written in 21.414474987s engine=tsm1
Feb 06 07:36:32 db04 influxd[4936]: [I] 2017-02-06T04:36:32Z shard ID 113 from database noc, retention policy default, deleted service=retention
Feb 06 07:36:51 db04 influxd[4936]: [I] 2017-02-06T04:36:51Z compacted level 1 group (0) into /var/lib/influxdb/data/noc/default/255/000000139-000000002.tsm.tmp (#0) engine=tsm1
Feb 06 07:36:51 db04 influxd[4936]: [I] 2017-02-06T04:36:51Z compacted level 1 2 files into 1 files in 39.309040146s engine=tsm1
Feb 06 07:37:38 db04 influxd[4936]: [I] 2017-02-06T04:37:38Z Snapshot for path /var/lib/influxdb/data/noc/default/255 written in 13.799420815s engine=tsm1
Feb 06 07:38:06 db04 influxd[4936]: [I] 2017-02-06T04:38:06Z shard ID 105 from database noc, retention policy default, deleted service=retention
Feb 06 07:39:08 db04 influxd[4936]: [I] 2017-02-06T04:39:08Z beginning level 1 compaction of group 0, 2 TSM files engine=tsm1
Feb 06 07:39:08 db04 influxd[4936]: [I] 2017-02-06T04:39:08Z compacting level 1 group (0) /var/lib/influxdb/data/noc/default/255/000000140-000000001.tsm (#0) engine=tsm1
Feb 06 07:39:08 db04 influxd[4936]: [I] 2017-02-06T04:39:08Z compacting level 1 group (0) /var/lib/influxdb/data/noc/default/255/000000141-000000001.tsm (#1) engine=tsm1
Feb 06 07:39:08 db04 influxd[4936]: [I] 2017-02-06T04:39:08Z Snapshot for path /var/lib/influxdb/data/noc/default/255 written in 13.077580697s engine=tsm1
Feb 06 07:39:37 db04 influxd[4936]: [I] 2017-02-06T04:39:37Z shard ID 99 from database noc, retention policy default, deleted service=retention
Feb 06 07:39:49 db04 influxd[4936]: [I] 2017-02-06T04:39:49Z compacted level 1 group (0) into /var/lib/influxdb/data/noc/default/255/000000141-000000002.tsm.tmp (#0) engine=tsm1
Feb 06 07:39:49 db04 influxd[4936]: [I] 2017-02-06T04:39:49Z compacted level 1 2 files into 1 files in 41.456813587s engine=tsm1
Feb 06 07:39:49 db04 influxd[4936]: [I] 2017-02-06T04:39:49Z beginning level 2 compaction of group 0, 6 TSM files engine=tsm1
Feb 06 07:39:49 db04 influxd[4936]: [I] 2017-02-06T04:39:49Z compacting level 2 group (0) /var/lib/influxdb/data/noc/default/255/000000139-000000002.tsm (#0) engine=tsm1
Feb 06 07:39:49 db04 influxd[4936]: [I] 2017-02-06T04:39:49Z compacting level 2 group (0) /var/lib/influxdb/data/noc/default/255/000000139-000000002.tsm (#1) engine=tsm1
Feb 06 07:39:49 db04 influxd[4936]: [I] 2017-02-06T04:39:49Z compacting level 2 group (0) /var/lib/influxdb/data/noc/default/255/000000139-000000002.tsm (#2) engine=tsm1
Feb 06 07:39:49 db04 influxd[4936]: [I] 2017-02-06T04:39:49Z compacting level 2 group (0) /var/lib/influxdb/data/noc/default/255/000000141-000000002.tsm (#3) engine=tsm1
Feb 06 07:39:49 db04 influxd[4936]: [I] 2017-02-06T04:39:49Z compacting level 2 group (0) /var/lib/influxdb/data/noc/default/255/000000141-000000002.tsm (#4) engine=tsm1
Feb 06 07:39:49 db04 influxd[4936]: [I] 2017-02-06T04:39:49Z compacting level 2 group (0) /var/lib/influxdb/data/noc/default/255/000000141-000000002.tsm (#5) engine=tsm1
Feb 06 07:40:44 db04 influxd[4936]: [I] 2017-02-06T04:40:44Z Snapshot for path /var/lib/influxdb/data/noc/default/255 written in 20.589170151s engine=tsm1
Feb 06 07:41:15 db04 influxd[4936]: [I] 2017-02-06T04:41:15Z shard ID 87 from database noc, retention policy default, deleted service=retention
Feb 06 07:42:07 db04 influxd[4936]: [I] 2017-02-06T04:42:07Z compacted level 2 group (0) into /var/lib/influxdb/data/noc/default/255/000000141-000000003.tsm.tmp (#0) engine=tsm1
Feb 06 07:42:07 db04 influxd[4936]: [I] 2017-02-06T04:42:07Z compacted level 2 6 files into 1 files in 2m18.122826827s engine=tsm1
Feb 06 07:42:17 db04 influxd[4936]: [I] 2017-02-06T04:42:17Z beginning level 1 compaction of group 0, 2 TSM files engine=tsm1
Feb 06 07:42:17 db04 influxd[4936]: [I] 2017-02-06T04:42:17Z compacting level 1 group (0) /var/lib/influxdb/data/noc/default/255/000000142-000000001.tsm (#0) engine=tsm1
Feb 06 07:42:17 db04 influxd[4936]: [I] 2017-02-06T04:42:17Z compacting level 1 group (0) /var/lib/influxdb/data/noc/default/255/000000143-000000001.tsm (#1) engine=tsm1
Feb 06 07:42:17 db04 influxd[4936]: [I] 2017-02-06T04:42:17Z Snapshot for path /var/lib/influxdb/data/noc/default/255 written in 23.556188496s engine=tsm1
Feb 06 07:42:43 db04 influxd[4936]: [I] 2017-02-06T04:42:43Z shard ID 93 from database noc, retention policy default, deleted service=retention
Feb 06 07:43:07 db04 influxd[4936]: [I] 2017-02-06T04:43:07Z compacted level 1 group (0) into /var/lib/influxdb/data/noc/default/255/000000143-000000002.tsm.tmp (#0) engine=tsm1
Feb 06 07:43:07 db04 influxd[4936]: [I] 2017-02-06T04:43:07Z compacted level 1 2 files into 1 files in 50.358003751s engine=tsm1
Feb 06 07:43:38 db04 influxd[4936]: [I] 2017-02-06T04:43:38Z Snapshot for path /var/lib/influxdb/data/noc/default/255 written in 13.478163782s engine=tsm1
Feb 06 07:44:09 db04 influxd[4936]: [I] 2017-02-06T04:44:09Z shard ID 83 from database noc, retention policy default, deleted service=retention

but it is still unpredictable. shards had been deleted out of any expected order
``
journalctl -r |grep "shard ID"
Feb 06 07:47:01 db04 influxd[4936]: [I] 2017-02-06T04:47:01Z shard ID 101 from database noc, retention policy default, deleted service=retention
Feb 06 07:45:33 db04 influxd[4936]: [I] 2017-02-06T04:45:33Z shard ID 85 from database noc, retention policy default, deleted service=retention
Feb 06 07:44:09 db04 influxd[4936]: [I] 2017-02-06T04:44:09Z shard ID 83 from database noc, retention policy default, deleted service=retention
Feb 06 07:42:43 db04 influxd[4936]: [I] 2017-02-06T04:42:43Z shard ID 93 from database noc, retention policy default, deleted service=retention
Feb 06 07:41:15 db04 influxd[4936]: [I] 2017-02-06T04:41:15Z shard ID 87 from database noc, retention policy default, deleted service=retention
Feb 06 07:39:37 db04 influxd[4936]: [I] 2017-02-06T04:39:37Z shard ID 99 from database noc, retention policy default, deleted service=retention
Feb 06 07:38:06 db04 influxd[4936]: [I] 2017-02-06T04:38:06Z shard ID 105 from database noc, retention policy default, deleted service=retention
Feb 06 07:36:32 db04 influxd[4936]: [I] 2017-02-06T04:36:32Z shard ID 113 from database noc, retention policy default, deleted service=retention
Feb 06 07:06:39 db04 influxd[4936]: [I] 2017-02-06T04:06:39Z shard ID 75 from database noc, retention policy default, deleted service=retention

Altering a retention policy does not immediately remove the shards.  They are periodically checked to see which have expired and then removed.  The schedule when the retention policy enforcement runs is:
[retention]
  check-interval = "30m0s"

If you lower that value, the check will run more frequently.  Running it too frequently can cause adverse performance issues though.
To immediately remove a shard, you can run manually do it via drop shard 101.

tnx.


Parse fixes

This addresses all the parsing bugs I found when I surveyed your assembler. The largest change is to move to strongly typed argument handling by scanning arguments as consistent tokens, before invoking each opcode's function. I have written more details in the commit messages and each commit is atomic.
I found that any exceptions thrown within the promises cannot be caught by the enclosing block and have context for the line added, since they are not awaited there, thus most validation errors are thrown as UnhandledPromiseRejection. I was tempted to duplicate the try/catch block within both promises, but that would be quite lengthy. Why did you choose the promise approach? The problem is sequential and each promise waits for the result of the previous, so there is no parallelism. I was tempted to refactor that, but thought you might want it.

Some other things not addressed in this PR:

Your breakpoint extension instruction is written debugger for your assembler and printed as dbg by your debugger. Which do you consider canonical? This difference makes the output of the disassembler not able to be fed into the assembler.
wsa-tests/count.wsa uses test, presumably from Burghard, but it is not supported by your assembler.

I found that any exceptions thrown within the promises cannot be caught by the enclosing block and have context for the line added, since they are not awaited there, thus most validation errors are thrown as UnhandledPromiseRejection. I was tempted to duplicate the try/catch block within both promises, but that would be quite lengthy. Why did you choose the promise approach? The problem is sequential and each promise waits for the result of the previous, so there is no parallelism. I was tempted to refactor that, but thought you might want it.

Mhh I'm not sure where the UnhandledPromiseRejection happens. In theory Promise.resolve().then(() => { throw "foo" }) should return a promise that rejects (so it can be handled from outside). All of the promises are added into the results array and then awaited through Promise.all, which also handles it correctly. The promise returned by the compile function should be capturing all of the errors.
I didn't add promises for concurrency, but to not constraint the compiling process into a synchronous operation. I know NodeJS has sync APIs to read files, but by abstracting it to the getIncludedStream: (filename: string) => LineStream makes it asynchronous. The Promises then are just a way of wrapping and working around this.

Your breakpoint extension instruction is written debugger for your assembler and printed as dbg by your debugger. Which do you consider canonical? This difference makes the output of the disassembler not able to be fed into the assembler.

Good point. I think the canonical should be dbg - Feels a bit more consistent with the compact nature of the others.
I'll probably also change the "debugExtensions" into something which is not just "debug", as that also includes bitwise opcodes. Or maybe split into different flags.

wsa-tests/count.wsa uses test, presumably from Burghard, but it is not supported by your assembler.

Yes, I see it was from very early on while I was still implementing the initial version.

Thanks for your review! I see I missed the email notification from two weeks ago; sorry about that.


Bump libloading to 0.8

That's pretty rapid, the update is only out for 3 hours 😅... Any update on what's new in this semver-breaking release, why we need it, and if it needs to be backported to the latest stable release?

Oh! Sorry, I didn't mean to make it seem like this was urgent. 😅 I just happened to be in the right place at just the right time to notice this bump.
The only major change I'm aware of is that libloading switched from winapi to windows-sys, which I'm excited for since it slims down my dependencies. I figured it was a quick change to make and wanted to be helpful. 🙂

Okay thanks, ditching winapi is definitely worth upgrading for. I'll do some extra scanning of the changelog to make sure this doesn't change any other semantics. However, as libloading is technically part of our public API in LoadingError::LibraryLoadFailure we cannot backport this to the current stable release.
The next breaking ash release is something I'd like to slowly start creeping towards though as we've accumulated quite a few useful breaking features now, but it is also right around this time that a lot of technically breaking changes are flowing in and I'd rather see that stabilize first.

libloading switched from winapi to windows-sys

Hmm, isn't the latest guidance to use windows-bindgen?

However, as libloading is technically part of our public API in LoadingError::LibraryLoadFailure

Perhaps we should fix this.

@Ralith windows-bindgen is the way to go, yes, but it's fairly new and I hope libloading can migrate to that without yet another breaking bump. Regardless, I've asked about it at https://github.com/nagisa/rust_libloading/pull/120#issuecomment-1503920648 though Jake might perform this conversion soon enough.
I'm fine dropping libloading from the public thiserror-like enum fwiw, but can only do that on main again.

@MarijnS95 If you closed my PR for this, when this PR would be merged? It's been half a year already.

@AngelicosPhosphoros it's been merged now?

Hooray!


Authentication

@shivang-16 assign me this issue under hacktoberfest to start working,

What home page before login? Can you explain it properly

What home page before login? Can you explain it properly

As I tried to login to the application it's not getting me to the home page after the successful authentication even. It stopped on saying the "free plan activated" only.
Is the data flow for authentication has been completed if not I will love to fix this.

Mentor web flow is like this .. Authentication > Mentor details > Verfication page > Dashboard
After admin verify the mentor then only dashboard is accessible...
Is there any problem in this flow? then share it with image


Lack of correspondence of marker order

Moving a marker on the marker page does not change the placement of the corresponding annotation line in the session display. Consequently, this should also change according to the drag & drop movement.

@TS-Stefan saw a sort statement for the marker annotation line sequence. Any reason for that sort statement? Otherwise the sorting order from the toolbar should be taken over

@markusrombach07 As discussed today, the fix is available with version 0.9.25 which is installed on the website. Closing this issue, please reopen if you face further problems with this topic.


Add Rust query modules infrastructure

The goal of this PR is to write a Rust wrapper for Memgraph query modules.
TODOs

[x] Decide how the library code will be tested and implement initial tests.

Probably the best mock framework is mockall.
The final approach is borrowed from here.

[x] Decide about workspace or implementation of the custom build process.

Workspaces and custom build both don't seem feasible (more info).
The decision is to go with a separated rsmgp-sys crate.
All query modules will be standalone projects (similar to the CPP structure).

[x] Add initial CI workflow.
[x] Implement and test all primitive value functions (null, bool, int, string, double).

[x] Implement struct rsmgp_sys::context::Memgraph containing args, graph, result, memory.

[x] Implement all properties related.
[x] Implement all vertex related.
[x] Implement all edge related.

[x] Implement wrapper and test set_error_msg.
[x] Polish regular error handling via MgpResult.

[x] Implement all path related.
[x] Implement all list related.
[x] Implement all map related.
[x] Implement all graph related.

[x] Setup code coverage on CI.
[ ] Implement top-level Python build capabilities.

[x] Test all properties related.
[x] Test all vertex related.
[x] Test all edge related.
[x] Test all path related.
[x] Test all list related.
[x] Test all map related.
[x] Test all graph related.

[x] Write macro for XYZ_procedure_c (try to minimize boilerplate code).
[x] Implement and test utils for defining returning structure and inserting results (types enum, macros).
[x] Add catch_unwind everywhere.
[ ] Write documentation.
[ ] Publish rsmgp-sys crate on crates.io.
[ ] Link all the live stream videos here!
[ ] Write a blog post about how to use rsmgp in complex environment, use rsmgclient.

[ ] Use mgp_memory and allocator C functions:

Resources:

https://doc.rust-lang.org/1.9.0/book/custom-allocators.html
https://stevenlr.com/posts/handmade-rust-1-allocators/
http://smallcultfollowing.com/babysteps/blog/2014/11/14/allocators-in-rust/
https://os.phil-opp.com/heap-allocation/#the-global-allocator-attribute
https://doc.rust-lang.org/std/alloc/index.html
https://doc.rust-lang.org/std/vec/struct.Vec.html#impl-1
Store something "globally" -> thread local storage key

@antaljanosbenjamin & @jmatak please leve high-level comments first because the code is not polished yet

Have you thought about implementing the IntoIterator trait for the iterable types? It would hide the error handling in some way but would make the for loops easier.

Have you thought about implementing the IntoIterator trait for the iterable types? It would hide the error handling in some way but would make the for loops easier.

Nope, I don't quite understand how would it make the for loops easier?  It would hide the error handling in some way but would make the for loops easier.

I think I'm going to quit this idea as well because e.g., ListIterator has &List that needs the lifetime specifier. While implementing the IntoIterator trait, it's not possible to specify the lifetime...


Can this be used to control the external unit without indoor unit?

Hi @marekorok,
I was wondering if this can be used to talk directly to external unit, skipping the internal unit?
Looking to convert Rotenso to heat pump and would get only the external unit.
Thanks!

Hi Tomek,
sorry for late reply.
Very likely it will not work
The internal unit communicates with external over proprieraty Midea protocol and the XYE connectors, and here we are using AB connect, standard modbus over RS485.
Disclaimer I might be totally wrong and somebody already implemented it, but I  never seen it.
You can check these threads:
https://community.home-assistant.io/t/midea-branded-ac-s-with-esphome-no-cloud/265236/711?page=36
https://renewableheatinghub.co.uk/forums/renewable-heating-air-source-heap-pumps-ashps/real-world-connection-to-a-heat-pump-over-modbus/paged/3
Cheers


<EMAIL_ADDRESS>is not compatible with the current JupyterLab

Having attempted to install I get:
(base) Robins-MBP:~ robincole$ jupyter labextension list
JupyterLab v0.35.4
Known labextensions:
   app dir: /Users/robincole/anaconda3/share/jupyter/lab
        @jupyter-widgets/jupyterlab-manager v0.38.1  enabled  OK
        @jupyterlab/plotly-extension v0.18.2  enabled  OK
        jupyterlab-chart-editor v1.1.0  enabled  OK
        jupyterlab-sql v0.3.0  enabled   X
        plotlywidget v0.11.0  enabled  OK

<EMAIL_ADDRESS>is not compatible with the current JupyterLab
Conflicting Dependencies:
JupyterLab              Extension        Package
>=0.19.1 <0.20.0        >=1.0.0 <2.0.0   @jupyterlab/application
>=0.19.1 <0.20.0        >=1.0.0 <2.0.0   @jupyterlab/launcher

You need jupyterlab-1.0

OK I am experiencing this https://stackoverflow.com/questions/56530454/cant-upgrade-jupyterlab-to-latest-version

@stonebig thanks for fielding this.
@robmarkcole -- the README has installation instructions for installing jupyterlab-sql compatible with JupyterLab 0.35.x.


[Dubbo-3682]Correct @Parameter config of field of ConfigCenterConfig

What is the purpose of the change
Fix #3682
Brief changelog
XXXXX
Verifying this change
XXXXX
Follow this checklist to help us incorporate your contribution quickly and easily:

[x] Make sure there is a GITHUB_issue field for the change (usually before you start working on it). Trivial changes like typos do not require a GITHUB issue. Your pull request should address just this issue, without pulling in other changes - one PR resolves one issue.
[ ] Format the pull request title like [Dubbo-XXX] Fix UnknownException when host config not exist #XXX. Each commit in the pull request should have a meaningful subject line and body.
[ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
[ ] Write necessary unit-test to verify your logic correction, more mock a little better when cross module dependency exist. If the new feature or significant change is committed, please remember to add integration-test in test module.
[ ] Run mvn clean install -DskipTests=false & mvn clean test-compile failsafe:integration-test to make sure unit-test and integration-test pass.
[ ] If this contribution is large, please follow the Software Donation Guide.

I will merge this pr.


Feature Requests

Hi Erik,
Not sure if this is the right spot to ask for feature requests. I am really liking this Project, it has become verify useful for my school.
In Profile Creator I would LOVE to see a way to:

Add Printers and set default
A place to add custom login screen background
Assigning admin rights to users.

Just my 2 cents. Thanks for all your hard work.

Profile creator is only able to create profiles, so if the profile exist to set something, i can imolement it.
There is a printer payload but many think its not working, i will add that though.
2 and 3 i Cant help you with as there are No profiles that  can set those things so you need to manage that using some other method than a profile.

Jason,
Join the MacAdmins Slack Team and you will find answers to all your questions. More info here: https://macadmins.slack.com
Once you join if you search the archives you will be directed to:
https://github.com/munki/munki/wiki/Managing-Printers-With-Munki to automate adding printers and adding "lpoptions -d NameOfPrinter" to your install script to set the default printer
Also, Rich Trouton’s Privileges app https://github.com/SAP/macOS-enterprise-privileges for managing admin rights
Eric Gomez’s instructions for modifying or customizing the login screen background here: https://blog.eriknicolasgomez.com/2016/09/24/apples-efi-logonui-managing-macos-sierras-wallpaper/
See you on Slack.

Thanks Roodavis. I've been meaning to get on Slack. Thanks for the nudge.


[Bug]: Missing Specific File (tls-client-linux-ubuntu-amd64-1.7.6.so) in Latest Release

TLS client version
v1.7.6
System information
Linux/Ubuntu on Heroku
Issue description
tls-client-linux-ubuntu-amd64-1.7.6.so is missing from the newest release which breaks the noble_tls library that I use for asynchronous TLS.
Steps to reproduce / Code Sample
Starting a project with noble_tls will try to pull the .so file from the latest release of tls-client but since the tls-client-linux-ubuntu-amd64-1.7.6.so file is missing, it's crashing my script immediately. It used to work fine with 1.7.5 on tls-client because that file was there.

@shubhamshah02 my bad. added the files here: https://github.com/bogdanfinn/tls-client/releases/tag/v1.7.6


[WIP]Support for gradle 2.5+

!!!WARNING!!!!! TEST WERE NOT RUN YET

renamed gdx-box2d module to gdx-box2d-parent
renamed gdx-controlled module to gdx-controller-parent
upgraded android plugin from 1.2.3 to 2.1.0

Uhm, I'm not sure what you are trying to do, but this is not something we'd merge even if it passed any tests.

I've participared in recent chat in IRC channel with mentions that current libgdx src is not buildable with latest gradle.
So, i was trying to fix this "issue".
I do agree with your decision, because I made changes that affect the whole project structure and require HUGE amount of tests to be done.


Send a list of past leads - by year - to Vishnu

2015

Mechanical: Rocely Mati
Electrical: Colin Chen
Controls: Matthew Boyd
Mission Control: Khalil Estell
President/Project Lead: Khalil Estell
Treasurer: Rocely Mati

2016

Mechanical: Alfred (Andy) Bru
Electrical: Colin Chen
Controls: Matthew Boyd
Mission Control: Henry Tran
President/Project Lead: Khalil Estell
Treasurer: ???

2017

Mechanical: David Cruz
Electrical: Sean Setterfield
Controls: Matthew Boyd
Mission Control: Alissa Sandore
President/Project Lead: Khalil Estell
Treasurer: Christian Timbol

2018

Mechanical: Zeng Zhaoyi
Electrical: Jeff Normand
Controls: Matthew Z Chew
Mission Control: Ari Koumis
President/Project Lead: Kevin Gallegos
Treasurer: ???

2019

Mechanical: Jonathon Nguyen
Electrical: Nathaniel Ciceron
Controls: Matthew Z Chew
Mission Control: Evan Ugarte
President/Project Lead: Ari Koumis
Treasurer: ???

2020
Well y'all know the rest. :P
This is all that I know.


Can vsvg be run during webpack build?

Could the vsvg command that is run manually now be set up to automatically run on each build? Would this be a supported feature or something that could be added? That way I could drop any new svg files into my icons directory, and webpack would automatically take care of it and I could use the vue-svgicon tag in my vue components immediately.

Especially useful for development mode using webpack-dev-server, the workflow isn't ideal right now as I'd like these icon files to be handled the same as all other development assets and JS files during production, rather than them needing to exist somewhere on the filesystem versus everything  else not needing that.

Would you consider adding a webpack loader at some point for this?

If it's added then this package wouldn't need to handle svgo, because if it's part of a standard webpack build then we could just use the svgo-loader with the loader for vue-svgicon to take care of that.

The next major version is add this feature, please try it and feedback. https://github.com/MMF-FE/vue-svgicon/tree/dev

Any documentation for how to use the new feature? Didn't see anything in the readme.

Any documentation for how to use the new feature? Didn't see anything in the readme.

https://github.com/MMF-FE/vue-svgicon/tree/dev


0.81.3 - bugrasitemkar

0.81.3 - bugrasitemkar

Hi Bugra,
Thank you for sending a PR. If you don't mind, I added a link to your Github profile, and together with the rest, merged your changes and published it! 👍
https://wealth.forcrowd.org/app/contributors
If you would like to update your info later on, feel free to send me a new request.
Let me know if you had any issues, and/or whether the instructions were clear.
And if you would like to get updates about our projects, you can follow us on twitter:
https://twitter.com/forCrowd


Add customizable clips_input property to Control

Enables clips_input as a modifiable property to complement clip_contents. See https://github.com/Cryszon/godot-clips-input-example for an example project.
This allows overriding clips_input for GraphEdit and ScrollContainer, but I think the clip_ contents already does the same thing. I used the original clips_input as the name, but was wondering if it should be renamed to clip_input to be more consistent with the existing clip_contents.
This is my first time contributing to Godot so hopefully I'm doing it right. Feedback and guidance is appreciated. I posted this on Discord yesterday but didn't get a reply so I thought I'd go ahead and make the pull request.

Sorry for the delay, PRs from December/January got piled under a huge backlog due to the 3.0 release...

Should I update this so that clip_contents also sets clips_input and remove the property?

I think it would be worth discussing yes, would you update this PR for that?

Sorry I couldn't get back to this during the weekend. Thanks for the fix!


fix(curriculum): Removed undesired quotations from steps[25-28]

Checklist:

[x ] I have read and followed the contribution guidelines.
[ x] I have read and followed the how to open a pull request guide.
[ x] My pull request targets the main branch of freeCodeCamp.
[ ] I have tested these changes either locally on my machine, or GitPod.

Closes #54558

Hi 👋🏽
Thanks for your PR. PR 54559 has already fixed the issue and it's merged. So, I'm gonna go ahead and close this.


Compiling a wallet on ubuntu

Hello, i am trying to compile a wallet on a ubuntu 14 32-bit wallet and i always get a strenge error, i looked everywhere in the web but i found nothing.
lcrypto -lgdi32 -lole32 -luuid -lws2_32 -ladvapi32 -lshell32 -luser32 -lkernel32
/home/ubuntu/build/blumedtoken/src/leveldb/libmemenv.a: could not read symbols: Archive has no index; run ranlib to add one
collect2: ld returned 1 exit status
make[1]: *** [release/blumedtoken-qt.exe] Error 1
make[1]: Leaving directory `/home/ubuntu/build/blumedtoken'
make: *** [release] Error 2
The coin in question is blumedtoken.

My guess is that libmemenv.a is an archive for a different platform. Try:
file /home/ubuntu/build/blumedtoken/src/leveldb/libmemenv.a
and see what it reports. Further questions are better asked on the discussion group.

I am also facing the same issue, did you find any solution?


Not showing correct value with format dd/MM/yyyy

Hi, I'm trying to use datepicker with another format, it shows correctly the value when I'm selecting, but when I pass a value it not respect the format:
<datepicker format="dd/MM/yyyy" value="01/05/2017"></datepicker>
It shows 05/01/2017, I'm missing something??

if you pass a string value to the prop it will try to construct the Date object with that.
Try typing new Date('01/05/2017') in your Chrome developer tools console.


Updated example on data containers.

Integration from https://github.com/mne-tools/mne-python/issues/3725.

Current coverage is 87.40% (diff: 100%)

Merging #3751 into master will decrease coverage by 0.01%

@@             master      #3751   diff @@
==========================================
  Files           343        343
  Lines         60976      60976
  Methods           0          0
  Messages          0          0
  Branches       9320       9320
==========================================
- Hits          53309      53297    -12
- Misses         4921       4931    +10
- Partials       2746       2748     +2

Powered by Codecov. Last update 6c2e222...b6de3b7

👍

thx heaps @jaeilepp


signature#SignRefresh() is too slow

Every time when I jump to another buffer vim call SignRefresh
which execute 5 second :(
It is too slow ...
FUNCTION  signature#SignRefresh()
Called 2 times
Total time:   5.150196
 Self time:   0.018367

count  total (s)   self (s)
                              " Description: Add signs for new marks/markers and remove signs for deleted marks/markers
                              " Arguments: '1' to force a sign refresh

    2              0.000045   if !exists('b:sig_marks')   | let b:sig_marks   = {} | endif
                                " b:sig_marks   = { lnum => signs_str }
    2              0.000029   if !exists('b:sig_markers') | let b:sig_markers = {} | endif
                                " b:sig_markers = { lnum => marker }

                              " If Signature is not enabled, return
    2              0.000030   if !exists('b:sig_enabled') | let b:sig_enabled = g:SignatureEnabledAtStartup | endif
    2              0.000018   if !b:sig_enabled | return | endif

    2              0.000052   let l:SignatureIncludeMarks = ( exists('b:SignatureIncludeMarks') ? b:SignatureIncludeMarks : g:SignatureIncludeMarks )
    2   0.010115   0.000116   let l:used_marks = map( copy(s:MarksList( "used" )), 'v:val[0]')

  106   0.010820   0.000664   for i in s:MarksList( "free" )
                                " ... remove it
  104   5.118709   0.016436     call s:ToggleSign( i, "remove", 0 )
  104              0.000381   endfor

                              " Add signs for marks ...
    2   0.009584   0.000183   for j in s:MarksList( "used" )
                                " ... if mark is not present in our b:sig_marks list or if it is present but at the wrong line,
                                " remove the old sign and add a new one
                                if !has_key( b:sig_marks, j[1] ) || b:sig_marks[j[1]] !~# j[0] || a:0
                                  call s:ToggleSign( j[0], "remove", 0 )
                                  call s:ToggleSign( j[0], "place", j[1] )
                                endif
                              endfor

                              " We do not add signs for markers as SignRefresh is executed periodically and we don't have a way to determine if the
                              " marker already has a sign or not

I still have some issues with this. It's fairly fast, but not fast enough to feel smooth.
In order of slow to faster, these functions I profiled cause the most trouble.
signature#sign#Refresh()
signature#mark#GetList()
signature#sign#Remove()
signature#utils#Set()
signature#sign#ToggleDummy()

@Alok Can you describe your specific scenario? i.e. whatever you're doing to make it slow.


Screens are not cleared when calling navigator.replaceAll

Suppose our rootNavigator is configured with the following disposeBehavior field:
NavigatorDisposeBehavior(
   disposeNestedNavigators = false,
   disposeSteps = true,
)

And it contains the navigation stack: A -> B -> C
Screen B also contains a nested navigator (for example, this could be a TabScreen) with the stack B1 -> B2 -> B3.
In turn, within screens B1, B2, B3, there are some view models.
From screen C, we perform a rootNavigator.replaceAll action to screen D.
Current Behavior:

View models on screens B1, B2, B3 are not cleared (because StepDisposableEffect does not perform recursive clearing of screens).

Expected Behavior:

View models on screens B1, B2, B3 are cleared.

It seems logical to me if ViewModels were cleared as soon as the screen they were attached to disappeared from the navigation stack.
This is a critical issue for building hierarchical navigation. Are there any plans to fix this?

My current workaround is:

When i create navigator i associate it with the Screen where it was created
Use custom StepDisposableEffect which disposes screens recursively

Sample code:
class TestScreen : Screen {

  @Composable
  override fun Content() {
    Navigator(ChildScreen()) { navigator ->
      StepDisposableEffect(navigator)
      NavigatorsRegistry.associate(this@TestScreen, navigator)
    }
  }
}

@OptIn(InternalVoyagerApi::class)
@Composable
internal fun StepDisposableEffect(
  navigator: Navigator,
) {
  val currentScreens = navigator.items

  DisposableEffect(currentScreens) {
    onDispose {
      val newScreenKeys = navigator.items.map { it.key }
      if (navigator.lastEvent in setOf(StackEvent.Pop, StackEvent.Replace)) {
        currentScreens.filter { it.key !in newScreenKeys }.forEach { screen ->
          navigator.dispose(screen)
          disposeRecursively(screen)
        }
        navigator.clearEvent()
      }
    }
  }
}

private fun disposeRecursively(screen: Screen) {
  val screenNavigators = NavigatorsRegistry.getAssociated(screen)

  screenNavigators.forEach { navigator ->
    navigator.items.forEach { descendantScreen ->
      disposeRecursively(descendantScreen)
    }
    disposeNavigator(navigator)
  }

  NavigatorsRegistry.clear(screen)
}

@OptIn(InternalVoyagerApi::class)
private fun disposeNavigator(navigator: Navigator) {
  for (screen in navigator.items) {
    navigator.dispose(screen)
  }
  NavigatorLifecycleStore.remove(navigator)
  navigator.clearEvent()
}

But I don't think this is the best way
I would like to have recursive cleanup at the library level

What would the disposeNavigator function be in your workaround? @shpasha

I suspect the ViewModels of B1, B2, B3 are not cleared because TabNavigator internally calls navigator.replaceAll(tab) when setting the current tab.
If they were cleared when calling replaceAll, that would mean that every time you jump to a new tab, the ViewModels for the other tabs would get disposed. That would lead to a whole new issue.
I think that ultimately the handling of tabs should be separated from the handling of individual screens, as the current implementation brings restrictions like this one.
The current easiest solution would be to provide a function that disposes of all tabs and their scopes inside a tab navigator as if disposeNestedNavigators was set to false.

I believe the solution I've come up with for https://github.com/adrielcafe/voyager/issues/402 may also help this issue.


Add 3.9 CI support. Also add some classifiers to setup.py

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@7a2ce2f). Click here to learn what that means.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master      #17   +/-   ##
=========================================
  Coverage          ?   97.77%
=========================================
  Files             ?       16
  Lines             ?     1301
  Branches          ?        0
=========================================
  Hits              ?     1272
  Misses            ?       29
  Partials          ?        0

Continue to review full report at Codecov.

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


is HDBSCAN model export possible?

Ask the question
Is it possible to export HDBSCAN model via ONNX? No such functionality exists in Python as far as I am aware.
Is your question about a specific ML algorithm or approach?
This is about clustering, specifically the HDBSCAN method
Is your question about a specific Tribuo class?
HdbscanModel.java
System details

Tribuo version
Java version (if appropriate)
OS/Architecture (if appropriate)

Additional context
It would be great if I can get some general pointers on how export/import of HDBSCAN could be achieved.

The HDBSCAN algorithm doesn't naturally have a predict method for determining the cluster assignment of a new point, as strictly speaking a new point could change the clustering of all the rest of the data. In Tribuo (and also in this Python scikit-learn-contrib HDBSCAN implementation) the prediction method is approximate and based on the nearest neighbour keypoints. It would be possible to export that nearest neighbour search into ONNX, but we've not done that for any of Tribuo's nearest neighbour prediction models (K-NN, K-Means, HDBSCAN) yet, and also as ONNX doesn't naturally have a nearest neighbour op it would bake in an exhaustive search of the keypoints (e.g. in the way this scikit-learn K-NN ONNX converter does - https://github.com/onnx/sklearn-onnx/blob/main/skl2onnx/operator_converters/nearest_neighbours.py#L64). We'd accept contributions to add that kind of export support, otherwise it's on the backlog of ONNX model export features and we'll get to it at some point in the future.
Tribuo is unlikely to ever support importing a HDBSCAN model into the HdbscanModel class, though with a small amount of additional work we could support loading in an ONNX clustering model (currently Tribuo is missing the ClusterID version of this output adaptor class which would be straightforward to add).


add external cache storage

It'd be nice to have an option to store state, failure count for each created object in a provided external storage like redis (implementation would be up to the user). This will ensure circuitbreaker has shared behaviour across deployed instances of the same app.

I agree with @ark-balandin  I would make sure to add support for upstash too on top of Io redis.

@Cliftonz @ark-balandin Well, thank you for waiting! It was published in https://github.com/SocketSomeone/nestjs-resilience/releases/tag/2.0.0