Add transaction index to Env

This came up in chat recently. With the transaction index we have a global tx identifier (block height, transaction index) that avoids exposing transaction hash.
Exposing block hash and transaction hash is not desired since people will use those for poor RNGs.

The problem is that I think the tx index is not exposed in Cosmos SDK.
I do not see it listed here: https://github.com/cosmos/cosmos-sdk/blob/v0.42.9/types/context.go
Maybe @alpe knows more, but we need to make sure it is feasible to support without forking the SDK. sigh

I love it!
A few notes:

I feel like index is part of the block, as it's the total gas that was used in the current block up until now.
Why is TransactionInfo an Option? When are exec or init called not inside a transaction?

IMO index can just be another field in BlockInfo.

The problem is that I think the tx index is not exposed in Cosmos SDK.
I do not see it listed here: https://github.com/cosmos/cosmos-sdk/blob/v0.42.9/types/context.go
Maybe @alpe knows more, but we need to make sure it is feasible to support without forking the SDK. sigh

Looking at https://github.com/CosmWasm/wasmd/blob/v0.18.0/proto/cosmwasm/wasm/v1/types.proto#L123-L131 and https://github.com/CosmWasm/wasmd/blob/v0.18.0/x/wasm/types/types.go#L206-L222 it seems you are right and we do not get a simple counter.

Why is TransactionInfo an Option? When are exec or init called not inside a transaction?

Messages do not have to be executed as part of a transaction. They can for example be executed in BeginBlocker or EndBlocker.

The problem is that I think the tx index is not exposed in Cosmos SDK.
I do not see it listed here: https://github.com/cosmos/cosmos-sdk/blob/v0.42.9/types/context.go
Maybe @alpe knows more, but we need to make sure it is feasible to support without forking the SDK. sigh

Looking at https://github.com/CosmWasm/wasmd/blob/v0.18.0/proto/cosmwasm/wasm/v1/types.proto#L123-L131 and https://github.com/CosmWasm/wasmd/blob/v0.18.0/x/wasm/types/types.go#L206-L222 it seems you are right and we do not get a simple counter.

Good eye. And the use of "GasConsumed" as a monotonic counter is actually quite useful. It also works when 3 messages are called in part of the same transaction. It is actually a quite clever way to order the various calls.
However, it may not provide @assafmo with what he wants to uniquely identify the transaction in the block.

Yeah, the gas meter is nice for ordering but not helpful when used together with external tooling. E.g. it would be nice to be able to find a transation (10985258, 0) or (10985258, 3) by simply looking at a tool like this: https://www.mintscan.io/cosmos/blocks/id/10985258

However, it may not provide @assafmo with what he wants to uniquely identify the transaction in the block.

@ethanfrey that's even better, we can distinguish between contract calls. I'm not really sure if that's necessary but it's pretty cool.

🤔  I have not found any information about the use case this patch should handle. The "gas based position" would just be an incrementing counter with random steps. Can you not achieve the same in the contract itself with a counter per block?
A submessage sent to the same contract would have a higher gas index while it is in the same TX.
If a TX index is what we really need then I would investigate and try to make this happen.

I have not found any information about the use case this patch should handle.

The original motivation is somewhere in a private chat, sorry. The contract should have the option of accurately describing when an event happened. A proposed solution was to expose the transaction hash. If we do that, we have to expose block hash as well for consistentcy. And we know once we expose those hashes, people use them for bad RNGs.

Can you not achieve the same in the contract itself with a counter per block?

The contract can only know how often per block height it was called. This can solve some of the problem but makes it very hard to use in combination with other tooling. Something like the 3rd contract call on height 6484654 barely allows you to find the transaction in a explorer or other client. It also requires costy storage writes.

If a TX index is what we really need then I would investigate and try to make this happen.

It would be amazing if we could implement that.

The wasmd counter part is https://github.com/CosmWasm/wasmd/issues/601. Alex says he can make it happen 🧙

Please note that a simple counter that says "this is the third time the contract was called in this block" is problematic for the following reasons:

It doesn't let us easily find which tx the call was included in (main motivation)
In complex callback chains a contract might be called multiple times in the same tx. This can happen either when contracts call back between each other, or when a contract is called multiple times with different arguments (e.g. sending CW-20 to multiple recipients). Do we want to distinguish those multiple calls? A contract counter would help here but it feels like an incomplete solution. The issue is that if a contract's counter says "5", that still might be in the first tx of the block. CC @assafmo
Do queries increment the counter? Should they?

Also, I think you should not be concerned by misusing txhash for creating random numbers. Professional devs wouldn't do it, and if a dev is unaware of how problematic it is to get random numbers in blockchain then nothing will help. :shrug:

Also, I think you should not be concerned by misusing txhash for creating random numbers. Professional devs wouldn't do it, and if a dev is unaware of how problematic it is to get random numbers in blockchain then nothing will help them. 🤷

I was thinking in that direction as well alredy.
However, for the sake of consistency we should either expose both block hash and tx hash or none of the two.

For the sake of consistency we should either expose both block hash and tx hash or none of the two.

Then I vote for exposing both of them.
Call counter - I think it'll just be confusing and ugly in x/wasmd.
Block gas index - Might be interesting, but I don't see the use case for it.

Block gas index - Might be interesting, but I don't see the use case for it.

I was gonna say that it's useful for when the same contract gets called twice in the same TX - then you can imagine a scenario where a contract sends funds to multiple accounts in one tx from its own (or someone else's) balance. But then if all events are registered in an internal event log, even if they are all registered with the same txhash, then you can still see the order of events inside the tx just by the order in which events were registered.

Okay, I don't think that's very interesting, but I get it. Also, you can have multiple messages in the same tx, so is the counter resets for every message? I'd argue that you have to add more context for that (E.g. {"msg":0, "call":3}), but again I don't think that's very interesting and the code for it in x/wasmd will be very ugly.

Yeah, I agree with that.
So... what interface do we want, then?
block time + block number + block hash + tx hash?

I am getting confused. The original discussion was about the TX index in Env. Is this still relevant or does this not work for you? A TX can have multiple messages though.

block hash + tx hash is a different story and I think we should keep it out of here. Maybe we do it, maybe not. Let's go with tx index for now.

Feel free to continue the block hash/tx hash discussion in https://github.com/CosmWasm/cosmwasm/issues/1086.


fix(deps): update dependency axios to v1

This PR contains the following updates:

Package
Type
Update
Change

axios (source)
dependencies
major
0.26.1 -> 1.4.0

Release Notes

axios/axios
v1.4.0
Compare Source
Bug Fixes

