Add GraphQL support to API Docs

Hey, I just made a Pull Request!
This is a quick & rough experiment for adding support for graphql API types.

Using graphiql for now. Most solutions for generating docs from graphql SDL schemas are tailored for generating static sites (e.g. https://github.com/2fd/graphdoc) and not dynamically. GraphiQL has a docs explorer but it's not ideal for documentation only. If anyone knows of something else that would be great.
Styling is really rough (borrowed from plugins/graphiql)

Future

Loading the API spec definition from an external location would be ideal. Possibly this could be done with locations (e.g. #2001)
Would be interesting to extend the API catalog model to support annotations to indicate the URL to a live instance (possibly including params for any required headers, etc.).

:heavy_check_mark: Checklist

[ ] All tests are passing yarn test
[ ] Screenshots attached (for UI changes)
[ ] Relevant documentation updated
[ ] Prettier run on changed files
[ ] Tests added for new functionality
[ ] Regression tests added for bug fixes

Eventually we may want to use something like prismjs, which seems to have graphql support https://prismjs.com/#supported-languages

Eventually we may want to use something like prismjs, which seems to have graphql support https://prismjs.com/#supported-languages

@freben - That's actually a great idea for the PlainApiDefinitionWidge, I created #2170 🎉

Hey again! Now with #2170, where do we go with this PR? :) Would you like to switch to prism or get this in as-is?

Hi @freben - Sorry, been focused on other things.
This started as a quick experiment to see what might be possible. I did implement #2170 which potentially added syntax highlighting using the CodeSnippet component. I thought it was actually using prism under the covers but it is using hljs which is the default for react-syntax-highlighter and doesn't include graphql syntax (even thought it looks decent :). The CodeSnippet component could in theory be updated to use prism as it is supported by react-syntax-highlighter. However, that likely would break styling so opting for a new component might be better.
Anyways, that aside, I'm open to merging then once I fix the styling, but I'm not hugely fond of this particular setup. I would have preferred if you could extract or make the docs more prominent with graphiql but they API seems limited. There is a complete revamp happening for v2 which could make this more feasible. I haven't been able to find any graphql react based dynamic docs specific viewers unfortunately.
Another option could be to have the API entity support something like an external URL reference instead of an inline definition and then have an embedded iframe or use shadow dom to render the external API. Internally we use graphdoc right now which generates the side dynamically. This could be a more general purpose option as well.
cc @Fox32, @dhenneke

Hey! I felt so bad for merging PRs in the wrong order - a younger one got in first and now it conflicted with yours - I took the liberty of rebasing and fixing the conflicts and pushing a branch to our repo with the same name as yours https://github.com/spotify/backstage/compare/api-docs-graphql
Feel free to hard-reset to that one or so to save time. Sorry for the noise :)

@freben - No problem at all. I actually need to confirm this also doesn't break support for displaying multiple implemented apis for a single component (e.g. openapi + graphql, etc.).

Another option could be to have the API entity support something like an external URL reference instead of an inline definition and then have an embedded iframe or use shadow dom to render the external static generated API docs. Internally we use graphdoc right now which generates the side dynamically. This could be a more general purpose option as well.

I'm not sure if we want that. It can be useful to have the raw API description/schema for other means (linting, indexing/searching, etc).
But it might be a good idea to make ApiDefinitionWidget configurable in the future, or even move it from the plugin to the app. This way each instance can compose its own display for the individual APIs. Maybe one wants to use GraphiQL while others just want to show a link/iframe to an externally hosted documentation. Or maybe one want to display special annotations from the Component->API relationship (after #1964 has landed) like an API endpoint, authorization/access scope, …. The api-docs plugin then provides common default widgets that can be exchanged with custom ones if needed.

Another option could be to have the API entity support something like an external URL reference instead of an inline definition and then have an embedded iframe or use shadow dom to render the external static generated API docs. Internally we use graphdoc right now which generates the side dynamically. This could be a more general purpose option as well.

I'm not sure if we want that. It can be useful to have the raw API description/schema for other means (linting, indexing/searching, etc).
But it might be a good idea to make ApiDefinitionWidget configurable in the future, or even move it from the plugin to the app. This way each instance can compose its own display for the individual APIs. Maybe one wants to use GraphiQL while others just want to show a link/iframe to an externally hosted documentation. Or maybe one want to display special annotations from the Component->API relationship (after #1964 has landed) like an API endpoint, authorization/access scope, …. The api-docs plugin then provides common default widgets that can be exchanged with custom ones if needed.

@dhenneke - This makes sense to me. I also don't like having to add hints into the API entity spec to drive the UI specifically. Having the ability for people to swap out the viewer of choice for a particular API definition makes most sense (especially if the api-docs plugin provides the components to compose them easily).


Terminate ServerApp when the server fails to start up

Fixes #911

This is going to need care as it merges back through 0.16 and 0.17.

Codecov Report

Merging #1090 into release-0.15.x will decrease coverage by 0.03%.
The diff coverage is 0%.

@@                Coverage Diff                 @@
##           release-0.15.x    #1090      +/-   ##
==================================================
- Coverage           69.05%   69.02%   -0.04%
==================================================
  Files                 211      211
  Lines                4431     4432       +1
  Branches              453      445       -8
==================================================
- Hits                 3060     3059       -1
- Misses               1371     1373       +2

Impacted Files
Coverage Δ

...r/src/main/scala/org/http4s/server/ServerApp.scala
0% <0%> (ø)
:arrow_up:

core/src/main/scala/org/http4s/Uri.scala
83.63% <0%> (-1.82%)
:arrow_down:

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 022cd42...b74f265. Read the comment docs.


Positional variable binding not working in java

Hello,
I wanted to use this feature to be able to store filtered element indexes like this doc example :
library.books#$i['Kernighan' in authors].{
'title': title,
'index': $i
}
It works well on the exerciser page which is based on the javascript version of this library but not with java where I get a Parsing exception :
com.api.jsonata4java.expressions.ParseException: line 1:13 at null: token recognition error at: '#'
, line 1:14 at [@3,14:15='$i',<47>,1:14]: mismatched input '$i' expecting {, '.', 'in', '?', '[', '{', '~>', '*', '/', '+', '-', '%', '=', '!=', '<', '<=', '>', '>=', '&', '^', 'and', 'or'}
Is it a bug or this feature is simply not supported by the java version ? If not is it planned ?
Thanks in advance.

All right thanks for the answer !


Some SERP pages don't work

For example this link doesn't show any SERPs
https://www.tira.io/serp/ir-benchmarks/user/tira-ir-starter/dataset/cranfield-20230107-training/10/2023-01-07-14-34-01

Indeed, this should not happen, I look into this.
I remember that the script that I used to unblind runs where possible had some failed REST calls, but in those cases the button should not be shown, so it is in any way a bug.
Best regards,
Maik


conflicting definitions of content of "entries"

There are currently two, conflicting definitions of the basic content of an "entry"

Section 4.1.2 describing the case of multiple entries
Section 6.1 describing properties used by multiple entry types

First of all, having two definitions seems unnecessary, since 4.2.2 states:

The response for a 'single entry' endpoint is the same as for 'entry listing' endpoint responses, except that the value of the "data" key MUST have only one entry.

Second, one needs to decide for one of the two, in particular

local_id vs id
last_modified vs modification_date
immutable_id vs nothing

I'm not sure whether this decision has already been made at some point and just hasn't found its way into the spec yet, could someone please comment on that?
Let me just reiterate that modification_date is a standard field in JSON schema as already pointed out in #1
Edit: Issue #1 has been fixed in PR #77, keeping only last_modified.

I'm sure the writing/organization of things can be improved and clarified, but I don't see a bug other than that last_modified in Sec 4.1.2 should be the jsonapi mandated modification_date as was reported in #1.
Note that Section 6.1.1 doesn't say that the fields it lists are the ones (and the only ones) that should appear in any specific output. 6.1.1 is really just intended mostly as an 'appendix' that lists field names and gives more precise details on how they are defined, wherever they appear in the output. The requirements for what MUST and MAY be included in a response is meant to be in section 4. So, if you are wondering if you should be reading section 4 or 6 to know which fields needs to be in some specific output, the answer is section 4.
The three ID fields were an intentional result from the 2016 workshop, with the following intent:

id is the jsonapi mandated id that sits at top level. This is an id that OPTIMaDe puts some requirements on in 6.1.1. Hence, it is possible that for some databases this cannot be their own preferred id.
local_id, on the other hand, has no requirements whatsoever. Here databases get to communicate their own ids for each record.
immutable_id should be used if the database preferred id points to something that may change. Some databases like to use a preferred id to point to "the latest version" of a record, but do still keep around older versions. In such cases, immutable_id MAY be provided to give information about what id can be used to find the precise version that was returned, in case this record changes in the future.

Where is modification_date mandated in https://jsonapi.org/format/1.0/ ? I would like a field in "attributes" mandated for all entry responses, either last_modified or modification_date.

Where is modification_date mandated in https://jsonapi.org/format/1.0/ ? I would like a field in "attributes" mandated for all entry responses, either last_modified or modification_date.

modification_date is defined not in JSON API, but in OPTiMaDe's JSON API. I agree this is quite confusing.

immutable_id vs nothing

@ltalirz I feel that immutable_id must stay in the spec as an optional field. It's use is comparable to a permalink. Providers who can't serve it can just skip the field.

I see. I now realize that when originally opening the issue, part of what I thought needed changing came from a misunderstanding of the headline "Properties used by multiple entry types" of section 6.1.
I may have confused "properties" (which in JSON simply means key-value pair) with "attributes" (which for entries e.g. do not contain an id field etc.).
In my defense, I would like to point out that we have a definition of the term "property" in the spec but it says

Property: Anything that can be in the filtering of results.

which differs a bit from the JSON definition linked above.
Two points:

If we agree that the intention in section 6.1 was to mean "properties = key-value pairs", then I think we can consider this issue resolved.
It might be worth clarifying the meaning of "property" vs the JSON definition in the spec and then, potentially, adapt the wording of 6.1 to make things clear.

Two points:

If we agree that the intention in section 6.1 was to mean "properties = key-value pairs", then I think we can consider this issue resolved.

In a discussion between @rartino, @giovannipizzi, @merkys, and myself, we found/agreed that it is not just attributes that are properties, but also, e.g., type and id. The fact they they are output at the same level as attributes is only to show that they are special properties and MUST always be present for a resource object.

It might be worth clarifying the meaning of "property" vs the JSON definition in the spec and then, potentially, adapt the wording of 6.1 to make things clear.

An issue has been opened for this; #109.

@CasperWA The link seems correct - here is the quote

Objects are the mapping type in JSON. They map “keys” to “values”. In JSON, the “keys” must always be strings. Each of these pairs is conventionally referred to as a “property”.

I cannot find this in the actual spec anywhere, but this is fine.
If we simply restrict a property to be a set of key-value-pairs only under the top-level data field, then all is good and fine, I think. It would make type, id, attributes and all fields under attributes (including their respective values) properties, effectively. Which is fine, I think. However, I will refer to issue #109 for further discussion of this.

The definition of "property" in PR #126 is consistent with point 1 in my comment.
So, this issue can be closed.


Add tests for cache-control header using http_spec

Write tests under /http to assert if the cache control headers are being forwarded correctly when set in any upstream responses. Also test if minimum is computed correctly in case multiple requests sent upstream have different cache control headers.

/bounty 50$

@tusharmath Can I work on this 🙋🏻

Hi @tusharmath, it's taking a bit longer to understand the LSP server codebase(re: #579). I will keep working on it. But, can I tackle this first? Would love a break from typescript and do rust 🦀.
/attempt

@A-N-uraag Let's welcome @ezhil56x to the tailcall community and give him a chance :)

@ezhil56x If you need a hand feel free to reach out on #contributors on Discord :smile:

This is a small change, opening this issue up for everyone to pick up!


feat(cli): add warning on version mismatch between client and server. Fixes #9212

Fixes #9212
Motivation
This adds a warning message to the CLI when it detects a mismatch between the client and server versions.
Modifications
There was another PR (https://github.com/argoproj/argo-workflows/pull/11909) for this issue that implemented it by making a blocking API call to /api/v1/version in a PersistentPreRun hook. This PR takes a different approach: have the server send the version in a new header called argo-version, which the client will extract. There's several advantages to this approach:

Negligible performance impact, since no additional requests are needed.
Warning is only shown when the command would normally send an API request
Can be useful for bug triaging, since the header can be seen in curl output:$ curl -v http://localhost:2746/api/v1/info
* Host localhost:2746 was resolved.
* IPv6: ::1
* IPv4: <IP_ADDRESS>
*   Trying [::1]:2746...
* connect to ::1 port 2746 from ::1 port 62973 failed: Connection refused
*   Trying <IP_ADDRESS>:2746...
* Connected to localhost (<IP_ADDRESS>) port 2746
> GET /api/v1/info HTTP/1.1
> Host: localhost:2746
> User-Agent: curl/8.8.0
> Accept: */*
>
* Request completely sent off
< HTTP/1.1 200 OK
< Content-Type: application/json
< Grpc-Metadata-Argo-Version: latest+303bcce.dirty
< Grpc-Metadata-Content-Type: application/grpc
< X-Ratelimit-Limit: 1000
< X-Ratelimit-Remaining: 999
< X-Ratelimit-Reset: Fri, 20 Sep 2024 17:44:03 UTC
< Date: Fri, 20 Sep 2024 17:44:02 GMT
< Content-Length: 1392
<
* Connection #0 to host localhost left intact
{"managedNamespace":"argo","links":[{"name":"Workflow Link","scope":"workflow","url":"http://logging-facility?namespace=${metadata.namespace}\u0026workflowName=${metadata.name}\u0026startedAt=${status.startedAt}\u0026finishedAt=${status.finishedAt}"},{"name":"Pod Link",
"scope":"pod","url":"http://logging-facility?namespace=${metadata.namespace}\u0026podName=${metadata.name}\u0026startedAt=${status.startedAt}\u0026finishedAt=${status.finishedAt}"},{"name":"Pod Logs Link","scope":"pod-logs","url":"http://logging-facility?namespace=${met
adata.namespace}\u0026podName=${metadata.name}\u0026startedAt=${status.startedAt}\u0026finishedAt=${status.finishedAt}"},{"name":"Event Source Logs Link","scope":"event-source-logs","url":"http://logging-facility?namespace=${metadata.namespace}\u0026podName=${metadata.n
ame}\u0026startedAt=${status.startedAt}\u0026finishedAt=${status.finishedAt}"},{"name":"Sensor Logs Link","scope":"sensor-logs","url":"http://logging-facility?namespace=${metadata.namespace}\u0026podName=${metadata.name}\u0026startedAt=${status.startedAt}\u0026finishedA
t=${status.finishedAt}"},{"name":"Completed Workflows","scope":"workflow-list","url":"http://workflows?label=workflows.argoproj.io/completed=true"}],"modals":{"feedback":true,"firstTimeUser":true,"newVersion":true},"columns":[{"name":"Workflow Completed","type":"label",
"key":"workflows.argoproj.io/completed"}]}%

Exposing the version information has security implications, since it could be used by attackers to identify vulnerable Argo servers. To mitigate that, the header is not sent on 401 errors. Of course, if a user is exposing their Argo server to the internet without authentication, then an attacker could see this header, but then they've got bigger problems (and an attacker could just call /api/v1/version).
This is implemented on the client and server side using grpc-go interceptors. On the server side, there's interceptors to set the version header in the response. On the client side, there's an interceptor to check the response for the header and stash it in a global variable (which is obviously not ideal, but I couldn't think of a better way to handle that).
Verification
Testing process:

Manually changed the version to v9.99 here: https://github.com/argoproj/argo-workflows/blob/ce7f9bfb9b45f009b3e85fabe5e6410de23c7c5f/Makefile#L95
Ran make cli && cp dist/argo argo2
Ran git checkout Makefile && make start API=true
Ran ARGO_SECURE=false ARGO_TOKEN="Bearer $(kubectl get secret argo-server.service-account-token -o=jsonpath='{.data.token}' | base64 --decode)" ARGO_SERVER=localhost:2746 ./dist/argo2 list

Output:
No workflows found
WARN[2024-09-20T18:03:26.116Z] CLI version (v9.99+303bcce.dirty) does not match server version (latest+303bcce.dirty). This can lead to unexpected behavior.

The one test failure is pretty clearly unrelated, and seems to be due to resource issues:
 ErrImageNeverPull: Container image "quay.io/argoproj/argocli:latest" is not present with pull policy of Never

    artifacts_test.go:218: timeout after 1m30s waiting for condition

@agilgur5 do you know how to selectively re-run that failed test?

@agilgur5 do you know how to selectively re-run that failed test?

In CI, you can't. You can re-run an individual CI job with a /retest comment after #13000 et al, but you need to be an Argoproj Member to do so. Other Members can add that comment for you and Approvers can manually re-run CI jobs as well.
Also relevant, would you be interested in becoming a Member? You have enough contributions to qualify now and enough would merge by the next quarterly Membership Meeting (November) as well

@agilgur5 Thanks!
Yes, I'm interested in becoming a member, but I need to get sign off from my employer first. Are you willing to sponsor me?

Yes I mentioned it, so ofc I can be one sponsor 🙂
Alan up-voted my comment and is potentially another sponsor, but we'll definitely be able to get you a second or more too.
You mentioned you were contributing in your personal capacity, so you don't have to list your employer as your affiliation, but it is usually good to cross-check with them anyway. Pretty sure Adobe would be happy to have more contributors affiliated too 😉


ci: really only handle Dependabot via pull_request

Currently, Dependabot PRs trigger each build twice: one time because of the PR, the other one because of the push. We wanted to prevent the latter specifically, but apparently I got the syntax wrong, see https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#example-ignoring-branches-and-tags.

Sorry I missed they were multi-level branch names.

Me, too!


Fix the 500 error from https://wellcomecollection.org/works/yxjy8j5f/items

https://wellcomecollection.org/works/yxjy8j5f/items
From the application logs:
"GET /works/yxjy8j5f/items HTTP/1.1" 500 33479 "-" "Amazon CloudFront"
TypeError: Cannot read property '0' of undefined
  at getServerSideProps (/app/catalogue/webapp/.next/server/pages/item.js:403:158)
  at runMicrotasks (<anonymous>)
  at processTicksAndRejections (internal/process/task_queues.js:95:5)
  at async Object.renderToHTML (/app/node_modules/next/server/render.tsx:733:13)
  at async doRender (/app/node_modules/next/server/next-server.ts:1669:27)
  at async /app/node_modules/next/server/next-server.ts:1783:21
  at async /app/node_modules/next/server/response-cache.ts:94:25

Fixed.


Add deploy task for payment reminder email

Description
Add step in circle config to deploy new subtask.
things changed from https://github.com/transcom/mymove/pull/2895 so opening new pr...
Reviewer Notes
Anything else I should add to not bring down master?
Code Review Verification Steps

[ ] Tested in the Experimental environment (for changes to containers, app startup, or connection to data stores)
[ ] User facing changes have been reviewed by design.

References

Pivotal story for this change

@chrisgilmerproj i think i have to update this... i copied the deploy from the prior script and looks like that may have changed...


Profile photo not showing when logging in with Azure AD

I setup an app registration in Azure with delegated API permissions for "email, openid and profile", which is the same scope as defined in the project from node module next-auth (src/node_modules/next-auth/providers/azure-ad.js)
Login works fine, email and name is shown correct when logging in with Microsoft 365 login.
But no profile photo showing in e.g. chat and menu. I tried adding the "User.Read" permissions to the scope and API permissions, did not help (mentioned in MS docs as relevant permission to retrieve profile photo: https://learn.microsoft.com/en-us/graph/api/profilephoto-get?view=graph-rest-1.0&tabs=http)
What am I missing, anyone facing the same issue or fixed it?
Thanks.

We also have the same issue with our organization!

Also looking for a resolution to this here thanks!

If you working with Azurechat in an enterprise the photo is not exposed with the default user.read scope. You can add additional scopes, including ProfilePhoto.Read.All, to your implementation by modifying the next-auth configuration in auth-api.ts. Personally I have not done this with profile photos but I pass additional scopes to enrich default functions with calendar.read, bookmark.read.all, user.readbasic.all etc. Next-auth does not have built in token refresh logic so you will need to implement it manually if you want to use additional graph scopes. Happy to provide additional details if interested.

@DakotaWray2 appreciate the input, thanks!
I tried adding ProfilePhoto.Read.All as Delegated permission, granted ok, still same - no profile photo showing.
I see in the next-auth azure-ad.js that its using this endpoint to fetch the profile photo:
https://graph.microsoft.com/v1.0/me/photos/${profilePhotoSize}x${profilePhotoSize}/$value
When testing this manually with Graph Explorer on same Azure AD, all is working, it fetches my profile photo in e.g. 48x48.


Istio control panel setting

@kezhenxu94 has set up the control panel observability on the live demo, I found there are following issues to be rechecked and fixed.

The metrics seems having incorrect metrics.

Configuration Validation is using self selectors as entity condition, which should be a bug.

There is a blank zone when use the current layout

We should try to fix there and update the demo env again.

Updated

Updated


Problems loading Xgboost models

I have trained an Xgboost regression model in R and I want to use it other data, Sadly I cannot convert it to PMML as it is a regression model.
I have made a test set which is a csv file that I want to use my model on.
I read in the test set and run  my model.
.
I then want to save my model load it and run it on the same data. When I do this I get totally different answers on the same data
Original
1.1608219 1.1608219 0.7352632 0.7352632 0.8696429 1.0045016 0.8416470 1.0045016
after reloading
3.487421 3.487421 3.487421 3.487421 3.487421 3.487421 2.712625 3.487421
I have used xgb.save and xgb.load
I have also used the .bin hack in another issue here. Didn't work but another different set of answers.
Obviously something is wrong but I can't work out what.
Any other ideas how to deploy an xgboost regression model on data without retraining it each time?

Can you post your R script so that I can try running it?

testsheetcsv <- read.csv("~/2018 racing models/testsheetcsv.csv")
View(testsheetcsv)
data=testsheetcsv
AW12.XG <- read.csv("~/2018 racing models/AW12 XG.csv")
trainIndex   <- createDataPartition(AW12.XG$Dist12, p=0.75, list=FALSE, times=1)
All_rmse<- c()
Param_group<-c()
params <- list(booster = "gbtree", objective = "reg:linear", eta=0.3, gamma=0, max_depth=6, min_child_weight=1, subsample=1, colsample_bytree=1)
xgbcv <- xgb.cv( params = params, data = dtrain, nrounds = 100, nfold = 5, showsd = T, stratified = T, print.every.n = 10, early.stop.round = 20, maximize = F)
#just get a quick best model
xgb1 <- xgb.train (params = params, data = dtrain, nrounds = 8, watchlist = list(val=dtest,train=dtrain), print.every.n = 10, early.stop.round = 10, maximize = F , eval_metric = "error")
predict(xgb1,newdata=as.matrix(data[, -12]))
[1] 1.1608219 1.1608219 0.7352632 0.7352632 0.8696429 1.0045016 0.8416470 1.0045016
xgb.save(xgb1, "Awmodel")
[1] TRUE
awmod1 <- xgb.load("Awmodel")
predict(awmod1,newdata=as.matrix(data[, -12]))
[1] 2.359888 2.650479 1.321146 0.838798 3.043278 2.277152 1.482323 2.767058
#not the same?

No idea why its scored out lines???

Is the dataset you're using public?

no. I was hoping it wouldn’t be a problem,
It consists of 8 0/1 variables and three real numbers.
Using R studio to import them from CSV files.
From: Philip Hyunsu Cho
Sent: Wednesday, September 12, 2018 11:45 PM
To: dmlc/xgboost
Cc: selphie1410 ; Author
Subject: Re: [dmlc/xgboost] Problems loading Xgboost models (#3696)
Is the dataset you're using public?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

@selphie1410

I was hoping it wouldn’t be a problem

Without the data, diagnosis of the bug is difficult. Can you generate a random dataset that looks like your dataset?

I can let you have the originals. I’ll put them up shortly.
From: Philip Hyunsu Cho
Sent: Thursday, September 13, 2018 7:50 AM
To: dmlc/xgboost
Cc: selphie1410 ; Mention
Subject: Re: [dmlc/xgboost] Problems loading Xgboost models (#3696)
@selphie1410
I was hoping it wouldn’t be a problem
Without the data, diagnosis of the bug is difficult. Can you generate a random dataset that looks like your dataset?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

GIT Stuff.xlsx
Here you are

Thanks, I tried running your script and get the error
Error in terms.formula(object, data = data) :
  'data' argument is of the wrong type
Calls: sparse.model.matrix -> terms -> terms.formula
Execution halted

I don’t get that!
I can build the model quite happily.
All the spare.model.matrix does is convert the CSV file into something XGb.Dmatrix can handle.
What do you need me to do?
From: Philip Hyunsu Cho
Sent: Thursday, September 13, 2018 8:34 AM
To: dmlc/xgboost
Cc: selphie1410 ; Mention
Subject: Re: [dmlc/xgboost] Problems loading Xgboost models (#3696)
Thanks, I tried running your script and get the error
Error in terms.formula(object, data = data) :
'data' argument is of the wrong type
Calls: sparse.model.matrix -> terms -> terms.formula
Execution halted
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

Can you post the CSV files you converted from XLS?

testcsv.zip
This is the CSV file zipped up because GIThub doesn't let me upload csv

@selphie1410 testcsv.zip doesn't contain Dist12. Did you upload the right file?

@selphie1410 There are several issues with the code you posted:

The variables train and test were not defined. I had to add

train <- AW12.XG[trainIndex,]
test <- AW12.XG[-trainIndex,]

The variables train.label and test.label were not defined either. Which column is supposed to be the target? Is Dist12 column the label?

@selphie1410 I found the problem: since you are using early stopping, you have to specify ntreelimit when predicting:
predict(xgb1,newdata=as.matrix(data[, -12]))
xgb.save(xgb1, "Awmodel")
awmod1 <- xgb.load("Awmodel")
predict(awmod1,newdata=as.matrix(data[, -12]), ntreelimit=1)   # 1 was the best iteration for xgb1

When you save a model and load it back, the best iteration isn't saved. To preserve early stopping information, you should save the R object using saveRDS().


The title bar does not display properly at startup

Lapce Version
v0.2.5
System information
windows 11
Describe the bug
The title bar does not display properly at startup
Additional information

Does this seem similar to https://github.com/lapce/lapce/issues/1014?

Yes, it is the same one


Remove overflow: hidden on .markdown-body

Ran into a bug where tooltips at the top of a blog and diffs were cut off by .markdown-body's overflow: hidden. No one has a clue why we have that right now—could be <table> related?—so let's see what's up.

We used to support some alignment stuff a long time ago. Mayb this was to clear floats?

We used to support some alignment stuff a long time ago. Maybe this was to clear floats?

Could've been @bkeepers, but if we run into any of that we can account for it with additional CSS around our Markdown wrappers on dotcom itself.


Downgrade version of base

Since a recent change, the version 1.5.11 of base was overridden by a new artifact. This caused a build failure in this repository due to an incompatibility in the Gradle plugin test utils.
In this PR we downgrade the version of base to 1.5.10 so that the build would pass again.

@alexander-yevsyukov, PTAL.


Scala 2.13 version

Would it be possible to have a new version compatible with Scala 2.13?

That would be great, hopefully its just a case of doing a release. The changes for the 2.13 cross build were made in a previous PR:
https://github.com/howardjohn/scala-server-lambda/pull/9

Yeah that's true.


Notes for voting request

This PR does not require modification of indexed-db, all data for notes for voting is already stored

The main difficulty is that we need to read data from several tables by linking them by foreign keys
https://github.com/penumbra-zone/penumbra/blob/eccf899efc07f2644d415dc70b1339a571d25c5a/crates/view/src/storage.rs#L1016
let spendable_note_records: Vec<SpendableNoteRecord> = dbtx
                .prepare(&format!(
                    "SELECT notes.note_commitment,
                        spendable_notes.height_created,
                        notes.address,
                        notes.amount,
                        notes.asset_id,
                        notes.rseed,
                        spendable_notes.address_index,
                        spendable_notes.source,
                        spendable_notes.height_spent,
                        spendable_notes.nullifier,
                        spendable_notes.position
                    FROM
                        notes JOIN spendable_notes ON notes.note_commitment = spendable_notes.note_commitment
                    WHERE
                        spendable_notes.address_index IS {address_clause}
                        AND notes.asset_id IN (
                            SELECT asset_id FROM assets WHERE denom LIKE '_delegation\\_%' ESCAPE '\\'
                        )
                        AND ((spendable_notes.height_spent IS NULL) OR (spendable_notes.height_spent > {votable_at_height}))
                        AND (spendable_notes.height_created < {votable_at_height})
                    ",
                ))?
                .query_and_then((), |row| row.try_into())?
                .collect::<anyhow::Result<Vec<_>>>()?;

Rust uses sqllite
Sqllite is a relational database and it looks easy, but indexed-db is not relational

The simple solution is that we can just read all the data from the NOTES and ASSETS tables and do in-memory selections and filtering
In fact, up to this point, we've always done in-memory filtering for indexed-db data

But really, we're better off avoiding in-memory filtering. See #312

cc @jessepinho
We didn't get a chance to work in pairs, so I'll try to reveal more details on working with this issue

The important point is that besides SpendableNotes we also need to get IdentityKey
In rust it looks like this:
let identity_key = DelegationToken::from_str(&denom)
                    .context("invalid delegation token denom")?
                    .validator();

And good news, we can do this without wasm.  udelegation_penumbravalid13m3vq62xwtjmesxyngayanp3tnllm2rta7ylc8pkz2vwqsag0v9snujwrz is an example delegation asset, and it looks like the substring valid13m3vq62xwtjmesxyngayanp3tnllm2rta7ylc8pkz2vwqsag0v9snujwrz is a validator identity key in bech32m encoding


Merge from aws into fork

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: abhay-krishna
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [abhay-krishna]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

The following users are mentioned in OWNERS file(s) but are untrusted for the following reasons. One way to make the user trusted is to add them as members of the abhay-krishna org. You can then trigger verification by writing /verify-owners in a comment.

mhausenblas

User is not a member of the org. User is not a collaborator. Satisfy at least one of these conditions to make the user trusted.
docs/OWNERS

micahhausler

User is not a member of the org. User is not a collaborator. Satisfy at least one of these conditions to make the user trusted.
docs/OWNERS

sostheim

User is not a member of the org. User is not a collaborator. Satisfy at least one of these conditions to make the user trusted.
docs/OWNERS

vignesh-goutham

User is not a member of the org. User is not a collaborator. Satisfy at least one of these conditions to make the user trusted.
docs/OWNERS

vivek-koppuru

User is not a member of the org. User is not a collaborator. Satisfy at least one of these conditions to make the user trusted.
docs/OWNERS


[FP8] Add shard strategy to from_linear for PTQ.

We missed this in #232. Fixes param loader error
2024-03-19 16:23:37 [info     ] Loading parameters from dist/mixtral-8x7b-instruct-v0.1-fp8_e4m3_e5m2_max-vllm-2gpu. [mlc_serve.model.tvm_model] func_name=get_tvm_model lineno=66 pathname=/home/csullivan/scratch/ollm-2/mlc-serve/mlc_serve/model/tvm_model.py process=146792
[16:23:43] /home/csullivan/scratch/ollm-2/deps/tvm/src/runtime/disco/loader.cc:464: [Worker #0] Loading model to device: cuda:0
[16:23:43] /home/csullivan/scratch/ollm-2/deps/tvm/src/runtime/disco/loader.cc:464: [Worker #1] Loading model to device: cuda:1
Traceback (most recent call last):
  File "<frozen runpy>", line 198, in _run_module_as_main
  File "<frozen runpy>", line 88, in _run_code
  File "/home/csullivan/scratch/ollm-2/deps/mlc-llm/python/mlc_chat/cli/worker.py", line 51, in <module>
    main()
  File "/home/csullivan/scratch/ollm-2/deps/mlc-llm/python/mlc_chat/cli/worker.py", line 46, in main
    worker_func(worker_id, num_workers, reader, writer)
  File "/home/csullivan/scratch/ollm-2/deps/tvm/python/tvm/_ffi/_ctypes/packed_func.py", line 239, in __call__
    raise_last_ffi_error()
  File "/home/csullivan/scratch/ollm-2/deps/tvm/python/tvm/_ffi/base.py", line 481, in raise_last_ffi_error
    raise py_err
tvm._ffi.base.TVMError: _Map_base: :at
terminate called after throwing an instance of 'std::out_of_range'
  what():  _Map_base::at

cc @vinx13 let me know if this looks fine to you, fixes the problem I was seeing earlier, mirrors your changes in #233


To support mutual SSL/TLS

duplicate with this issue https://github.com/apache/rocketmq-mqtt/issues/51

duplicate with this issue #51

The issue has been updated, unidirectional authentication has been implemented in #51. But mutual SSL/TLS authentication has not been implemented yet.

Mutual SSL/TLS authentication , can you put forwoard a pr to fix it?

How's the feature going? @zongtanghu @shendongsd


Broken Examples

Having trouble with many of the Gantt examples:
>mermaid graphTD.mmd

Produces the following response:
PHANTOM ERROR: TypeError: 'null' is not an object (evaluating 'oDOM.documentElement.attributes.getNamedItem('height').value')
TRACE:

Sorry to hear that.
May I ask what version of mermaid you are running and perhaps a pointer to a broken example.

mermaid --version
0.4.0

used this from the website
gantt
    dateFormat  YYYY-MM-DD
    title Adding GANTT diagram functionality to mermaid

    section A section
    Completed task            :done,    des1, 2014-01-06,2014-01-08
    Active task               :active,  des2, 2014-01-09, 3d
    Future task               :         des3, after des2, 5d
    Future task2               :         des4, after des3, 5d

    section Critical tasks
    Completed task in the critical line :crit, done, 2014-01-06,24h
    Implement parser and jison          :crit, done, after des1, 2d
    Create tests for parser             :crit, active, 3d
    Future task in critical line        :crit, 5d
    Create tests for renderer           :2d
    Add to mermaid                      :1d

    section Documentation
    Describe gantt syntax               :active, a1, after des1, 3d
    Add gantt diagram to demo page      :after a1  , 20h
    Add another diagram to demo page    :doc1, after a1  , 48h

    section Last section
    Describe gantt syntax               :after doc1, 3d
    Add gantt diagram to demo page      : 20h
    Add another diagram to demo page    : 48h

I think you are lacking a gantt config. Look at issue number #158 for more info.
I think that there should be a default config though in order to avoid these kind problems in the future. In the light of #158, I will close this issue as a duplicate. Please let me know if this works out.


mobile: Go to latest version / this crate has been yanked not clear from icon

I noticed that on mobile, the topbar menus turn into icons, which makes sense. When someone is not on the latest version, or is on a yanked version, the icon is a yellow triangle with an exclamation point. However, in the absence of text or the ability to hover, it's not clear what clicking on that icon will do.
I think it would be nice to also put the text "this crate has been yanked" or "go to latest version" in the body of the page, at least on mobile. Maybe below the search box?

Closing this: as we wrap up #1438, the importance of the "go to latest version" link will be much less, and people will see it less often. I think it's not worth investing the time to fix this.


Merge in Robins changes

Few bug fixes and support for a new SPT correlation model (vs_sd however will need improvements in future to properly align).
Removes some filtering and conversion to leave raw data for CPT's
Added effective stress to the VsProfile and fixed issues with it to enable front end to still function
Added some documentation to functions where the parameters where changed to our new "standard"
Adjusted examples to actually work by specifying the vs30_correlations for the vs_profiles

Seems fine to me. I have made comments more as FYI than "you should fix" because I wasn't sure how closely to critique the code.

Fair, all of this code isn't quite up to scratch with our standards but would be too much to do just for the sake of doing something "nicer" that doesn't give too much of a performance boost or fix any bugs or with the changes allow it to be extendable/readable etc. Not going to lose sleep over these, but when this gets looked at again can clean up little things that matter as we go.


Add duptable support for reth db get

Describe the feature
reth db get does not currently support duptables but it would be nice if it did
Additional context
https://github.com/paradigmxyz/reth/pull/2772#pullrequestreview-1436354459

Hey I would be interested in trying to solve this issue :)

Thanks! I've assigned you to the issue. If you feel stuck, open up a draft PR with your questions and someone will help you. If you are prevented from solving the issue, let me know and I will unassign you :smile:

This seems stale, can I take over this one?


Final Changes for Release 11.1.0

@stevenchalem @dylan-sa The only thing this might affect would be the display of README.html. Could you take a look at it in the release package to check that it's ok?


DateField unit tests fail on macos.latest

See https://github.com/gui-cs/Terminal.Gui/actions/runs/9831020519/job/27137868075#step:7:6759
@BDisp Can you look into this since you have more familiarity with the culture stuff than I?

I have to find out which culture he is failing. It looks like at least one is failing on macOS (zh-CN/zh-TW). But I'll have to debug on macOS to confirm.

I have to find out which culture he is failing. It looks like at least one is failing on macOS (zh-CN/zh-TW). But I'll have to debug on macOS to confirm.

It's easy to tweak dotnet-core.yml to run on macos now...

Hopefully you saw that I disabled the unit test from running on macos:

I have to find out which culture he is failing. It looks like at least one is failing on macOS (zh-CN/zh-TW). But I'll have to debug on macOS to confirm.

It's easy to tweak dotnet-core.yml to run on macos now...

Tests can also be specified to run in more than one culture.
That's something I'll stick on my todo list for #3558 since that's a pretty logical place for it.


Create roles for the land registry contract

Land Registry Admin:
Can add or remove other roles
Can update system parameters
Land Inspector:
Can verify land details
Can approve or reject land registrations
Land Registrar:
Can register new lands
Can update land details
Land Owner:
Can transfer their own land
Can view their own land details
Public:
Can view basic land information...

Follow OZ standard for creating roles: https://docs.openzeppelin.com/contracts-cairo/0.17.0/access
E.G:
const ADMIN_ROLE: felt252 = selector!("ADMIN_ROLE");
const INSPECTOR_ROLE: felt252 = selector!("INSPECTOR_ROLE");
const REGISTRAR_ROLE: felt252 = selector!("REGISTRAR_ROLE");

imports

fn register_land(
        ref self: ContractState,
        land_id: u256,
        location: felt252,
        area: u256,
        land_use: felt252,
        document_hash: felt252
    ) -> Land {
        self.accesscontrol.assert_only_role(REGISTRAR_ROLE);

@fishonamos is this issue open for contribution I would love to work on this issue

I am applying to this issue via OnlyDust platform.
My background and how it can be leveraged
I have 2 years of coding and learning about web development, recently I joined Dojo Coding to learn about web 3.0 and I think this will be a great opportunity to start contributing.
How I plan on tackling this issue
I would follow the standard for creating roles and use the example as reference


Cannot assign to read only property 'orientation' of object

Describe the Nug
The package throws this error: Cannot assign to read only property 'orientation' of object

How To Reproduce
Sometimes, This happens when you resize the browser window
Error Messages and Tracebacks
I traced the issue, it's being thrown at this line:
https://github.com/matthewhudson/current-device/blob/f8f301b262dc1346b51b995bd922e39add70947e/src/index.js#L367
I checked the code, and it looks like the device object is not being frozen at any point.

nvm, I found the issue. The issue was in our codebase!


Tooltip: Add an example for TooltipTriggerMode.manual and add tests for existing Tooltip examples

fixes https://github.com/flutter/flutter/issues/100552
Note:
~This will land after https://github.com/flutter/flutter/pull/100553 is merged~
TooltipTriggerMode.manual example is similar an example for RefreshIndicator
Pre-launch Checklist

[x] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[x] I read the Tree Hygiene wiki page, which explains my responsibilities.
[x] I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
[x] I signed the CLA.
[x] I listed at least one issue that this PR fixes in the description above.
[x] I updated/added relevant documentation (doc comments with ///).
[x] I added new tests to check the change I am making, or this PR is test-exempt.
[x] All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

Gold has detected about 1 new digest(s) on patchset 1.
View them at https://flutter-gold.skia.org/cl/github/100554

Hey @chuntai
Adding this example after Tooltip State PR.


Allow model forward() to return embedding vectors

Originally authored by: Davis Wertheimer<EMAIL_ADDRESS>

@JRosenkranz

This was the goal of our "Headless" modules, e.g. gpt_bigcode.base_model. Can the user just call into base_model to get the embeds, then pass those to an instead of the head if necessary?
See also: https://github.com/foundation-model-stack/foundation-model-stack/issues/8

This was the goal of our "Headless" modules, e.g. gpt_bigcode.base_model. Can the user just call into base_model to get the embeds, then pass those to an instead of the head if necessary?
See also: #8

The problem with this is that we would like to re-use generate’s post iteration hook in fms-fsdp (rather than re-writing the entire generation loop to account for hidden states). If the contract had the option of returning hidden states we would not need to re-write this generation loop and instead just include the output as part of the post iteration hook.
The current options were:

extend the existing models and create new variants (this works but means we have a lot of extra code adding new  variants)
creating some hidden states extractor wrapper which takes the headless model and head in and produces the hidden states (this solves the extra variants issue, but this won’t be useable through the current generation loop as the contract currently is returning (logits, cache)) - it also seems somewhat overkill for just getting the hidden states
Add a return_embeds to the forward method which would then also return the embeds (captured in generate) - this is the simplest option yet it also adds another parameter to the forward method which is single purpose.
Add a hook to forward that could take in the embeddings, logits, etc. and return in the format of the users choosing? This is probably the most flexible but requires slightly more work on the user

creating some hidden states extractor wrapper which takes the headless model and head in and produces the hidden states (this solves the extra variants issue, but this won’t be useable through the current generation loop as the contract currently is returning (logits, cache)) - it also seems somewhat overkill for just getting the hidden states

I think we can probably find simple ways to do this that also allow us to remove the special copy-paste embeddings-extracting generate function too. E.g. what if we did something like:
In [18]: class EmbeddingRecorder:
    ...:     def __init__(self, model):
    ...:         self.model = model
    ...:         self.embeds = []
    ...:     def __call__(self, *args, **kwargs):
    ...:         return self.forward(*args, **kwargs)
    ...:     def forward(self, *args, **kwargs):
    ...:         result = self.model(*args, **kwargs)
    ...:         if len(result) > 1:
    ...:             emb = result
    ...:         else:
    ...:             emb = result[0]
    ...:         self.embeds.append(emb)
    ...:         return result
    ...:

In [19]: recorder = EmbeddingRecorder(model)

In [20]: result = generate(recorder, input_ids=torch.tensor( [[1,2,3,4,5 ]] ) )

In [21]: len(recorder.embeds)
Out[21]: 256

In [22]: len(result)
Out[22]: 1

In [23]: len(result[0])
Out[23]: 261

Wouldn't something like that give us everything we need, in user-space, without special-casing anything about the fms APIs? This records each step of generate, doesn't need a special generate function, and doesn't require modifying the underlying model?
I guess you want to capture the output of the headless model not exactly what I captured above, but I believe we have a headless instance too, so I think it's still pretty straightforward?

creating some hidden states extractor wrapper which takes the headless model and head in and produces the hidden states (this solves the extra variants issue, but this won’t be useable through the current generation loop as the contract currently is returning (logits, cache)) - it also seems somewhat overkill for just getting the hidden states

I think we can probably find simple ways to do this that also allow us to remove the special copy-paste embeddings-extracting generate function too. E.g. what if we did something like:
In [18]: class EmbeddingRecorder:
    ...:     def __init__(self, model):
    ...:         self.model = model
    ...:         self.embeds = []
    ...:     def __call__(self, *args, **kwargs):
    ...:         return self.forward(*args, **kwargs)
    ...:     def forward(self, *args, **kwargs):
    ...:         result = self.model(*args, **kwargs)
    ...:         if len(result) > 1:
    ...:             emb = result
    ...:         else:
    ...:             emb = result[0]
    ...:         self.embeds.append(emb)
    ...:         return result
    ...:

In [19]: recorder = EmbeddingRecorder(model)

In [20]: result = generate(recorder, input_ids=torch.tensor( [[1,2,3,4,5 ]] ) )

In [21]: len(recorder.embeds)
Out[21]: 256

In [22]: len(result)
Out[22]: 1

In [23]: len(result[0])
Out[23]: 261

Wouldn't something like that give us everything we need, in user-space, without special-casing anything about the fms APIs? This records each step of generate, doesn't need a special generate function, and doesn't require modifying the underlying model?
I guess you want to capture the output of the headless model not exactly what I captured above, but I believe we have a headless instance too, so I think it's still pretty straightforward?

Yes this is the same as the HiddenStatesExtractor, you are just adding state to it (rather than returning another value). I'm ok with that, just seemed like overkill for just the hidden states. This can be done though as long as the state is held in the Recorder and the contract for forward stays the same

we could also just slightly modify the above EmbeddingRecorder to call model._helper then model.shared, though that only works in cases where the model follows that particular interface. If this happens in user code for specific known (known to have _helper/shared) models (as is probably the case for speculation?) then it might be fine, though we can built a more robust interface using 'Headless' instances if necessary?

we could also just slightly modify the above EmbeddingRecorder to call model._helper then model.shared, though that only works in cases where the model follows that particular interface. If this happens in user code for specific known (known to have _helper/shared) models (as is probably the case for speculation?) then it might be fine, though we can built a more robust interface using 'Headless' instances if necessary?

In my local code, I believe I did something like this:
HiddenStatesExtractor(base_model, head)


request help: Can it support "response rewrite"？

Issue description
Can it support "response rewrite"？
Environment

your apisix-java-plugin-runner version

not supported yet, have plans to support.

When will it be supported？

in the next version, recently I will1 focus on this.

apisix-java-plugin-runner ,Can this be configured with multiple nodes?

apisix and plugin runner is one to one.

specially hope support reponse rewrite


Output Url Generation approach compared to the V1 pkg

Hi,
Really want this to work so we can have a smaller bundle.
I tried to convert parts of an app to use this SDK and compared the old SDK urls side by side - here are some examples:
(-old, +new)
-https://rs.wescover.com/c_pad,h_250,w_250/v1/wescover-image-store/e3toavbx0drg7xxozw8c.jpg
+https://rs.wescover.com/c_pad,h_250,w_250/f_jpg/v1/wescover-image-store/e3toavbx0drg7xxozw8c
-https://rs.wescover.com/c_limit,f_auto,q_auto,w_500/v1/wescover-image-store/lhxpyb380gvknqrmdxbj
+https://rs.wescover.com/c_limit,w_500/q_auto/f_auto/v1/wescover-image-store/lhxpyb380gvknqrmdxbj
As you can see, the URLs are not exactly compatible - usage of the / approach vs , and appending an extension vs using the f_ modifier - make the old URLs and new not compatible.
I know the output image will be the same! So why is this important?
Some sites (like us) have been using the old URLs for years, with many (many) images already crawled by search engines (like Google) and in use.
Swapping all URLs suddenly, even if the same image is produced would cause a massive re-crawl of all images since the URL means "another image". The result is:

Huge waste of crawl budget
Huge waste of transfer bandwidth from Cloudinary (which costs$$)
Possible transformations if Cloudinary thinks those new URLs need a new transform (even if the output is identical)
Possible, image ranking could be lost since there is no such thing as "image 404" to advertise to google.

This means for us, URL equivalency, given the same transformation needs is extremely important.
WDYT?

Hi @yoadsn! Of course, it makes sense to be able to generate the same URLs with transformations through both versions.
Could you please share the code snippet you've used to generate those URLs with v1 and v2 versions of the SDK?

@aleksandar-cloudinary Thanks!
Since I was sanity-testing the two version - I did the following to compare them side by side within a real app.
I knew which subset of transformations are in use to created a simple transformer from "options" object to an actions API calls.
This way I just ran the app and any mismatches were printed to the log.
import { Cloudinary } from 'cloudinary-core';

import { Cloudinary as CLD } from '@cloudinary/base';
import { Actions } from '@cloudinary/base';

const cld = new CLD({
  cloud: {
    cloudName: cloudinaryCloudName,
  },
  url: {
    secure: true,
    cname: imageCdnHost,
    secureDistribution: imageCdnHost,
    privateCdn: true,
    useRootPath: true,
    analytics: false,
  },
});

const cloudinaryConfig = {
  cloud_name: cloudinaryCloudName,
  cname: imageCdnHost,
  secure_distribution: imageCdnHost,
  secure: true,
  private_cdn: true,
  use_root_path: true,
};
const cloudinary = Cloudinary.new();
cloudinary.config(cloudinaryConfig);

function cloudinaryUrl(publicId, options) {
  const cimg = cld.image(publicId);

  if (options) {
    if (options.crop) {
      if (options.crop === 'limit') {
        cimg.resize(Actions.Resize.limitFit(options.width, options.height));
      } else if (options.crop === 'pad') {
        cimg.resize(Actions.Resize.pad(options.width, options.height));
      }
    }

    if (options.quality === 'auto') {
      cimg.quality(Actions.Delivery.quality('auto'));
    }

    if (options.fetchFormat || options.format) {
      cimg.delivery(
        Actions.Delivery.format(options.fetchFormat || options.format)
      );
    }

    if (options.transformation && typeof options.transformation === 'string') {
      cimg.namedTransformation(
        Actions.NamedTransformation.name(options.transformation)
      );
    }
  }

  const v2url = cimg.toURL();

  const v1url = cloudinary.url(publicId, { ...options });

  if (v1url !== v2url) {
    console.log(`-${v1url}\n+${v2url}`);
  }
  return v1url;
}

Assuming the order in which you apply those transformations also effects the order they are applied to the URL - another layer of compatibility needs to be in place to ensure unordered "options objects" are always converted in the same order to the functional approach with the V2 SDK.
Also, I think, since in many apps I assume "option objects" are passed down from top level components to lower level image URL producing layers. (at least we have such abstractions in many places). Converting a V1 to V2 is going to be a full re-write of those layers or implementing a conversion function like I did (but of course robust enough to handle all options).
IMHO - this layer should be provided built-into V2 for easier migrations and more importantly compatibility with existing usage.
Also, the API style of V2 is clearly well thought out - trying to be simple to use, typed, future proof etc.
The problem is that it does not lend itself well for configuration based code architecture such that a top level layer can "define a configuration" and let lower layers parse it to URLs.
E.g any top layer who needs control over "width" needs to "know" the SDK methods to define such an action. (Or, a parser needs to be built in between which is what I did in the example above, but clearly is not part of a normal "user-land" code).
This is a down side in my opinion  but only my 2cents.

Hey @yoadsn
Thanks for the well-thought-out input.
To your immediate question, yes there's an in-between way of creating the old URLs, but with better package size.
There's a method called createCloudinaryV1URL exposed at the top of the package that creates the old URLs
You can find test examples here, but the syntax is identical to what you already know.
import {createCloudinaryV1URL} from '@cloudinary/base';

createCloudinaryV1URL(/* v1-style-options */)

As to your second argument, the new SDK is indeed imperative, this is not to say that we aren't considering a more declarative API (on top of, not instead of) as well.
As an extra bonus tip, if you use the new imperative syntax, you can cut down the bundle size even further by only importing what you need at that time.
so instead of import {Actions} from '@cloudinary/base', you could use import {scale} from '@cloudinary/base/actions/resize'

Thank you @patrick-tolosa your answer is sport on and shame on me for not finding that top level import. I just assumed it's not there. Will test it out right away.

Hi @patrick-tolosa after some initial test, it's looking good except for some bugs.
I have opened a PR with failing test that cover those bugs so I hope it would be easy to spot.
Thanks again!


[Error] A JavaScript error occurred in the main process

Getting an Error popup while opening the app.
A JavaScript error occurred in the main process
Uncaught Exception:
ReferenceError: win is not defined
at createWindow (/Applications/Instagram.app/Contents/Resources/app/main.js:49:5)
at App. (/Applications/Instagram.app/Contents/Resources/app/main.js:70:9)
at App.emit (events.js:182:13)
Please Check
Thanks
Avinash

Getting an Error popup while opening the app.
A JavaScript error occurred in the main process
Uncaught Exception:
ReferenceError: win is not defined
at createWindow (/Applications/Instagram.app/Contents/Resources/app/main.js:49:5)
at App. (/Applications/Instagram.app/Contents/Resources/app/main.js:70:9)
at App.emit (events.js:182:13)
Please Check
Thanks
Avinash

I will detect and solve the error as soon as possible :)


clang attributes

Describe the bug
The presence of attributes of functions breaks the norm
Erroneous code
float __attribute__((overloadable)) len(t_float2 a)
{
	t_float2	v;

	v = a;
	return (sqrt(a.x * a.x + a.y * a.y));
}

Additional infos

OS: macos 10.14.6
python --version: Python 3.7.8
norminette -v: norminette 3.3.2

Additional context
The attribute argument does not matter

There is also a problem with attributes of functions in the header files

Hello,
Can you give me an example for the second problem?


Output comparison report to a file

Fixes #7
This PR adds a feature to generate a report file to be saved to disk that contains the results of the benchmarks comparison.

@fedefernandez @juanpedromoreno sorry for the amount of files, most of them are just copyright dates updates.


Dev

Coverage decreased (-28.8%) to 64.286% when pulling f4d9acb1571a290c9a4d49ee72d40a0a44490d5a on dev into c24025ec3983adfdc34214656082e0d19f18d16e on master.


problem with discord scum maybe?

Exception ignored in thread started by: <bound method GatewayServer._response_loop of <discum.gateway.gateway.GatewayServer object at 0x00000226DADBED60>>
Traceback (most recent call last):

could be but this could be very vague as i dont know what the cause was

i fixed the error now i have this :
Traceback (most recent call last):
File "C:\Users\sipho\Documents\MudaeAutoBot-4\MudaeAutoBot.py", line 34, in
bot = discum.Client(token=settings["token"],log={"console":False, "file":False})
File "C:\Users\sipho\AppData\Roaming\Python\Python310\site-packages\discum\discum.py", line 54, in init
import random_user_agent.user_agent #only really want to import this if needed
ModuleNotFoundError: No module named 'random_user_agent'

When you installed discum you should have gotten all the modules it needed I think you improperly installed it

closing due to expected improper discum installation


✨[Feature] Perform constant folding of operations in the graph if nodes can be evaluated at compile time

Is your feature request related to a problem? Please describe.
%28 : int = aten::size(%22, %27)
...
%31 : Tensor[] = tensorrt::execute_engine(%30, %trt_engine_0x55cc735470f0)
%32 : Tensor, %33 : Tensor = prim::ListUnpack(%31)

%34 : int = prim::Constant[value=15]()
%35 : int = prim::Constant[value=7]()
%36 : int = prim::Constant[value=0]()
%37 : int[] = prim::ListConstruct(%28, %34, %34, %35)

...
%41 : Tensor[] = tensorrt::execute_engine(%40, %trt_engine_0x55cc73547290)
%bar : Tensor = aten::reshape(%foo, %37)

In the snippet below we have a reshape node %bar which is forced to fallback by min_block_size. Because %bar is forced to fallback its input %37 = prim::ListConstruct is also forced to fallback along with %28 : int = aten::size. In both cases these ops are supported by evaluators and (at least with static shapes) should be resolved to constants during conversion. Currently these ops are creating unnecessary breaks between TRT regions that will impact performance.
Describe the solution you'd like
Could evaluatable nodes be resolved to constants in the torchscript graph before partitioning to avoid this impact on the partition?
Describe alternatives you've considered
Could fallback nodes with no dependencies on active TRT nodes be consolidated to avoid breaking TRT regions? (In this case %37 is not used anywhere other than in the reshape node %bar and could be moved to just before its use)

Shouldn’t OpSupported report back that the node can be evaluated? https://github.com/pytorch/TensorRT/blob/5fa38f4566ca3d4b2daf0f65f2d87ddaa2a304cf/core/conversion/conversion.cpp#L22

https://github.com/pytorch/TensorRT/pull/1263 This pr aims to log every state change in target executor for nodes, might help clear up what is happening

Shouldn’t OpSupported report back that the node can be evaluated?
https://github.com/pytorch/TensorRT/blob/5fa38f4566ca3d4b2daf0f65f2d87ddaa2a304cf/core/conversion/conversion.cpp#L22

Yes. But the request here is to remove these nodes  (make it a constant list which is passed to reshape node directly) altogether in the torchscript graph before partitioning phase so that ListConstruct won't obstruct partitioning and create additional segments.
%28 : int = aten::size(%22, %27)
%37 : int[] = prim::ListConstruct(%28, %34, %34, %35)

So that

Is this because of the input signature changes?

My thinking here is that when an op is supported with an Evaluator, it is resolvable to a constant in TRT. If these are ops are resolvable to constants in TRT they should also be resolvable to constants in TorchScript. If we implemented an evaluator pass which ran before partitioning and evaluated any evaluatable node (ex. aten::size with static shaped input) we could replace those nodes with constants in the graph. We could then rerun jit's constant propagation potentially simplifying the graph further.
I think this has a few benefits:

Simplifies the graph before partitioning, avoids cases like the example in the original post where an evaluatable op is forced to fallback and breaks up a TRT segment
Allows testing of evaluators independently of partitioning and conversion
Improved debug, makes it clear and visible which ops are assumed to be constant
May simplify torch fallback regions
Allows for support for the same op with either a converter or evaluator (ex. aten::size). If the evaluator is contextually able to resolve a node to a constant (ex static shape aten::size) it will not be present in the graph at partitioning/conversion time. If it is, it will need to be implemented in fallback or through a converter which can handle dynamic shapes.

My thinking here is that when an op is supported with an Evaluator, it is resolvable to a constant in TRT. If these ops are resolvable to constants in TRT they should also be resolvable to constants in TorchScript. If we implemented an evaluator pass which ran before partitioning and evaluated any evaluatable node (ex. aten::size with static shaped input) we could replace those nodes with constants in the graph. We could then rerun jit's constant propagation potentially simplifying the graph further.
I think this has a few benefits:
1. Simplifies the graph before partitioning, avoids cases like the example in the original post where an evaluatable op is forced to fallback and breaks up a TRT segment

2. Allows testing of evaluators independently of partitioning and conversion

3. Improved debug, makes it clear and visible which ops are assumed to be constant

4. May simplify torch fallback regions

5. Allows for support for the same op with either a converter or evaluator (ex. aten::size). If the evaluator is contextually able to resolve a node to a constant (ex static shape aten::size) it will not be present in the graph at partitioning/conversion time. If it is, it will need to be implemented in fallback or through a converter which can handle dynamic shapes.

This is true in some cases but not all. For example a prim::list_construct could take a number of tensors which are the result of preceding TRT converted nodes. In this case the nvinfer1::ITensors must exist to create the list.
Therefore, such a preprocessing system would need to be able to distinguish constant nodes using some characteristic other than node kind. All that is guaranteed by the torchscript IR is that once a value is produced it will never change but that is conditioned on one or many preceding ops being executed which may be dependencies of this value not all of which are going to be guaranteed to be evaluatable. I would think you could potentially evaluate to constants any nodes where you can trace-back to solely constants but I think that's what constant-prop/pool does. There is the slight detail that we have shape information, which could fold a few more ops, but we should then seek to fork the constant-prop/pool passes to take this into account vs other approaches I would think.
2. We do have an evaluator test rig, but not tests for all evaluators
3. I think I need some more detail here
5. We currently support per schema specialization, e.g. aten::add has many schemas, some are evaluators some are converters. But yes we cannot currently handle having the same schema registered in both places and picking between them. #1130 could help enable this.

Thanks @narendasan. are there more examples beyond prim::ListConstruct and prim::ListUnpack? I agree these do not fit the resolve-to-constant pattern I'm trying to address here. Could these be considered as converters?

Therefore, such a preprocessing system would need to be able to distinguish constant nodes using some characteristic other than node kind. All that is guaranteed by the torchscript IR is that once a value is produced it will never change but that is conditioned on one or many preceding ops being executed which may be dependencies of this value not all of which are going to be guaranteed to be evaluatable. I would think you could potentially evaluate to constants any nodes where you can trace-back to solely constants but I think that's what constant-prop/pool does. There is the slight detail that we have shape information, which could fold a few more ops, but we should then seek to fork the constant-prop/pool passes to take this into account vs other approaches I would think.

This addresses one of my concerns. I'm worried about cases where evaluators may resolve a value incorrectly to a constant or error out because the input is not constant. Ex. aten::mul.int of a value from an aten::size with dynamic input shapes should not be resolved to a constant. I think the case where we can resolve an aten::mul.int to a constant that is still in the Torch-TensorRT input after constant propagation is actually fairly rare and would only come up because of constants that we can identify that torchscript cannot (ex. size with static input shapes). If we removed these kinds of evaluators and instead relied on constant propagation after resolving known-to-torch-trt constants (size with static input shapes, dtype) then I think they would be automatically removed by constant propagation in all the cases where it would be valid for torch-trt to do the same. In the remaining cases the aten::mul would still be in the graph and could fallback correctly or be handled by a future converter that could correctly capture the non-constant input.
I think based on your input this is what I'm proposing:

Add a jit pass which explicitly resolves aten::size and similar ops that torch-tensorrt can prove are constants based on input specification. Rerun jit constant propagation to eliminate any ops which now have constant inputs.
Remove most evaluators that today resolve to constant values (if they are not resolvable by constant propagation, assume inputs are non-constant and we must fallback or support with converters). ListConstruct, ListUnpack, Constant and small number of special-cases would remain.

This would explicitly allow us to explicitly call out what torch-trt is assuming is constant in the initial jit pass and give us a clear torchscript dump after constant propagation of what is still in the graph that will need to be converted or otherwise handled in partitioning. It removes the risk of evaluators incorrectly resolving a value to a constant, creates a path to preserve these ops in fallback regions without erroring out and it allows for the possibility of adding new converter support for nodes that remain in the graph with non-constant inputs (ex. aten::size outputing a shape-tensor which could be consumed by a dynamic reshape).

Thanks @narendasan. are there more examples beyond prim::ListConstruct and prim::ListUnpack? I agree these do not fit the resolve-to-constant pattern I'm trying to address here. Could these be considered as converters?

prim::TupleConstruct/Unpack, aten::append, aten::size, aten::clone, aten::copy are all evaluators which are designed to handle ITensors i.e. potentially non constant data. They are not converters since converters are designed to purely emit ITensors. Evaluators produce IValues so types such as int, double, Tensor, Tuple, List (or wrapped ITensors).  We have in the past discussed unifying Evaluators and Converters to all emit IValues but it did not seem like it added to much other than reducing the number of registries we have. Maybe we will do it some day but I don't think it helps too much here.
Re. 1. I think this sounds reasonable although it not sure how many cases it will hit, like you as point out as soon as there is dynamic shape we are on equal footing to TorchScript lowering information wise (give or take a few dimensions which are static across the input range). Regardless for the effort required I don't see any harm attempting to implement such a pass. The MVP I have in my head is really just inplace replacing directly known (i.e. what we get from the input specs) aten::size, aten::shape with prim::Constant tuples, or ints then seeing what constant pool/prop does. But as soon as we need to go through intermediate ops and start executing subgraphs ourselves I think that opens a can of worms I am not convinced is worth it yet.
Re. 2. I don't really see why we need to remove evaluators, the combo of injecting more shape information into the graph then running constant pooling won't necessarily resolve all ops that would be handled by evaluators. My understanding of the fundamental issue here after talking to @peri044 was that data like shapes which Torch-TensorTRT knows but TorchScript lowering doesn't is not taken into account. Seems like 1. solves that on its own. If evaluators just don't get called anymore I guess that's a plus but I don't really expect that to be the case.
Also from a while back we were chatting with the TS guys when we were trying to start implementing shape analysis and they said they were looking at baking shape info into the graph themselves, I don't know what came of that or if it was moved to a new project like functorch or fx but it would be worth taking a look at what they have these days that we can leverage.

Seems like tracing is now including shape information:
graph(%self : __torch__.GatherNDListModel,
      %x : Float(3, 4, 5, strides=[20, 5, 1], requires_grad=0, device=cuda:0)):
  %4 : Long(2, strides=[1], requires_grad=0, device=cpu) = prim::Constant[value= 1  0 [ CPULongType{2} ]]() # 1274.py:19:0
  %5 : Device = prim::Constant[value="cuda:0"]() # 1274.py:19:0
  %6 : int = prim::Constant[value=4]() # 1274.py:19:0
  %7 : bool = prim::Constant[value=0]() # 1274.py:19:0
  %8 : bool = prim::Constant[value=0]() # 1274.py:19:0
  %9 : NoneType = prim::Constant()
  %10 : Long(2, strides=[1], requires_grad=0, device=cuda:0) = aten::to(%4, %5, %6, %7, %8, %9) # 1274.py:19:0
  %11 : int = prim::Constant[value=1]() # 1274.py:19:0
  %12 : int = prim::Constant[value=0]() # 1274.py:19:0
  %13 : int = prim::Constant[value=9223372036854775807]() # 1274.py:19:0
  %14 : int = prim::Constant[value=1]() # 1274.py:19:0
  %15 : Float(3, 4, 5, strides=[20, 5, 1], requires_grad=0, device=cuda:0) = aten::slice(%x, %11, %12, %13, %14) # 1274.py:19:0
  %16 : Long(2, strides=[1], requires_grad=0, device=cpu) = prim::Constant[value= 1  0 [ CPULongType{2} ]]() # 1274.py:19:0
  %17 : Device = prim::Constant[value="cuda:0"]() # 1274.py:19:0
  %18 : int = prim::Constant[value=4]() # 1274.py:19:0
  %19 : bool = prim::Constant[value=0]() # 1274.py:19:0
  %20 : bool = prim::Constant[value=0]() # 1274.py:19:0
  %21 : NoneType = prim::Constant()
  %22 : Long(2, strides=[1], requires_grad=0, device=cuda:0) = aten::to(%16, %17, %18, %19, %20, %21) # 1274.py:19:0
  %23 : NoneType = prim::Constant()
  %24 : Tensor?[] = prim::ListConstruct(%10, %23, %22)
  %25 : Float(2, 4, strides=[4, 1], requires_grad=0, device=cuda:0) = aten::index(%15, %24) # 1274.py:19:0
  return (%25)

Would we hit issues with dynamic shapes if we rely on the traced shape values?

Potentially, also I think this would force people to use trace. We need to investigate this further.


Node app to find unimplemented games by language

Node script to display the apps that still need to be implemented, grouped by language. Command line parameters can filter the output to just the language or languages you are interested in. (Adapted from find-missing-implementations.js.)

Hey cool thanks for this! 🤝


Robot Marking?

Hi guys, anyone knows if the exam will be fully script marked on code crunch like PE, project and lab or will there be hand marking as well?
Like if we accidentally add and extra space at the back of the output would we still be penalized to the ends of the earth?

There won't be autograding everything is marked by prof

thanks for the heads up @jamietan123 !!!

I think prof manually marks it

aight thanks guys


Use path2d

see http://jsperf.com/anm-path-vs-path2d for free performance gains.

do not merge yet please - i found a bug in SVG parsing when using new Path(<svg path>), I'd like to fix it as a part of this.

I think it only could be merged when it will also provide bounds, hitAt, tangentAt etc. methods using Path2D from the inside, otherwise, Translate/Orient-To-Path tweens and handling events for scripting will all be broken when Path2D will be used inside.

how and why should we do this given that Path2D is a drawing primitive which contains no math and we use it just to draw stuff?
I can see this will fail to respond to path modification, but that is easily fixed - I'll add it to the next commit.

@shamansir does any code actually modify the path itself? I'm not sure.

@mcm69 Yes, you are right, sorry! I somehow thought it replaces the segment data inside with Path2D instance while it's not, for sure. Sorry! It's ok to merge.

so... if it's ok to merge, then merge!

just let me fiddle with importer a bit and we should be good

should be good now


Which caffe version does DIGITS now support

There is a new version of Caffe mainly 0.17 does DIGITS now support it ? I guess at version 0.16 and with DIGITS it was not possible to train mainly because of some bugs.
Best regards.

The current DIGITS docker container supports 0.15.14. I think if you want to use a custom install of caffe, then there is a way to repoint DIGITS to use your local install of caffe instead of the bundled one.


⚠ Bofrost.at has degraded performance

In ae179f8, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 1886 ms

Resolved: Bofrost.at performance has improved in ad1bc20.


Idea: Add custom label or suffix with ".fertilizer"

Adding custom label or modifying existing label where present(and only a single label is supported) would help to know which torrents were actually added by fertilizer. Similar as to cross-seed functionality.

It seems this is already implemented (it suffixes with .fertilizer)


chores: basic fixes appearance

Done:

Fixed Dark mode issue
Made new hero section

To be fixed:

Make Bento Grid
Better Hamburger

Fixed, performance needs to be analysed


Implement a simple pattern inference

Implement a simple pattern inference which roughly finds the smallest terms that contains all the quantifier variables. It works as:

If a user writes {:pattern ...} on a forall/exists, then F* uses the user-supplied pattern (no automated generation).
If a user writes {:nopattern} on a forall/exists, then F* generates no pattern and therefore lets Z3 choose the pattern.
Otherwise, F* attempts to automatically generate patterns for the forall/exist. If the generation fails, then F* emits a warning.
To automatically generate patterns for (forall (x1...xn). e) or (exists (x1...xn). e), F* searches inside e for a term t that contains all the variables x1...xn:

For simplicity, the search does not look inside other binders, such as nested foralls, exists, let, or lambdas inside e.
The term t should contain only function applications, constants, and variables.  It should contain at least one function application (i.e. it can't just be a variable by itself).  It should not contain:

any function with the "[@smt_theory_symbol]" attribute, like /, ==, +, etc.
"let", foralls, exists, and lambdas

F* should make t as small as possible while still covering x1...xn.  For example, it should choose f(x, y) instead of h(f(x, y))
If there are no such t, automatic generation fails.
There may be more than one t.  In this case, F* would generate a disjunction of the terms {:pattern t1 / ... / tk}

F* would only try to infer patterns if the --auto_patterns flag is set on the command line

I don't have permission to see what tests failed in FStar-Linux. Is it possible to run the tests locally? If so, how to run them?


[Regression] formatting don't work in command line

Expected behavior
if you type formatting into cmd it should display formatted text
Actual behavior
the cursor is behaving like it display only text inside formatting but it show formatting brackets.
Steps to reproduce
in demo:
$.terminal.active().set_command('[[;#fff;]xxx]')

Also there is need for tests, the feature was added but never tested.

LOL, According to my comment this how it should work, you should not be able to type formatting, only formatters should change command line.

There is still one issue though, the cursor is in wrong position, the cursor is corrected like formatting would work.

released in 2.8.0


Fix relation sort (issue #2283)

fix for issue #2283 - after relation sort column with eq. name in main \ relation table set eq. values

Thanks!


provenance examples in wiki

@RubenSchalk says:
do we want to add a section on provenance? If so, we should probably think of a way to try and standardize that as well in the json template

@rlzijdeman: it seems this issue is resolved? I see a provenance chapter in the wiki that was edited on Oct 22, 2018 and you self-assigned it on Oct 18, 2018. I'm closing this issue for now, if you think there's more to be done you can reopen it.


added sass,nodejs category & many other courses

Thank you for helping

@Leocardoso94
Welcome :)
Happy Hacktoberfest!


Don’t auto-update golang (npm, rust, …) packages

golang and npm use the concept of lockfiles, carrying all their files with them. Just changing the version string doesn’t cut it in these cases, the dependencies have to be updated as well (if the lockfile changes), for example https://github.com/NixOS/nixpkgs/commit/413e41db9da54ea1ce4e1552e7815e0342dbe16e#diff-78d6ebbd9a005053af6388888c66decf (in this case the lockfile luckily didn’t change).
The languages I know of that use lockfiles are:

node (yarn.lock for yarn and package-lock.json for npm)
rust (cargo.lock)
golang (sometimes master, sometimes vendor.conf sometimes something different)

It could be automated, but requires some work. Until then I suggest we are conservative.

@Profpatsch Thanks for raising this issue, and I agree they should be excluded until then. Someone already asked to exclude all the python packages because of the python 2 vs 3 issue.
Where is the lockfile for the buildah package and how does the builder refer to it? I was expecting to find it in the nixpkgs repository next to the default.nix file.

Okay, my bad. In case of buildah, they use a vendor/ directory which contains all the sources of all dependencies (ikr). So that would be a rule for golang, if there is a vendor/ dir you can update.


Updating the readme section by adding how to contribute

Hope you like this

Can i know the reason of closing this issue @hasmithagunda123


Feature/image options

Updated to a single dashboard.py file to run the dashboard, images are called from their GitHub URLS, component pieces are in test_components folder with separate instructions, and the main README has been updated.
Note that the current iteration only calls one sample image, we could put an issue to select how many sample images a user wants.

When trying to view the Files changes tab the browser tab becomes unresponsive for me. In the future (assuming we have another PR with many images) if you could put the image files into a separate PR it would make it much easier to review the code.


in/acc manifesto revision proposals - add as new file

Catch-all Issue to tag any PRs related to edits in the manifesto.
Proposed file structure for the interim:

The IndicAcceleration Manifesto.md (The original commit)
in-acc manifesto v2 draft.md (Use this as your file name, we will figure out better organisation with upcoming issues)

well, we can merger and pull requests already https://github.com/protosphinx/in/pull/8#pullrequestreview-1615273253. So will close this "issue", it does not seem to be so.


human-friendly uids

short, human-friendly uids (as an extra, not instead of their original uid) would be nice for identifying events, they could be used for, e.g. deleting an event or printing its details, search could print them etc.
example: 2015-02-03-1600-awesome-idea

The way I solved this in mates is to let the user provide the filepath or an arbitrary search string (that has to yield exactly one result).


Added a configuration needed

server.port needed to assure port conflicts do not occur.

Affects: <github-graphql-collector-version-number>.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

@erictice please update your branch so that this PR can be merged


[FEATURE] Add an automated dataset card on CustomDataset.push_to_hub

Is your feature request related to a problem? Please describe.
It would be nice to automatically have a dataset card for distilabel datasets when we call CustomDataset.push_to_hub.
Describe the solution you'd like
Custom dataset card on the hub with the info from the dataset.
Describe alternatives you've considered
Do it by hand.
Additional context
It should contain at least the badge, the relevant tags, a row example from the dataset...

Closed in favor of #478


Internal dataStorage is incompatible with Meteor

Today I tried this module out on meteor and have to tell that it doesn't work very well with Meteor.
Meteor can update a list, visible on the client, by changes made on the server. The problem I face now is, that the content of the table, decorated by mdDataTable, isn't updated when my reactive collection (that's what meteor creates - see http://richsilv.github.io/meteor/meteor-reactive-data-types/) is updated - either by removing, updating or adding an item.
Changes done to the table (f.e. removing a row) are neither forwarded to the object this table originally was bound to, but has to be done manually by the delete-row-callback callback.
I guess this is mostly because this plugin has it's own internal data storage instead of directly using the collection I provide.
What ideas are connected to this data storage? What hinders you to directly work with the collection provided?

Don't mean to hijack but.....
I have a similar issue, which I think is related (also in Meteor).
The table reflects changes made to my model (including adding rows), but changes made to cell contents (via the editable-field attribute on the cell) are not reflected back to the model. Perhaps there is a binding required in my code?
Any help/suggestions are appreciated.

@barttt I now switched to https://github.com/daniel-nagy/md-data-table which has a quite similar appearance and works perfectly with meteor and meteor-angular.

Thanks Simon
I was under the impression that the nagy project was no longer maintained??

Don't know ... it at least works better in my case. If there's something I need, I'll fork it and create a PR. If it turns out not to be maintained anymore, I'll maintain my own fork.
There's a request for this feature on the official material-design package and some PRs for this have been closed due to inactivity, but I need something now ... https://github.com/angular/material/issues/796

Thanks again Simon-
I will have a look. I am in the same boat re: needing something now. Unfortunately I am rather new to angular and fud reigns currently.


Buffer.open_in_editor() deletes the file before opening editor

For me -  running in synch mode, i.e.not asynch :) - the parameter enable_open_in_editor works the first time. But the second time it's invoked. The temp file is deleted before the editor is launched.
buffer.py#L1348
I added some logging around the above line, and it seems that the second time it just falls through down to the os.remove(filename) even before the editor is launched. This behavior is 100% consistent, so far...
This second time, when the editor is launched, the content is of course empty (and editor might say it is a new file).
Anyone else seen this?
I didn't dig into run_in_terminal() and the Future it returns, yet. I thought I'd ask here first.

Hi @tatsujin1,
That looks like a bug indeed. Thanks a lot for reporting!
I could not reproduce it, but noticed that this code wasn't running in an executor. This is fixed here: https://github.com/jonathanslenders/python-prompt-toolkit/commit/c33281e3d1f288e2dc7771962e14bdaa0b517b4a
Could you try again?
(Internally, prompt toolkit is completely async, even if you call it through synchronous APIs.)
Jonathan

Yep, that fixed it! Thanks!


Avoid relinking because of CompilationInfo

Now only indices built via IndexBuilderMain will have the correct git hash.
The advantage is , that the index library doesn't have to be relinked on every recompilation which greatly helps, because a lot of unit tests depend on it.

What's the benefit of this vs using the cmake flag DONT_UPDATE_COMPILATION_INFO?

@RobinTF
The DDONT_UPDATE_COMPILATION_INFO flag has several disadvantages:

You have to manually set it for every new configuration, and I have a lot of them (several compilers, Debug/Release/RelWithDebInfo, Sanitizers, whatever QLeverspecific configuration we might have).
For each configuration you have to first run CMake once without the flag (so you actually have the .cpp file) and only then set the flag. This is annoying.
 This in particular holds with students who don't have that much experience with lowlevel CMake stuff.

In summary I think that my approach makes everyone happy using the default configuration.


Method not found: Microsoft.ML.AutoML.BestResultUtil.GetTopNRunResults

Model Builder Version: <IP_ADDRESS>7905
Visual Studio Version: VS2019 16.6.3
Bug description
With freshly-updated [as of today, 2020-07-04] VS2019 and model builder, I tried to use the new ML builder wizard "image classifier". It failed with an exception: Method not found: 'System.Collections.Generic.IEnumerable1<System.ValueTuple2<Microsoft.ML.AutoML.RunDetail`1<!!0>,Int32>> Microsoft.ML.AutoML.BestResultUtil.GetTopNRunResults
Steps to Reproduce

Installed latest VS 2019 and updated Model Builder to latest version
Create new project. Right click on project -> Add -> "Machine Learning"
Choose image classification, "Local ML", Next.
As input, choose an appropriate folder, observe "data preview" looks like I expected, with images being shown under various classifications
Train, Start Training.

Expected Experience
Pretty much what I'd expect from the tutorial, and of a wizard.
Actual Experience
Shortly after click "start training", I get this:
"GPU Service not found. Falling back to CPU AutoML Service."
Moments later, this exception:
Method not found: 'System.Collections.Generic.IEnumerable1<System.ValueTuple2<Microsoft.ML.AutoML.RunDetail1<!!0>,Int32>> Microsoft.ML.AutoML.BestResultUtil.GetTopNRunResults(System.Collections.Generic.IEnumerable1<Microsoft.ML.AutoML.RunDetail1<!!0>>, Microsoft.ML.AutoML.IMetricsAgent1<!!0>, Int32, Boolean)'.
at Microsoft.ML.ModelBuilder.AutoMLService.Experiments.AutoMLExperiment3.<ExecuteAsync>d__21.MoveNext()    at System.Runtime.CompilerServices.AsyncTaskMethodBuilder1.Start[TStateMachine](TStateMachine& stateMachine)
at Microsoft.ML.ModelBuilder.AutoMLService.Experiments.AutoMLExperiment3.ExecuteAsync(IDataView trainData, IDataView validateData, ColumnInformation columnInformation, Nullable1 userCancellationToken, Nullable`1 timeout)
at Microsoft.ML.ModelBuilder.AutoMLEngine.d__30.MoveNext() in /_/src/Microsoft.ML.ModelBuilder.AutoMLService/AutoMLEngineService/AutoMLEngine.cs:line 147
Additional Context
Clicking "Open Log File" brings up this file:
bdcc7a7b-fad5-4a23-8f95-54b9d04e13f6.txt
Screenshot:

This is a MS Surface, not sure what marque. It has an intel core i7-7660U @ 2.50GHz, 16GB Memory, 64-bit OS.
Windows 10 Enterprise 1903, build 18362.900

digits_small.zip
Here's the dataset I was using

I just updated VS to the latest 16.6.5, but I'm still having the same problem.

Sorry this fell off my radar! I'll try it out today. Thanks for all the details

Thank you! Please let me know if there's anything else I can do to assist. At work I'm exploring a cavalcade of new AI and ML options right now, and if this was working for me, it adds a very appealing option to the table.

Unfortunately this is still happening in today's new release of ML Model Builder [<IP_ADDRESS>1102] with the latest VS [16.7.532.28833]

I just tried completely uninstalling and reinstalling VS, but am still having the same issue. Is a fix for this on the horizon?

As mentioned, I previously had tried uninstalling and reinstalling VS, no dice. I happened to get a new laptop at work, and tried installing just the latest VS and Model Builder from scratch on a fresh windows install, today. I had had the previous laptop for ~4 years, and during that time it had had pretty much every released dotnet core version installed on it. I'm guessing that latest
This error has now gone away.

I have exactly the same behaviour: on my dev PC where previous versions of .NET Core SDK 3.1 have been installed the above error occures. I tried to uninstall all other .NET Core SDK versions except the newest one but this doesn't help. On a fresh windows install everything works like expected with VS19. So sounds indeed like a leftover of an old installation. Is there any chance to get this fixed?

I have same problem, work on it for several days , cann't fixed yet.

this solved my problem https://github.com/dotnet/machinelearning-modelbuilder/issues/1259#issuecomment-813568213

this solved my problem #1259 (comment)

Would also be interested in testing this. @LiQIjie  could you quickly explain how to install the mentioned preview?

this solved my problem #1259 (comment)

Would also be interested in testing this. @LiQIjie  could you quickly explain how to install the mentioned preview?

Take a look here
https://docs.microsoft.com/en-us/visualstudio/extensibility/private-galleries?view=vs-2019

CPU model builder works well ,but GPU model builder not.

All the work I do that involved ML.NET is on Linux. As far as I know, that's only CLI for the forseeable future?

Correct, Linux is CLI for the foreseeable future. I'll update the issue when the new CLI ships.

@chunky
You can try cli preivew from this feed

https://mlnetcli.blob.core.windows.net/mlnetcli/index.json

To install mlnet from that feed

dotnet tool install -g mlnet --add-source https://mlnetcli.blob.core.windows.net/mlnetcli/index.json

This issue should be resolved and released. If anyone is still experiencing a problem please open a new issue. Thanks!


react-tap-event-plugin and React "1.0 release"

Doc says that react-tap-event-plugin will go away with React "1.0", React is now in Version 15.0.1, not exactly 1.0 but what this all mean for the react-tap-event-plugin dependecy?

@L3V147H4N that information is outdated and will be fixed in the upcoming release.

:+1:

I'm reopening this Issue on account that the documentation hasn't changed and the react-tap-event-plugin is still listed in the peerDependencies, do I need the react-tap-event-plugin package?

What was out of date was the reference to React 1.0 - they jumped straight from 0.14.x to 15.0.0, so no version 1.0. What isn't out of date is the need for react-tap-event-plugin, since React 15.0.0 didn;t change anything in that regard.

@mbrookes thx for clearing the misunderstanding


E2E: Stop retrying destroy if inputs are missing

In situations where we don't create anything, e.G. because an invalid
release image was specified, the e2e destroy code loops forever withot
any chance of success. Avoid this.

What this PR does / why we need it:
Which issue(s) this PR fixes (optional, use fixes #<issue_number>(, fixes #<issue_number>, ...) format, where issue_number might be a GitHub issue, or a Jira story:
Fixes #
Checklist

[ ] Subject and description added to both, commit and PR.
[ ] Relevant issues have been referenced.
[ ] This change includes docs.
[ ] This change includes unit tests.

/lgtm