POSIX readv()/preadv()/writev()/pwritev() misreporting number of bytes read/written under preview 2 (as found by Python)

Test Case
TODO: upload Wasm file here
Steps to Reproduce

https://github.com/python/cpython/blob/07236f5b39a2e534cf190cd4f7c73300d209520b/Lib/test/test_posix.py#L520-L525
https://github.com/python/cpython/blob/07236f5b39a2e534cf190cd4f7c73300d209520b/Lib/test/test_posix.py#L307-L311
https://github.com/python/cpython/blob/07236f5b39a2e534cf190cd4f7c73300d209520b/Lib/test/test_posix.py#L487-L490
https://github.com/python/cpython/blob/07236f5b39a2e534cf190cd4f7c73300d209520b/Lib/test/test_posix.py#L364-L369

Expected Results
To be told 10 bytes were read/written.
Actual Results
5 bytes, which matches the first buffer, not the total bytes written across all buffers.
Versions and Environment
Wasmtime version or commit: 17.0.0
Operating system: Linux/WSL
Architecture: x64
Extra Info
Success logs when testing readv():
success-readv.txt
Failuse logs:
failure-readv.txt

If I'm looking this up right, https://github.com/bytecodealliance/wasmtime/blob/5c0027be59553f085589ce7b11cb596a3704aff2/crates/wasi/src/preview2/preview1.rs#L1309 seems to ignore all but the first buffer. https://github.com/bytecodealliance/wasmtime/blob/5c0027be59553f085589ce7b11cb596a3704aff2/crates/wasi-preview1-component-adapter/src/lib.rs#L989 examines all of them.

The preview2 based preview1 implementation which is now used by default indeed only looks at the first buffer. See also https://github.com/bytecodealliance/wasmtime/issues/7757. wasi-preview1-component-adapter also only looks at the first buffer as far as I can see.

Yes I can confirm that this is expected right now. It's expected that this is still posix-conformant in that posix doesn't guarantee everything is written. Vectored reads/writes aren't present in preview2 so they're polyfilled from preview1 by looking at the first buffer.

Yes I can confirm that this is expected right now.

As in this isn't expected to change? I think I can mark those POSIX functions as unsupported in https://github.com/python/cpython/blob/main/Tools/wasm/config.site-wasm32-wasi so the tests pass if you plan to keep the current semantics.

Correct yeah, that's not expected to change.

I've tweaked the title and closing this as it's working as intended. I'll patch CPython to consider these functions as unavailable.


ingore unnecessary-pass in pylintrc

Title for squash and merge:
ingore unnecessary-pass in pylintrc

Description:
Because that caused problems e.g. when defining custom
exception classes by subclassing from building base exceptions.

Codecov Report

Merging #81 (418f238) into main (955aad8) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main      #81   +/-   ##
=======================================
  Coverage   68.53%   68.53%
=======================================
  Files          14       14
  Lines          89       89
=======================================
  Hits           61       61
  Misses         28       28

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 955aad8...418f238. Read the comment docs.


[MM-25263] Add view group members modal

Summary

Adds view group members modal to the team and channel configuration pages in the system console
Updates the existing groups list on the group page to use the newly added getProfilesInGroup selector and action.

Ticket Link

https://mattermost.atlassian.net/browse/MM-25263

Related Pull Requests

Has server changes: https://github.com/mattermost/mattermost-server/pull/14733
Has redux changes: https://github.com/mattermost/mattermost-redux/pull/1167

Screenshots

Updated screens based on discussion with @michaelgamble

@michaelgamble can you review the search component on the team > users block

This is the specific page with https://mattermost-webapp-pr-5634.test.mattermost.cloud/admin_console/user_management/teams/4kz3b5gwqfr8drcxyiknuprror changes to view @michaelgamble

Also a question to @michaelgamble:
Currently the link to view Members count does not has an underline while hovering over it. The other 2 links in the same section, i.e. Member dropdown and Remove button has an underline when we hover over it. Should we make this consistent?

@srkgupta that is an existing bug that exists on master - I would prefer to fix that as a different PR as this PR is getting massive and theres a bunch of type fixes that i need to get merged into master

@srkgupta that is an existing bug that exists on master - I would prefer to fix that as a different PR as this PR is getting massive and theres a bunch of type fixes that i need to get merged into master

Sure. Thanks for the confirmation @fmunshi. I am going ahead and approving this PR. @michaelgamble please let me know if the hovering over issue also needs to be fixed. It's a very very minor issue which can be eventually fixed later. So not holding this PR for it.

@srkgupta that is an existing bug that exists on master - I would prefer to fix that as a different PR as this PR is getting massive and theres a bunch of type fixes that i need to get merged into master

Sure. Thanks for the confirmation @fmunshi. I am going ahead and approving this PR. @michaelgamble please let me know if the hovering over issue also needs to be fixed. It's a very very minor issue which can be eventually fixed later. So not holding this PR for it.

It should be consistent, the hover state should have an underline like the others, so we should fix this.
On another note the GIF that you posted has a value of "NaN Members" that should never be possible, are we making sure that doesnt get in this way? @fmunshi @srkgupta

On another note the GIF that you posted has a value of "NaN Members" that should never be possible, are we making sure that doesnt get in this way? @fmunshi @srkgupta

Thanks for the confirmation. Yeah that issue is reported here and it's not a regression. So this will be fixed outside this PR.
https://mattermost.atlassian.net/browse/MM-26219

Im gonna merge and fix the link issue along with the NaN issue in a separate ticket along with any other issues Mike brings cause there are a lot of test changes from redux that I want to merge in asap.


[User Story] User Retrieves their Username

[User Story]
User Retrieves Username

Epic Title
Advance Authentication #65

User Story Title
User Retrieves their Username

T-shirt size: SML

User Story
An an authorized user with a bad memory, I want to retrieve my NEXT username on my own without assistance from a person.

Acceptance Criteria/Tests
The user is prompted for some information that only they would know (or email address used within Next) Once info is provided, the system coughs up the username (or emails username to the registered email address).  If the info provided doesn't match anything, we shouldn't inform the user.

UX/UI Details and/or mockups
Looks like we need UI on the sign in page.  Have to add a 'forgot username' button.  It should then prompt me for my registered email address?

Questions/Clarifications

An alternative to this story would be a feature to simply allow a user to log in via either their username or their email. Or that may be a configurable option and would need to support both.

I like Adam's suggestion on this one...  so main screen maybe just needs to say "username or email" and we accept either one. ??

migrated to new tmobile/sawtooth-next-directory repo


Login with username or password

I wonder if there is any easy way to set login with either username or password. When I read the doc it does specify this. But allauth does have that feature. It is activated by putting ACCOUNT_AUTHENTICATION_METHOD = "username_email" in settings file. But clearly this does not apply for the django-rest-auth.

ahh... find a solution you just need to set proper settings combination like so and you also need to add email authentication backends :
ACCOUNT_AUTHENTICATION_METHOD = "username_email"
ACCOUNT_EMAIL_REQUIRED = True
ACCOUNT_UNIQUE_EMAIL = True
ACCOUNT_USERNAME_REQUIRED = False


Convert to src to TypeScript

Right now we have recognized a few issues in the build process such as missing the ability to support union types and some of the other ts2.0 new type features.  The build process also can be a bit tricky since there are so many moving parts.  With Aurelia-Validation I believe @jdanyow and @niieani have done a good job of showing that the plugin repo's can use TS in a nice, clean, and elegant fashion.
I'm proposing we convert over the existing codebase to use the TypeScript build and enforce typings a bit further.
Pros:
Easier build process
Easier to enforce typings are correct
Cons:
Could be intimidating to ask for PRs if the developer isn't comfortable with TypeScript
Adds no real "features" to the repo.
@EisenbergEffect @StrahilKazlachev @cmichaelgraham and anyone else mentioned or who is interested feedback welcome.

I'm ok with this but we need a full working build process. The Validation library is actually in TypeScript but it's kind of a pain because it's missing a lot of features that the build from our other libraries have. We need to get that library at 100% fidelity first and then we can use it as a template to move other libraries over.

https://github.com/aurelia/validation/issues/357

Thanks!
On Oct 8, 2016 12:29 PM, "Jeremy Danyow"<EMAIL_ADDRESS>wrote:

aurelia/validation#357 https://github.com/aurelia/validation/issues/357
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/aurelia/dialog/issues/217#issuecomment-252443583, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAIBnRhsrfBNHALizo_UO74QHxlt8tHsks5qx-82gaJpZM4KRzV1
.

Agreed then that those issues need to be resolved first.  I'll comment there.

Still waiting on a few last tasks before converting just giving an update

@StrahilKazlachev I think we can safely start on this after the current PR's are accepted as all of the outstanding issues from validation are handled (except for one last task which has a PR that will be merged this week)
If you want to schedule a quick call some time over the next week or two to discuss current state and how we can do this whilst achieving the coveted v1 tag let me know!  Thanks again for all your contributions, they do not go unnoticed.

For the initial implement -

Convert build.js task to use gulp-typescript instead of babel
Remove dts-generator
Make sure .d.ts is being generated / output
Make sure output matches current output structure

After that we can review tooling.

@PWKad I think it might be easier to just switch to the stack used by any of the Aurelia repos which already use TypeScript, and get rid of gulp dependencies.

After converting over we will probably do that, trying to isolate to one major change at a time.

Done and released. Common build infrastructure is being discussed separately.


Removed revision related permission checks

ping @yakky

Coverage remained the same at 82.459% when pulling 3b53db7c800801ed6c80071a4dab273f47eb93c6 on czpython:fixes/remove-can-recover-checkbox into 55250cec8c9844a7608abffe5eab23b8214f4ce6 on divio:develop.