formdata: add multipart/form-data content type for FormData payload on custom client environments; (#5678) (bbb61e7)
package: export package internals with unsafe path prefix; (#5677) (df38c94)

Features

dns: added support for a custom lookup function; (#5339) (2701911)
types: export AxiosHeaderValue type. (#5525) (726f1c8)

Performance Improvements

merge-config: optimize mergeConfig performance by avoiding duplicate key visits; (#5679) (e6f7053)

Contributors to this release

 Dmitriy Mozgovoy
 Arthur Fiorette
 PIYUSH NEGI

1.3.6 (2023-04-19)
Bug Fixes

types: added transport to RawAxiosRequestConfig (#5445) (6f360a2)
utils: make isFormData detection logic stricter to avoid unnecessary calling of the toString method on the target; (#5661) (aa372f7)

Contributors to this release

 Dmitriy Mozgovoy
 Michael Di Prisco

1.3.5 (2023-04-05)
Bug Fixes

headers: fixed isValidHeaderName to support full list of allowed characters; (#5584) (e7decef)
params: re-added the ability to set the function as paramsSerializer config; (#5633) (a56c866)

Contributors to this release

 Dmitriy Mozgovoy

1.3.4 (2023-02-22)
Bug Fixes

blob: added a check to make sure the Blob class is available in the browser's global scope; (#5548) (3772c8f)
http: fixed regression bug when handling synchronous errors inside the adapter; (#5564) (a3b246c)

Contributors to this release

 Dmitriy Mozgovoy
 lcysgsg
 Michael Di Prisco

1.3.3 (2023-02-13)
Bug Fixes

formdata: added a check to make sure the FormData class is available in the browser's global scope; (#5545) (a6dfa72)
formdata: fixed setting NaN as Content-Length for form payload in some cases; (#5535) (c19f7bf)
headers: fixed the filtering logic of the clear method; (#5542) (ea87ebf)

Contributors to this release

 Dmitriy Mozgovoy
 陈若枫

1.3.2 (2023-02-03)
Bug Fixes

http: treat http://localhost as base URL for relative paths to avoid ERR_INVALID_URL error; (#5528) (128d56f)
http: use explicit import instead of TextEncoder global; (#5530) (6b3c305)

Contributors to this release

 Dmitriy Mozgovoy

1.3.1 (2023-02-01)
Bug Fixes

formdata: add hotfix to use the asynchronous API to compute the content-length header value; (#5521) (96d336f)
serializer: fixed serialization of array-like objects; (#5518) (08104c0)

Contributors to this release

 Dmitriy Mozgovoy

v1.3.6
Compare Source
Bug Fixes

types: added transport to RawAxiosRequestConfig (#5445) (6f360a2)
utils: make isFormData detection logic stricter to avoid unnecessary calling of the toString method on the target; (#5661) (aa372f7)

Contributors to this release

 Dmitriy Mozgovoy
 Michael Di Prisco

v1.3.5
Compare Source
Bug Fixes

headers: fixed isValidHeaderName to support full list of allowed characters; (#5584) (e7decef)
params: re-added the ability to set the function as paramsSerializer config; (#5633) (a56c866)

Contributors to this release

 Dmitriy Mozgovoy

v1.3.4
Compare Source
Bug Fixes

blob: added a check to make sure the Blob class is available in the browser's global scope; (#5548) (3772c8f)
http: fixed regression bug when handling synchronous errors inside the adapter; (#5564) (a3b246c)

Contributors to this release

 Dmitriy Mozgovoy
 lcysgsg
 Michael Di Prisco

v1.3.3
Compare Source
Bug Fixes

formdata: added a check to make sure the FormData class is available in the browser's global scope; (#5545) (a6dfa72)
formdata: fixed setting NaN as Content-Length for form payload in some cases; (#5535) (c19f7bf)
headers: fixed the filtering logic of the clear method; (#5542) (ea87ebf)

Contributors to this release

 Dmitriy Mozgovoy
 陈若枫

v1.3.2
Compare Source
Bug Fixes

http: treat http://localhost as base URL for relative paths to avoid ERR_INVALID_URL error; (#5528) (128d56f)
http: use explicit import instead of TextEncoder global; (#5530) (6b3c305)

Contributors to this release

 Dmitriy Mozgovoy

v1.3.1
Compare Source
Bug Fixes

formdata: add hotfix to use the asynchronous API to compute the content-length header value; (#5521) (96d336f)
serializer: fixed serialization of array-like objects; (#5518) (08104c0)

Contributors to this release

 Dmitriy Mozgovoy

v1.3.0
Compare Source
Bug Fixes

headers: fixed & optimized clear method; (#5507) (9915635)
http: add zlib headers if missing (#5497) (65e8d1e)

Features

fomdata: added support for spec-compliant FormData & Blob types; (#5316) (6ac574e)

Contributors to this release

 Dmitriy Mozgovoy
 ItsNotGoodName

1.2.6 (2023-01-28)
Bug Fixes

headers: added missed Authorization accessor; (#5502) (342c0ba)
types: fixed CommonRequestHeadersList & CommonResponseHeadersList types to be private in commonJS; (#5503) (5a3d0a3)

Contributors to this release

 Dmitriy Mozgovoy

1.2.5 (2023-01-26)
Bug Fixes

types: fixed AxiosHeaders to handle spread syntax by making all methods non-enumerable; (#5499) (580f1e8)

Contributors to this release

 Dmitriy Mozgovoy
 Elliot Ford

1.2.4 (2023-01-22)
Bug Fixes

types: renamed RawAxiosRequestConfig back to AxiosRequestConfig; (#5486) (2a71f49)
types: fix AxiosRequestConfig generic; (#5478) (9bce81b)

Contributors to this release

 Dmitriy Mozgovoy
 Daniel Hillmann

1.2.3 (2023-01-10)
Bug Fixes

types: fixed AxiosRequestConfig header interface by refactoring it to RawAxiosRequestConfig; (#5420) (0811963)

Contributors to this release

 Dmitriy Mozgovoy

[1.2.2] - 2022-12-29
Fixed

fix(ci): fix release script inputs #5392
fix(ci): prerelease scipts #5377
fix(ci): release scripts #5376
fix(ci): typescript tests #5375
fix: Brotli decompression #5353
fix: add missing HttpStatusCode #5345

Chores

chore(ci): set conventional-changelog header config #5406
chore(ci): fix automatic contributors resolving #5403
chore(ci): improved logging for the contributors list generator #5398
chore(ci): fix release action #5397
chore(ci): fix version bump script by adding bump argument for target version #5393
chore(deps): bump decode-uri-component from 0.2.0 to 0.2.2 #5342
chore(ci): GitHub Actions Release script #5384
chore(ci): release scripts #5364

Contributors to this release

 Dmitriy Mozgovoy
 Winnie

[1.2.1] - 2022-12-05
Changed

feat(exports): export mergeConfig #5151

Fixed

fix(CancelledError): include config #4922
fix(general): removing multiple/trailing/leading whitespace #5022
fix(headers): decompression for responses without Content-Length header #5306
fix(webWorker): exception to sending form data in web worker #5139

Refactors

refactor(types): AxiosProgressEvent.event type to any #5308
refactor(types): add missing types for static AxiosError.from method #4956

Chores

chore(docs): remove README link to non-existent upgrade guide #5307
chore(docs): typo in issue template name #5159

Contributors to this release

Dmitriy Mozgovoy
Zachary Lysobey
Kevin Ennis
Philipp Loose
secondl1ght
wenzheng
Ivan Barsukov
Arthur Fiorette

[1.2.0] - 2022-11-10
Changed

changed: refactored module exports #5162
change: re-added support for loading Axios with require('axios').default #5225

Fixed

fix: improve AxiosHeaders class #5224
fix: TypeScript type definitions for commonjs #5196
fix: type definition of use method on AxiosInterceptorManager to match the the README #5071
fix: __dirname is not defined in the sandbox #5269
fix: AxiosError.toJSON method to avoid circular references #5247
fix: Z_BUF_ERROR when content-encoding is set but the response body is empty #5250

Refactors

refactor: allowing adapters to be loaded by name #5277

Chores

chore: force CI restart #5243
chore: update ECOSYSTEM.md #5077
chore: update get/index.html #5116
chore: update Sandbox UI/UX #5205
chore:(actions): remove git credentials after checkout #5235
chore(actions): bump actions/dependency-review-action from 2 to 3 #5266
chore(packages): bump loader-utils from 1.4.1 to 1.4.2 #5295
chore(packages): bump engine.io from 6.2.0 to 6.2.1 #5294
chore(packages): bump socket.io-parser from 4.0.4 to 4.0.5 #5241
chore(packages): bump loader-utils from 1.4.0 to 1.4.1 #5245
chore(docs): update Resources links in README #5119
chore(docs): update the link for JSON url #5265
chore(docs): fix broken links #5218
chore(docs): update and rename UPGRADE_GUIDE.md to MIGRATION_GUIDE.md #5170
chore(docs): typo fix line #856 and #920 #5194
chore(docs): typo fix #800 #5193
chore(docs): fix typos #5184
chore(docs): fix punctuation in README.md #5197
chore(docs): update readme in the Handling Errors section - issue reference #5260 #5261
chore: remove \b from filename #5207
chore(docs): update CHANGELOG.md #5137
chore: add sideEffects false to package.json #5025

Contributors to this release

Maddy Miller
Amit Saini
ecyrbe
Ikko Ashimine
Geeth Gunnampalli
Shreem Asati
Frieder Bluemle
윤세영
Claudio Busatto
Remco Haszing
Dmitriy Mozgovoy
Csaba Maulis
MoPaMo
Daniel Fjeldstad
Adrien Brunet
Frazer Smith
HaiTao
AZM
relbns

[1.1.3] - 2022-10-15
Added

Added custom params serializer support #5113

Fixed

Fixed top-level export to keep them in-line with static properties #5109
Stopped including null values to query string. #5108
Restored proxy config backwards compatibility with 0.x #5097
Added back AxiosHeaders in AxiosHeaderValue #5103
Pin CDN install instructions to a specific version #5060
Handling of array values fixed for AxiosHeaders #5085

Chores

docs: match badge style, add link to them #5046
chore: fixing comments typo #5054
chore: update issue template #5061
chore: added progress capturing section to the docs; #5084

Contributors to this release

Jason Saayman
scarf
Lenz Weber-Tronic
Arvindh
Félix Legrelle
Patrick Petrovic
Dmitriy Mozgovoy
littledian
ChronosMasterOfAllTime

[1.1.2] - 2022-10-07
Fixed

Fixed broken exports for UMD builds.

Contributors to this release

Jason Saayman

[1.1.1] - 2022-10-07
Fixed

Fixed broken exports for common js. This fix breaks a prior fix, I will fix both issues ASAP but the commonJS use is more impactful.

Contributors to this release

Jason Saayman

[1.1.0] - 2022-10-06
Fixed

Fixed missing exports in type definition index.d.ts #5003
Fixed query params composing #5018
Fixed GenericAbortSignal interface by making it more generic #5021
Fixed adding "clear" to AxiosInterceptorManager #5010
Fixed commonjs & umd exports #5030
Fixed inability to access response headers when using axios 1.x with Jest #5036

Contributors to this release

Trim21
Dmitriy Mozgovoy
shingo.sasaki
Ivan Pepelko
Richard Kořínek

[1.0.0] - 2022-10-04
Added

Added stack trace to AxiosError #4624
Add AxiosError to AxiosStatic #4654
Replaced Rollup as our build runner #4596
Added generic TS types for the exposed toFormData helper #4668
Added listen callback function #4096
Added instructions for installing using PNPM #4207
Added generic AxiosAbortSignal TS interface to avoid importing AbortController polyfill #4229
Added axios-url-template in ECOSYSTEM.md #4238
Added a clear() function to the request and response interceptors object so a user can ensure that all interceptors have been removed from an axios instance #4248
Added react hook plugin #4319
Adding HTTP status code for transformResponse #4580
Added blob to the list of protocols supported by the browser #4678
Resolving proxy from env on redirect #4436
Added enhanced toFormData implementation with additional options 4704
Adding Canceler parameters config and request #4711
Added automatic payload serialization to application/x-www-form-urlencoded #4714
Added the ability for webpack users to overwrite built-ins #4715
Added string[] to AxiosRequestHeaders type #4322
Added the ability for the url-encoded-form serializer to respect the formSerializer config #4721
Added isCancel type assert #4293
Added data URL support for node.js #4725
Adding types for progress event callbacks #4675
URL params serializer #4734
Added axios.formToJSON method #4735
Bower platform add data protocol #4804
Use WHATWG URL API instead of url.parse() #4852
Add ENUM containing Http Status Codes to typings #4903
Improve typing of timeout in index.d.ts #4934

Changed

Updated AxiosError.config to be optional in the type definition #4665
Updated README emphasizing the URLSearchParam built-in interface over other solutions #4590
Include request and config when creating a CanceledError instance #4659
Changed func-names eslint rule to as-needed #4492
Replacing deprecated substr() with slice() as substr() is deprecated #4468
Updating HTTP links in README.md to use HTTPS #4387
Updated to a better trim() polyfill #4072
Updated types to allow specifying partial default headers on instance create #4185
Expanded isAxiosError types #4344
Updated type definition for axios instance methods #4224
Updated eslint config #4722
Updated Docs #4742
Refactored Axios to use ES2017 #4787

Deprecated

There are multiple deprecations, refactors and fixes provided in this release. Please read through the full release notes to see how this may impact your project and use case.

Removed

Removed incorrect argument for NetworkError constructor #4656
Removed Webpack #4596
Removed function that transform arguments to array #4544

Fixed

Fixed grammar in README #4649
Fixed code error in README #4599
Optimized the code that checks cancellation #4587
Fix url pointing to defaults.js in README #4532
Use type alias instead of interface for AxiosPromise #4505
Fix some word spelling and lint style in code comments #4500
Edited readme with 3 updated browser icons of Chrome, FireFox and Safari #4414
Bump follow-redirects from 1.14.9 to 1.15.0 #4673
Fixing http tests to avoid hanging when assertions fail #4435
Fix TS definition for AxiosRequestTransformer #4201
Fix grammatical issues in README #4232
Fixing instance.defaults.headers type #4557
Fixed race condition on immediate requests cancellation #4261
Fixing Z_BUF_ERROR when no content #4701
Fixing proxy beforeRedirect regression #4708
Fixed AxiosError status code type #4717
Fixed AxiosError stack capturing #4718
Fixing AxiosRequestHeaders typings #4334
Fixed max body length defaults #4731
Fixed toFormData Blob issue on node>v17 #4728
Bump grunt from 1.5.2 to 1.5.3 #4743
Fixing content-type header repeated #4745
Fixed timeout error message for http 4738
Request ignores false, 0 and empty string as body values #4785
Added back missing minified builds #4805
Fixed a type error #4815
Fixed a regression bug with unsubscribing from cancel token; #4819
Remove repeated compression algorithm #4820
The error of calling extend to pass parameters #4857
SerializerOptions.indexes allows boolean | null | undefined #4862
Require interceptors to return values #4874
Removed unused imports #4949
Allow null indexes on formSerializer and paramsSerializer #4960

Chores

Set permissions for GitHub actions #4765
Included githubactions in the dependabot config #4770
Included dependency review #4771
Update security.md #4784
Remove unnecessary spaces #4854
Simplify the import path of AxiosError #4875
Fix Gitpod dead link #4941
Enable syntax highlighting for a code block #4970
Using Logo Axios in Readme.md #4993
Fix markup for note in README #4825
Fix typo and formatting, add colons #4853
Fix typo in readme #4942

Security

Update SECURITY.md #4687

Contributors to this release

Bertrand Marron
Dmitriy Mozgovoy
Dan Mooney
Michael Li
aong
Des Preston
Ted Robertson
zhoulixiang
Arthur Fiorette
Kumar Shanu
JALAL
Jingyi Lin
Philipp Loose
Alexander Shchukin
Dave Cardwell
Cat Scarlet
Luca Pizzini
Kai
Maxime Bargiel
Brian Helba
reslear
Jamie Slome
Landro3
rafw87
Afzal Sayed
Koki Oyatsu
Dave
暴走老七
Spencer
Adrian Wieprzkowicz
Jamie Telin
毛呆
Kirill Shakirov
Rraji Abdelbari
Jelle Schutter
Tom Ceuppens
Johann Cooper
Dimitris Halatsis
chenjigeng
João Gabriel Quaresma
Victor Augusto
neilnaveen
Pavlos
Kiryl Valkovich
Naveen
wenzheng
hcwhan
Bassel Rachid
Grégoire Pineau
felipedamin
Karl Horky
Yue JIN
Usman Ali Siddiqui
WD
Günther Foidl
Stephen Jennings
C.T.Lin
mia-z
Parth Banathia
parth0105pluang
Marco Weber
Luca Pizzini
Willian Agostini
Huyen Nguyen

v1.2.6
Compare Source
Bug Fixes

headers: added missed Authorization accessor; (#5502) (342c0ba)
types: fixed CommonRequestHeadersList & CommonResponseHeadersList types to be private in commonJS; (#5503) (5a3d0a3)

Contributors to this release

 Dmitriy Mozgovoy

v1.2.5
Compare Source
Bug Fixes

types: fixed AxiosHeaders to handle spread syntax by making all methods non-enumerable; (#5499) (580f1e8)

Contributors to this release

 Dmitriy Mozgovoy
 Elliot Ford

v1.2.4
Compare Source
Bug Fixes

types: renamed RawAxiosRequestConfig back to AxiosRequestConfig; (#5486) (2a71f49)
types: fix AxiosRequestConfig generic; (#5478) (9bce81b)

Contributors to this release

 Dmitriy Mozgovoy
 Daniel Hillmann

v1.2.3
Compare Source
Bug Fixes

types: fixed AxiosRequestConfig header interface by refactoring it to RawAxiosRequestConfig; (#5420) (0811963)

Contributors to this release

 Dmitriy Mozgovoy

v1.2.2
Compare Source
Fixed

fix(ci): fix release script inputs #5392
fix(ci): prerelease scipts #5377
fix(ci): release scripts #5376
fix(ci): typescript tests #5375
fix: Brotli decompression #5353
fix: add missing HttpStatusCode #5345

Chores

chore(ci): set conventional-changelog header config #5406
chore(ci): fix automatic contributors resolving #5403
chore(ci): improved logging for the contributors list generator #5398
chore(ci): fix release action #5397
chore(ci): fix version bump script by adding bump argument for target version #5393
chore(deps): bump decode-uri-component from 0.2.0 to 0.2.2 #5342
chore(ci): GitHub Actions Release script #5384
chore(ci): release scripts #5364

Contributors to this release

 Dmitriy Mozgovoy
 Winnie

v1.2.1
Compare Source
Changed

feat(exports): export mergeConfig #5151

Fixed

fix(CancelledError): include config #4922
fix(general): removing multiple/trailing/leading whitespace #5022
fix(headers): decompression for responses without Content-Length header #5306
fix(webWorker): exception to sending form data in web worker #5139

Refactors

refactor(types): AxiosProgressEvent.event type to any #5308
refactor(types): add missing types for static AxiosError.from method #4956

Chores

chore(docs): remove README link to non-existent upgrade guide #5307
chore(docs): typo in issue template name #5159

Contributors to this release

Dmitriy Mozgovoy
Zachary Lysobey
Kevin Ennis
Philipp Loose
secondl1ght
wenzheng
Ivan Barsukov
Arthur Fiorette

v1.2.0
Compare Source
Changed

changed: refactored module exports #5162
change: re-added support for loading Axios with require('axios').default #5225

Fixed

fix: improve AxiosHeaders class #5224
fix: TypeScript type definitions for commonjs #5196
fix: type definition of use method on AxiosInterceptorManager to match the the README #5071
fix: __dirname is not defined in the sandbox #5269
fix: AxiosError.toJSON method to avoid circular references #5247
fix: Z_BUF_ERROR when content-encoding is set but the response body is empty #5250

Refactors

refactor: allowing adapters to be loaded by name #5277

Chores

chore: force CI restart #5243
chore: update ECOSYSTEM.md #5077
chore: update get/index.html #5116
chore: update Sandbox UI/UX #5205
chore:(actions): remove git credentials after checkout #5235
chore(actions): bump actions/dependency-review-action from 2 to 3 #5266
chore(packages): bump loader-utils from 1.4.1 to 1.4.2 #5295
chore(packages): bump engine.io from 6.2.0 to 6.2.1 #5294
chore(packages): bump socket.io-parser from 4.0.4 to 4.0.5 #5241
chore(packages): bump loader-utils from 1.4.0 to 1.4.1 #5245
chore(docs): update Resources links in README #5119
chore(docs): update the link for JSON url #5265
chore(docs): fix broken links #5218
chore(docs): update and rename UPGRADE_GUIDE.md to MIGRATION_GUIDE.md #5170
chore(docs): typo fix line #856 and #920 #5194
chore(docs): typo fix #800 #5193
chore(docs): fix typos #5184
chore(docs): fix punctuation in README.md #5197
chore(docs): update readme in the Handling Errors section - issue reference #5260 #5261
chore: remove \b from filename #5207
chore(docs): update CHANGELOG.md #5137
chore: add sideEffects false to package.json #5025

Contributors to this release

Maddy Miller
Amit Saini
ecyrbe
Ikko Ashimine
Geeth Gunnampalli
Shreem Asati
Frieder Bluemle
윤세영
Claudio Busatto
Remco Haszing
Dmitriy Mozgovoy
Csaba Maulis
MoPaMo
Daniel Fjeldstad
Adrien Brunet
Frazer Smith
HaiTao
AZM
relbns

v1.1.3
Compare Source
Added

Added custom params serializer support #5113

Fixed

Fixed top-level export to keep them in-line with static properties #5109
Stopped including null values to query string. #5108
Restored proxy config backwards compatibility with 0.x #5097
Added back AxiosHeaders in AxiosHeaderValue #5103
Pin CDN install instructions to a specific version #5060
Handling of array values fixed for AxiosHeaders #5085

Chores

docs: match badge style, add link to them #5046
chore: fixing comments typo #5054
chore: update issue template #5061
chore: added progress capturing section to the docs; #5084

Contributors to this release

Jason Saayman
scarf
Lenz Weber-Tronic
Arvindh
Félix Legrelle
Patrick Petrovic
Dmitriy Mozgovoy
littledian
ChronosMasterOfAllTime

v1.1.2
Compare Source
Fixed

Fixed broken exports for UMD builds.

Contributors to this release

Jason Saayman

v1.1.1
Compare Source
Fixed

Fixed broken exports for common js. This fix breaks a prior fix, I will fix both issues ASAP but the commonJS use is more impactful.

Contributors to this release

Jason Saayman

v1.1.0
Compare Source
Fixed

Fixed missing exports in type definition index.d.ts #5003
Fixed query params composing #5018

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.

[ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot.

⚠ Artifact update problem
Renovate failed to update an artifact related to this branch. You probably do not want to merge this PR as-is.
♻ Renovate will retry this branch, including artifacts, only when one of the following happens:

any of the package files in this branch needs updating, or
the branch becomes conflicted, or
you click the rebase/retry checkbox if found above, or
you rename this PR's title to start with "rebase!" to trigger it manually

The artifact failure details are included below:
File name: frontend/package-lock.json
npm WARN deprecated<EMAIL_ADDRESS>Please see https://github.com/lydell/urix#deprecated
npm WARN deprecated<EMAIL_ADDRESS>See https://github.com/lydell/source-map-url#deprecated
npm WARN deprecated<EMAIL_ADDRESS>Please upgrade  to version 7 or higher.  Older versions may use Math.random() in certain circumstances, which is known to be problematic.  See https://v8.dev/blog/math-random for details.
npm WARN deprecated<EMAIL_ADDRESS>See https://github.com/lydell/source-map-resolve#deprecated
npm WARN deprecated<EMAIL_ADDRESS>https://github.com/lydell/resolve-url#deprecated
npm WARN deprecated<EMAIL_ADDRESS>The querystring API is considered Legacy. new code should use the URLSearchParams API instead.
npm WARN deprecated<EMAIL_ADDRESS>support for ECMAScript is superseded by `uglify-js` as of v3.13.0
npm notice
npm notice New major version of npm available! 8.19.4 -> 9.6.7
npm notice Changelog: <https://github.com/npm/cli/releases/tag/v9.6.7>
npm notice Run `npm install -g<EMAIL_ADDRESS>to update!
npm notice
npm ERR! code 127
npm ERR! path /tmp/renovate/repos/github/bcgov/nr-forests-access-management/client-code-gen/gen
npm ERR! command failed
npm ERR! command sh -c -- npm run build
npm ERR! ><EMAIL_ADDRESS>build
npm ERR! > tsc && tsc -p tsconfig.esm.json
npm ERR! sh: 1: tsc: not found

npm ERR! A complete log of this run can be found in:
npm ERR!     /tmp/renovate/cache/others/npm/_logs/2023-05-30T11_16_28_656Z-debug-0.log

Edited/Blocked Notification
Renovate will not automatically rebase this PR, because it does not recognize the last commit author and assumes somebody else may have edited the PR.
You can manually request rebase by checking the rebase/retry box above.
⚠ Warning: custom changes will be lost.

This is an interesting case.
While it is desired to upgrade axios' package version in client-code-gen/gen, frontend (which has axios package and uses generated client) also is better to match the version of axios with client-code-gen/gen.
However, the gen folder is generated (manually) whenever there is a backend endpoint change/addition for OpenAPI (Swagger), so we can't directly just update to its axios version, it will be overwritten next time.
I tried to see if there is an option to specify axios version when generating the frontend client but could not find such option (or maybe hidden?). It probably requires additional investigation.
The alternative, is probably document this in Readme in "client-code-gen" folder for adding one extra manual step => when gen is generated, update its (overwritten) package.json axios version to match frontend version, then do a npm install before being imported into frontend.
This is alternative solution before we can find a permanent solution.

Renovate Ignore Notification
As this PR has been closed unmerged, Renovate will ignore this upgrade and you will not receive PRs for any future 1.x releases. However, if you upgrade to 1.x manually then Renovate will reenable minor and patch updates automatically.
If this PR was closed by mistake or you changed your mind, you can simply rename this PR and you will soon get a fresh replacement PR opened.


[dv] Split out the logic to connect a sequencer to a monitor

Note: This is in draft because it depends on #5861. That is a quick bodge to get things working again; this is supposed to be a more considered fix.
This connection is handy, but not very generic. In particular, it
implies some slightly unnecessary parameterisations for types in the
dv_lib base classes: not impossible, but a cost to users who don't
want the feature.
This patch splits that logic into a new "dv_seq_agent" core file. This
subclasses the parts of an agent that need to know about the special
behaviour (the agent itself, its configuration, the monitor and the
sequencer). Now, the code that uses this feature (csrng, i2c, spi and
push_pull) can use it explicitly, and the rest of the code doesn't see
it.

The problem with the control knobs is that in order to compile, an agent that uses different types for its sequence and its monitored transactions has to instantiate e.g. the monitor with the sequence item types. This seems a bit crazy to me: if I'm not using this functionality, it's kind of odd to have to pass sequence item types to the monitor.
You're right that there's another way of doing things for OTBN, but I actually ran into this when trying to vendor OT into Ibex, where the ICache testbench uses different types for sequence request, sequence response and monitored bus item.

agree with Sri. seems a bit waste to add another layer to just have the req/rsp port and fifo connected.
otbn agent is a bit special. It only has monitor but no driver no sequencer, so that we need a bit workaround for it. perhaps try to supply dummy types to make it compile

As I said above, this is not really about the OTBN agent. Anyway, it seems you guys feel strongly, so I'll just accept what I think is a slightly broken data model: it's not a big deal.


Issue with k8s.io/docs/tasks/configure-pod-container/configure-pod-configmap/

This is a...

[x] Feature Request
[ ] Bug Report

Problem:
The example yaml has the configMap data (e.g. for "game-special-key") italicized. This includes the pipe symbol, which, when italicized, looks very much like a forward-slash.
Proposed Solution:
Do not italicize the pipe.
Page to Update:
https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/

/language en
/assign @DanyC97


Implement fix for PipelineRuns getting stuck in the cluster

Changes
Tries to fix https://github.com/tektoncd/pipeline/issues/6076
Submitter Checklist
As the author of this PR, please check off the items in this checklist:

[ ] Has Docs included if any changes are user facing
[ ] Has Tests included if any functionality added or changed
[ ] Follows the commit message standard
[ ] Meets the Tekton contributor standards (including
functionality, content, code)
[ ] Has a kind label. You can add one by adding a comment on this PR that contains /kind <type>. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep
[ ] Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings)
[ ] Release notes contains the string "action required" if the change requires additional action from users switching to the new release

Release Notes
Fix a bug that made big PipelineRuns get stuck in the running state in the cluster

Thanks, @RafaeLeal for this PR!
Could you provide a bit more context about the issue in the commit message / PR description, and fill in the PR checklist from the template? Also, tide does not automatically squash commits before merging, so I would ask you to please squash them at least once the PR has been approved.
Thank you!

Could you provide a bit more context about the issue in the commit message / PR description, and fill in the PR checklist from the template? Also, tide does not automatically squash commits before merging, so I would ask you to please squash them at least once the PR has been approved.

Sure, I was not done yet actually. I added another test on HasTimedOutForALongTime func. I had some ideas on how to avoid arbitrary thresholds, that I shared in the issue, which I quote here.

While implementing it, I was considering maybe we could always do a two-step timing out, this way we could avoid arbitrary thresholds. The first reconciliation would check pr.HasTimedOut() and mark the status and return controller.NewRequeueImmediately(). This would trigger a UpdateStatus with only the condition change, then in the second reconciliation, we could try to update the rest of the status (the childReferences, for example).

This could work, I think. But the problem I had is that we still depend a lot on the order of the execution to make everything work properly. In the second reconciliation, we already have the timed-out condition, which means the pr.IsDone() is true and this changes the whole reconciliation process.
https://github.com/tektoncd/pipeline/blob/main/pkg/reconciler/pipelinerun/pipelinerun.go#L205-L225

Looking at this, does it make sense to "fail fast" the reconciliation process?
For example, even inside in this pr.IsDone() branch, it runs several cleanup processes. If one fails, should we really prevent the next one from executing? 🤔

/retest

While implementing it, I was considering maybe we could always do a two-step timing out, this way we could avoid arbitrary thresholds. The first reconciliation would check pr.HasTimedOut() and mark the status and return controller.NewRequeueImmediately(). This would trigger a UpdateStatus with only the condition change, then in the second reconciliation, we could try to update the rest of the status (the childReferences, for example).

It could work, but I have two concerns:

orchestrating updates across reconciles can be tricky - if there is no external input it's generally best to try and do everything in one reconcile cycle
but I think it would be confusing for clients. If a client reads that the pipelinerun has completed, how does it know whether there is an update missing somewhere? Even with NewRequeueImmediately, the controller queue can be quite busy and it may take some time before the new reconcile happens

orchestrating updates across reconciles can be tricky - if there is no external input it's generally best to try and do everything in one reconcile cycle

but I think it would be confusing for clients. If a client reads that the pipelinerun has completed, how does it know whether there is an update missing somewhere? Even with NewRequeueImmediately, the controller queue can be quite busy and it may take some time before the new reconcile happens

I agree with these concerns. I think we might need a more robust solution long-term for this, but it seems pretty good for now. WDYT?

@afrittoli let me know if there's anything missing to merge this :)

@RafaeLeal do you think there is any work remaining to address #6076 once this is merged? (If not I'll link the issue directly to the PR)

I don't think so, you can link the issue.

/retest

@jerop @lbernick  accepted all suggestions and rebased 👍


cruft update cruft to latest timothycrosley/cookiecutter-python

While playing with cruft trying to build git history integration I realized that cruft was out of date with its own template.

Ahh, was digging into that failure. The dependency came from the updated cookiecutter-python.

Hmm, with the new failure should we update numpy here in cruft, or update the template and then re cruft update this project?

I'm not finding any way that numpy is even referenced via any dependency chain. Maybe the travis-ci worker didn't get cleaned and has the library already installed? Is strange it failed for the 3.7 run but not the 3.6 run (I use 3.7 on my local box without issue)

I agree, this seems like a travis-ci bug on 3.7. Unfortunate, but I'll work around it for now.


Adding concurrency for alarmJob

Which module is your feature request related to?
batch
Is your feature request related to a problem?
Current alarm job takes too much time while the span is 5 mins.
Describe the solution you'd like
Querying metrics concurrently might decrease the latency.
Describe alternatives you've considered
Additional context

related to #9052


Add rendered_component method to ViewComponent::TestHelpers

Summary
As discussed in https://github.com/github/view_component/issues/304#issuecomment-629468829, this PR renames @raw to @rendered_component and exposes a rendered_component reader.
With this method, it becomes possible to write the following expectation in an rspec-rails view spec:
expect(rendered_component).to have_css("header h1", text: "Buy milk")

which mirrors the example code from Capybara's README:
https://github.com/teamcapybara/capybara/blame/3.32.1/README.md#L235
I also backfilled some test coverage for the return value of render_inline. This seemed appropriate given that we started documenting it in the README in https://github.com/github/view_component/commit/18d4569721457a34ae4c2096cb2b0a0c36570637. (I should've added this test when I was working on https://github.com/github/view_component/pull/298.)

GitHub Actions seems to have hit an error running this PR:

https://github.com/github/view_component/actions/runs/106062463
@joelhawksley Are you able to try rerunning the workflow manually?

Hmm, this might explain it:

@rmacklin can you re-push to trigger a new build?

@joelhawksley Done!


AKIBA'S TRIP UNDEAD & UNDRESSED [PCSE00428]

App summary

App name: AKIBA'S TRIP UNDEAD & UNDRESSED
App serial: PCSE00428
App version: 1.00

Vita3K summary

Version: v0.1.6
Build number: 3004
Commit hash: https://github.com/vita3k/vita3k/commit/[commit]
CPU backend: Dynarmic
GPU backend: Vulkan

Test environment summary

Tested by: Ismaya Melasrana
OS: Windows 10
CPU: Intel Core I5-2500
GPU: NVIDIA GTX 650
RAM: 8 GB

Issues
Everything looks normal and runs really good
-Sound scratching on long a dialog voice
Screenshots

https://user-images.githubusercontent.com/102879961/218297302-92be4577-a9cb-457d-86eb-11e7ffc92c7a.mp4
Log
vita3k.log
Recommended labels

Ingame+

The Audio Bug is Fixed

The Audio Bug is Fixed

For android version crash on tutorial

On android, the audio bug still exist. Any known fix?

App summary

App name: AKIBA'S TRIP UNDEAD & UNDRESSED
App serial: PCSE00428
App version: 1.00

Vita3K summary

Version: v0.2.0
Build number: 3691
Commit hash: https://github.com/vita3k/vita3k/commit/31826697
CPU backend: Dynarmic
GPU backend: Vulkan

Test environment summary

Tested by: Benjamin Toledo
OS: Windows 11
CPU: AMD Ryzen 5 4600G
GPU: AMD Radeon(TM) Graphics

Issues

No issues

Screenshot

Log
vita3k.log
Recommended labels

Playable


[Feature] Sub List when opening and closing

Description
Hi,
I hope you are doing well.
There is something if we bring onto the website, it will look awesome and that is "adding animation when closing and opening each category".
Screenshots

Checklist

[X] I have checked the existing issues
[X] I have read the Contributing Guidelines
[X] I am willing to work on this issue (optional)
[ ] I am a GSSoC'23 contributor

Hi, @AliReza1083 that's a great idea, we can proceed with it, assigning to you!

There is no problem.
I have opened a PR.


ADDED RequestID feature

Pull Request Test Coverage Report for Build 214

10 of 14 (71.43%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-1.2%) to 94.386%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

atreugo.go
9
10
90.0%

context.go
1
4
25.0%

Totals

Change from base Build 213:
-1.2%

Covered Lines:
269

Relevant Lines:
285

💛  - Coveralls

Hi @losingle,
You could do that with a middleware. it's not necessary to add inside the internal handler, because it's your custom functionality. Just copy it and register the middleware in your atreugo instance.

I think this RequestID is fundamental,
because even the simplest business needs to be monitored,
but monitoring is not possible without RequestID

But the best way to do that, really is to use middleware

@savsgio
Middleware we made a change to atreugo Middleware, dividing it into beforeMiddlewares and afterMiddlewares, as they execute before and after viewFn
Atreugo is considering offering Middlewares as well?

Yeah atreguo offer middlewares https://godoc.org/github.com/savsgio/atreugo#Atreugo.UseMiddleware

But the middlewares will just execute before vienFn is executed.

You could make a PR to adds support to Before/After Middlewares :)

About RequestID middleware, it would be a good idea to create a middlewares folder and adds inside it.

well,I modified it in this way

Make two PR, please!

If middleware is used to append RequestID without changing the atreugo structure, obtaining RequestID externally is inconvenient.
I wanted to get RequestID through atreugo.requestctx

No because, the RequestID is a header, it's not necessary add to RequestCtx structure to access to it.

Okay, so just provide the entry that the header gets

One way is adds a method that return the RequestID if it's present in request without change structure
For example
   return ctx.Request.Headers.Peek("X-Request-ID")
}```

I felt I had to use RequestID as a basic feature, so I didn't submit the middleware PR over time

I don't understand you, sorry.
What do you mean?

I think the current PR should be ok

Sorry, but the RequestID function could be a middleware function perfectly.

I've just added the before/after middlewares.

Sorry, but the RequestID function could be a middleware function perfectly.
The middlewares add granularity to the handler and extensibility if you need

This conclusion is correct, but I still feel that RequestID should be provided as a basic feature
as atreugo grows, many of features depend on requestID

Yeah it's a basic feature, so i will added into predefined middlewares to use if it's neccesary or not. Also adds the method into atreugo.RequestCtx to get their value easier.

If you want to make this chage, i will accept your PR

thanks

I've just added the request id middleware into the middlewares folder

Now, if you register that middleware, you could access to de header value with ctx.RequestID()

Sorry, I'm not familiar with fasthttp server. I recently discovered that the server API has an ID method that is actually RequestID


Discussion: command buffers design

Introduction
If you're not familiar with Vulkan, a command buffer is a list of commands that can be executed by the GPU.
The purpose of this issue is to find a convenient way for the user to be able to create a struct that represents a command buffer, and this struct must implement the CommandBuffer trait.
A brief description of this trait:

There are only four methods that need to be implemented.
The inner() method is an implementation detail that makes the library work. Nothing special to say about it.
The prepare_submit() must check whether the command buffer is able to be executed at a given moment on a given queue. The implementation is supposed to make sure that all the resources it accesses are available from that queue and at this given moment, and that the command buffer itself is allowed to be executed on the given queue.
The check_buffer_access() and check_image_access() methods exist to tell the caller whether the command buffer accesses or modifies a given resource during its execution, and if so at which pipeline stage.
The // FIXME: lots of other methods comment refers to several safety details and to secondary command buffers, which isn't the priority here.

As you can see this trait is pretty loose and can be implemented in various ways as long as you go through an UnsafeCommandBuffer (as this is required by inner()).
The UnsafeCommandBuffer type is, as its name tells, the lowest level object that vulkano provides and that can be used to create command buffers.
Safety challenges
Here is an exhaustive list of what an implementation of a command buffer must do in order to correctly use an UnsafeCommandBufferBuilder:

It must keep alive all the buffers, images, framebuffers, render passes, pipeline objects, and descriptors that it uses during its execution. Since the command buffer object itself is going to be kept alive during this execution, all the command buffer has to do is hold ownership of these resources.
It must make sure that the device of the buffers/images/etc. is the same as the device of the command buffer.
It must make sure that the commands are supported by the queue family of the command buffer (each command buffer has a precise queue family and can only be executed on this family).
Some commands must be executed in a precise context. For example the commands that modify the state must only do so after a pipeline object has been bound and if this pipeline object has the corresponding states marked as dynamic. Similarly if you add a draw command for example, then the currently bound vertex buffers must match the currently bound pipeline. In summary you can't just accept any command in any order.
Since Vulkan implementations are allowed to execute multiple commands simultaneously, pipeline barriers have to be inserted in order to avoid data races. Similarly image layouts transitions have to be handled. It is debatable whether this should be explicitely done by the user or automatically by vulkano, but even if done manually vulkano would still have to make sure that they are correct.
While this may seem obvious, the methods of the CommandBuffer trait (described above) have to be implemented correctly.

Because all these requirements add an implementation overhead and because building command buffers is often done in performance-critical paths, we want to provide ways for the user to skip some of them through unsafe code if they wish so, and/or move some of these checks at compile-time.
The current system
The system I went with is to create "layers" that implement a trait named CommandBufferBuilder and that each wrap around another generic object that implements CommandBufferBuilder. Each check is then put in a different layer.
While we can extract the "queue type check" (3rd element in the list above) and the "device check" (2nd in the list) in their own layer, the others are more problematic:

The "context check" (4th) is really expensive as it has to keep track of everything that happens in the command buffer.
The other checks (1st, 5th, 6th) are really tied together. The 5th and 6th overlap a bit because they both need to track resources usage, and the 6th requires storing the resources, which is already covered by 1st.

The overlapping problem clearly limits the point of using layers in the first place. If we merged the layers that should be merged, we would only have 3 layers.
In addition to this, there's the problem that layers need to keep track of things between commands, and thus require the various resources to be clonable.

Obviously we want to keep providing a AutoCommandBufferBuilder type, as its API is simple to understand and not cumbersome.
There's a lot of code between the API of AutoCommandBufferBuilder and the API of UnsafeCommandBufferBuilder (all the safety things described above, plus the state cache).
The problem is that if a user wants to implement their own more optimal alterative to AutoCommandBufferBuilder, or if we want to provide such an alternative in vulkano in the future, then we would have to rewrite some parts of this intermediate code. This is why the current layers system exists.

Some general remarks concerning the current layers system:

Right now the commands storage layer must be the layer right above the unsafe command buffer builder, as it takes ownership of the commands. It should be possible to make some changes in order to be able to inject a state cache layer between the commands storage and the unsafe command buffer builder, but it's probably not worth the efforts.

Consequently there's no point in making the commands storage layer generic. We might as well put the UnsafeCommandBufferBuilder directly in it instead of using a generic parameter that implements a trait.

Implementing the submit sync layer without taking into account the presence of the auto-pipeline layer is going to be a hack at best and a safety hole at worse.

Therefore I think the submit sync layer, auto-pipeline layer, and commands storage layers should be merged. They overlap anyway.

This new type could provide some flags if the user wants to enable or disable some features in the builder.

The current AddCommand<Cmd> trait system works well (except that -I think- refined commands like drawing shouldn't use it), but it makes the API really confusing.

This trait exists because adding a command to a command buffer builder may modify the type of the builder, and this new type depends on the type of the parameters of the commands. If Rust had HKTs we could merge all the AddCommand trait impls into one, but right now we can't.

The state cache layer could be provided as a standalone struct, without being a layer.

Checking the validity of commands could be done by freestanding functions.

The queue type check and device check could be done by these freestanding functions as well (not different freestanding functions, the same).

The context check should be part of the API of the command buffer. For example the AutoCommandBufferBuilder wouldn't provide a method to modify a state, which would eliminate the need for checking that.

Conclusion:
I think the UnsafeCommandBufferBuilder should provide one method for each vkCmd that exists in Vulkan, without trying to be smart about anything.
Then there should be a SyncedCommandBufferBuilder that wraps around a UnsafeCommandBufferBuilder and builds pipeline barriers and handles synchronization. Some flags could be added if we want to give the possibility to customize the behavior.
Aside of this, freestanding functions that check the validity of commands, plus check the device and queue family capability.
Aside of this, a freestanding state cacher.
The implementation of AutoCommandBufferBuilder would simply wrap around the SyncedCommandBufferBuilder, the state cacher, and the validity checking functions.
If the user wants to implement their own command buffer type, they can easily do so by reusing the various components.

For the record I have a local branch which almost has features parity with the current code, but I have troubles implementating the SyncCommandBufferBuilder.
The problem is that commands have to be cached in order to be submitted later (as we want to inject pipeline barriers in between commands), but at the same time we have to track the state of buffers and images used by these commands in a hashmap.
I'd like for the hashmap to self-borrow from the commands list, but that's not possible.
The API is definitely correct, but I have troubles finding an elegant implementation.


Suggestion of more operators

The following is my personal suggestions.
The purpose is to make wenyan-lang easier to express program logic.
Although there are alternative methods in the current wenyan syntax, but can be simpler and flexibler.
Welcome to discuss.

負。 負「甲」 means  以零減「甲」
模。模「甲」以「乙」 means  除「甲」以「乙」所餘幾何, but much simpler.
严格等於。「甲」严格等於「乙」
非严格等於。「甲」非严格等於「乙」
形。 形「甲」等於「「數」」 ,  形「甲」等於「「物」」
or   「甲」之形者 ?    「甲」乃一物否 ?
邏輯且或非。
非「甲」
「甲」且「乙」  same as  夫「甲」「乙」中無陰乎 , but much simpler.
「甲」或「乙」   same as  夫「甲」「乙」中有陽乎 , but much simpler.
「甲」且「乙」且「丙」且「丁」。名之曰「戊」
位運算子，多種。Use simple operators instead of stdlib functions. For example, 「甲」位左移二，same as 施「左移」於「甲」於「乙」, but much simpler.
銜接。一接二 result as 「「一二」」
一接二接三接四 result as 「「一二三四」」
轉換。一變作一言 result as 「「一」」, and 「「一」」變作一數 result as 一

May be we can try macro first, when it is impossible by macro then resort to syntax parser.
And in later version, may built in some popular marco.


array of keys empty after calling createKey

after calling
var keys=[....];
regedit.createKey(keys, function(err) {...});
the array keys is empty, why did the createKey function empty the array?

At some point the code empties the array when its being fed it to the stream. While its against normal best practices (such as defensive programming and such) I opted not to copy the array immediately since at times we are talking about very long arrays.
In this particular we rely on the client (i.e you) to use defensive programming.
Will update the documentation about this.

ok, for my case I want to keep the keys after the creation so I cloned the array before.
Thank you for your explanation.


Add Launcher to Houdini

This launcher makes it easy to stay updated with the latest commits to Houdini, and provides a "noob friendly" way to update the modules necessary to run Houdini.

There seems to be issue with how Houdini starts the server, no matter the launch order, if the game and login servers are launched in the same instance, the game always gets the precedence, and is launched first. This causes issues, as the login server is therefore, never launched. Maybe @TunnelBlanket you have an idea of why this is happening?

@AmusingThrone that's because when both Login and Game are in same instance,  when Game handlers are loaded,  it nullifies or removes login handlers

@valid22 Thanks! Should work now thanks to @TunnelBlanket.


Rain detect Django

Fixes #28

Changes proposed

Check List (Check all the applicable boxes)

[ x] I have updated the documentation accordingly.
[x ] I have added a new Project.
[ x] I have added a README.md file for the Project.
[x ] The title of my pull request is a short description of the requested changes.

Screenshots

Add the hactoberfest label

this application seems to be just showing yes or no in a website, It would be good if you create a UI to input the place name instead of accessing it in the URL.


Resize without -dPDFFitPage to be able to add right margin

Hello,
I had use you awesome script (congrats) to add a right margin to document.
I was able to do it by removing the -dPDFFitPage argument in resize command.
It could be great to add an option to do that in you script.
Best regards,
Manuel

Merged on v2.4.4
Thanks for the contribution!!

BTW, another option would be to run in mixed mode with scale 1 (100% / no scaling).
This way you could run the scaling mode without scaling anything.
And then would be able to position the pages with the parameters:

--hor-align, --horizontal-alignment <left|center|right>
Where to translate the scaled page
Default: center
Options: left, right, center
--vert-align, --vertical-alignment <top|center|bottom>
Where to translate the scaled page
Default: center
Options: top, bottom, center
--xoffset, --xtrans-offset <FloatNumber>
Add/Subtract from the X translation (move left-right)
Default: 0.0 (zero)
Options: Positive or negative floating point number
--yoffset, --ytrans-offset <FloatNumber>
Add/Subtract from the Y translation (move top-bottom)
Default: 0.0 (zero)
Options: Positive or negative floating point number

I am gonna leave the option to disable the fit-to-page option anyways, just changed it to (yes/no), but still accepts f/fit.

👍


Travis CI: flake8 finds syntax errors and undefined names

Add flake8 tests to find Python syntax errors and undefined names.
E901,E999,F821,F822,F823 are the "showstopper" flake8 issues that can halt the runtime with a SyntaxError, NameError, etc. Most other flake8 issues are merely "style violations" -- useful for readability but they do not effect runtime safety.

F821: undefined name name
F822: undefined name name in __all__
F823: local variable name referenced before assignment
E901: SyntaxError or IndentationError
E999: SyntaxError -- failed to compile a file into an Abstract Syntax Tree

Thanks for your PR! I am not familiar with flake8, but it looks like a substitute for pylint?
If I understand correctly, this will stop the Travis build early if there are syntax errors in the code (is this typically an issue?) and report PEP8 violations as warnings in the Travis log? I am hesitant to add too many code quality tools since it's all too easy to set up many tools and end up doing nothing but tooling. Codacy runs pylint so we already have a linter in place.
I am struggling to see the added benefit of this. The real improvement might be stopping builds early, and it would make sense to add this to Appveyor as well since in my experience Travis builds are much faster than Appveyor builds but even still, most the time is spent setting up the environment so this wouldn't help out there. I don't think long build runtimes have ever really been a real issue though. Please help me see why this makes sense.
As for the benchmarks directory, I am considering removing this from the repository entirely. Most of the files in there are very, very messy and their only use is to load data sets (if you have them locally), run benchmarks and to experiment with the code. It is not included anywhere in the actual tSNE library itself, so this directory should be excluded from tests/linting or anything of that nature at the very least, if not removed entirely.

Yes.  The idea is to fail fast.  If a PR contains a syntax error or an undefined name then we want the contributor to get feedback fast so they can fix it fast.  No need to run longer tests, just fail the build quickly.  I consider both Circle CI and Travis to be faster at startup than the rather lethargic AppVeyor to I added the tests to Travis.  We do not need to run these tests in multiple CI systems as they would merely return identical results.  It is however useful to run the tests on both Python 2 and 3 if both are going to be supported as they each have different syntax and therefor different Abstract Syntax Trees.
A linter in a dynamic language should flag issues that the compiler would flag in a compiled language.  It should raise an alert if there is a syntax error or if an import is missing.  It should warn you that basestring, cmp(), long, reload(), unicode, xrange() is not builtins in Python 3.  Codacy does none of these things that a compiler would.  It merely says that async def func(): is not valid Python.  It seems to be more legacy than the PyLint that it is based on.  In the hands of a strong practitioner, PyLint can catch many of the issues above but it take configuration and usually a lot of # pylint: disable=xyz directives in the code.
The second round of flake8 tests is purely optional and that is why I exit-zero it.  The vast majority of those issues can be automatically corrected with Black, AutoPEP8, or yapf.  The remaining ones are actually worth fixing but are not vital to runtime safety.

Removed the second round (exit-zero) flake8 tests.  We are down to just five "showstopper" tests discussed in the commit message above.  If Codacy can be configured to flag these issues, I would love to learn how to do that.

AppVeyor does Windows and Linux.  Travis does Mac and Linux or anything in a Docker container.  Circle focuses on making the Docker approach easier.
I like the Python 3.5+ approach — tuned to the times.
79 characters is for punch cards!  Black likes 88 which is sane.  My max-line-length is 127 so code can be read on GitHub without right-left scrolling.
I don’t use Codacy but it does have a following so I might be missing something.

Black likes 88 which is sane.

I was not aware of that, I may have to look into it then.
Thanks for the PR and for introducing me to flake8. If it turns out to be really good, I may end up replacing Codacy with it entirely. Thanks for this informative conversation!


Visible line appears on Container edges despite borderWidth set to 0.0

Steps to reproduce
Run the code
Expected results
When setting the borderWidth of a Container to 0.0, no visible border or line should appear around the edges of the container.
Actual results
Despite setting borderWidth to 0.0, a faint line is still visible along the edges of the container, indicating that the border is not completely removed.
Code sample
Code sample
import 'package:flutter/material.dart';

void main() => runApp(MyApp());

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Material App',
      home: Scaffold(
        backgroundColor: Colors.white,
        appBar: AppBar(
          title: const Text('Material App Bar'),
        ),
        body: Container(
          margin: const EdgeInsets.all(8),
          height: 60,
          width: 100,
          decoration: BoxDecoration(
            border: Border.all(
              color: Colors.white,
              style: BorderStyle.none,
              width: 0.0,
            ),
            color: Colors.blue,
          ),
          alignment: Alignment.centerRight,
          child: Container(
            decoration: BoxDecoration(
              color: Colors.white,
              border: Border.all(
                color: Colors.white,
                style: BorderStyle.none,
                width: 0.0,
              ),
            ),
            child: const SizedBox(
              height: 60,
              width: 60,
            ),
          ),
        ),
      ),
    );
  }
}

Screenshots or Video

Screenshots / Video demonstration

Logs
Logs
[Paste your logs here]

Flutter Doctor output
Doctor output
[✓] Flutter (Channel stable, 3.24.0, on Ubuntu 22.04.4 LTS 6.8.0-40-generic, locale en_US.UTF-8)
    • Flutter version 3.24.0 on channel stable at /home/andry/fvm/versions/3.24.0
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision 80c2e84975 (5 weeks ago), 2024-07-30 23:06:49 +0700
    • Engine revision b8800d88be
    • Dart version 3.5.0
    • DevTools version 2.37.2

[✓] Android toolchain - develop for Android devices (Android SDK version 34.0.0)
    • Android SDK at /../
    • Platform android-34, build-tools 34.0.0
    • Java binary at: /home/andry/android-studio/jbr/bin/java
    • Java version OpenJDK Runtime Environment (build 17.0.10+0-17.0.10b1087.21-11572160)
    • All Android licenses accepted.

[✓] Chrome - develop for the web
    • Chrome at google-chrome

[✗] Linux toolchain - develop for Linux desktop
    ✗ clang++ is required for Linux development.
      It is likely available from your distribution (e.g.: apt install clang), or can be downloaded from https://releases.llvm.org/
    ✗ CMake is required for Linux development.
      It is likely available from your distribution (e.g.: apt install cmake), or can be downloaded from https://cmake.org/download/
    ✗ ninja is required for Linux development.
      It is likely available from your distribution (e.g.: apt install ninja-build), or can be downloaded from
      https://github.com/ninja-build/ninja/releases
    ✗ pkg-config is required for Linux development.
      It is likely available from your distribution (e.g.: apt install pkg-config), or can be downloaded from
      https://www.freedesktop.org/wiki/Software/pkg-config/

[✓] Android Studio (version 2023.3)
    • Android Studio at /home/andry/android-studio/
    • Flutter plugin version 81.0.1
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • android-studio-dir = /home/andry/android-studio/
    • Java version OpenJDK Runtime Environment (build 17.0.10+0-17.0.10b1087.21-11572160)

[!] Android Studio (version unknown)
    • Android Studio at /home/andry/android-studio
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    ✗ Unable to determine Android Studio version.
    • Java version OpenJDK Runtime Environment (build 17.0.10+0-17.0.10b1087.21-11572160)

[✓] VS Code (version 1.92.2)
    • VS Code at /usr/share/code
    • Flutter extension version 3.96.0

[✓] Connected device (3 available)
    • SM A336M (mobile) • RZCW128DSEX • android-arm64  • Android 14 (API 34)
    • Linux (desktop)   • linux       • linux-x64      • Ubuntu 22.04.4 LTS 6.8.0-40-generic
    • Chrome (web)      • chrome      • web-javascript • Google Chrome 128.0.6613.113

[✓] Network resources
    • All expected network resources are available.

! Doctor found issues in 2 categories.

borderWidth 0.0 means 1 physical pixel

@moffatman Mmmmm, but, how could i remove the border then?

You already have BorderStyle.none. I don't think this is due to the borders. Do you see the same problem with borders removed?

What do you mean by "with borders removed"?

@adonisRodxander can it be an issue when you use some displays? because I cannot literally see it on device or simulator

What I mean is, just put border: null
My guess is this isn't really due to the borders, but rather the subpixel alignment of the white box on top of the blue box. there is some floating point rounding issue with the positioning. So that on the right side of the white box, it slightly doesn't cover the blue box.

This is a duplicate of https://github.com/flutter/flutter/issues/14288.
Kindly follow up in the original issue for updates.
Closing from here.
Thank you


ReturnValue::Set(uint32_t i) does not preserve unsignedness on 0.10

One would expect this code:
 info.GetReturnValue().Set((uint32_t)0xffffffff);

to produce the same result as
info.GetReturnValue().Set(Nan::New((uint32_t)0xffffffff));

on nodejs 0.10, but it does not. In the first case the returned value is -1, in the second case it's<PHONE_NUMBER>.
Nodejs 5.0 returns the positive value in both cases.
In nan_implementation_pre_12_inl.h we see (the code in nan_implementation_12_inl.h is essentially the same):
Factory<v8::Uint32>::return_t
Factory<v8::Uint32>::New(uint32_t value) {
  return To<v8::Uint32>(v8::Uint32::NewFromUnsigned(value));
}

But the Implementation of ReturnType<T> in nan_callbacks_pre_12_inl.h:
  inline void Set(uint32_t i) {
    TYPE_CHECK(T, v8::Integer);
    value_->Dispose();
    *value_ = v8::Persistent<T>::New(v8::Uint32::New(i));
  }

does not use v8::Uint32::NewFromUnsigned, but straight v8::Uint32::New.
Changing New to NewFromUnsigned fixes the behavior.
nan_callbacks_12_inl.h just forwards to v8:
https://github.com/v8/v8/blob/master/include/v8.h#L7708
which uses Integer::NewFromUnsigned (in this latest version).
There has been one noteworthy change to v8's ReturnValue::Set(uint32_t) since it's introduction: https://github.com/v8/v8/commit/3c8a79cabadeaa8c356b7789a8b621464d643b2d - but I'm not sure of its implications.

You seem to be correct. Would you like to submit a patch and a test case?


🐞 dagger doesn't work with sysbox

What is the issue?
I've tried to run Dagger in docker-in-docker on top of sysbox, but it doesn't work - because it seems like sysbox doesn't allow Dagger to create a new network namespace
Log output
dagger-engine container logs (in debug mode):
time="2023-12-12T09:19:13Z" level=info msg="detected mtu 1500 via interface eth0"
dnsmasq[89]: started, version 2.89 cachesize 150
dnsmasq[89]: compile time options: IPv6 GNU-getopt no-DBus no-UBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP no-conntrack ipset no-nftset auth no-cryptohash no-DNSSEC loop-detect inotify dumpfile
dnsmasq[89]: warning: interface dagger0 does not currently exist
dnsmasq[89]: using only locally-known addresses for dagger.local
time="2023-12-12T09:19:13Z" level=debug msg="setting up engine tracing"
dnsmasq[89]: reading /etc/dnsmasq-resolv.conf
dnsmasq[89]: using nameserver <IP_ADDRESS>#53
dnsmasq[89]: using only locally-known addresses for dagger.local
time="2023-12-12T09:19:13Z" level=error msg="failed to create tracer provider" error="cannot merge resource due to conflicting Schema URL"
dnsmasq[89]: read /var/run/containers/cni/dnsname/dagger/addnhosts - 0 names
time="2023-12-12T09:19:13Z" level=debug msg="creating engine GRPC server"
time="2023-12-12T09:19:13Z" level=debug msg="creating engine lockfile"
time="2023-12-12T09:19:13Z" level=debug msg="creating engine controller"
time="2023-12-12T09:19:13Z" level=error msg="failed to create tracer exporter" error="cannot merge resource due to conflicting Schema URL"
time="2023-12-12T09:19:13Z" level=info msg="auto snapshotter: using overlayfs"
time="2023-12-12T09:19:13Z" level=debug msg="could not read \"/var/lib/dagger/net/cni\" for cleanup: open /var/lib/dagger/net/cni: no such file or directory"
time="2023-12-12T09:19:13Z" level=debug msg="creating new network namespace yk686y8k59878nrcavwq2cto2"
buildkitd: permission denied

Steps to reproduce

create the dagger-engine container in debug mode in dind
see that the container stops soon after being created

SDK version
0.9.4
OS version
linux something (sorry I don't know, I don't control it)

note that I had it working with dagger 0.8 by disabling the services feature - so basically not using the CNI
with dagger 0.9 this is not possible.
so a workaround is to keep using dagger 0.8 with _EXPERIMENTAL_DAGGER_SERVICES_DNS=0
or to use a dagger engine set up elsewhere...

Paging @vito @jedevc @sipsma who may have more insights into the internals.
@vbehar what is your flexibility in changing your setup? Are you using sysbox because there's no other way? Can you share details on your infrastructure? I believe this is a gitlab runner - is it running on kubernetes? Would you have the option of running a sidecar container, to bypass docker-in-docker altogether?

yes, we're using a shared set of gitlab runners hosted in kubernetes - using sysbox to get a "safe" way to allow docker-in-docker.
for our dagger builds, we've just setup an extra docker-based gitlab runner running in a single box, so that all our dagger builds uses the same dagger-engine instance, and we get local caching.
for now it's enough for our scale - we'll see later when we'll need to scale if more projects move to dagger

for our dagger builds, we've just setup an extra docker-based gitlab runner running in a single box, so that all our dagger builds uses the same dagger-engine instance, and we get local caching. for now it's enough for our scale - we'll see later when we'll need to scale if more projects move to dagger

Ok. Just so you know, you can run Dagger as a DaemonSet on your cluster: each node in the cluster gets a dedicated Dagger engine, with persisted local storage (up to the lifetime of the node). Clients in each Gitlab runner pod route their requests to their local node's engine.
Something to keep in mind when you look for an upgrade from your single-node configuration.

I got the same error when attempting to get a quick idea about Dagger using AWS Cloud Shell.
I'm just mentioning it because the cause might be the same and it's easier to reproduce there. I don't intend to actually keep using AWS Cloud Shell, but it might be a quick and free way to go through the quickstart and see what Dagger is.

I really would love to be able to run this unpriveleged in one or another way as well. This is currently the only thing stopping me from using this awesome tool.


Using examples/search.php clarification

Hi, first of all, thanks a lot for this library, it sure seems like it is easy enough to learn.
With that said, I have a question regarding the use of this example, as it's not very clear to me.
I'm keeping the code mostly as-is, except for the parameters:
$params = array(
  'q'        => 'Search Query',
//  'since_id' => 'Get results since this ID (or leave blank for earliest allowed)',
//  'pages'    => 'How many pages should be retrieved?',
//  'rpp'      => 'Results per page (default 15)',
//  'max_id'   => 'Max ID to accept. This isn\'t sent to Search but instead used to filter the received results',
//  'geocode'  => 'Geo co-ordinates (e.g. 37.781157,-122.398720,1mi)',
//  'lang'     => 'Restrict results to a specific language? (en,fr,de etc)'
);

If I load the page on my test server (question: is this meant to be loaded from a web browser?) I get this:
Strict Standards: Non-static method tmhUtilities::read_input() should not be called statically in E:\xampp\htdocs\twitter2\examples\search.php on line 20
Search Query:
Notice: Undefined index: pages in E:\xampp\htdocs\twitter2\examples\search.php on line 25
Received page 1	http://search.twitter.com/search.json?page=1 There was an error. string(55) "{"error":"You must enter a query."}"
Any ideas on what I'm doing wrong?
Again, thank you very much.

Can you share all your code and also tell me which version of PHP you are running?

Certainly. PHP version is 5.3.8 (using XAMPP 1.7.7 on Windows 7)
I actually think I found what the "problem" is and also answered my own question, but I've included a clarification.
Code (basically the same as the example but modified a bit):
<?php

date_default_timezone_set('GMT');

require '../tmhOAuth.php';
require '../tmhUtilities.php';
$tmhOAuth = new tmhOAuth(array());

$params = array(
  'q'        => 'Twitter API',
  'since_id' => '',
  'pages'    => '10',
  'rpp'      => '15',
//  'max_id'   => 'Max ID to accept. This isn\'t sent to Search but instead used to filter the received results',
//  'geocode'  => 'Geo co-ordinates (e.g. 37.781157,-122.398720,1mi)',
  'lang'     => 'es'
);

//This sets parameters if using this script through a CLI:
/*
foreach ($params as $k => $v) :
  $p[$k] = tmhUtilities::read_input("{$v}: ");
  if (empty($p[$k]))
    unset($p[$k]);
endforeach;

*/
/* Modification to get it to run without CLI: */
$p = array_filter($params);
//Removes "Notice: Undefined index: pages in..."
if( !isset($p['pages']) ):
    $p['pages'] = 1;
endif;
/*    End modification. */

$pages = intval($p['pages']);
$pages = $pages > 0 ? $pages : 1;
$results = array();

for ($i=$pages; $i > 0; $i--) {
  $args = array_intersect_key(
    $p, array(
      'q'        => '',
      'since_id' => '',
      'rpp'      => '',
      'geocode'  => '',
      'lang'     => ''
  ));
  $args['page'] = $i;

  $tmhOAuth->request(
    'GET',
    'http://search.twitter.com/search.json',
    $args,
    false
  );

  echo "Received page {$i}\t{$tmhOAuth->url}" . PHP_EOL;

  if ($tmhOAuth->response['code'] == 200) {
    $data = json_decode($tmhOAuth->response['response'], true);
    $results = array_merge($results, $data['results']);
  } else {
    $data = htmlentities($tmhOAuth->response['response']);
    echo 'There was an error.' . PHP_EOL;
    var_dump($data);
    die();
  }
}

foreach ($results as $result) {
  $date = strtotime($result['created_at']);
  $result['from_user'] = str_pad($result['from_user'], 15, ' ');
  $result['text'] = str_replace(PHP_EOL, '', $result['text']);
  echo "{$result['id_str']}\t{$date}\t{$result['from_user']}\t\t{$result['text']}" . PHP_EOL;
}

?>

Yeah, that would do it. This example is there just to show how to retrieve results from the Twitter Search API. You could use it as a CLI script, or webpage called by a cron job.
As this script could make multiple requests to the Twitter API (pages) I wouldn't allow it to be reached through a public URL.
There are a lot of optimizations you can make if you know what you want the script to do - for example, don't prompt for the values to search for. Your code does most of this but you can optimize a little more by doing something like this:
<?php

date_default_timezone_set('GMT');

require '../tmhOAuth.php';
require '../tmhUtilities.php';
$tmhOAuth = new tmhOAuth(array());

$pages = 5;
$args = array(
  'q'        => 'Twitter',
  'since_id' => '0',
  'rpp'      => '15',
  'lang'     => 'es',
);

$results = array();

for ($i=$pages; $i > 0; $i--) {
  $args['page'] = $i;

  $tmhOAuth->request(
    'GET',
    'http://search.twitter.com/search.json',
    $args,
    false
  );

  echo "Received page {$i}\t{$tmhOAuth->url}" . PHP_EOL;

  if ($tmhOAuth->response['code'] == 200) {
    $data = json_decode($tmhOAuth->response['response'], true);
    $results = array_merge($results, $data['results']);
  } else {
    $data = htmlentities($tmhOAuth->response['response']);
    echo 'There was an error.' . PHP_EOL;
    var_dump($data);
    die();
  }
}

foreach ($results as $result) {
  $date = strtotime($result['created_at']);
  $result['from_user'] = str_pad($result['from_user'], 15, ' ');
  $result['text'] = str_replace(PHP_EOL, '', $result['text']);
  echo "{$result['id_str']}\t{$date}\t{$result['from_user']}\t\t{$result['text']}" . PHP_EOL;
}

?>

As for the strict warning, it's because I don't declare the read_input method as a static function in the utilities file. It's there as a helper function so if strict compliance is something you need then adding static should silence the warning.
I'll mark this issue as closed as I think you have found the information you needed - if not feel free to comment and re-open the issue.


Add information about when net core 3.0 might be supported

Right now it says "We hope to make this available soon" which is not enough for me. Giving us an indication will be helpful.

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

ID: 76f39eec-9dd1-6167-56ec-47b26e0b5063
Version Independent ID: f9f2b0f3-01eb-cf58-8767-194fe0fc0e44
Content: Migrate from ASP.NET Core 2.2 to 3.0
Content Source: aspnetcore/migration/22-to-30.md
Product: aspnet-core
Technology: aspnetcore-migration
GitHub Login: @Rick-Anderson
Microsoft Alias: riande

At the time of writing, it wasn't known.
Currently, the runtime and shared framework should be there. The SDK rollout is in progress.
https://aspnetcoreon.azurewebsites.net/
I'll add that site to that section.

This might be offtopic but I hope you can still answer my question.
I want to create a new ASP.NET Core 3.0 project. I want to build and release it in Azure Pipelines using a self-hosted agent that has .NET Core 3.0 agent installed.
I will release it to an app service hosted in Azure.
Do I understand it correctly when I say that Azure has no support yet for hosting an ASP.NET 3.0 app yet and that your link shows me the progress of this step? I have read about creating a standalone app or using a docker image but I'd rather wait for it to be actually supported fully instead of using workarounds.
Also, if im right, is there an indication somewhere that will tell me more  about the possible release date of normal .NET COre 3.0 support in app service?
Thanks!

@sander1095 My understanding is that if you go the self-hosted agent route, you can configure to use the 3.0 SDK. If you need to use their hosted agents, then you have to wait on the full rollout ... until they get the SDK rolled out.
You're correct in checking their docs and asking them for more coverage if they don't make it clear. I see a bullet that pertains to this ...

After a new version of the .NET Core SDK is released, it can take a few weeks for us to roll it out to all the datacenters that Azure Pipelines runs on. You don't have to wait for us to finish this rollout. You can use the .NET Core Tool Installer, as explained in this guidance, to install the desired version of the .NET Core SDK on Microsoft-hosted agents.

https://docs.microsoft.com/azure/devops/pipelines/ecosystems/dotnet-core#troubleshooting

no support yet for hosting an ASP.NET 3.0 app

The runime and the shared framework for 3.0 are there, so you can host a 3.0 app on App Service. Without the SDK, you can't build right now (e.g., Kudu). Since the SDK isn't there, that's probably related to why their build agents also aren't available yet for Azure Pipelines (the agents that they offer).
Regarding the website, yes ... that's official. Keep an :eye: on that.


Bing and microphone permission

Hi All
Not sure if rates as an issue, but I've setup a basic Winforms and added the Webview control. I then do a Webview.Navigate and go to https:///www.bing.com/search?q=something....
The search works well and results are displayed but I get a popup dialog asking if I'd like to allow the microphone to be accessed (see pic). I thought I could handle the dialog using the PermissionRequested event but it never seems to get triggered for this dialog. Is there any way to supress the dialog or handle it in any way?
Cheers
Peter

@azchohfi any thoughts, should this be filed as an issue on the Win32 repo at least?

It should be filed as an issue on the Win32 repo, yes.

@pL0ck can you file an issue on the WebView2 Feedback repo so they can understand this scenario?
FYI @pagoe-msft


@app is scope leaky

When we have something like this:
@app begin
  DATA = sort!(DataFrame(rand(10, 2), ["x1", "x2"]))
  @out df = DATA

  # more code here

df is scoped inside the ReactiveModel and is not accessible at module scope
however, DATA leaks into the module scope -- which is surprising and not good for performance

I hoped it would be straightforward and wrapped the @app macro output into a let ... end block but it turns out that handlers are in a different scope and stuff breaks as handlers can't access the vars in the scope introduced by the let block:
ERROR: UndefVarError: `DATA` not defined
Stacktrace:
 [1] var"##Main_ReactiveModel!#292"()
   @ Main ./util.jl:567
 [2] #invokelatest#2
   @ ./essentials.jl:819 [inlined]
 [3] invokelatest
   @ ./essentials.jl:816 [inlined]
 [4] |>
   @ ./operators.jl:907 [inlined]
 [5] init(::Type{Main_ReactiveModel}; vue_app_name::String, endpoint::String, channel::Any, debounce::Int64, transport::Module, core_theme::Bool)
   @ Stipple ~/.julia/dev/Stipple/src/Stipple.jl:430
 [6] init
   @ ~/.julia/dev/Stipple/src/Stipple.jl:419 [inlined]
 [7] init_from_storage(::Type{Main_ReactiveModel}; channel::Nothing, kwargs::Base.Pairs{Symbol, Union{}, Tuple{}, NamedTuple{(), Tuple{}}})
   @ Stipple.ModelStorage.Sessions ~/.julia/dev/Stipple/src/ModelStorage.jl:15
 [8] init_from_storage(::Type{Main_ReactiveModel})
   @ Stipple.ModelStorage.Sessions ~/.julia/dev/Stipple/src/ModelStorage.jl:11
 [9] top-level scope
   @ ~/.julia/dev/Stipple/src/ReactiveTools.jl:607
in expression starting at /Users/adrian/.julia/dev/StippleUI/demos/tables/app.jl:40

Well, other things needing patching before getting to this point so it looks like scoping is a bit messy.

If I'm right, this is due to historic devolopment of the ReactiveTools API.
We started off with the desire to dynamically add variables to an existing model without a surrounding @appmacro. This was solved by a module-related storage. Then we aimed to support also ancient model syntax and relied on the model fields rather than on a storage. But this needed an evaluation parts of the code before the calculation of the macro expressions.
That has quite some pitfalls and I'd probably design the API - at least the app macro - a bit differently now with all the knowledge that I gained during programming.
Things would be a bit easier, if we'd split @app and @handlers as we had done in the past. Or we would need to introduce a storage for named models, which I had proposed initially but then somehow gave up.
The point is that for the correct rewriting of handlers we need to know the full set of variable names of the model. So we either need to have defined the model type before writing the handlers, or we need to write the storage also for named models to keep track of the variable names.
So cleaning up model scope is probably related with rewriting non-negligible parts of the macro code.
Having said all this, constructions like the one above
@app begin
  DATA = sort!(DataFrame(rand(10, 2), ["x1", "x2"]))
  @out df = DATA
   <...>
end

are currently not handled correctly. There are two ways to achieve that sort of behaviour:

include extra code in a manual route, e.g.

route("/") do
    model = @init
    DATA = sort!(DataFrame(rand(10, 2), ["x1", "x2"]))
    model.df[!] = DATA # The `[!]` is only needed if you have a handler attached to `df`, otherwise `model.df` is sufficient
    page(model, ui) |> html
    @onchange isready notify(df) # to transfer the updated value of the model to the front-end after the setup
end

include the code in the isready handler

@app begin
    @out df = DataFrame()
    <...>
    @onchange isready begin
        DATA = sort!(DataFrame(rand(10, 2), ["x1", "x2"]))
        df = DATA # here it is ok to trigger a handler, because everything is already setup, so no `[!]` is necessary
    end

end

We can at least use references to already declared variables with a little trick.
See https://github.com/GenieFramework/Stipple.jl/issues/300#issuecomment-2490336737 and following


Fix signed URLs for objects with spaces in the name

Closes #562.

Should we also include a unit test?

@dwsupplee done!


Core test pipeline failing without a visible error

This happens pretty consistently in nighly runs:
https://dev.azure.com/azure-sdk/internal/_build/results?buildId=541642&view=logs&j=1e00682f-6081-5348-8da2-7d601664b2e3&t=4f3e1a81-cacf-5ad2-6e75-5049507bfdad

This appears to be caused by https://github.com/coverlet-coverage/coverlet/blob/master/Documentation/KnownIssues.md#1-vstest-stops-process-execution-earlydotnet-test. I will address in #14427.


Add a general amb operator

There is an amb (ambiguous) operator equivalent for FutureStreams, a more general one for Publishers should be added to Spouts. It should race publishers and publish data downstream from the winner only.

Released in 2.0.0-MI3


What i do?

[Enter feedback here]

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

ID: 63281b03-c455-5a80-3716-e374372330fe
Version Independent ID: 05617725-bce1-fe54-7dda-d0767f9cc527
Content: Visual Studio Subscriptions Professional Development
Content Source: subscriptions/professional-development.md
Product: vs-subscription
GitHub Login: @evanwindom
Microsoft Alias: lank

@oswal92 Were you trying to leave feedback for this topic?


Cloud hpcs

Major feature

added an option to use an on-cloud HPCS
Minor changes
simplified Dockerfile to install grpcio-tools with pip3 command
changed pyep11.py to use a single step encrypt/decrypt API
changed a grep11 constant file from ep11.py to grep11consts.py

LGTM

Thank you @tnakaike


using pagination

So it seems there is not built in pagination, I'm trying to build my own.
That said, when I use ->query() it gives me the total_count number I need. But when I use ->get() it gives me the model I want (with the relations), but no total count so  I can't paginate properly.
Is there a way to get the total count while using get()?

I do it using Illuminate\Pagination\LengthAwarePaginator. Check this SO answer.