👍


Unable to dismiss popover from popover.

Hey everyone, I am having an odd issue thats easy to solve, I probably just can't see it. Basically, I am trying to programmatically dismiss the popover from the popover, for which I haven't had success with.
Here is the code I am trying (hooked up to a button in the popover):
[self.delegate dismissPopoverAnimated:YES];
where delegate is set to:
selectionViewController.delegate = (MasterViewController*) self.view.window.rootViewController;
MasterViewController is the view controller from which I am instigating the popover. Any suggestions?

@mdaymond I ended up not using the popover.

Well, same issue. Any more ideas?

UIWindow *mainWindow = [[[UIApplication sharedApplication] windows] objectAtIndex:0];
for (UIView *view in mainWindow.subviews) {
if (view.class == [WYPopoverOverlayView class]) {
[(WYPopoverOverlayView *)view touchesBegan:nil withEvent:nil];
}
NSLog(@"Subviews %@", mainWindow.subviews);
}
is how I accomplished it

Even easier! And in Swift:
Parent View (with Popover Controller):
`
override func viewDidLoad(){
....
NSNotificationCenter.defaultCenter().addObserver(self, selector: "dismissPopover", name: "dismissPopover", object: nil)
.....
}
func dismissPopover(){
self.popoverController?.dismissPopoverAnimated(true)
}
....
The actual Popover's View Controller:
func save(){
.....
NSNotificationCenter.defaultCenter().postNotificationName("dismissPopover", object: nil)
....
}
`


Why you are using conv2d in the Discriminator?

 Hope they will be fixed in a future version.

@hbk16
Thanks for correction.
Since this is an extension version which tries Unet as generator and wgan-gp as Discriminator. Currently, the code is mainly working on 2D, and the codes in Unet2d_pytorch.py are fine (we are currently mainly testing on the 2D).
We will update the 3D version as soon as we can. Sorry for the confusion. And we have a 3d version with tensorflow.

@hbk16
Here is the original 3d version in TF (since we create it as early as 2016, part of the codes may be deprecated. And that's also partially the reason we implement a new one with pytorch)
https://github.com/ginobilinie/medSynthesis/tree/master/3dversion

Thank you.
BTW, the Generator in this code is a bit different from the one described in your paper.

Thank you.
BTW, since the input size of the generator is 32x32x32 and the output size is 16x16x16, it seems that there should be a down sampling layer before the input being add to the residual output, which is not described in the paper.

@hbk16
We do not involve a down sampling layer in the FCN since downsampling layer will lose too much information and it is bad for image synthesis. We only involve convs+(bn+)relu in the FCN.
As in the code we uploaded, it is source image: 32x32x32-> target image: 24x24x24. If you need that 32x32x32->16x16x16, I can also find it and share with you.

Many thanks.
It would be really appreciated if you can send the model to<EMAIL_ADDRESS>or make a new commit.

Sure


Add an input_circuit(s) method in css & qss

Allows users to output the circuit they submitted for a job in css and qss. Implementation mirrors the compiled_circuit(s) method.
Also ensures that compiled circuit metadata is the same as the input circuit; fixes https://github.com/Infleqtion/server-superstaq/issues/2555
Requires https://github.com/Infleqtion/server-superstaq/pull/2608.

https://github.com/Infleqtion/server-superstaq/pull/2636/files doesn't remove returning of the input circuit so it should be fine, but I'll wait for that to be merged in first


Update debt email popup GovDelivery code

Per stakeholder, the email popups on debt-related pages should be changed from USCFPB_153 to USCFPB_152. See GHE#2528.
Testing

Run a local server with a production dump.

Visit http://localhost:8000/consumer-tools/debt-collection/ in an incognito window and scroll to the bottom of the page. You should see an email popup appear.

Submit the popup form with an email address.

In the console, you should see a line like this:
<EMAIL_ADDRESS>[u'USCFPB_152'], send_notifications=True)

indicating that the USCFPB_152 code is the one being subscribed to.

Checklist

[X] PR has an informative and human-readable title
[X] Changes are limited to a single goal (no scope creep)
[X] Code can be automatically merged (no conflicts)
[X] Code follows the standards laid out in the development playbook
[X] Passes all existing automated tests
[X] Any change in functionality is tested
[x] New functions are documented (with a description, list of inputs, and expected output)
[X] Placeholder code is flagged
[X] Visually tested in supported browsers and devices
[X] Project documentation has been updated
[X] Reviewers requested with the Reviewer tool :arrow_right:

Self-merging to get this out on time and because it's a one-line change.


MB-4940 Display move info for all valid move types

Description
Before, we were only displaying the Move status, locator and number of
shipments for moves of SelectedMoveType HHG. For now, we also want
to support HHG_PPM, NTS, and NTSR, but not PPM, UB, and POV.
Reviewer Notes
Run make db_dev_e2e_populate
Log in as a TOO
Verify that you see the NTS and NTSR moves and that they show the move locator, status, and number of shipments.
Code Review Verification Steps

[ ] If the change is risky, it has been tested in experimental before merging.
[ ] Code follows the guidelines for Logging
[ ] The requirements listed in
Querying the Database Safely
have been satisfied.
Any new migrations/schema changes:

[ ] Follow our guidelines for zero-downtime deploys (see Zero-Downtime Deploys)
[ ] Have been communicated to #g-database
[ ] Secure migrations have been tested following the instructions in our docs

[ ] There are no aXe warnings for UI.
[ ] This works in Supported Browsers and their phone views (Chrome, Firefox, IE, Edge).
[ ] Tested in the Experimental environment (for changes to containers, app startup, or connection to data stores)
[ ] User facing changes have been reviewed by design.
[ ] Request review from a member of a different team.
[ ] Have the Jira acceptance criteria been met for this change?

References

Jira story for this change

Screenshots

Messages

:book:
:link: MB-4940

  Generated by :no_entry_sign: dangerJS against 734312a59fd927dc4f96aa824930efdf56785a89


Add column order support for index annotations

This brings in support for ordered indexes in cycle annotations like:
@Index(columns={"name", "id DESC"})

Could you cut a fresh release as well?

Sure, but, sadly, SQLite issue for 7.4+ must go first. Going to check it today.


cloud-print-connector.service  Active: inactive (dead)

I followed the instructions for Rasbian (Jessie). After boot the service is inactive:
root@10102:~# sudo systemctl status cloud-print-connector.service -l
● cloud-print-connector.service - Google Cloud Print Connector
Loaded: loaded (/etc/systemd/system/cloud-print-connector.service; enabled)
Active: inactive (dead) since Mon 2017-03-20 22:42:20 CET; 31s ago
Docs: https://github.com/google/cloud-print-connector
Process: 530 ExecStart=/opt/cloud-print-connector/gcp-cups-connector -config-filename /opt/cloud-print-connector/gcp-cups-connector.config.json (code=exited,                                         status=0/SUCCESS)
Main PID: 530 (code=exited, status=0/SUCCESS)
Mar 20 22:42:20 10102.cps.domain.com systemd[1]: Started Google Cloud Print Connector.
Mar 20 22:42:20 10102.cps.domain.com gcp-cups-connector[530]: Google Cloud Print Connector for CUPS version DEV-linux
After
sudo systemctl start cloud-print-connector.service:
● cloud-print-connector.service - Google Cloud Print Connector
Loaded: loaded (/etc/systemd/system/cloud-print-connector.service; enabled)
Active: active (running) since Mon 2017-03-20 22:54:33 CET; 6s ago
Docs: https://github.com/google/cloud-print-connector
Main PID: 1216 (gcp-cups-connec)
CGroup: /system.slice/cloud-print-connector.service
└─1216 /opt/cloud-print-connector/gcp-cups-connector -config-filename /opt/cloud-print-connector/gcp-cups-connector.config.json
Mar 20 22:54:33 10102.cps.domain.com systemd[1]: Started Google Cloud Print Connector.
Mar 20 22:54:33 10102.cps.domain.com gcp-cups-connector[1216]: Google Cloud Print Connector for CUPS version DEV-linux
Mar 20 22:54:36 10102.cps.domain.com systemd[1]: Started Google Cloud Print Connector.
Mar 20 22:54:37 10102.cps.domain.com gcp-cups-connector[1216]: Ready to rock as proxy 'eb9db293-b337-4d09-9d40-3ab3b4898022' and in local mode
Has anybody an idea?

I have the same issue.  From what I read here Why is my Systemd unit loaded, but inactive (dead)?, it appears that the cloud print service is loading and then exiting.
Any help would be appreciated.

By default, systemd will give up trying to restart a failed service after a while. This is surprising to me, but it is documented to do this. See https://github.com/systemd/systemd/issues/2416.
I suggest editing the systemd config so that it will indefinitely try to restart cups-connector.

I got it to work using this:
Restart=always RestartSec=90 StartLimitInterval=400 StartLimitBurst=3
It originally had:
Restart=on-failure
Since the service would first start and them exit successfuly (no failure) it would never try to restart.
Thanks agode for pointing me in the right direction.


Prerendering routes ends with .html to non-indexed HTML file

Describe the problem
Currently, routes like src/routes/about.html.svelte are prerendered to build/about.html/index.html .  But they should be written to build/about.html
I think this is not a bug (routes which ends with .html are not considered and not mentioned in docs).  But it would be useful if we could use a route which ends with .html , especially for custom 404 page for some platforms (See Additional Information).
Describe the proposed solution
Routes like src/routes/**/*.html.svelte are prerendered to build/**/*.html .
This may conflict with SvelteKit option trailingslash: "always" .  When prerendering, all internal links are normalized to urls with trailing slash.  We have to exclude links ends with .html from this behavior.
Alternatives considered
Currently I worked out by directory copying files in the output, like cp build/404.html/index.html build/404.html (See my solution in build command )
Importance
nice to have
Additional Information
Some platforms for static website uses 404.html for custom 404 page.

GitHub Pages: https://docs.github.com/en/pages/getting-started-with-github-pages/creating-a-custom-404-page-for-your-github-pages-site
Cloudflare Pages: https://developers.cloudflare.com/pages/platform/serving-pages#not-found-behavior
Netlify: https://docs.netlify.com/routing/redirects/redirect-options/#custom-404-page-handling
Vercel: https://vercel.com/guides/custom-404-page#static-site-generatator-(ssg)

Sorry, this was a duplicate of #1443 .


not working like before .. error on home page

Hi
After upgrade to rc6 and dividing code ... it is showing :+1:
Whitelabel Error Page
on <IP_ADDRESS>:8080 - for both gradle bootRun and gradle bootRepackage and running Jar file

navigate to localhost:3000, angular code is served on it's own webpack dev server now. The rest api runs on tomcat which is at localhost:8080, there is no html content served from that port any longer. You can check the updated readme/wiki for more info.

Hi
Many thanks for your reply. I thought the idea is to host the ui in spring as a frontend to access other remote rest, now no connection between rest client - ui - and jave code right ??
Regards
Sent from my iPhone

On Sep 7, 2016, at 10:45 AM, Borys H.N<EMAIL_ADDRESS>wrote:
navigate to localhost:3000, angular code is served on it's own webpack dev server now. The rest api runs on tomcat which is at localhost:8080, there is no html content served from that port any longer. You can check the updated readme/wiki for more info.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

The idea is to have an app server abstracted away from a client. The app server can then be used for any front end client, like an android apps!
The project then specifically focuses on a web client implementation using angular2. The only connection between the java code (app server) and the front end client (angular2) is the rest api, that was true before as well.
The app server and the client can still access what ever rest api they need. The application functions the same, the web code is just served on it's own server following good restful methodology.

Thanks a lot

On Sep 7, 2016, at 8:18 PM, Borys H.N<EMAIL_ADDRESS>wrote:
The idea is to have an app server abstracted away from a client. The app server can then be used for any front end client, like an android apps!
The project then specifically focuses on a web client implementation using angular2. The only connection between the java code (app server) and the front end client (angular2) is the rest api, that was true before as well.
The app server and the client can still access what ever rest api they need. The application functions the same, the web code is just served on it's own server following good restful methodology.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/borysn/spring-boot-angular2/issues/14#issuecomment-245335293, or mute the thread https://github.com/notifications/unsubscribe-auth/ABYoc6szkC2BDsXKAS_0c1co2iIMifloks5qnuPJgaJpZM4J2ldT.

@siddigd no problem!


Cannot install latest version with Laravel 5.5

On dev-master, the composer.json updated to support Laravel 5.5, but in latest released, it doesn't.
Could you make a new release, please?

+1

+1

+1

+1

Add "nahid/talk": "dev-master" under 'require' in composer.json and then run composer update. Works fine.

#108

#108


Navigation styles

In this pull request i performed,

[ ] Make corrections to navigations
[ ] Intergrated some icons
[ ] fixed linter errors

I confirmed that iam on the recent branch and not getting errors, kindly confirm that


tests/vm_test.go: Add missing matcher to Eventually

What this PR does / why we need it:
Some of the VirtualMachineControllerFinalizer test use Eventually with a polling function but are missing a matcher to verify the polling function actually succeeds. This adds matchers where they are missing.
Release note:

None

/cc @tiraboschi


Updating ontology upload scripts to include a pair for upload TSV as …

…KBaseOntology.OntologyTranslation objects and vice-versa, including tests

I'm going to merge for you to test in CI, but I think you may still have problems with "./ont.pl", since where your script is called from will be different, and since KBase has these "wrapper" shell scripts that instantiate an environment before calling the actual perl or python script.  This means "ont" would be in your path, which would be something like /kb/deployment/lib/bin/, but "ont.pl" would not be there and so you would likely get an error from CI here.


Wrong link in curren documentation although in github it looks right to me

On this page https://docs.mendix.com/refguide6/search-bar the Drop-Down Search Field link goes to https://docs.mendix.com/refguide6/drop_down instead of  docs/refguide6/drop-down-search-field.md .
Either I am not understaning how links are generated in the document or that something else goes wrong here.
Regards,
Ronald

Hi Ronald,
Thanks for the report. We're investigating the issue.

Good call, missed that one. I think the problem is in this redirect.
Curl log:
14:21 $ curl -I -L -v https://docs.mendix.com/refguide6/Drop+Down+Search+Field
*   Trying <IP_ADDRESS>...
* Connected to docs.mendix.com (<IP_ADDRESS>) port 443 (#0)
* TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* Server certificate: *.mendix.com
* Server certificate: RapidSSL SHA256 CA
* Server certificate: GeoTrust Global CA
> HEAD /refguide6/Drop+Down+Search+Field HTTP/1.1
> Host: docs.mendix.com
> User-Agent: curl/7.43.0
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
HTTP/1.1 301 Moved Permanently
< Content-Length: 178
Content-Length: 178
< Content-Type: text/html
Content-Type: text/html
< Date: Thu, 19 Jan 2017 13:21:34 GMT
Date: Thu, 19 Jan 2017 13:21:34 GMT
< Location: https://docs.mendix.com/refguide6/drop-down-search-field
Location: https://docs.mendix.com/refguide6/drop-down-search-field
< Server: nginx
Server: nginx
< X-Vcap-Request-Id: 3a91e311-b1f5-4142-5621-98a425089613
X-Vcap-Request-Id: 3a91e311-b1f5-4142-5621-98a425089613
< Connection: keep-alive
Connection: keep-alive

<
* Connection #0 to host docs.mendix.com left intact
* Issue another request to this URL: 'https://docs.mendix.com/refguide6/drop-down-search-field'
* Found bundle for host docs.mendix.com: 0x7fab3140fc90
* Re-using existing connection! (#0) with host docs.mendix.com
* Connected to docs.mendix.com (<IP_ADDRESS>) port 443 (#0)
> HEAD /refguide6/drop-down-search-field HTTP/1.1
> Host: docs.mendix.com
> User-Agent: curl/7.43.0
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
HTTP/1.1 301 Moved Permanently
< Content-Length: 178
Content-Length: 178
< Content-Type: text/html
Content-Type: text/html
< Date: Thu, 19 Jan 2017 13:21:34 GMT
Date: Thu, 19 Jan 2017 13:21:34 GMT
< Location: https://docs.mendix.com/refguide6/drop_down
Location: https://docs.mendix.com/refguide6/drop_down
< Server: nginx
Server: nginx
< X-Vcap-Request-Id: d572cf18-801b-401e-4db8-decaa45f4f03
X-Vcap-Request-Id: d572cf18-801b-401e-4db8-decaa45f4f03
< Connection: keep-alive
Connection: keep-alive

<
* Connection #0 to host docs.mendix.com left intact
* Issue another request to this URL: 'https://docs.mendix.com/refguide6/drop_down'
* Found bundle for host docs.mendix.com: 0x7fab3140fc90
* Re-using existing connection! (#0) with host docs.mendix.com
* Connected to docs.mendix.com (<IP_ADDRESS>) port 443 (#0)
> HEAD /refguide6/drop_down HTTP/1.1
> Host: docs.mendix.com
> User-Agent: curl/7.43.0
> Accept: */*
>
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
< Accept-Ranges: bytes
Accept-Ranges: bytes
< Content-Length: 23049
Content-Length: 23049
< Content-Type: text/html; charset=utf-8
Content-Type: text/html; charset=utf-8
< Date: Thu, 19 Jan 2017 13:21:34 GMT
Date: Thu, 19 Jan 2017 13:21:34 GMT
< Etag: "58807ce8-5a09"
Etag: "58807ce8-5a09"
< Last-Modified: Thu, 19 Jan 2017 08:46:32 GMT
Last-Modified: Thu, 19 Jan 2017 08:46:32 GMT
< Server: nginx
Server: nginx
< X-Vcap-Request-Id: f821db38-a95e-42ce-402d-505e85736edf
X-Vcap-Request-Id: f821db38-a95e-42ce-402d-505e85736edf
< Connection: keep-alive
Connection: keep-alive

<
* Connection #0 to host docs.mendix.com left intact

I'll investigate this

Created a fix, but having some trouble with Cloudfoundry, so I'll test this later


v.0.5.0 to Dev

See commits for details.

Hello @mikkokotila! Thanks for submitting the PR.

In the file setup.py, following are the PEP8 issues :

Line 68:80: E501 line too long (85 > 79 characters)
Line 69:80: E501 line too long (84 > 79 characters)
Line 74:80: E501 line too long (81 > 79 characters)

In the file talos/__init__.py, following are the PEP8 issues :

Line 17:80: E501 line too long (80 > 79 characters)

In the file talos/commands/deploy.py, following are the PEP8 issues :

Line 16:9: E303 too many blank lines (2)
Line 19:66: W291 trailing whitespace
Line 29:62: W291 trailing whitespace
Line 31:80: E501 line too long (81 > 79 characters)
Line 67:80: E501 line too long (82 > 79 characters)
Line 91:80: E501 line too long (301 > 79 characters)

In the file talos/commands/kerasmodel.py, following are the PEP8 issues :

Line 11:80: E501 line too long (83 > 79 characters)
Line 76:80: E501 line too long (92 > 79 characters)

In the file talos/commands/params.py, following are the PEP8 issues :

Line 104:80: E501 line too long (84 > 79 characters)

In the file talos/examples/datasets.py, following are the PEP8 issues :

Line 4:80: E501 line too long (92 > 79 characters)
Line 18:80: E501 line too long (92 > 79 characters)
Line 42:80: E501 line too long (92 > 79 characters)
Line 59:80: E501 line too long (92 > 79 characters)
Line 77:80: E501 line too long (92 > 79 characters)

In the file talos/examples/models.py, following are the PEP8 issues :

Line 10:80: E501 line too long (83 > 79 characters)
Line 52:80: E501 line too long (83 > 79 characters)

In the file talos/metrics/keras_metrics.py, following are the PEP8 issues :

Line 4:1: E303 too many blank lines (3)
Line 59:80: E501 line too long (82 > 79 characters)

In the file talos/parameters/ParamGrid.py, following are the PEP8 issues :

Line 41:80: E501 line too long (85 > 79 characters)
Line 48:80: E501 line too long (89 > 79 characters)
Line 52:80: E501 line too long (83 > 79 characters)
Line 65:1: W293 blank line contains whitespace
Line 74:1: W293 blank line contains whitespace

In the file talos/parameters/permutation_filter.py, following are the PEP8 issues :

Line 3:1: W191 indentation contains tabs
Line 3:2: E117 over-indented
Line 5:1: W191 indentation contains tabs
Line 7:1: W191 indentation contains tabs
Line 9:1: W191 indentation contains tabs
Line 11:1: W191 indentation contains tabs
Line 11:3: E117 over-indented
Line 12:1: W191 indentation contains tabs
Line 14:1: W191 indentation contains tabs
Line 16:1: W191 indentation contains tabs
Line 17:1: W191 indentation contains tabs
Line 18:1: W191 indentation contains tabs
Line 20:1: W191 indentation contains tabs
Line 20:80: E501 line too long (95 > 79 characters)
Line 21:1: W191 indentation contains tabs
Line 21:3: E117 over-indented
Line 23:1: W191 indentation contains tabs
Line 24:1: W191 indentation contains tabs
Line 24:3: E117 over-indented
Line 26:1: W191 indentation contains tabs
Line 26:80: E501 line too long (91 > 79 characters)
Line 27:1: W191 indentation contains tabs
Line 27:14: E225 missing whitespace around operator
Line 28:1: W191 indentation contains tabs
Line 30:1: W191 indentation contains tabs
Line 32:14: W292 no newline at end of file

In the file talos/reducers/sample_reducer.py, following are the PEP8 issues :

Line 9:5: E303 too many blank lines (2)
Line 34:80: E501 line too long (80 > 79 characters)
Line 61:80: E501 line too long (86 > 79 characters)

In the file talos/scan/Scan.py, following are the PEP8 issues :

Line 10:60: W291 trailing whitespace
Line 12:64: W291 trailing whitespace
Line 13:35: W291 trailing whitespace
Line 20:1: W293 blank line contains whitespace
Line 22:67: W291 trailing whitespace
Line 23:19: W291 trailing whitespace
Line 29:26: W291 trailing whitespace
Line 34:68: W291 trailing whitespace
Line 39:61: W291 trailing whitespace
Line 87:65: W291 trailing whitespace
Line 91:75: W291 trailing whitespace

In the file talos/scan/scan_run.py, following are the PEP8 issues :

Line 14:1: W293 blank line contains whitespace
Line 15:38: E711 comparison to None should be 'if cond is not None:'
Line 16:17: E225 missing whitespace around operator
Line 16:65: E231 missing whitespace after ','
Line 16:80: E501 line too long (82 > 79 characters)
Line 25:42: E711 comparison to None should be 'if cond is not None:'

In the file talos/utils/string_cols_to_numeric.py, following are the PEP8 issues :

Line 27:13: E722 do not use bare 'except'
Line 30:17: E722 do not use bare 'except'

In the file test/core_tests/test_scan.py, following are the PEP8 issues :

Line 46:80: E501 line too long (80 > 79 characters)
Line 92:9: E117 over-indented
Line 135:80: E501 line too long (80 > 79 characters)
Line 178:80: E501 line too long (87 > 79 characters)
Line 199:80: E501 line too long (80 > 79 characters)
Line 223:80: E501 line too long (85 > 79 characters)

In the file test_script.py, following are the PEP8 issues :

Line 34:1: W293 blank line contains whitespace

Pull Request Test Coverage Report for Build 418

281 of 305 (92.13%)  changed or added relevant lines in 19 files are covered.
6 unchanged lines in 4 files lost coverage.
Overall coverage decreased (-0.02%) to 90.77%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

talos/init.py
17
18
94.44%

talos/metrics/keras_metrics.py
4
5
80.0%

talos/parameters/ParamGrid.py
25
26
96.15%

talos/commands/params.py
77
79
97.47%

talos/parameters/permutation_filter.py
16
18
88.89%

talos/utils/init.py
6
8
75.0%

talos/utils/string_cols_to_numeric.py
3
5
60.0%

talos/scan/scan_run.py
3
6
50.0%

talos/commands/kerasmodel.py
32
42
76.19%

Files with Coverage Reduction
New Missed Lines
%

talos/metrics/keras_metrics.py
1
90.24%

talos/scan/scan_prepare.py
1
97.44%

talos/parameters/round_params.py
2
88.24%

talos/reducers/sample_reducer.py
2
70.97%

Totals

Change from base Build 381:
-0.02%

Covered Lines:
1131

Relevant Lines:
1246

💛  - Coveralls


Simulation fails with VCS; VCS does not sign-extend using $signed()

I saw this referenced in #33 but closed.  I am using VCS N-2017.12-SP2-1 and traced simulation errors back to sign-extending using $signed, which appears to be the same issue.
After the following code changes I see expected results using VCS.
picorv32.patch.txt

That's a bug in VCS. If you have support for that, tell Synopsys to fix their f*cking tool. I tried reporting bugs in that piece of crap software before but I didn't get further than "we do not provide support for university licenses". I refuse to masquerade the fact that they are uncapable of fixing trivial bugs in their tool by working around those bugs in my code.
I know it must be frustrating for you, but given the fact that I don't even have access to VCS anymore so I could not even simulate with it after I make changes, I'd rather have it broken in an obvious way that risking tripping obscure VCS bugs whenever I make a trivial change to the design.
 Ignoring critical issues like that for many years is just not acceptable.

I understand, but unfortunately do not have the luxury of arguing with Synopsys over who is right...  I will file a STAR but at the moment I'm a really, really small fish to them.

jfyi https://twitter.com/oe1cxw/status/1035852371870527488
Re arguing with Synopsys:
(1) :1st_place_medal: for trying.  :laughing:
(2) As I've said, I don't have access to VCS at the moment. But I do have access to Verilog and SystemVerilog standards. If you can produce an MCVE then I can produce the relevant quotes from the standard documents. There really should not be any "arguing" required. They are clearly not correctly implementing IEEE 1364 nor IEEE 1800 here.

So there's something deeper about this bug.  I extracted out the failing code into a discrete test case:
module signbug;

  reg [31:0] decoded_imm_uj;
  reg [31:0] mem_rdata_latched;

  initial
    begin
      decoded_imm_uj = 32'h0;
      mem_rdata_latched = 32'hF000_0000;

      { decoded_imm_uj[31:20], decoded_imm_uj[10:1], decoded_imm_uj[11], decoded_imm_uj[19:12], decoded_imm_uj[0] } <= $signed({mem_rdata_latched[31:12], 1'b0});

      #1;

      $display("decoded_imm_uj = %x", decoded_imm_uj);
    end

endmodule

This code fragment passes in both simulators, but this line fails in VCS when executed in context.  Looks like a good bug.

Hello again,
I had been testing your code, in both scenarios I will relate below, have the same result. Please check and comment.
iverilog 10.1.1 Windows:
C:\iverilog\bin\vvp.exe example.vvp
decoded_imm_uj = fff00700
VCS L-2016.06-SP2-3 with gcc version 4.7.2 (GCC)
Chronologic VCS simulator copyright 1991-2016
Contains Synopsys proprietary information.
Compiler version L-2016.06-SP2-3_Full64; Runtime version L-2016.06-SP2-3_Full64;  Sep  1 11:00 2018
decoded_imm_uj = fff00700
V C S   S i m u l a t i o n   R e p o r t
Time: 1
CPU Time:      0.360 seconds;       Data structure size:   0.0Mb
Sat Sep  1 11:01:23 2018
CPU time: .264 seconds to compile + .224 seconds to elab + .344 seconds to link + .492 seconds in simulation

Some extra input. Versions 'N-' are experimental in features. Use L or M. I have been testing in M-2017 and L-2016. I may be able to push further analysis, but as I wrote you, N versions had experimental features.

Something that caught my attention. All Synopsys Solvnet customers are qualified to open a STAR case, and being VCS a full featured and most purchased products, even most used in other EDA tools, you should have an answer.
Check your installation, compile with full64 flag, change VCS c compiler for GCC, and check again. If that does not fix your issue, download L or M version and fill a case, so VCS R&D can help you. That's the flow.

I submitted a test case with the N version and downloaded an M version to try it out.  I believe than the letter simply indicates the release train; as the newest train N is likely to have experimental features.
I also tried with M-2017.03-SP2-10, which had the same result.  We only have 64 bit versions installed, and using system-default gcc didn't have any effect.
I'll update this bug if Synopsys comes back with anything.

Synopsys responded to the bug report and confirmed that they see the bug.  The simulation runs correctly when run with -debug_acess+all flag, they are investigating the discrepancy.

Quite interesting,
Please share case number.

It's case<PHONE_NUMBER>, which has been promoted to STAR<PHONE_NUMBER>.
Registered SolvNet users may see the full details on this
STAR at:
https://onlinecase.synopsys.com/Home.aspx?starNumber=9001399377

Synopsys provided a workaround for this issue, which is to add the "-Xoptflow=off" flag for simulation.  The STAR has gone over to the VCS design team.


Set quickfix colours dynamically

The quickfix extension sets the colour of section A statically on startup. To handle highlighting changes, it has to be set dynamically.

closed with #1118


Setup for multiple job brokers

It would be nice to run osmium as a single service for multiple uses. This means it should be configurable for multiple hosts, instead of the current single host. The user can then choose which host to use (perhaps setting a default host as well).
Example request:
{
    "host": "my.cluster.net",
    "jobdir": "/tmp/jobdir",
    "executable": "/bin/sh",
    ...
}

Example job launcher configuration:
hosts:
  my.cluster.net:
    scheduler:
      ...
    sandbox:
      ...
    ...
  my.othercluster.net:
    ...
xenon:
  defaultHost: my.cluster.net
http:
  port: 9998
  adminPort: 9998
  bindHost: localhost

The xenon heading can then be used to set default settings.

An alternative request method could be to bind a host to a URL, and keep the request contents the same. For example, the submission URL could be http://localhost:9998/my.cluster.net or http://localhost:9998/ for the default host. The configuration YML would still need to have multiple hosts.

I think you want a Xenon scheduler which can run jobs on different hosts. Osmium should make the queue name or resource filter available in it's api.

Implemented in fe2966106e28a7e65a55c1237c7f82fe7b65db11. As we discussed, I set it up to not use multiple URLs but to use a single URL, and the user can specify the scheduler property. The joblauncher.yml supports the schedulers and defaultScheduler properties. The former is a map of scheduler configurations, the second the name of the default scheduler.

The sandbox belongs with scheduler and the new config has not been documentend.
Group scheduler and sandbox together under xenon>launchers
For example:
xenon:
  launcher:
    myfirst:
      scheduler:
        scheme: ssh
        location: localhost:22
        queue: multi
      sandbox:
        scheme: ssh
        location: localhost:22
        path: /tmp/jobs
    mysecond:
      scheduler:
        scheme: local
        location: /
        queue: multi
      sandbox:
        scheme: local
        location: /
        path: /tmp/jobs

Backwards incompatible change added: multiple launchers, each with its own scheduler and sandbox


Impossible to easily perform arithmetic on uints / cast constexpr

@triton.jit
def simple_modulo(input):
    values = tl.arange(0, 128).to(tl.uint32)
    even = values % 2

simple_modulo[(1,)](ch.randn(10).cuda())

yields
ValueError('Cannot use /, #, or % with triton.language.uint32 and triton.language.int32 because they have different signedness;this is unlikely to result in a useful answer. Cast them to the same signedness.')

Unfortunately there is no easy way to convert 2 a constexpr from int32 to uint32, usually one would assume that when there is a typing error in a compiler on a literal, alternative interpretations (here a uint32) are considered before completely giving up.
I tried converting 2 to a uint32 in many different way but the only thing I could come up to was:
@triton.jit
def simple_modulo(input):
    values = tl.arange(0, 128).to(tl.uint32)
    two = tl.full((128,), 2, dtype=tl.uint32)
    even = values % two

simple_modulo[(1,)](ch.randn(10).cuda())

I hope/assume that this gets simplified during various optimization passes but this really makes the code much harder to follow especially for relatively long arithmetic calculations. In my real use cases those are random numbers and while I could technically perform a type conversion I would like to avoid the unnecessary instruction (which I don't think would be optimized out in this scenario)

Thanks for reporting, this is a known problem and we have plans to fix this so that the constexpr type gets inferred from other operands.

And there is no way to manually force the type of a literal ? I guess in the compiler you have constexpr a type and not a modifier on the underlying type ?

And there is no way to manually force the type of a literal ? I guess in the compiler you have constexpr a type and not a modifier on the underlying type ?

basically literals are always converted to a type using this logic:
def _to_tensor(x, builder):
    if isinstance(x, bool):
        return tensor(builder.get_int1(x), int1)
    # Note: compile-time const integers are represented by unsigned values
    elif isinstance(x, int):
        if -2**31 <= x < 2**31:
            return tensor(builder.get_int32(x), int32)
        elif 2**31 <= x < 2**32:
            return tensor(builder.get_uint32(x), uint32)
        elif -2**63 <= x < 2**63:
            return tensor(builder.get_int64(x), int64)
        elif 2**63 <= x < 2**64:
            return tensor(builder.get_uint64(x), uint64)
        else:
            raise RuntimeError(f'Nonrepresentable integer {x}.')

So the workaround you already have is the only way.

This sounds better already since it means I don't have to figure out the shape, I'll try it out instead

The builder is internal, you can't get access to that.  Thomas was trying to illustrate that

the workaround you already have is the only way.

However, you should be able to do two = tl.full((1,), 2, dtype=tl.uint32), and rely on implicit broadcasting.

Sounds good! I guess if you already have an issue for this no need to keep this one open.


Better info message upon adding comments

The information message displayed upon saving a comment could be better.

The information box has been removed as it's not necessary to inform the user of anytime they add a comment.


react 15 support

Does it support react 15.3?

It's npm friendly
You can use it in all frameworks like Vue ,React ...
just import!


C#: Destroy script before clearing owner

The C# script destructor needs to access the owner (i.e.: to disconnect signals) so we now clear it after the script has been destroyed.

Fixes https://github.com/godotengine/godot/issues/95663.

Great!
I confirm that this fixes the issue I reported in #95663 .
Thanks!

Thanks!


Prepare v0.25.0

NOTE: This is a bit early. Merge immediately before release only.

Google Cloud PHP v0.25.0
Cloud BigQuery v0.2.0

:heavy_exclamation_mark: BREAKING CHANGE All methods returning a
Generator have been updated to return an iterator. In most cases, this
change will not require changes in implementing code. Iterators function the
same as the previous Generators did, but offer much more flexibility for us,
and for you as a user. (#399)
:heavy_exclamation_mark: BREAKING CHANGE The constructor of
Google\Cloud\BigQuery\Job has changed; $mapper is now required, and the
arguments have been reordered.
Cloud BigQuery now requires Google Cloud PHP Core at version 1.0. (#402)

Cloud Core v1.0.0
Google Cloud PHP Core is now supported at v1.0.0. This means that we
consider the API to be solid and reliable, and while we'll continue to work to
improve it, we will not introduce breaking changes very often, and when we do,
they will come with full Semantic Versioning compliance,
giving you the peace of mind to develop without worrying about an unstable API!

:heavy_exclamation_mark: BREAKING CHANGE
Google\Cloud\Core\Iam\Iam::testPermissions() now returns an array of
permission names, rather than the API response containing a permissions key.
(#395)

Cloud Datastore v1.0.0
Google Cloud PHP now supports Cloud Datastore at v1.0.0. This means that we
consider the API to be solid and reliable, and while we'll continue to work to
improve it, we will not introduce breaking changes very often, and when we do,
they will come with full Semantic Versioning compliance,
giving you the peace of mind to develop without worrying about an unstable API!

:heavy_exclamation_mark: BREAKING CHANGE All methods returning a
Generator have been updated to return an iterator. In most cases, this
change will not require changes in implementing code. Iterators function the
same as the previous Generators did, but offer much more flexibility for us,
and for you as a user. (#399)
Cloud Datastore now requires Google Cloud PHP Core at version 1.0. (#402)

Stackdriver Logging v1.0.0
Google Cloud PHP now supports Stackdriver Logging at v1.0.0. This means that we
consider the API to be solid and reliable, and while we'll continue to work to
improve it, we will not introduce breaking changes very often, and when we do,
they will come with full Semantic Versioning compliance,
giving you the peace of mind to develop without worrying about an unstable API!

:heavy_exclamation_mark: BREAKING CHANGE All methods returning a
Generator have been updated to return an iterator. In most cases, this
change will not require changes in implementing code. Iterators function the
same as the previous Generators did, but offer much more flexibility for us,
and for you as a user. (#399)
Stackdriver Logging now requires Google Cloud PHP Core at version 1.0. (#402)

Cloud Natural Language v0.2.0
Google Cloud PHP now supports Cloud Natural Language at a beta level. This means
that we will not make many breaking changes going forward. While we may
introduce changes prior to v1.0.0, they will be relatively rare, and changes
will mostly focus on improvements to your developer experience within the bounds
we've already defined.

Cloud Natural Language now requires Google Cloud PHP Core at version 1.0. (#402)

Cloud Pub/Sub v0.2.0
Google Cloud PHP now supports Cloud Pub/Sub at a beta level. This means that we
will not make many breaking changes going forward. While we may introduce
changes prior to v1.0.0, they will be relatively rare, and changes will mostly
focus on improvements to your developer experience within the bounds we've
already defined.

:heavy_exclamation_mark: BREAKING CHANGE All methods returning a
Generator have been updated to return an iterator. In most cases, this
change will not require changes in implementing code. Iterators function the
same as the previous Generators did, but offer much more flexibility for us,
and for you as a user. (#399)
Cloud Pub/Sub now requires Google Cloud PHP Core at version 1.0. (#402)

Cloud Speech v0.2.0

:heavy_exclamation_mark: BREAKING CHANGE Google\Cloud\ServiceBuilder::speech()
and Google\Cloud\Speech\SpeechClient::__construct() now require a
configuration option languageCode be set to a
supported language code. (#420)
:heavy_exclamation_mark: BREAKING CHANGE
recognize() and beginRecognizeOperation() in Google\Cloud\Speech\SpeechClient
options have changed. $options.speechContext is now $options.speechContexts.
$options.sampleRate has been removed in favor of $options.sampleRateHertz.
$options.languageCode has been removed. (#420)
Client-side detection of encoding and sample rates using getID3 is no longer
supported. (#420)
Cloud Speech now requires Google Cloud PHP Core at version 1.0. (#402)

Google Cloud Storage v1.0.0
Google Cloud PHP now supports Google Cloud Storage at v1.0.0. This means that we
consider the API to be solid and reliable, and while we'll continue to work to
improve it, we will not introduce breaking changes very often, and when we do,
they will come with full Semantic Versioning compliance,
giving you the peace of mind to develop without worrying about an unstable API!

:heavy_exclamation_mark: BREAKING CHANGE All methods returning a
Generator have been updated to return an iterator. In most cases, this
change will not require changes in implementing code. Iterators function the
same as the previous Generators did, but offer much more flexibility for us,
and for you as a user. (#399)
Fixed a bug where setting predefinedAcl on an object raised a conflict
error. (#401)
Google Cloud Storage now supports IAM access control on Buckets. (#395)
Cloud Storage now requires Google Cloud PHP Core at version 1.0. (#402)

Cloud Translation v0.2.0
Google Cloud PHP now supports Cloud Translation at a beta level. This means that
we will not make many breaking changes going forward. While we may introduce
changes prior to v1.0.0, they will be relatively rare, and changes will mostly
focus on improvements to your developer experience within the bounds we've
already defined.

Cloud Translation now requires Google Cloud PHP Core at version 1.0. (#402)

Cloud Vision v0.2.0

Cloud Vision now requires Google Cloud PHP Core at version 1.0. (#402)

Release notes updated.

Note: we are not ready to declare 1.0 on Bigquery, because we want to synchronize across languages.

@michaelbausor updated

Discussed with @omaray offline, all good!

Updated with speech. @dwsupplee can you confirm that I accurately represented the major changes?

LGTM, except for one small item:
$options.languageCode has been removed. - this isn't the case. It is still a valid option on both recognize and beginRecognizeOperation

oops! thanks


Smooth Ranging for distance

hi there,
I am using your library file as its more in depth compared to others I have looked however looking at this github https://github.com/thotro/arduino-dw1000
Is there a way using your library file I can implement a smooth distance filter like this.
//Enable the filter to smooth the distance
DW1000Ranging.useRangeFilter(true);
I couldn't see anything looking through your code.

Hi @FXUDarkNova,
as soon as possible I will reply to you!

@Sonic0  Thank you

Hi @FXUDarkNova ,
We have removed DW1000Ranging::useRangeFilter because it is a useless function that modifies the range based on the precedent range measure.
We think that this operation must be implemented user side. The user will receive the exact range value and he will handle it based on his necessities.

Hi @Sonic0
Ok makes sense maybe you could help that I have created a X coord using two sensors but issue i am having is seems really sensitive using it for a robot facing forward ie centre is fine but if I slightly turn I go from 0 to say 120 for example.
Please see code I am using to work out X coord
x = (pow(dist_left,2) - pow(dist_right,2) + pow(dist_l_r,2)) / (2 * dist_l_r);

Was this solved? @FXUDarkNova


chore: Update pinata package to pinata-web3

What changed? Why?
I've updated the Pinata SDK package to use the pinata-web3 instead of the original SDK which no longer supports IPFS
Notes to reviewers
This is a direct fork of the original Pinata SDK that was originally included in the app
How has it been tested?
I have not tested this app specifically but the pinata-web3 package is working exactly as<EMAIL_ADDRESS>

🟡 Heimdall Review Status

Requirement
Status
More Info

Reviews

🟡
0/1

Denominator calculation

Show calculation

1 if user is bot
0

1 if user is external
0

From .codeflow.yml

1

Additional review requirements

Show calculation

Max
0

0

From CODEOWNERS

0

Global minimum
0

Max

1

1

1 if commit is unverified
0

Sum
1

@stevedylandev Thanks for your PR & suggestion.
What are the benefits of pinata-web3 over pinata?
AFAICS the differences between the two are:

pinata-web3 has a slightly different README.md
pinata-web3 is 59 commit behind pinata

Hey @kirkas!
Thanks for responding! I'm actually the maintainer of both. The pinata package had a v1 breaking change where it only uses our new Files API. This API is similar to our traditional IPFS API but it does not actually use public IPFS. The pinata-web3 package was a fork before the v1 release and maintains the IPFS APIs. Any further changes to our IPFS SDK will be made in that package.


adding ng arab community

Hello World <3
We are here and happy to join amazing Angular World

You're welcome!


Scroll restoration issues in solid-start docs

When i visit What is SolidStart?  and scroll to middle of page and after that when i move to Project setup  the scroll position is at same place where previous link scroll was. This is happening with all links in docs.

I just noticed this as well, it makes me think that I'm being taken to a specific part of the page for a reason, like an fragment, but It's just maintaining the scroll from the previous page.

Yeah with our new server routing, this is still a problem, that we haven't solved. It wont be in your apps, but our docs are using our experimental stuff.. We are working on fixing this

if you turn off the islands router or even switch to csr it still has the same problem

Now that we are using MPA islands here it doesn't happen. This issue is largely the way the site is designed. We will look at changing that in the future. But for now the issue isn't present.


d.ts

I would like to use this in Typescript 2.1, is there a type definition file for this?

#15 might help you. For now you could just copy the index.d.ts into your project.
Feedback would be nice. ;)


Plot histograms instead of heatmaps for wandb.Histogram

Would it be possible to implement histogram plots instead of bin heatmaps for histogram objects? It's much more intuitive to read these. It also seems a histogram is already plotted when you hover over the heatmap:

Hello! Thanks for writing in. That's a great feature request! I've added to our internal tracker.

Any news about that feature? :)

+1 this would be more useful for me too.

I'd love to see this too. And the ability to compare histograms across runs would be amazing.

This would be very helpful!

Hi folks, we have a new beta feature for custom visualizations that will support these histograms, would you please message me at<EMAIL_ADDRESS>so I can help you try it out and get your feedback

Hey folks,
Would love to hear your feedback on the custom viz feature.
It would be helpful if one could also send in feedback related to this ticket. :smile:

@ariG23498 I'm not sure how to do a histogram plot still.
In my code I am doing:
wandb.log({"Dice": wandb.Histogram(np.asarray(dice))})
But when adding a custom viz. on the website, I don't see a full histogram - just options for 10%, 25%, etc.

Hey @prash-p if you want to use our custom charts feature you can log custom histograms with:
data = [[s] for s in scores]
table = wandb.Table(data=np.asarray(dice), columns=["scores"])
wandb.log({'my_histogram': wandb.plot.histogram(table, "scores", title=None)})

Hey guys
I am closing this ticket due to the inactivity of the ticket and that we have a perfectly working scenario with custom charts for this.

Hi!
Is there a tutorial / script anywhere to compare histograms across runs, rather than across steps? I have a few runs for which I used wandb.log({'values': wandb.Histogram(values)}, and I'd like to plot overlapping histograms across runs.

Hey @GeoffNN
You can use our custom chart tool and use a Vega preset to get an overlapping histogram.


Some angle fixes

Took a while to receive and integrate diagonal NPCs, but good things come to those who wait. Or maybe it's bugs. Or bug fixes. Anyway....
I noticed some time ago there's some strange skew with the player character's diagonal movements and wanted to see if it's true also for NPCs. It was. The demo scene doesn't really have what it takes to reproduce these problems, but I hope that doesn't prevent a merge.
This fixes what I could discern so far and replaces some less good checks with error-reporting.

I definitely trust your feedback on this. I already had fixed this, or at least I thought I had succeeded. Maybe I didn't. Anyway, I think this one can be safely merged. Thanks a lot :)

@StraToN merci! I was sure it was fixed as well, but the demo stuff would really benefit from clearer examples, as this was obviously less than obvious. If you play A Lunar Adventure, you can see things working at least ;)


addFeatureVariations problem

Hi,
I tried to run a script that always worked fine for me, but now it throws an error:
condSubst = [
    ([{"SS01": (0.01, 1.0)}], {"a": "a.ss01"}),
]
addFeatureVariations(font, condSubst)

results in
Traceback (most recent call last):
  File "/Users/koeberlin/Library/Python/3.7/lib/python/site-packages/fontTools/ttLib/tables/otBase.py", line 111, in compile
    return writer.getAllDataUsingHarfbuzz()
  File "/Users/koeberlin/Library/Python/3.7/lib/python/site-packages/fontTools/ttLib/tables/otBase.py", line 555, in getAllDataUsingHarfbuzz
    return hb.repack(data, obj_list)
AttributeError: module 'uharfbuzz' has no attribute 'repack'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Users/koeberlin/Jobs/_eigene Fonts/Pangea Custom/Lonely Planet/otvar/Pangea_makeFeatureVariations 2.py", line 20, in <module>
    f.save(newFontPath)
  File "/Users/koeberlin/Library/Python/3.7/lib/python/site-packages/fontTools/ttLib/ttFont.py", line 184, in save
    writer_reordersTables = self._save(tmp)
  File "/Users/koeberlin/Library/Python/3.7/lib/python/site-packages/fontTools/ttLib/ttFont.py", line 224, in _save
    self._writeTable(tag, writer, done, tableCache)
  File "/Users/koeberlin/Library/Python/3.7/lib/python/site-packages/fontTools/ttLib/ttFont.py", line 647, in _writeTable
    tabledata = self.getTableData(tag)
  File "/Users/koeberlin/Library/Python/3.7/lib/python/site-packages/fontTools/ttLib/ttFont.py", line 669, in getTableData
    return self.tables[tag].compile(self)
  File "/Users/koeberlin/Library/Python/3.7/lib/python/site-packages/fontTools/ttLib/tables/otBase.py", line 112, in compile
    except (ValueError, MemoryError, hb.RepackerError) as e:
AttributeError: module 'uharfbuzz' has no attribute 'RepackerError'

I have fontTools 4.33.3 installed.
Thank you!
Christoph

You may need to upgrade your uharfbuzz install.

It was as easy as this. Thank you, Just! 🙏

maybe we could do better than that and try to catch the AttributeError or check uharfbuzz.__version__ is greater than 0.23 that exports that symbol, and fall back to the pure-python serializer if not.
when one installs using the extra fonttools[repacker] (or fonttools[all]), uharfbuzz >= 0.23 is automatically requested
https://github.com/fonttools/fonttools/blob/97958a95e1636a45d718a49d0ebd72d7382b45c0/setup.py#L129
whereas in @koeberlin's case, I suppose he simply found fonttools and uharfbuzz installed independently from one another in the same environment, but uharfbuzz didn't match fonttools minimum required version hence the uncaught exception.


does it make sense to lint a values+chart combo?

i'm working on a simple ci/cd flow to run a helm install on a given chart with some values,
and wondering if it makes sense to lint the chart/values combo via helm lint --values...?
if so, then in my case, i would want to run lint on packaged charts with a given values.yml, but @bacongobbler says lint is not supposed to be used on packaged charts.
trying to reconcile the stated "local-only" nature of helm lint with the --values option which implies that it's possible to run into linting issues when combining a chart with a particular set of values, just reaching out for some thoughts, thx!

Hi @tony-kerz
I think it makes sense to lint your chart in CI. If you want to lint charts created by others you will need to extract them first. I would suggest experimenting to see if linting  with--values gives you any advantages since values is user specified and can change.

Closing due to inactivity. Please open a new ticket against Helm 3 if this issue persists. Thanks!


How should we handle the cross-cloud invocation scenario?

Please answer these questions before submitting your issue.

Why do you submit this issue?
[x] Question or discussion
[ ] Bug
[ ] Requirement
[ ] Feature or performance improvement

Question

What do you want to know?

How should we handle the cross-cloud invocation scenario?
In our business scenario, because of the compliance audit, our core payment services run in Alibaba Finance Cloud, and because of the cost considerations, the pre-payment services run in Alibaba Public Cloud. When we make a payment, the trace is from Public to Finance, when the payment finshed, the trace is from Finance to Public.
Currently, our deployment mode of Skywalking is that Finance and Public each have a integrated Skywalking services, which are responsible for the service tracing in their respective Cloud regions.
As we know, it will be discarded if the tracing is from the other Skywalking, because of the registration mechanism, the registration information of the service across the cloud is not available at the other end.
Therefore, in order to support the cross-cloud invocation, we developed a service named inventory_sync_server to finish registration information sync, and also slightly modified some OAP source code.
The scheme is as follows:

Inventory_sync_server was added to monitor the changes of Skywalking registration information, and push the changes to Aliyun RocketMQ.
Meanwhile, the data monitoring service on the other end will subscribe messages via the Internet HTTP Endpoint to register the changes to Skywalking;
The data monitoring service is deployed at both ends to synchronize the application registration information in real time, so that the tracing which across the cloud can be processed;
This requires slightly modified of the OAP source code to support this approach;
Of course, we also made some other enhancements to support our business scenarios, such as:
a. carry the user-defined transactionId of frontend to passthrough to the backend services, so that the frontend and business log and Skywalking will be related. We think this is a very practical function;
b. Make sure of the cross-cloud invocation has the same treaceId.

This is our way of dealing with it, we are looking forward to some better solutions. Thank you!

As what you are doing, we don't expect have trace, topology and metrics across cloud, then why don't you simply use namespace to isolate two env?

Make sure of the cross-cloud invocation has the same treaceId.

You just sync the metadata across cloud, sharing traceid doesn't change the fact, the trace saved in different Clouds. What is the point of this?
BTW, what do you want the SkyWalking community to take part in? I just read the contents, all are about what you did. I assume what you did, defintely makes sense to you.
Do you intend to share your change? Or something else?

I think maybe this is a complicated discussion, I will send the detail of my questions to<EMAIL_ADDRESS>If my current problem is resolved and the implementation is adopted, I would be very happy to be a Contributor of Skywalking!

Welcome to join the mail list. Let's discuss there.


There should be a way to test overwriting pending transactions

With the current functionality of Ganache Core, if you try to broadcast a transaction with a higher fee that has already been broadcast with the same nonce, you will receive the following error the tx doesn't have the correct nonce. account has nonce of: 1 tx has nonce of: 0.
This is because it verifies the nonce itself before running against the vm https://github.com/trufflesuite/ganache-core/blob/283cbeca1cf9f9c598845a00baaa331afc621596/lib/statemanager.js#L965
ganache-core does not currently support a mempool, although this WIP refactor by @davidmurdoch does support a mempool to some degree https://github.com/trufflesuite/ganache-core/blob/a4e8989efc301b28d094082297dfbb1c4b25a744/src/ledgers/ethereum/components/transaction-pool.ts#L80-L87
A feature like this is incredibly important for DApp developers. Especially ones creating time sensitive DApps that need to ensure parties can overwrite pending transactions.

100% this feature is imperative for testing complicated pending and cancelling scenarios.

upvote +1

upvote +1

Pending transaction support (with geth-like tx replacement mechanisms) is slated for the next major release.

@davidmurdoch I see that the PR for fixing some of this has been merged. Is this feature now available on the next tag? I would be glad to try this for our tests and feedback on it's compatibility with the geth dev mode behaviour.

@monokh it's not yet released. I'm close to cutting an alpha/internal release (it won't include forking). It also won't include the ability to use the "pending" block tag. If you can't still run your tests even with those caveats let me know and I'll tag you when I create the release.

Thanks @davidmurdoch That still covers my use case. The main feature we required was correct handling of pending nonces, such that it is possible to bump transaction fee.

@monokh Awesome, initially the price bump % amount will be hard coded to 10%; will this hard-coded limitation work for you?

@monokh you can try it out via npm install ganache@internal or  for global cli use: npm install ganache@internal -g.
This version is pretty much guaranteed to have new bugs and regressions. And here is a list of known changes and breaking changes: https://github.com/trufflesuite/ganache-core/pull/657
One of the biggest problems with the cli is that I forgot to add the legacyInstamine flag, which needs to be true for tests that immediately check for a tx receipt after receiving the tx hash, as the receipt may return null. This won't be a problem if your tests already use geth, as this is how geth works already.
I'll probably cut a few more internal release this week, so you can expect lots of changes coming soon.
One final caveat: don't spend much time updating your tests as this release's API is not considered stable.
If you do end up trying this release let me know how it goes, even if it's a catastrophic failure!

@davidmurdoch The fee updating tests worked seamlessly when migrating from geth to ganache!
I did have some tests that have started to fail but I believe these are unrelated to your changes. More to do with the differences with geth.

@davidmurdoch Actually I think i have found a regression in the latest version.
eth_getCode returns empty, even with latest block.

The fee updating tests worked seamlessly when migrating from geth to ganache!

That is great to hear, @monokh!

I did have some tests that have started to fail but I believe these are unrelated to your changes. More to do with the differences with geth.

For many aspects I'd like to try to align more with geth, so if it's not too hard to pin point where we differ I'd greatly appreciate if you could provide more info.

Actually I think I have found a regression in the latest version. eth_getCode returns empty, even with latest block.

I'll try to reproduce now, please send reproduction steps if you have them!
Thanks again!

False alarm. The actual issue was that the contract was not deployed. Tx receipt was returned with status: 0 and a contract address (should it?)
But the inconsistency with geth is that the transaction gas limit seems to be hardcoded to 90000 when not supplied in the transaction. On geth, I believe the node is appending an estimate.
Example:
await web3.eth.sendTransaction({ from: accounts[0], data: '0x608060405234801561001057600080fd5b5060408051678ac7230489e800008152905133916000917fddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef9181900360200190a3336000908152602081905260409020678ac7230489e80000905561055b8061007a6000396000f3fe608060405260043610610087577c0100000000000000000000000000000000000000000000000000000000600035046306fdde03811461008c578063095ea7b31461011657806323b872dd14610163578063313ce567146101a657806370a08231146101d157806395d89b4114610216578063a9059cbb1461022b578063dd62ed3e14610264575b600080fd5b34801561009857600080fd5b506100a161029f565b6040805160208082528351818301528351919283929083019185019080838360005b838110156100db5781810151838201526020016100c3565b50505050905090810190601f1680156101085780820380516001836020036101000a031916815260200191505b509250505060405180910390f35b34801561012257600080fd5b5061014f6004803603604081101561013957600080fd5b50600160a060020a0381351690602001356102d6565b604080519115158252519081900360200190f35b34801561016f57600080fd5b5061014f6004803603606081101561018657600080fd5b50600160a060020a0381358116916020810135909116906040013561033c565b3480156101b257600080fd5b506101bb6103ab565b6040805160ff9092168252519081900360200190f35b3480156101dd57600080fd5b50610204600480360360208110156101f457600080fd5b5035600160a060020a03166103b0565b60408051918252519081900360200190f35b34801561022257600080fd5b506100a16103c2565b34801561023757600080fd5b5061014f6004803603604081101561024e57600080fd5b50600160a060020a0381351690602001356103f9565b34801561027057600080fd5b506102046004803603604081101561028757600080fd5b50600160a060020a038135811691602001351661040f565b60408051808201909152600a81527f546f6b656e205465737400000000000000000000000000000000000000000000602082015281565b336000818152600160209081526040808320600160a060020a038716808552908352818420869055815186815291519394909390927f8c5be1e5ebec7d5bd14f71427d1e84f3dd0314c0f7b2291e5b200ac8c7c3b925928290030190a350600192915050565b600160a060020a038316600090815260016020908152604080832033845290915281205482111561036c57600080fd5b600160a060020a03841660009081526001602090815260408083203384529091529020805483900390556103a184848461042c565b5060019392505050565b601281565b60006020819052908152604090205481565b60408051808201909152600481527f5357415000000000000000000000000000000000000000000000000000000000602082015281565b600061040633848461042c565b50600192915050565b600160209081526000928352604080842090915290825290205481565b600160a060020a038216151561044157600080fd5b600160a060020a03831660009081526020819052604090205481111561046657600080fd5b600160a060020a038216600090815260208190526040902054818101101561048d57600080fd5b600160a060020a03808316600081815260208181526040808320805495891680855282852080548981039091559486905281548801909155815187815291519390950194927fddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef929181900390910190a3600160a060020a0380841660009081526020819052604080822054928716825290205401811461052957fe5b5050505056fea165627a7a72305820db460d87e53e94fdd939b99d2a07ceb235e8a2ce62f7d320cd34a12c1c613a860029' })

Error: The contract code couldn't be stored, please check your gas limit.

I think this has always been the issue with Ganache though.

@monokh I was unable to reproduce myself, but on the plus side, I nearly doubled the number of eth_getCode tests in the process (PR here: https://github.com/trufflesuite/ganache-core/pull/667)

Tx receipt was returned with status: 0 and a contract address (should it?)

No, I don't believe it should. I'll look into why this is happening.

But the inconsistency with geth is that the transaction gas limit seems to be hardcoded to 90000 when not supplied in the transaction. On geth, I believe the node is appending an estimate.

The default transaction gas limit is will be configurable via cli eventually. With that said, I thought this behavior was in-line with geth's. I'll have to do more digging here.
Thanks!

@monokh it seems that geth changed from using the default 90000 transaction gas limit to using its own estimate in April of last year: https://github.com/ethereum/go-ethereum/pull/19508#issue-274273340

RE:

No, I don't believe it should. I'll look into why this is happening.

@monokh I just checked geth's response for failed contract creation and it aligns with ours.
Here are the steps I took to reproduce on geth:

Start up geth in dev mode on port 8545
use the dev account to upload a contract, but don't supply enough gas
get receipt; status is "0x0" and contractAddress is non-null.

curl commands for reproduction (update params where necessary):
$ curl http://localhost:8545 -H 'Content-Type: application/json' --data '{"id": 1, "method": "eth_sendTransaction", "params":[ {"from": "0xb132A8a07e9E2e286AcE35110c294220d30E1e98", "gas": "0x10000", "data": "0x6080604052348015600f57600080fd5b50603f80601d6000396000f3fe6080604052600080fdfea2646970667358221220c7bc579e8a7331a8a5ca62d82e464a95365884707bfa3344d5810466213946b864736f6c63430007040033"} ]}'
{"jsonrpc":"2.0","id":1,"result":"0xfb83518ef1f2a26cc92407a9699c91bb79fdefa426ebddf0169895c0ea8c5dc3"}

$ curl http://localhost:8545 -H 'Content-Type: application/json' --data '{"id": 1, "method": "eth_getTransactionReceipt", "params":[ "0x58b6a55a1f987950d0229b8d359468b37afecece49a88cb40c18b689c665f326" ]}'
{"jsonrpc":"2.0","id":1,"result":{"blockHash":"0x3e2c7726d464898087a4167f4e704fa72d34d52ad45aa7568852d7848d302d0b","blockNumber":"0x1","contractAddress":"0xc134e0d5e31d0c362446c76931c74c15eae4f1fb","cumulativeGasUsed":"0x10000","from":"0x6293d184b8e1c893dd6be0315d8177b4dec1434b","gasUsed":"0x10000","logs":[],"logsBloom":"0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000","status":"0x0","to":null,"transactionHash":"0xfb83518ef1f2a26cc92407a9699c91bb79fdefa426ebddf0169895c0ea8c5dc3","transactionIndex":"0x0"}}

We'll talk internally if we want to change our default behavior in this next major release, I imagine the answer is "Yes!", so I'd expect this to change in the near future.

Thinking about it more, making this change will slow down eth_sendTransaction requests that omit gas/gasLimit by maybe 40-60% (as gas estimation must be run at least twice for every estimate, and each run is slower than just running the transaction in the first place).
This performance difference isn't really a concern for geth, as geth needs to worry about mining a block in ~15 seconds, not running a new transaction in 20 _milli_seconds. But for ganache, this could theoretically double the execution time of some test suites. If we do change anything, I'm now leaning towards making this behavior opt-in.

@davidmurdoch Not estimating gas in the client sounds right if you are worried about the performance. I would ask though in that case for the default gas limit to be configurable. At the moment I have modified the tests to supply estimateGas.
That was the only change that was required and everything else passed! Looking forward to seeing it in prod :)

@monokh I've released<EMAIL_ADDRESS>which includes a new cli option: defaultTransactionGasLimit, which you can set to the string estimate to align the behavior with geth's (ganache --defaultTransactionGasLimit estimate)`.

done in<EMAIL_ADDRESS>


Add link to documentation in tsconfig.json template generated by tsc --init

Fixes #34538

A PR adding the link to the top is OK, but again, we do not want literally every compiler flag listed in the init tsconfig. For example, some of the flags listed here do nothing, are explicitly discouraged, or have dangerous effects.

Reopening in case you want to just make the PR about providing the link to other options. In that case, I would also suggest we remove the comment descriptions because they tend to be a major pain when using tsc --init.

I removed the Advanced Options again... however I would suggest to move various options then into better category names like "Deprecated", "Use with Caution" etc.
Me not being really familiar with the codebase just assumed these are all "Advanced options" that you should be able to use as an advanced user.
In addition I removed the comment descriptions as you suggested.

@borgfriend Can you update the description of this PR? I'm triaging our old PRs that we forgot about and I can't tell what this evolved into, but it seems different than the initial description.

I think it is quite misleading to only expose a subset of flags available in tsconfig.json when generating it via tsc --init.
The current flags are "handpicked" because - there are dangerous, deprecated flags that should not be exposed.
The issue evolved into:

add link to documentation
remove documentation strings

Thus users would be encouraged to take a look at the documentation to learn more about available flags (also those that are not available in the 'handpicked selection')

@borgfriend  can you please update this to resolve merge conflicts.. Thanks

There's an example of what we'd like it to look like in https://github.com/microsoft/TypeScript/issues/37361#issuecomment-598867169 too

@sheetalkamat I fixed the merge conflicts, @orta adjusted the link to be like in the example

I just noticed that for the flag "target" the description states the default is 'es3' - however it is set to 'es5'?
Maybe the target and description should be updated to ES2017 (version supported by node 8, and all current Browsers without IE)?
Should I change the flag?

@borgfriend default for target is es3 (that means if target is not specified it is es3). The comment is correct


Fixed a rare bug where a wrong videocard was selected in Local.ini

Alright merged the changes in just now :D


Download actions/action-versions latest release on Windows and set ACTIONS_RUNNER_ACTION_ARCHIVE_CACHE

Description
New tool
Fetching latest release from https://github.com/actions/action-versions
The latest release contain all tar.gz or zip of all versions of the top 5 used first-party actions (ex: actions/checkout).
With these cached on the hosted runner image, the hosted runner won't need to reach out to codeload to download those same assets over and over again.
For new tools, please provide total size and installation time.
The asset is about 120MB for both Windows and non-Windows, the download and unzip normally is less than 10s.
Since the assets is an archive of other archive, we only need to unzip the outer layer, after unzip the total size on disk are pretty much the same.

Related issue:
https://github.com/github/actions-broker/issues/17
Check list

[x] Related issue / work item is attached
[x] Tests are written (if applicable)
[ ] Documentation is updated (if applicable)
[ ] Changes are tested and related VM images are successfully generated

/azp run windows2019,windows2022

/azp run windows2019,windows2022

/azp run windows2019,windows2022

/azp run windows2019,windows2022


ZCRMRestClient doesn't exist

The ZCRMRestClient is a class of the original archived zcrm sdk and you have to require it in order for this sdk to work

Hi @dimizago do you have a trace of the error?
I can't find anything related to this class in the code

@dimizago what version of this package have you used in your test?

In your example you have this line
ZCRMRestClient::initialize($configBuilder->create());
I get an error from PHPStorm that this Class doesn't exist, and by searching at the repos files it doesn't exist somewhere.
The only repo that has this class is the original zcrm sdk which is archived.

My bad, that's right, I didn't updated the documentation and samples, let me fix this!

I've updated the sample code and the README.md:
https://github.com/thomas-kl1/php-sdk-zoho-desk/blob/master/docs/sample/code/index.php
I hope I've didn't missed anything!