Item NPC gives you sometimes randomly dissappears

I've been unable to trace the cause. Or recreate it.
If you've had this happen, please leave comment how/when and under what conditions, held items, things clicked and if you consistently have the issue.

When I have it happen it's a desync, I only have had it on a server.

It happens in singleplayer as well. But it is very similar to a desync. I think it has something to do with how the mod checks the players inventory and when it does it.

I play on Singleplayer. When I turn in the 9 Hardy Turnips to Jade, the reward was a Sickle and seeds. They appear in my inventory after my conversation with Jade but once I open my inventory or a chest, they disappear.

Hmm, I've tried to recreate that one you say piemantr like 30 odd times at least, every time I've had no issue :(. Ya'll must be doing something else differently.

We're having the same issue with both our server (running sponge) and singleplayer. Using latest version of the mod and the pack is FarmingValley. Both sickels and hoes traded with the npc disappear after few steps away.

I've the same problem but I think I've found the cause of the problem.
In my modpack I've Inventory Tweack/Mouse Tweack, i've disabled both and no more item dissappearing.
I think IT is the main cause because once I re-enable it the problem return.

I had this issue happen to the miner, i talked to him and he tried to give me copper ore but it replaced my iron sword in slot 1, i opened my inventory, tried to drag it and it turned back to the sword and the copper ore was gone. This has happened with pretty much every npc so far up to the miner.

It seems having an open hotbar gives you everything without replacing or deleting items.

Ive had it happen as well, I think it's not checking if a slot is empty in the inventory prior to giving the item.

I rewrote parts of the quest system in 0.6. Ideally anyone who can test if this still occurs will be apreciated.

This is happening on a server I play with my friends. there are just 3 of us. but every time we give a tool to the blacksmith (for upgrade or repair) when he gives it back it appears on hot bar, the disappears as soon as we open our inventory. this happens to all 3 of us. Any idea the cause?

'This is happening on a server I play with my friends. there are just 3 of us.'
I had exactly the same problem until a minute ago, using the latest version of Harvest Festival with 0.5.27 in the current version of Farming Valley (which doesn't have inventory tweaks). It was really ruining my enjoyment for the half hour before I found this thread.
'I rewrote parts of the quest system in 0.6. Ideally anyone who can test if this still occurs will be apreciated.'
Tested on 0.6.0-218 on my dedicated server, and... fixed!

I can confirm this bug.
It'll happen nearly every time something is on the first slot of the hotbar, only workaround is to re-train on organizing it.

Happens with empty hotbar also.
MC:1.10.2
Forge:*.2511
Harvest Festival:0.5.27
Modpack: Farming Valley 0.9.1

Should be fixed in 0.6. Please open a new issue, if you are able to reproduce it for 0.6 though!

So, this just happened to me in singleplayer (though opened to LAN with one other player).  The upgraded tool appeared in the first slot of my hotbar (replacing a diamond pick) and also the first empty slot of the hotbar.  When I tried to move the upgraded tool (copper watering can), both vanished and the pick reappeared.
MC:1.10.2
Forge: .2511
Harvest Festival: 0.5.27
Modpack: Farming Valley 0.9.1

As stated previously, in this issue even, this is fixed in 0.6+

Still having the Issue Concolora mentioned and I'm in 0.9

This just happened to me on my friends and my multiplayer world the blacksmith to upgrade/ repair anything takes the items and gold but never gives the item back it just dissappears.


Reload HAProxy without impacting server states

Blocked until haproxy-1.6-rdev6
This will improve the time required to forward traffic after a reload examples/seamless_reload.txt

this is great!
@ramr @smarterclayton fyi

Very cool

awesome, look fwd to trying it out.

ping @bprashanth

Reading through the release notes it looks like haproxy will save the weights of the backends. This isn't useful today. How do we make it useful (https://github.com/kubernetes/contrib/issues/144?)? Can you give me a better example so I understand how to fully utilize this?
Otherwise LGTM, please test/add a test for this to the basic e2e test I have in the main repo https://github.com/kubernetes/kubernetes/pull/14988

Please update licenses and we can get this in

LGTM but for the one comment nit. Please run the e2e with the new build, if you haven't already. Would be even better if you added one for the soft reload, but no real requirement right now, since it is a more advanced use case.


Pages with Fewer Links

Pages with Fewer Link
Try to provide a clickable card using column management.

Unprofessional Look
Using these two colored buttons will give it an unprofessional look. Closing this issue for now.


Mention graceful_node_shutdown_state in kubelet local files page

Description
Add a mention of the file graceful_node_shutdown_state on the page https://kubernetes.io/docs/reference/node/kubelet-files/
Issue
Closes: https://github.com/kubernetes/website/issues/48610

/lgtm


[TACHYON-1387] Use Ttl instead of TTL for naming

https://tachyon.atlassian.net/browse/TACHYON-1387

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Tachyon-Pull-Request-Builder/7726/
Test PASSed.

LGTM

LGTM, but I still feel better with TTL since it's a defined concept in Tachyon.

TTL it's a solid defined concept in IT Infrastructure, not sure if changing
that could be a good fit.
@caadecarvalho

LGTM, but I still feel better with TTL since it's a defined concept in
Tachyon.
—
Reply to this email directly or view it on GitHub
https://github.com/amplab/tachyon/pull/2413#issuecomment-170037961.

my two cents are that TTL and Ttl have the same meaning it is the same concept and the only difference is capitalization
the problem with using TTL consistently is that it violates the recommended style guide and also 3rd party code generation tools such as thrift create getFoo() getters even if the field name is FOO (so we end up with thrift generated getTtl and hand written getTTL elsewhere).
@aaudiber

@jsimsa summed up my thoughts nicely. I would only add that in addition to Thrift unavoidably generating getTtl, our protocol buffer code is also generating getTtl.
One alternative is to stop using the abbreviation and spell it out with getTimeToLive. This is done by https://docs.oracle.com/javase/7/docs/api/java/net/DatagramSocketImpl.html, which deprecated getTTL in favor of getTimeToLive

Good to know, thanks for the info and docs!
2016-01-08 15:38 GMT-02:00 Andrew Audibert<EMAIL_ADDRESS>
@jsimsa https://github.com/jsimsa summed up my thoughts nicely. I would
only add that in addition to Thrift unavoidably generating getTtl, our
protocol buffer code is also generating getTtl.
One alternative is to stop using the abbreviation and spell it out with
getTimeToLive. This is done by
https://docs.oracle.com/javase/7/docs/api/java/net/DatagramSocketImpl.html,
which deprecated getTTL in favor of getTimeToLive
—
Reply to this email directly or view it on GitHub
https://github.com/amplab/tachyon/pull/2413#issuecomment-170068692.

@aaudiber getTimeToLive is a bit verbose and it may not be obvious to people TimeToLive here is TTL.

I am good with this PR.

+1 LGTM


Create Source Mapping NEP initial draft

In order to have greater compatibility with all programming languages supported by NEO, it's necessary that we create a source mapping standard. This NEP should explain the file format used to map the source code from high-level programming languages (C#, Typescript, Python, Go, Java) into NEO VM Opcodes.
I spoke with individuals interested in this subject, and their desire is to use an existing model, instead of creating a new one. We already have this kind of mapping done using neo-debugger-tools, however, it has to be adapted.
The main difference from this model to our model is the compression used in map files to make it much smaller. In smart contracts I have worked with, the map files are 10 times larger than the Smart Contract code.
"Universal mapping" reference:
https://developer.mozilla.org/en-US/docs/Tools/Debugger/How_to/Use_a_source_map
https://docs.google.com/document/d/1U1RGAehQwRypUTovF1KRlpiOFze0b-_2gc6fAH0KY0k/preview#
https://github.com/ryanseddon/source-map/wiki/Source-maps%3A-languages,-tools-and-other-info
https://www.html5rocks.com/en/tutorials/developertools/sourcemaps/
Credits: @Relfos for the initiative, @afragapane and @dicarlo2 for the mapping references and collaboration.
I would like to suggest that @Relfos produces the initial draft, and we add our input on top of it. In my dreams we can have this NEP done in one month 🙏.
Required for #147 and #5

I've talked with @lock9, I will delegate the creation of the initial draft to him and help review it.

👍 from @afragapane and me


When events fire should match the latest CSSOM View spec

See https://drafts.csswg.org/cssom-view/#events
I could add some hook or something to CSSOM View for this if that would help.

Should I just copy this into my spec or is linking to it enough? I currently link to the existing WD.

Linking works I suppose. Eventually this spec should probably be merged into cssom-view if it's widely implemented. 😊

Thanks, agreed it would probably belong in cssom-view eventually. I've updated the links to point to your ED for now.

These events follow the procedure defined in section 12.1 of the CSSOM View module.

I didn't really know what this meant until I stumbled across this issue.
It'd be great if the spec could be more specific about how it interacts with CSSOM. For example:
These steps should happen as part of run the resize steps, after the existing steps:


Replace Mutex with parking_lot::Mutex and Arc with rclite::Arc

Rationale:

parking_lot::Mutex is the unwritten actual standard for various reasons (see Differences from the standard library Mutex).
It also makes the code not being littered with unwrap()s wherever a Mutex is locked. I.e. you will find that almost all crates in the wild that need Mutex or RwLock will use the ones from parking_lot and not the ones from std.
Using this is kind of a one way street as adding a feature flag means a lot of code duplication and lots of clutter in the code (i.e. worse than the aforementioned unwrap()s).

rclite::Arc is purportedly faster than the std variant and it also uses a lot less memory (4 bytes on 64 bit systems vs 16 bytes for the std variant).
This could be hidden behind a feature flag as the access syntax is the same.

If you agree I am happy to do the required changed and open a PR.

Thank you for the introduction. We would love to include it. These crates have a lot of downloads and seem reliable. There are a few things we are concerned about, such as behavior with wasm, but those can be found by turning CI in our GitLab. Please send me a pull request.

Please send me a pull request.

Done! It's now part of #48.

Fixed with merge of #48.


ECR repo creation - Add Image scanning configuration

Signed-off-by: Andrew Kundrock<EMAIL_ADDRESS>
https://github.com/RoadieHQ/roadie-backstage-plugins/issues/695

Adds AWS ECR image scanning on push functionality to the custom action via a boolean (check box) in the UI
Added additional unit tests to the ECR creation action. Function coverage is now at 100%
Updated documentation for an example ECR repo creation template

:heavy_check_mark: Checklist

[X] Added tests for new functionality and regression tests for bug fixes
[X] Added changeset (run yarn changeset in the root)
[ ] Screenshots of before and after attached (for UI changes)
[X] Added or updated documentation (if applicable)

Other notes
I left a change to app-config.yaml so that the "ECR creation" software template is enabled by default. I can remove this if desired.

Few tests failures on CI so when those are fixed we can ship this.

Updated linting errors and manually tested the github actions workflow. Should be good to go now


Refactor fill models

Description

Removing usages of Security.Subscriptions and
Security.IsExtendedMarketHours properties without modifying existing
interfaces
Modifying FillModel and SecurityTransactionModel adding a new setter for the
ISubscriptionDataConfigProvider that will be called by the system.
Maintaining retro compatibility.
Since the Security.FillModel can be set at any time by user (or system
code) will call the new SetSubscriptionDataConfigProvider() when the
fill model will be used at BacktestingBrokerage.Scan().  The objective  here
is to centralize and give robustness to the system.
Small tweak for the LiveTradingResultHandler seting
_nextChartsUpdate time after storing the data

Related Issue

Closes https://github.com/QuantConnect/Lean/issues/2634
Motivation and Context

https://github.com/QuantConnect/Lean/projects/5
Requires Documentation Change

N/A
How Has This Been Tested?

Unit and regression tests
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Non-functional change (xml comments/documentation/etc)

Checklist:

[x] My code follows the code style of this project.
[x] I have read the CONTRIBUTING document.
[ ] I have added tests to cover my changes.
[x] All new and existing tests passed.
[x] My branch follows the naming convention bug-<issue#>-<description or feature-<issue#>-<description>

Closing the PR. The issue will be solved using a context approach.


N21: Profiling

Please, read the contributing guidelines before submitting a PR.

Forgot to add reference to #589


feat(Portal): add portals to BootsrapBlazor 🙏

Is there an existing issue for this?

[x] I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.
i am trying to use a modal (the modal is within BootsrapBlazor.Components.Modal) in a component within a component, so the modal is 2 layers deep. Because of this the modal starts to experience issues i think because its too deep.
using the BlazorPortals project fixes the modal by rendering it to a parent component, but that is a depricated project...
Describe the solution you'd like
because of these issues it would be really cool to see some kind of a portal implementation in BootstrapBlazor. But while there isnt one ill be using the depricated library for now...
Additional context
I can post code of an example of putting a modal 2 child components deep, but it should be easy to reproduce...

@celadaris hi thanks for you contacting us. please submit the mini-repo-project for this issue. let us to known the BlazorPortals

My apologies, after doing extensive amounts of testing i found that my issue only appears when im using DockView version 8.1.1 when upgrading to DockView version 8.1.3 it seems to fix the bug.
i kind of mislead you into thinking it happens when the modal is a child of a child and its two layers deep but that was an incorrect cause of the bug, the bug actually happens when you launch a modal inside a DockViewV2
because the bug is fixed when upgrading to the latest version
of DockView i will close this, but ill still post my repo project if your curious.
BrokenModal.zip

@celadaris got. let us resolve this issue. thank you report this

@celadaris
https://github.com/user-attachments/assets/eb0834a7-5565-41af-9f55-6d99a46dac1f
use DialogService to replace Modal
please download this demo and try it. please let us know if you have any questions.
BrokenModal.zip


Add a script to transform output into CSV format

It is useful to debug differences between implementations, e.g.:
$ while ./create_measurements.sh 1000 && diff <(./calculate_average_royvanrijn.sh 2>/dev/null | ./tocsv.sh) <(./calculate_average.sh 2>/dev/null | ./tocsv.sh) ; do echo OK; done
Created file with 1,000 measurements in 50 ms
60c60
< Bucharest;-2.9;2.9;6.1
---
> Bucharest;-2.9;2.8;6.1
265c265
< Petropavlovsk-Kamchatsky;0.9;9.3;17.7
---
> Petropavlovsk-Kamchatsky;0.9;9.2;17.7

For #14

Nice one, thanks!


Distinct().Result

Make it clear that Distinct() returns a one-column table with column named "Result".
Your example on this page should say:
Distinct(Employees, Department).Result

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

ID: f2cd6eb9-a7fe-aac7-ac9b-ab7430d57a8f
Version Independent ID: cd91bd3a-e580-1204-3ed5-2c429bce0c6f
Content: Distinct function - PowerApps
Content Source: powerapps-docs/maker/canvas-apps/functions/function-distinct.md
Service: powerapps
GitHub Login: @gregli-msft
Microsoft Alias: gregli

Thanks for the suggestion.  I took the opportunity to expand the examples as well.


Updating caching dependencies

Caching was not working as expected and was getting cache not found due to mismatch between key and restore key.

Why:
Cache dependency was not working for maven.
Closes https://github.com/github/docs/issues/6920

What's being changed:
restore-keys: ${{ runner.os }}-m2-${{ hashFiles('**/pom.xml') }}

Check off the following:

[x] I have reviewed my changes in staging (look for the deploy-to-heroku link in your pull request, then click View deployment).
[x] For content changes, I have completed the self-review checklist.

Writer impact (This section is for GitHub staff members only):

[ ] This pull request impacts the contribution experience

[ ] I have added the 'writer impact' label
[ ] I have added a description and/or a video demo of the changes below (e.g. a "before and after video")

@ankur512512 Thanks so much for opening a PR and an issue! I'll get this triaged for review ⚡

👋 Hi @ankur512512, thanks for submitting this PR! 🙇♂
The change you're suggesting shouldn't be necessary because the cache action already matches on key, and restore-keys should also works with partial matches. (see our caching doc for more info: https://docs.github.com/en/actions/guides/caching-dependencies-to-speed-up-workflows#matching-a-cache-key)
If you are still having issues, you could contact our support team.

👋 Hi @ankur512512, thanks for submitting this PR! 🙇♂
The change you're suggesting shouldn't be necessary because the cache action already matches on key, and restore-keys should also works with partial matches. (see our caching doc for more info: https://docs.github.com/en/actions/guides/caching-dependencies-to-speed-up-workflows#matching-a-cache-key)
If you are still having issues, you could contact our support team.

Oh thanks, that makes sense.


Offset out of range error?

after a few years, I came back to this project and found the newest version working with the latest copy of artemis. Set everything back up, and tested it and it worked great, but after about a minute, I receive this error.
RangeError [ERR_OUT_OF_RANGE]: The value of "offset" is out of range. It must be >= 0 and <= 193. Received<PHONE_NUMBER>
at boundsError (internal/buffer.js:77:9)
at Buffer.readUInt8 (internal/buffer.js:243:5)
at Socket. (C:\Users\Mary\Desktop\New folder\node-MVM-master\node-MVM-master\mvm.js:214:35)
at Socket.emit (events.js:316:20)
at addChunk (_stream_readable.js:297:12)
at readableAddChunk (_stream_readable.js:273:9)
at Socket.Readable.push (_stream_readable.js:214:10)
at TCP.onStreamRead (internal/stream_base_commons.js:186:23) {
code: 'ERR_OUT_OF_RANGE'
}

Does it crash like that every time?
Try un-commenting lines 212 and 213 in your local copy and then paste the console results here.

Yes it crashes like that every time.
After uncommenting those lines, the output is as follows.
C:\Users\Mary\Desktop\games\Artemis\node-MVM-master\node-MVM-master>node mvm -l 3010 -f 2010 -v 3 -s <IP_ADDRESS>
(node:1700) [DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. Please use the Buffer.alloc(), Buffer.allocUnsafe(), or Buffer.from() methods instead.
Mainscreen View Manager v1.3.0
Listening on port 3010
Relaying to <IP_ADDRESS> port 2010
View will be set to: Aft
Use Control+C to quit.
bitmap:  <Buffer 80 a8 01 08 00>
Buffer Index:  55
Server Says the mainScreen view is:  Port
But we are sending:  Aft
bitmap:
Buffer Index:<PHONE_NUMBER>
internal/buffer.js:77
throw new ERR_OUT_OF_RANGE(type || 'offset',
^
RangeError [ERR_OUT_OF_RANGE]: The value of "offset" is out of range. It must be >= 0 and <= 193. Received<PHONE_NUMBER>
at boundsError (internal/buffer.js:77:9)
at Buffer.readUInt8 (internal/buffer.js:243:5)
at Socket. (C:\Users\Mary\Desktop\games\Artemis\node-MVM-master\node-MVM-master\mvm.js:214:35)
at Socket.emit (events.js:316:20)
at addChunk (_stream_readable.js:297:12)
at readableAddChunk (_stream_readable.js:273:9)
at Socket.Readable.push (_stream_readable.js:214:10)
at TCP.onStreamRead (internal/stream_base_commons.js:186:23) {
code: 'ERR_OUT_OF_RANGE'
}

OK thanks - that is very helpful. Looks like I'm getting some default value back from my unpackBitmap function.
I should have some time this weekend to look into this further.

My apologies - have not had time to look at this with an actual Artemis client yet. Will advise further.

If you can, please try the patched version here: https://github.com/UserMcUser/node-MVM/tree/UserMcUser-patch-1
I added a quick-and-dirty check of the offending value so that the program doesn't crash. However, I think the underlying protocol may have changed. So MVM may not crash but it also may not work.
If you can test this and let me know I would appreciate it. As soon as I am able I will do some real work on this.

See https://artemis.forumchitchat.com/post/mvm-mainscreen-view-manager-7470121?highlight=mvm&trail=60
I THINK Artemis 2.7.X and 2.8.0 require your fieldBytes ... 4,4,2,0 to be ... 4,4,1,0
Not sure if you want to extend the oldVersion to include 3 version-ranges?
... or might be time to ditch support for reeeeeeally old versions, and make it so oldVersion just changes that 18th field length from 2 to 1?
NN

See #3 ... or my fork at https://github.com/NoseyNick/node-MVM
I have obsoleted --oldVersion (made it auto-detect Artemis protocol version instead) and added support up to Artemis 2.8.0, probably 2.8.1.
:warning: NOT WELL TESTED - appreciate some help there   :grinning: :rocket:


What are the differences between this and Papyros's qml-material?

I found yours is easier to get started than this https://github.com/papyros/qml-material. I wonder what are the differences between the two?

This project is actually pitched in MOPCON 2014 Lightning Talk, to demonstrate the capability of QML. It's mostly tailored for the example app, with usability prior to extensibility. I haven't noticed Papyros until recently, but they've done great works on formalizing components AFAIK.
Also, Papyros is GPL licensed, whilst Material is BSD. Hope you could find some good use of this project. :)


Optimize dynparquet.MergeDynamicColumnSets

This commit

Adds test (There were no test covering this function)
Introduce a new implementation for merging column sets that can be reused.
Use *sync.Pool to reuse the new dynamic column set merger

Benchmark result
goos: darwin
goarch: amd64
pkg: github.com/polarsignals/frostdb/dynparquet
cpu: Intel(R) Core(TM) i7-7820HQ CPU @ 2.90GHz
                         │   old.txt   │               new.txt               │
                         │   sec/op    │   sec/op     vs base                │
MergeDynamicColumnSets-8   2.220µ ± 1%   1.330µ ± 1%  -40.09% (p=0.000 n=10)

                         │   old.txt   │              new.txt               │
                         │    B/op     │    B/op     vs base                │
MergeDynamicColumnSets-8   1104.0 ± 0%   544.0 ± 0%  -50.72% (p=0.000 n=10)

                         │   old.txt   │              new.txt               │
                         │  allocs/op  │ allocs/op   vs base                │
MergeDynamicColumnSets-8   16.000 ± 0%   6.000 ± 0%  -62.50% (p=0.000 n=10)

Dynamic columns are sorted intentionally, so we can do a k-way merge, we just hadn't implemented doing that yet.

@brancz

Dynamic columns are sorted intentionally, so we can do a k-way merge, we just hadn't implemented doing that yet.

Yes, I think this is described in commit message but didn't go into godoc for MergeRecords   #293
I know this is a statement, but I was wondering if you could provide some context relative to this PR.
note : in this PR behaviour is the same ,only implementation changed (dynamic columns are sorted as before)

@asubiotto I addressed your comments PTAL.


Changing repo instructions

We don't really make new files in this repo, so it would make more sense to just write:
  git add .

in the instruction section "Make changes in your repo".

This has been merged


question: considerations when upgrading from 1.x chart

Is the values.yaml backwards compatible? Is that the only thing to consider?

Do you indeed mean backwards (i.e. you can take a 2.x values.yaml to 1.x and still have it work) or forwards (you can take your existing 1.x values.yaml and upgrade to 2.x without changes)?
The answer is essentially yes to both, though it depends on exactly what you have in it. Most values.yaml settings are unchanged between 1.x and 2.x. There are a select few settings that, on 1.x, supported an older configuration format, covered in the deprecated features removed in 2.x section of the upgrade guide.
1.x gradually added support for the new versions over time, and if you're reverting from 2.x to 1.x, you can use the format 2.x uses so long as you're downgrading to a version after the new format was added and the original format was removed (e.g. you can use the migrations setting block from 2.x as far back as 1.5). As such, the config format in 2.0 is largely backwards-compatible with 1.x, though the degree varies. We are not guaranteeing this going forward, however, and will add new functionality and/or deprecations that are not 1.x backwards-compatible in future 2.x versions.
Forwards compatibility depends on your replacing any old-format/deprecated config before upgrading from 1.x to 2.x. If any deprecated configuration is present, 1.14 will print a warning when you upgrade or install a release. If you see no warnings, your config is ready for 2.x.
The one quasi-exception to the above is the proxy ingress host configuration. Although the above still applies, the old format for that was deprecated relatively late (in 1.14, the second-to-last 1.x release before 2.x), so that configuration is not backwards-compatible very far. However, we expected that actual use of the proxy Ingress was probably uncommon (probably only in environments where Kong was behind another proxy+ingress controller). You can make that section of the config backwards-compatible further by simply omitting it if you do not use it.
Will go ahead and close this, but if you have any follow-up questions, please respond back and I'll reopen it.

That's exactly what I was asking, thank you very much :pray:


GET requests

Can you add a feature to make GET requests to turbowarp clouddata just like the Scratch clouddata?
https://clouddata.turbowarp.org/logs?projectid=612229554
^ says can't do GET request
#26 why won't fix?

The server intentionally does not store any logs to reduce load.

I suppose we could add a way to get all variables, but it won't be anything like Scratch's logs

I suppose we could add a way to get all variables, but it won't be anything like Scratch's logs

That would be good too!
{
  var1 : [name, value, modified, user, ....... ], #list can be a dict for readability too
  var2 : [name, value, modified, user, ....... ]
}

This is a possible structure for that?


Skip some unknown medit keywords generated by mmg software

I ran into trouble when reading a medit mesh output by the remeshing software mmg due to unknown keyword and not supported information in the mesh: "RequiredVertices", "TangentAtVertices", "Tangents", and "Ridges".
I propose just to skip these information and inform the user that these keywords are not supported by meshio.
I attached an example mesh with the problematic keywords:
plane.o.zip
Thanks for review,
Moise

You'll have to fix the linter errors. Also, use f-strings instead of format().

You can run just lint or install pre-commit to see the lint results locally.

Thanks!


King : workflows : student-bio

[x] I wrote my markdown locally on a new branch
[x] My bio file is named exactly the same as my GitHub username
[x] My bio link in the class README opens to my student bio file
[x] I pulled and merged main into my branch before pushing
[x] I pushed my branch to the class repository and opened a PR
[x] I went through the PR checklist
[x] All the CI check pass
[x] I assigned a coach to review my PR
[x] I
linked my PR to this issue

@GKing3  could you create a deliverable issue and linked to your PR.


tooltipStyles not working

When I've used 'tooltipStyles' on <Icon Button> the style is not going to apply. here is my code.
<IconButton
              tooltip={strings.READY_FOR_JOB_TOOLTIP}
              tooltipPosition="top-center"
              tooltipStyles={{
                 backgroundColor: '#f00',
                 color: '0f0'
              }}>
              <FontIcon
                className={readyForJobIcon}
                color={amber500}
                hoverColor={purple500}
              />
</IconButton>

Tech
Version

Material-UI
19.2

React
16.0

browser
chrome

etc

We have been porting the component on the v1-beta branch. We reimplemented it from the ground-up. While we haven't tested it, I think that the issue is most likely fixed on that branch. Hence, I'm closing it.
Still, we will accept PR fixes until v1-beta takes over the master branch.


Dev releases marked as stable releases

Description
Hi, we are offering cosign as a download in arkade, a Kubernetes marketplace.
The dev releases are being marked as "stable releases", but if they were marked as pre-release, then GitHub's API would show us the latest v1.0 etc release to download.
Most projects don't mark dev or preview / RC releases as full releases. It's a checkbox in the UI, I wonder what your thoughts are?
As it is, we'd need to hard-code a cosign version because GitHub's API can't determine which is the stable release.
Thanks,
Alex

@dekkagaijin @dlorenc how about we have a dedicated repo for the Helm Charts?
then we can add rekor helm chart, fulcio helm chart, and others together with the cosigned.
WDYT?

That works!

@dlorenc i will ping you in slack to talk about and to create the repo 🎸

done! we can close this

move to here: https://github.com/sigstore/helm-charts
PR: https://github.com/sigstore/helm-charts/pull/10


Conduits

Description
Merging work on conduits into main branches.
Thanks a bunch to @agnor99 who did all of the work, I'm just helping merge this stuff in.
Todo

[x] Full review of everything

Checklist:

[x] My code follows the style guidelines of this project (.editorconfig, most IDEs will use this for you)
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have made corresponding changes to the documentation

Going to merge this for now; TODOs left over can be addressed in future. Going to try for a swifter pace.

Thanks a lot @agnor99 and @wahfl2 for your ace work on this!


operators [R] etcd (0.6.1 0.9.0 0.9.2 0.9.2-clusterwide 0.9.4 0.9.4-clusterwide)

Substitute https://github.com/operator-framework/community-operators/pull/4146, a simple description as follows,
This apiextensions.k8s.io/v1beta1 has been deprecated in OCP 4.9(K8s 1.22) according to the Deprecated API Migration Guide. It leads to the etcd operator failed to install on OCP 4.9, so this PR updates the related CRD.

@camilamacedo86 Could you help have a review when you're free? Thanks!

/bugzilla refresh

/test 4.7-deploy-operator-on-openshift

/merge possible

/merge possible


net/http: remove support for status code 418 I'm a Teapot

Go HTTP implements the 418 I'm a Teapot status code in go/src/net/http/status.go.
Its reference is RFC7168, but really came from RFC2324, Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0). Note the title - HTCPCP/1.0 is not HTTP/1.x.
HTCPCP was an April 1 joke by Larry to illustrate how people were abusing HTTP in various ways. Ironically, it's not being used to abuse HTTP itself -- people are implementing parts of HTCPCP in their HTTP stacks.
Node's support for the HTCPCP 418 I'm a Teapot status code (see https://github.com/nodejs/node/issues/14644) has been used as an argument in the HTTP Working Group to preclude use of 418 in HTTP for real-world purposes.
While we have a number of spare 4xx HTTP status codes that are unregistered now, the semantics of HTTP are something that (hopefully) are going to last for a long time, so one day we may need this code point.
Please consider removing support for 418 from Go HTTP, since it's not a HTTP status code (even by its own definition). I know it's amusing, I know that a few people have knocked up implementations for fun, but it shouldn't pollute the core protocol; folks can extend Go easily enough if they want to play with non-standard semantics.
Thanks,
/cc @bradfitz

@ALTree: This should probably be a Go 2 proposal, net/http.StatusTeapot is used in the wild.

It could still get a Deprecated: doc comment though so tools warn against its use?

Yes, that's right but it looks like there many implementations of the HTCPCP. I think it's ok to break them in a major release of Go since it's not really part of the HTTP specification.
Flexibility is the key here, if users needs to support the 418 status code for some reason, they should be able to extends the Go stdlib.

I'll be terse as I don't want to litter this issue, I'm referring to the standard deprecated notices documented https://blog.golang.org/godoc-documenting-go-code 3rd party tools already do check this such as https://staticcheck.io/docs/staticcheck SA1019 | Using a deprecated function, variable, constant or field.

Yes, removing the 418 constant would break the go1 compat promise... but since it appears to be a joke (is it?) I'll leave to others to decide if it would be fine to remove it. That's why I didn't (yet) tag it as go2.

Doing some git digging... It was added in 5fb82d8cf600ad7388306a0bf9899dc2a93aaafa
We can remove it from Go 2.
I have another proposal somewhere to hide stuff (symbols, packages) from docs without removing it from the API. This might be a candidate of a thing to hide from docs but keep for compatibility.

SGTM, thanks.

I would be saddened to see 418 removed. It's a fun bit of flavor that does no harm, and is a fun little easter egg to stumble upon - I feel it would be a shame to smother it.

Why bother? It's amusing, and doesn't hurt anything.

While we have a number of spare 4xx HTTP status codes that are unregistered now, the semantics of HTTP are something that (hopefully) are going to last for a long time, so one day we may need this code point.

Just to be clear, is your argument that when/if the 400 block runs out, we'll want that one extra code available to stretch out the usefulness of the 400 block just a bit further?
Unless I'm reading it incorrectly, the 400 block of HTTP status codes has more than 50 codes available. With the available "space" of the 400 block at more than 50%, this might be a pre-mature optimization for a problem that may never occur (400 block running out of available codes, that is).
Not trying to sound harsh, but I for one like fun little easter eggs that you find throughout a programming career. To me, it shows that everything that goes on to make a computer actually do work is still made by humans, and keeping small slices of that human element is nice (in my opinion). Your argument is sound and logical, but this requested change ever so slightly lowers the "fun-ness" of Go (and potentially NodeJS) in the spirit of engineering robustness. At the end of the day, I have to say I don't think that tradeoff is worth it.
(I appreciate the history lesson though! I always thought 418 was a part of the HTTP/1.x spec; didn't know about the "HTCPCP/1.0" spec. 🙂)

We have a history of people squatting on HTTP status codes, and they're a scarce resource. The registry is the mechanism we use to coordinate their semantics and assure interoperability, and this status code is not registered.
I'm all for Easter eggs in headers (effectively infinite space), body content, etc. Putting a joke in a status code isn't a big deal right now, but it sets a precedent of treating this space carelessly, and considering what we hope the lifetime of HTTP will be, it's a concern.
Also, we have a chance of getting rid of this now; when it comes down to that last status code, it'll be far too embedded to get rid of (the resistance we see now will be 100x greater).

I propose removing it from net/http and creating net/htcpcp as as many stated before - code 418 is not in fact a HTTP/1.x status code, but HTCPCP/1.0.

Perhaps we should just register 418 officially, and then everyone can be happy.

Also, we have a chance of getting rid of this now; when it comes down to that last status code, it'll be far too embedded to get rid of (the resistance we see now will be 100x greater).

@mnot I would challenge this claim. If your fear is that 418 will gain widespread adoption, I think you're a little late; 418 was introduced in 1998, 19 years ago. Quite the opposite - once HTTP codes start becoming a scarce resource, the value of having a joke code will not be worth taking up a code for.

@birjolaxew I think lots of implementations have included it because they someone thought it was relevant, and they took a pull request without checking. As a proportion of traffic / applications / requests / whatever other metric you choose, it's basically unused for the defined semantics.

We have a history of people squatting on HTTP status codes, and they're a scarce resource.

How is it a scarce resource with over 50% of the space still available? Considering it's taken 19 years to get to the current point I very much doubt that claim. No one seems to be in any need or hurry to introduce additional codes either, and definitely not another 82 of them just in the 4xx range. Unless there's some RFC that we haven't seen yet?

The registry is the mechanism we use to coordinate their semantics and assure interoperability, and this status code is not registered.

Fair enough. Lets just register it then.

I'm all for Easter eggs in headers (effectively infinite space), body content, etc. Putting a joke in a status code isn't a big deal right now, but it sets a precedent of treating this space carelessly, and considering what we hope the lifetime of HTTP will be, it's a concern.

That precedent was set 19 years ago. It hasn't caused much of a problem yet. Why the sudden 🔥 now? What 82 status codes do you expect to need in the 4xx space, even during the lifetime of HTTP? Aside from that, as far as I'm aware it's perfectly possible to come up with HTTP/3 that uses different status codes and ranges. We'll likely keep reusing the same ones b/c it makes interoperability easier and it's what people expect, but there's nothing stopping is from expanding the 4xx range to 4xxx instead.

Also, we have a chance of getting rid of this now; when it comes down to that last status code, it'll be far too embedded to get rid of (the resistance we see now will be 100x greater).

418 is already in use. Removing it now from Go, or NodeJS, while not removing it from Java, Python, Ruby, and a whole bunch of others does nothing to solve this problem. If you'd like to get rid of 418, submit an RFC that declares that 418 should not be implement as part of HTTP/1.1 or HTTP/2.

If you'd like to get rid of 418, submit an RFC and have it ratified that declares that no standards compliant HTTP implementation may return or interpret 418 in the teapot sense.

That's not how it works; we don't define every thing that's not allowed, we define the semantics and record them in the registry.
If you're suggesting we mark the HTCPCP RFCs as Historic, we can do that, but I suspect that will make even more people sad.

If you're suggesting we mark the HTCPCP RFCs as Historic, we can do that, but I suspect that will make even more people sad.

You're already making a lot of people sad. At least doing it that way won't leave it up to language implementations but actually provides guidance as to what implementers are expected to do.

Some people have no sense of humor. This isn't harmful. It's funny.

Regardless of all of this, you still haven't been able to provide an argument as to why supporting 418 is actually harmful. Sure it's not registered, but that's about it.

The argument is quite clear:

While we have a number of spare 4xx HTTP status codes that are unregistered now, the semantics of HTTP are something that (hopefully) are going to last for a long time, so one day we may need this code point.

An alternative solution, although I think it's fine to schedule the constant's removal, is to remove it from http.StatusText(code int) string function. net/http can continue to define the constant as there's no harm there, but StatusText would not recognise the code, instead reserving it for use by an accepted status code.

I find that argument to be rather weak. I'm onboard with the principle, but I'm having a hard time seeing us running out of status codes or not being able to solve that.
But, lets assume that next year we run out of 4xx status codes, what then? Freeing up 418 won't save us for long, we'll have to come up with a different way of handling status codes entirely.

Crossing the streams; also raised in https://github.com/nodejs/node/issues/14644 and https://github.com/aspnet/HttpAbstractions/issues/915

Some people have no sense of humor. This isn't harmful. It's funny.

That's a matter of taste. Go is an opinionated language, and I was surprised to find this status code here. I don't think it's particularly funny or harmful. Due to compatibility, it has to stay in the language. I don't see why it should be deprecated either, does the status code really need to be maintained or acknowledged in any special way?

Someone even went so far as to start save418.com because of what you're trying to do.

It is a bit frighting how much time collectively gets spent on issues like this.

We have a history of people squatting on HTTP status codes, and they're a scarce resource. The registry is the mechanism we use to coordinate their semantics and assure interoperability, and this status code is not registered.

@mnot do you have any examples of this? From the top of my head I can't think of any examples of people squatting HTTP status codes, nor are they a scarce resource when more than half of the 400 are unused.

@sondr3 Plenty here, but none as widely recognised as the 418.

That list is a good start. When we did 451, there was a concern we couldn't use it because Exchange server had squatted on it in the past, but working with MSFT, we determined that it wasn't likely to be an interop problem (because it was confined to one bit of code that was old, not still widely deployed, and specialised, IIRC).

The code 451 was chosen as a reference to the novel Fahrenheit 451.

Isn't this a bit ironic given you want to remove 418 I'm a Teapot? You could've chosen any of the free status codes but you had to use one that's a reference to a novel.

We use 418 in Production. I highly oppose this request.

I dislike how this is being done, piecemeal across multiple projects, in a way that disputes there isn't a standard implementation here.

I strongly believe there's a finite number of 4xx error cases that you will ever see. The very fact they have grown really slow is indicative to me that we are unlikely to ever need all the space.

What is your proposal for current implementations using 418? At the minimum I would expect to see an RFC providing best practice for existing HTCPCP-compliant devices (which do exist). Arguing that it's April 1st RFC is insufficient. It has been published and implemented in practice.

418 is not a HTCPCP control code. It's an inter-op code for HTTP given overlapping resources. It indicates that the device is a HTCPCP device and not a HTTP device. This displays a fundamental lack of understanding of the RFC.

Regarding effort, the coffee pot control protocol has it's earliest origins in the foundation of the internet. See https://en.wikipedia.org/wiki/Trojan_Room_coffee_pot In fact, the Too Early code that is being proposed owes it's existence to the invention of the webcam which the coffee pot played a key part in showing the need for. So from a variety of standpoints the issue is of merit, aside from actual commercial implementations.

While the author has linked to one conversation on one RFC for one new code, nowhere has he provided any indication of the claims, namely that:

Unregistered codes cause problems for RFC writers
Unregistered codes with small usage rates are actually considered by RFC writers
The body of opinion of those writing and reading RFCs is behind the view that we will need to rescind non-official codes.

The Internet of Things is a key development area for the Internet. HTTP will doubtless provide a useful transport protocol for that medium. Is there room for a more generic 'Wrong Device Type' error code that would preserve the meaning and adoption of the error code while broadening the scope of it's usability beyond the RFC?

Hi! Speaking as part of team "Teapot", which is named based on this error code, I want to have 418 as it is. If you change it you break compatibility, for being too serious. ;)
We really need this client error code for answering questions personally.
Fun fact:
Our web page https://www.google.com/teapot is maybe not very known, while not working for google we appreciate it.

I'm the CTO, CEO of a popular IoT company, you may have heard of it: tPot.
What status code am I supposed to return from my teapots if this is removed from Go?
A teapot must have hurt you very deeply for you to take up this crusade against them.

The argument for freeing up 418 for space reasons holds little weight -- it came out nearly 20 years ago and the need for additional space for status codes has yet to become a major issue, even in the rise of HTTP/2.0.
Think about it, nearly 20 years that people have been using this status code. It's been apart of Node, Golang, and others, so of course people have been using it. At work, we have automated tests that check for status errors to ensure the right events happen, and ImATeapot is one we use as a wildcard -- a random status error we know we'd never get back, so we use it to automatically fail the tests. It honestly fits this purpose beautifully -- being both random, and unexpected. We don't want to fail our tests with a realistic error in that case which could be the cause of a bug elsewhere. ImATeapot is perfect for this case.
It's also one of those things when you're new to programming, or working with HTTP when you see it, you can't help but smile and be happy for a moment, remembering how humbling and cute it is sometimes to program computers. Removing this, after nearly 2 decades, just seems a little sad. People love it, and it should stay. There's no effective reason not to. Sure, it's not HTTP standard, okay, I see the argument for wanting to migrate it to HTCPCP, but I just fail to see how this is harming anyone. It's age has nearly made it a standard--every specification listing errors codes online includes it, so why should we not deem it prominent enough to be included?

Do not remove 418, it's what makes the internet fun. #Save418

#Save418.

Please do not comment on the issue unless you have something to say other than "but I like teapots". We have a NoMeToo policy. You can add a reaction to the initial post to show support or opposition to the proposal.

We should keep 418. It is used in production, like here: https://www.google.com/teapot

A request to register 418 has been submitted to IANA, under number 979050.

 The conversation has been pretty civil so far, lets keep it that way.

If somebody actually believes we are going to run out of HTTP error codes in near future, he/she should try to fix HTTP design.
Having one extra error code isn't going to solve that problem (which I think is fictitious).

 Collective intelligence actually often falls into that category.

Thank you all for your input, I believe the case has been made clearly both for and against the proposal and while there is nothing that can be done inside the scope of Go 1, this issue will be revisited in the planning for Go 2.
I am closing discussion on this issue as there is nothing more to be said at this time. Thank you.

For future reference, @mnot has drafted https://tools.ietf.org/id/draft-nottingham-thanks-larry-00.html to reserve code 418.

The status of 418 seems to be unresolved.  Closing until it is resolved.


Eslint Error Line

Platform: Win & Mac
Vetur version: 0.8.5
Are this a bug ?  or are i am using wrong,
I get an error like below when .vue format is selected. But code color style very good.

Problems are resolved when I select vue-html format. But code color style Incompatible and bad.

Search through existing issues before posting, please?
#266


[FLINK-4732] remove maven junction plugin

On Windows, the plugin may download code from the author's web
site. The downloaded file is not signed in the same way as Maven
artifacts from Maven central which have to be signed with the
developer's key. This could be a potential target for attackers.

CC @uce

Thanks! It's good to address this. I really liked the symbolic link, maybe we can enable it again after this has been resolved by the Maven plugin.
+1 to merge this to master and release-1.1 branches.

Merging to both branches.

Merged to master and release-1.1.
@uce I also like the symbolic link. I contacted the maintainer of the plugin because it wouldn't be hard to fix this nowadays with Java 7+ which supports the creation of symbolic links. I think the lack of this was the reason why the author chose to download a binary. However, I don't know why he didn't simply ship it with the jar which should have been possible.


Special characters are not supported in build, but supported in dev

Even primitive ASCII characters are destroyed when i run Vizabi in build.
Use cases when i need them:

put arrows on buttons in testing preview page UI, like ⇅ and ⇄
otherwise i have to write TOP/BOTTOM, LEFT/RIGHT, which is ugly or TB, LR which is both ugly and confusing

intercept keyboard shortcuts, like [a] equals "a", [shift]+[a] equals "A", that's fine. now [alt]+[shift]+[a] equals "Å", but this shortcut works only in dev, not in build

i spent time trying to find a workaround, but maybe it's just one setting in Grunt, than breaks the thing?
Issue is not very urgent, but please help
It's not blocking me from developing, but is kinda blocking from demoing
@arthurcamara1 @ambodi

@angieskazka Have you tried using HTML codes for those characters instead?
← for ← , etc ? See more here: http://character-code.com/arrows-html-codes.php
Let me know if this helps.

As for the second problem, I'm not sure how you implemented it or if this is what you mean, but you can use the event properties to detect shift and alt. Then I don't see how you would need to check special chars.
Something like this would detect Enter+Shift :
if ( event.which == 13 && event.shiftKey ) {
// yay, Enter + Shift are being pressed
}

same goes with altkey and ctrlKey

HTML character codes help somewhat (can place an arrow on a button), until you look at the code later on and be wondering what do they mean. so, one-time solution is ok, but maintainability is very low. I would prefer the production to be displaying things as good as develop.

yes, fixed that as you suggest. i had a convenience recognition (String.fromCharCode(charCode) == "Å") before, that's why it got screwed up. Now i have (charCode == 197) // Å, but again this is worse on readability of the code

Well, you can comment those, as you did, to keep readability. :+1:  But those are quite common practice, since special characters do tend to cause problems when encoding files. I believe concat and min will always generate UTF-8 encoded files, and that can be the problem in build. We can try to check more on encoding and improve this later.
About the second problem, I did not mean checking for charCode 197 (which is a character produced by this combination according to your computer's configurations). I meant checking for "a" (97, which is a in every keyboard), shift and alt.
Anyways, this is not so important, and I'm glad you got it working :)

ok


UDP connection returns "write: connection refused"

Requirement - what kind of business use case are you trying to solve?
We use jaeger in a production kubernetes cluster. Agents run as daemonset with an UDP hostPort for 6831. Sometimes when an agent is restarted, the service that was calling it returns a "write: connection refused", and from then on it keeps returning the same error until the service is restarted.
Problem - what in Jaeger blocks you from solving the requirement?
This causes the service not reporting spans correctly. The error log comes from: https://github.com/jaegertracing/jaeger-client-go/blob/896f2abd37e099bae3eae942250d1a37e4bdce0b/reporter.go#L264
Proposal - what do you suggest to solve the problem or improve the existing situation?
I suggest recreating the connection in https://github.com/jaegertracing/jaeger-client-go/blob/master/utils/udp_client.go#L91 if an error is returned (or maybe after a certain number of errors?). Maybe an calling Temporary() bool and recreating only if the error is not temporary would work even better.
Any open questions to address
It's a rare issue and i can't really reproduce it. On the other hand i don't think my suggestion would break anything. I'm also open to any suggestions on how i could handle this issue in my code.

UDP is a connectionless protocol. The fact that Go has such a thing as UDPConn doesn't mean there's an actual connection to the server, it's just a representation of the local socket. There's an explanation on SO of how such connectionless protocol can report errors like "connection refused".
So I am skeptical about "it keeps returning the same error until the service is restarted" - it maybe just a temporary condition. I just tried it locally, and I did get the errors for some spans after restarting all-in-one, but then those errors went away and traces were reported fine.

I have the same problem, it's hard to find how long this "temporary condition" will stay, I believe this problem is related to some system udp configurations.

This problem is caused by conntrack, the linux kernel keeps track of each connection, when you restart jaeger, the cluster ip of jaeger-agent has changed, but the track is still stored on your service host, so your service sent spans to the non-existing ip, there is a conntrack configuration called ip_conntrack_udp_timeout which default value is 30s, that is to say, if your service has not been visited for 30s, the track will be expired and the service will return to normal, that is the "temporary condition", and you can manully delete the track by sudo conntrack -D -p udp.


Import historical events

Import historical events
Allows the ingestion of historical accounts and transfers with their original timestamp into TigerBeetle.
The new flag.imported allows the creation of transfers and accounts using a user-defined timestamp representing when the event happened outside TigerBeetle.
Refer to the docs for more details about the validations introduced, in a nutshell:

Timestamps must be monotonically increasing. Even when importing events with a past date, the user-defined timestamp must be greater than the last timestamp committed for the same kind of object.

That is, it's possible for the user to write a migration script like this:
for (account in old_database):
    client.create_accounts([account])
for (transfer in old_database):
    client.create_transfers([transfer])

It's possible for an Account and a Transfer to have the same timestamp. However, it's not allowed for a transfer to refer to an account with a more advanced timestamp, such as transfer.timestamp < debit_account.timestamp or transfer.timestamp < credit_account.timestamp.

The imported flag is orthogonal to all other flags, except that it does not allow timeout > 0 for pending transfers.

Best reviewed per commit.
Included:

Unit tests and client integration tests.
Docs and client README.

Releated #1893 and #1968
Replaces #1989

Continuation of https://github.com/tigerbeetle/tigerbeetle/pull/2171#discussion_r1705570279:

Why shouldn't we allow an imported Transfer whose timestamp is equal to one of the imported Accounts?

Imo if we disallow it now, we can trivially allow it later if it turns out to be valuable.
But going the other direction would be much harder.

This isn't as simple as I thought! Still doable though.
On create_transfers, we need to prefetch an account with that transfer's import timestamp, to verify that it doesn't exist.
(We'll need to add a Groove.prefetch_enqueue_timestamp function.)

This isn't as simple as I thought! Still doable though.

Prefetching by timestamp is fine (we already have the machinery in place). The tricky part is how we can efficiently index the object_cache by both .id and .timestamp, also, it would require more memory for an extra account per transfer.
We can optimize for memory,  instead of needing a prefetch cache of 3x Accounts per Transfer, we could first try to prefetch the Account by timestamp, and then abort prefetching the {dr,cr}_account by id if we found a conflicting one (creating accounts isn't a problem because we can repurpose the Transfer cache).
Although it would make the prefetch more complex and involve more steps, we pay the price only when imported is enabled.
Do you think the idea is worth exploring?

It is just ~1MiB of extra memory, right? Or does it get multiplied by the batch multiple somehow?
Also based on
                    .prefetch_entries_for_read_max = batch_accounts_limit,
                    .prefetch_entries_for_update_max = @max(
                        batch_accounts_limit, // create_account()
                        2 * batch_transfers_limit, // create_transfer(), debit and credit accounts
                    ),

it seems like we might not actually need to increase the prefetch size, since prefetch_entries_for_read_max is "unused" by create_transfers?
I'm not sure how to handle indexing the cachemap, though. :thinking:

I'm not sure how to handle indexing the cachemap, though. 🤔

Quick (and dirty) PoC here: https://github.com/tigerbeetle/tigerbeetle/commit/7bd446a63521790769303d0dbad81ddee150de25
Please, tell me what do you think (unit tests are failing with timestamp_must_not_regress as expected).
I'm using an extra HashMap(u64, *Value) keyed by timestamp with a pointer from the cache/stash (but the pointer may not be stable, even trying to keep them in sync during update).
Maybe we can implement not a real lookup by timestamp, but just a Set to check whether the timestamp exists or not :thinking:.

Ahh, I was wrong about the 1MiB memory -- that number actually does gets multiplied by the batch multiple:
                .map_value_count_max = constants.lsm_batch_multiple *
                    (options.tree_options_object.batch_value_count_limit +
                    options.prefetch_entries_for_read_max),

As you say though, we are already allocating enough space... except that we need to allocate a new hash map anyway :facepalm:
A simple set of "timestamp-exists" would be smaller, at least... Maybe something like prefetch_enqueue_exists(timestamp)? If it used a separate prefetch_keys_exists hashmap on the groove, we could reuse that in-place as the "exists" set.

A simple set of "timestamp-exists" would be smaller, at least... Maybe something like prefetch_enqueue_exists(timestamp)? If it used a separate prefetch_keys_exists hashmap on the groove, we could reuse that in-place as the "exists" set.

Implemented a TimestampSet that "survives" only during a single batch, and can assert that exists is only called for timestamps that were prefetched by prefetch_exists_enqueue.
The benchmark now can run imported workloads using the cli arg --flag_imported.
!! Still need more tests to explore all paths.


add link to Linked List

Thanks for this fix, but I just committed a rewrite of Queue, so I already fixed it in there.

good


Implement search with Algolia

Searching is currently done by looping through the repository array and finding the one matching criteria. This is computationally very expensive and something like Algolia might help us.

Interested in taking this on over the weekend. At a high level, what would be involved to implement this? Also, are there any other solutions you are considering other than Algolia?

Hey @lukebrichey! Thanks for the interest. I am not sure, Algolia has a service that takes your json and makes it more searchable, or so I heard. Something I'd need to look into as well. I think kbar is another such tool. The golden solution would be to have a database instead of a json file.

Gotcha, haven't heard of Algolia before but I would be down to try it out.

Hey Luca, was about to start working on search. Is the database more of a priority? If so, would be happy to take that issue on instead and work on search features later.

@lukebrichey No specific priority. Database is cool but it will take a lot more work. Feel free to work on your favourite issue ;)


[REVIEW] Creating dedicated loader submodule to build TF async dataloader

Addressing #218

Some pretty major overhauls in the last few commits. Chief among them:

Tensor -> framework conversion and batching are now done up front in the async thread. This is done because the batching in TF is nontrivial and so it pays to do it with a single tf.split op rather than slicing at each iteration
Conversion from cats, conts, labels representation to framework-specific representations are done via a _handle_tensors method, which defaults to doing nothing but can be overridden in child classes as it is in the KerasSequenceLoader
TF 2.3.0 excludes Sequence objects from being used as validation_data in .fit. As a result, I've implemented a custom validation callback to use when training Keras models. In the long run, this is probably a better scenario anyway, since a lot of recommender metrics depend on the input data and this makes implementing them in a custom validation loop easier anyway.

@jperez999 this code includes a parts_per_chunk kwarg on the DataLoader class, are we cool with that? I can add it in to the criteo example notebook


Enabling browserlink produces "weird" artifact on body tag

I just noticed that when I enable browserlink app.UseBrowserLink(); weird artifacts is produced in the html page pushing the content down. This seems to be Chrome specific as with Edge I could not produce it.. (that == $0 is just chrome dev tool tip, but what comes after is the artifact)

dependencies:
 "Microsoft.VisualStudio.Web.BrowserLink.Loader": "14.0.0-rc2-final"

Yeah it's already reported
https://github.com/aspnet/Mvc/issues/4706#issuecomment-220808090

Yup, dup of https://github.com/aspnet/Mvc/issues/4706#issuecomment-220808090.
Workaround is to remove the call to UseBrowserLink from Startup.cs.


Better isClean check

https://github.com/EndangeredMassa/npub/blob/14c6569e95cf7a683335d4877e9f00260c44648d/src/git.coffee#L10-L14
The better check is:

Run git status --untracked-files=all --porcelain
Make sure the output is empty
If not, the output contains all individual files that were modified, deleted, or added

To simplify this to an exit code, how about [[ -n $(git status --untracked-files=all --porcelain) ]] && exit 1 || exit 0?

[[ -z $(git status --untracked-files=all --porcelain) ]]? Though I really think printing out the list of files as part of a nice error message might be helpful.

That's true. We should print out the list.


LoadSwaggerFromYAMLData replaced

Fixes https://github.com/danielgtaylor/openapi-cli-generator/issues/19

Confirmed go install works with the mod. Not sure why build is failing -- something wrong in test.sh?

@danielklim Gopkg.lock file changes should look something like this:
diff --git a/Gopkg.lock b/Gopkg.lock
index e511750..5c5e9b8 100644
--- a/Gopkg.lock
+++ b/Gopkg.lock
@@ -79,14 +79,14 @@

 [[projects]]
   branch = "master"
-  digest = "1:3e62095b858d5fb21d6e9b3254f26edacb2a77d666d49753be97bcf892b09c72"
+  digest = "1:837de1c55985477eaddf0662efe610be0582da86c80ecd5c98d33c2a5aa7a926"
   name = "github.com/getkin/kin-openapi"
   packages = [
     "jsoninfo",
     "openapi3",
   ]
   pruneopts = "UT"
-  revision = "44c981756c70d8724edaea8b7662bbb5245088bb"
+  revision = "e6aa6352832d5c2b0bc28bc5e1065db6cc18d221"

 [[projects]]
   digest = "1:2cd7915ab26ede7d95b8749e6b1f933f1c6d5398030684e6505940a10f31cfda"


Potential listener leak detected

Open preferences UX and an editor side by side
Play around in the preferences UX (I was changing the font size and dragging the preferences editor to different editor groups)

Notice warning in dev tools
[8af] potential listener LEAK detected, having 200 listeners already. MOST frequent listener (10):
at attachStyler (file:///Users/isidor/Development/vscode/out/vs/platform/theme/common/styler.js:33:29)
    at Object.attachSelectBoxStyler (file:///Users/isidor/Development/vscode/out/vs/platform/theme/common/styler.js:68:16)
    at SettingEnumRenderer.renderTemplate (file:///Users/isidor/Development/vscode/out/vs/workbench/contrib/preferences/browser/settingsTree.js:582:44)
    at TreeRenderer.renderTemplate (file:///Users/isidor/Development/vscode/out/vs/base/browser/ui/tree/abstractTree.js:152:48)
    at renderers.map.r (file:///Users/isidor/Development/vscode/out/vs/base/browser/ui/list/listWidget.js:703:46)
    at Array.map (<anonymous>)
    at PipelineRenderer.renderTemplate (file:///Users/isidor/Development/vscode/out/vs/base/browser/ui/list/listWidget.js:703:35)
    at RowCache.alloc (file:///Users/isidor/Development/vscode/out/vs/base/browser/ui/list/rowCache.js:32:47)
    at ListView.insertItemInDOM (file:///Users/isidor/Development/vscode/out/vs/base/browser/ui/list/listView.js:365:39)
    at ListView.rerender (file:///Users/isidor/Development/vscode/out/vs/base/browser/ui/list/listView.js:753:34)
    at ListView.layout (file:///Users/isidor/Development/vscode/out/vs/base/browser/ui/list/listView.js:310:26)
    at TreeNodeList.layout (file:///Users/isidor/Development/vscode/out/vs/base/browser/ui/list/listWidget.js:950:23)
    at SettingsTree.layout (file:///Users/isidor/Development/vscode/out/vs/base/browser/ui/tree/abstractTree.js:796:23)
    at SettingsEditor2.layoutTrees (file:///Users/isidor/Development/vscode/out/vs/workbench/contrib/preferences/electron-browser/settingsEditor2.js:976:31)
    at SettingsEditor2.layout (file:///Users/isidor/Development/vscode/out/vs/workbench/contrib/preferences/electron-browser/settingsEditor2.js:156:18)
    at EditorControl.layout (file:///Users/isidor/Development/vscode/out/vs/workbench/browser/parts/editor/editorControl.js:167:37)
    at EditorGroupView.layout (file:///Users/isidor/Development/vscode/out/vs/workbench/browser/parts/editor/editorGroupView.js:1034:32)
    at LeafNode.layout (file:///Users/isidor/Development/vscode/out/vs/base/browser/ui/grid/gridview.js:331:30)
    at Object.layout (file:///Users/isidor/Development/vscode/out/vs/base/browser/ui/splitview/splitview.js:113:27)
    at viewItems.forEach.item (file:///Users/isidor/Development/vscode/out/vs/base/browser/ui/splitview/splitview.js:429:49)
    at Array.forEach (<anonymous>)
    at SplitView.layoutViews (file:///Users/isidor/Development/vscode/out/vs/base/browser/ui/splitview/splitview.js:429:28)
    at SplitView.relayout (file:///Users/isidor/Development/vscode/out/vs/base/browser/ui/splitview/splitview.js:213:18)
    at SplitView.onViewChange (file:///Users/isidor/Development/vscode/out/vs/base/browser/ui/splitview/splitview.js:312:22)
    at view.onDidChange.size (file:///Users/isidor/Development/vscode/out/vs/base/browser/ui/splitview/splitview.js:105:70)
    at e (file:///Users/isidor/Development/vscode/out/vs/base/common/event.js:79:135)
    at Emitter.fire (file:///Users/isidor/Development/vscode/out/vs/base/common/event.js:477:38)
    at i (file:///Users/isidor/Development/vscode/out/vs/base/common/event.js:52:93)
    at Emitter.fire (file:///Users/isidor/Development/vscode/out/vs/base/common/event.js:477:38)
    at Emitter.fire (file:///Users/isidor/Development/vscode/out/vs/base/common/event.js:480:41)
    at EditorControl.doSetActiveControl (file:///Users/isidor/Development/vscode/out/vs/workbench/browser/parts/editor/editorControl.js:104:46)
    at EditorControl.doShowEditorControl (file:///Users/isidor/Development/vscode/out/vs/workbench/browser/parts/editor/editorControl.js:59:18)
    at EditorControl.openEditor (file:///Users/isidor/Development/vscode/out/vs/workbench/browser/parts/editor/editorControl.js:45:34)
    at EditorGroupView.doShowEditor (file:///Users/isidor/Development/vscode/out/vs/workbench/browser/parts/editor/editorGroupView.js:575:56)
    at EditorGroupView.doOpenEditor (file:///Users/isidor/Development/vscode/out/vs/workbench/browser/parts/editor/editorGroupView.js:569:25)
    at EditorGroupView.openEditor (file:///Users/isidor/Development/vscode/out/vs/workbench/browser/parts/editor/editorGroupView.js:535:25)
    at EditorGroupView.doCloseActiveEditor (file:///Users/isidor/Development/vscode/out/vs/workbench/browser/parts/editor/editorGroupView.js:764:22)
    at EditorGroupView.doCloseEditor (file:///Users/isidor/Development/vscode/out/vs/workbench/browser/parts/editor/editorGroupView.js:718:22)
    at handleDir

I can get there with 4 groups open at the same time that once contained a settings editor. Doesn't need to be 4 settings editors open at the same time. They are only disposed when the group is closed. That seems like too many enum templates to render a settings editor? I'll look into it some more.

Oh that particular stack was only hit 10 times so it might not be a real problem. Will still look into it because I've seen this randomly before too.

I'm getting a similar issue while trying to figure out some noticeably degraded performance in VSCode. Not sure if this will help.
[45e] potential listener LEAK detected, having 175 listeners already. MOST frequent listener (1):
check @ workbench.main.js:76
workbench.main.js:76     at new e (file:///Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/workbench.main.js:5197:612)
    at c._createInstance (file:///Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/workbench.main.js:1390:671)
    at createInstance (file:///Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/workbench.main.js:1390:92)
    at C.renderTemplate (file:///Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/workbench.main.js:5224:621)
    at renderTemplate (file:///Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/workbench.main.js:828:131)
    at renderers.map.t (file:///Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/workbench.main.js:817:247)
    at Array.map (<anonymous>)
    at H.renderTemplate (file:///Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/workbench.main.js:817:238)
    at n.alloc (file:///Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/workbench.main.js:166:34)
    at w.insertItemInDOM (file:///Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/workbench.main.js:417:48)
    at w.render (file:///Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/workbench.main.js:416:249)
    at w.onScroll (file:///Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/workbench.main.js:421:330)
    at d.fire (file:///Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/workbench.main.js:77:1003)
    at _register._scrollable.onScroll.e (file:///Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/workbench.main.js:395:347)
    at d.fire (file:///Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/workbench.main.js:77:983)
    at r._setState (file:///Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/workbench.main.js:211:482)
    at r.setScrollPositionNow (file:///Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/workbench.main.js:210:91)
    at v._onMouseWheel (file:///Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/workbench.main.js:399:281)
    at HTMLDivElement._mouseWheelToDispose.push.i.addDisposableListener.e (file:///Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/workbench.main.js:398:284)

Not able to repro and don't rememer randomly seeing this for awhile. Closing for now


PROPOSAL - Standup config custom section should not have 'Task for' prepended.

Different projects can have different sections like in case we mentioned 'blockers' as well in standups. it would look like - Tasks for blockers. We should let the whole section name to be custom.

Can I take this one up?

@goku321 sure, that would be awesome! Let me know if you need any help with this issue or setting up things in general.

Thanks @harshilsharma63 :) Glad to take this up.

@goku321 hey, just checking for any progress.

Hi @harshilsharma63 did not make any progress yet as I was busy with other work. Give me a couple of days and I will get back to you on this. Thanks for your patience.

@harshilsharma63 Do I need to make changes in the webapp as well?

@goku321 sorry I missed your first message.
Regarding your question, yes, we need tome change in webapp as well. The text tasks for appears in one place in webapp -

There is one usage of tasks for that I'm curious on how you intent to deal with - https://github.com/standup-raven/standup-raven/blob/24650a74b382c52007684a671408a96264f0630b/server/standup/notification/notification.go#L486
So in type aggregated reports, if a member has no tasks for a specific section, we currently show the text -
John Doe has no tasks for <section name>

I can't come up with something to use in place of "tasks for" which will suite all section titles. I'm also open to removing that line all together.

How about using open items for instead of tasks for ?

@goku321 yeah, open items for sounds nice! So we are removing tasks from from all places and adding open items for` just in the one place I mentioned above. Did I get you right?

@harshilsharma63 yes, that's correct. I'll make the changes and create a PR then :)

Awesome job @goku321 !


libtiff: add patch for CVE-2022-1354

Description of changes
https://security-tracker.debian.org/tracker/CVE-2022-1354
Tested on x86_64 linux that it solves the poc.
Still having some issues because it looks like the listed fix does not fix the poc, but also seems like a much harder issue to exploit.
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
22.05 Release Notes (or backporting 21.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[ ] Fits CONTRIBUTING.md.

the listed fix does not fix the poc

What do you mean by the listed fix?

The commit linked from https://security-tracker.debian.org/tracker/CVE-2022-1355 - though I note that there is a different commit (https://gitlab.com/libtiff/libtiff/-/commit/c1ae29f9ebacd29b7c3e0c7db671af7db3584bc2, merged via https://gitlab.com/libtiff/libtiff/-/merge_requests/323) which references the issue (https://gitlab.com/libtiff/libtiff/-/issues/400) and looks far more related to the problem. So I guess I should try that one and drop debian a note to let them know they've got the wrong patch.

Urg sorry @lheckemann I realize my original message is confusing because I missed a clause. It's CVE-2022-1355 I was having problems with.


Script to create a new dataset?

Hi,
I wanted to check if there is any script to create a custom dataset file *.json.gz from a set of code files available in a directory.
If there is some script/method available in the repository, please provide me with the reference for the same.
I am asking for a script because the format of .json file included in the ./data/test_dataset doesn't seem to be json as it is missing "," after every instance of data point.
regards,
Aman

Hi,
It's in jsonl format: each line is in json format and corresponds to a file.
We don't have a script to create the .json.gz files (but we have some instructions on how to get some from BigQuery) but it would be easy to do. Just add your files in "content" and an ID in "repo_name" in format x/y like for github repositories.
Baptiste

Thank you @brozi for you reply. I was confused because in json file entries are separated by a ",". But after checking the sample dataset I was able to figure out the delimiter is "\n".
-Aman


Upgrade pytz to 2016.4

Core dependencies in requirements_all.txt are generated based off setup.py

Thank, wrong way around.


Think about SRU

As a follow-up to #242 :
Software Re-Use (SRU) is listed as a research skill, but it is actually one of the classical key SE/technical skill. Also its description is mainly technical and not very research-specific, so I wonder if it should be moved to the technical skills?

Notifying @annalenalamprecht

phrase it towards research. Possible items:

conflict between efficient reuse and competing implementations for re-use.
conflicts between science funders and researchers, implementors.
better documenting reuse? reproducibility?
abundance of prototype stage software?

"abundance of prototype stage software": A term I really liked here from the discussion was the "EDA (exploratory data analysis)". The emphasis is on the exploration: You are putting together rough tools to do some research, but without even thinking that these tools would ever be reused even by yourself.
Interesting concept as well (suggested by @jngrad): https://de.wikipedia.org/wiki/Bananenprinzip (English page: https://en.wikipedia.org/wiki/Perpetual_beta)

Re-Use has a consumer side-> We address this in technical skills.
Here it is about the consumer side, being researchers.

I tried to bend that more towards "Research Skills": #254.


how to create channels dynamically for one-to-one voice calls?

Hello I am fairly new to this service and not sure if it is the right tool that I should use.
I want to make an app that allows users to make voice call to other individual to have one-to-one chat, but the demo I checked seems to be sharing the same channel for all users, if there a way to create a new channel programmatically when a user wants to call the other one?

hello I am also facing the same issue regarding video call.

you can let different clients join different channels by using different channel IDs.

@AdminBizzfinity @haoyuant you can create a server to generate a token for you. You can use either nodejs or golang for creating a server.
The link below contains the full code along with its explaination for golang server:
https://www.agora.io/en/blog/how-to-build-a-token-server-using-golang/?utm_campaign=build-a-video-call-flutter-app-with-agora&utm_source=youtube&utm_medium=organic-social
The following link is for nodejs server:
https://www.agora.io/en/blog/how-to-build-a-token-server-for-agora-applications-using-nodejs/

Many Thanks @jaypal1046 :)  I think it would be good to have a clearer demo/tutorial for this scenario, looks like many people are also confused when I was searching the solution online.


findobject by name giving null

Type
Other
Operating System
None
OS Version
No response
Bug description

blast furnance
Screenshots or videos
No response
RuneLite version
asd
Logs
No response

Should be fixed on latest dev 98c90124bd5880c7a92d1f6976ba953dd76e17ed


Revert "Scanner pre-73 update (#3477)"

This reverts commit 151fbe9e723afd9afcf03e0730e6b4368a7eedf9.
Description
The gke-upgrade-test is not happy with the scanner change. Try a revert so that it can be fixed out of main. https://issues.redhat.com/browse/ROX-13242
Checklist

[ ] Investigated and inspected CI test results

Testing Performed
CI is sufficient

I see the upgrade tests failing anyway ^. Are we sure this is related to the upgrade tests failing?
I do see
go<EMAIL_ADDRESS>requires
<EMAIL_ADDRESS>invalid version: git ls-remote -q origin in /go/pkg/mod/cache/vcs/490949d4ae5eefdc73aceb001a97037702f10[3052](https://prow.ci.openshift.org/view/gs/origin-ci-test/pr-logs/pull/stackrox_stackrox/3526/pull-ci-stackrox-stackrox-master-gke-upgrade-tests/1583522226085302272#1:build-log.txt%3A3052)66d6ab409726415cbd222ed: exit status 128:
    	fatal: could not read Username for 'https://github.com': terminal prompts disabled
    Confirm the import path was entered correctly.
    If this is a private repository, see https://golang.org/doc/faq#git_https for additional information.
    go: downloading github.com/golang/protobuf v1.4.3
    go: downloading github.com/spf13/cobra v1.1.3
    go: downloading github.com/DataDog/gorocksdb v0.0.0-20200107201226-9722c3a2e063
    go: downloading go.uber.org/atomic v1.7.0
    go<EMAIL_ADDRESS>requires
<EMAIL_ADDRESS>invalid version: git ls-remote -q origin in /go/pkg/mod/cache/vcs/490949d4ae5eefdc73aceb001a97037702f10305266d6ab409726415cbd222ed: exit status 128:
    	fatal: could not read Username for 'https://github.com/': terminal prompts disabled
    Confirm the import path was entered correctly.
    If this is a private repository, see https://golang.org/doc/faq#git_https for additional information.
    Exit: 1

But I can't actually tell if that's the reason these tests are failing. If it is, this doesn't have to do with the SCANNER_VERSION. This would have to do with the Scanner dependency in go.mod

The go fetch error is irritating but benign. The test is trying to dump the central DB to JSON but the error is not fatal.
The test fails because scanImage() fails because scanner is not responding. I'd like to try this again with a rebase after #3507 merges as the initial install in the upgrade test uses helm.

Reverting to the earlier scanner does not fix the issue. Closing.


Docker

:tada: This PR is included in version 2.2.0 :tada:
Your semantic-release bot :package::rocket:


Bug in notebooks/Emukit-Categorical-with-Tensorflow.ipynb

In cell 8 of the notebook Emukit-Categorical-with-Tensorflow.ipynb following line is used:
loop = BayesianOptimizationLoop(rf_model, space)
This causes an error as the constructor of the class BayesianOptimizationLoop in file emukit/bayesian_optimization/loops/bayesian_optimization_loop.py is defined as
class BayesianOptimizationLoop(OuterLoop):     def __init__(self, space: ParameterSpace, model: IModel, ...)
Changing the notebook line to
loop = BayesianOptimizationLoop(space, rf_model) solved the error for me.

I've already created a PR #193 for that

Appears to be fixed in #192


Travis execution inline with webpack/webpack

Bring karma-webpack travis execution inline with webpack core

[ ] Plan & author tests ( help wanted )
[ ] Add linting
[ ] Add coverage generation / reporting via codecov.io

@MikaAK - https://codecov.io/gh/webpack/karma-webpack needs to be enabled by a member with write access.

@d3viant0ne it's enabled now!

Cheers :)


Checksum isn't calculated correctly for all cases.

The sum check goes negative, and the index for the checksum can't be calculated from that point. An example valid code that the game recognizes, but the tool does not is 98888BD with a score of 9,999,000 on Level 2. Indices are 14, 9, 9, 9, 12, X. The sum calculates to 347, causing a negative value. A manual sum comes up to 57 + 56 + 56 + 56 + 56 + 66 = 347. This leads to a negative number: 347 - 390= -43. Somehow the checksum calculation is working in many cases, so there is another factor that is being missed.

The issue has likely been discovered. 347 - 390 = -43, but -43 can also be represented as 0xFF5D. Treating this as an unsigned 16-bit integer, we can continue the calculation. 65493 % 26 = 25, which is the correct index for the checksum character 'D'. Hopefully we get an update and some testing this week.


Slides direction

Hi @eliezerantonio
once again, you have done a nice work. However, I was wondering if it would not be good if we could have vertical and horizontal slides.

hello, it would be really good

sorted out


Something does not make sense here.

Okay...... How to fix then?

Got it fixed. It was Edm dateTime that was the reason for it. (Its easier to use now)
Error is misleading though,


Try harder to Delete Files on Windows

Fixes #25984

Context

on the Windows filesystem, such that if we delete a directory immediately after deleting its contents, the deletion might occasionally fail.
If a DirectoryNotEmptyException occurs when deleting, it may help to wait and try deleting a few more times
Contributor Checklist

[x] Review Contribution Guidelines
[x] Make sure that all commits are signed off to indicate that you agree to the terms of Developer Certificate of Origin.
[x] Make sure all contributed code can be distributed under the terms of the Apache License 2.0, e.g. the code was written by yourself or the original code is licensed under a license compatible to Apache License 2.0.
[x] Check "Allow edit from maintainers" option in pull request so that additional changes can be pushed by Gradle team
[ ] ~Provide integration tests (under <subproject>/src/integTest) to verify changes from a user perspective~
[x] Provide unit tests (under <subproject>/src/test) to verify logic
[ ] ~Update User Guide, DSL Reference, and Javadoc for public-facing changes~
[x] Ensure that tests pass sanity check: ./gradlew sanityCheck
[x] Ensure that tests pass locally: ./gradlew <changed-subproject>:quickTest

Reviewing cheatsheet
Before merging the PR, comments starting with

❌ ❓must be fixed
🤔 💅 should be fixed
💭 may be fixed
🎉 celebrate happy things

@eskatos, Can you review it for me? There's no one assigned here.

@bot-gradle test this

I've triggered the following builds for you. Click here to see all build failures.

PullRequestFeedback build

@bot-gradle test this

I've triggered the following builds for you. Click here to see all build failures.

PullRequestFeedback build

@nodmp, reviewing again I amended your branch with a couple changes:

restore retry in all failure cases, this was an unnecessary behavior change
don't rely on exceptions, given the above this is not necessary and might be more performant

I also refined the GC comment with evidence that it is necessary.

@bot-gradle test this

I've triggered the following builds for you. Click here to see all build failures.

PullRequestFeedback build

I've triggered the following builds for you. Click here to see all build failures.

PullRequestFeedback build

@bot-gradle test this

I've triggered the following builds for you. Click here to see all build failures.

PullRequestFeedback build

I've triggered a build for you. Click here to see all failures if there's any.

Pre-tested commit build failed. Click here to see all build failures.

@bot-gradle test and merge

Your PR is queued. See the queue page for details.

I've triggered a build for you. Click here to see all failures if there's any.


Extend x-fern-streaming functionality

This extends the x-fern-streaming OpenAPI extension syntax so that it lets users define an endpoint that has both a unary and streaming version of the same method, which is distinguished with a boolean property set to true or false, which is beginning to be a common usage pattern seen in several (optionally) streaming APIs.


Add submitted callback.

Sometimes I want to access form data of ignored fields in callback functions. It is not possible at this moment because the saving & saved callbacks are called after the ignore fields are filtered.
I add a submitted callback in this pull request so that we can access the raw data of the ignored fields before they are filtered.

This callback can also solve my problem https://github.com/z-song/laravel-admin/issues/763

Thanks!

@z-song please push submitted callback to official documents. I think it's more helpful for another developer thank you.

Thanks!


tree icons broken

I think the one of them needs to be tree (for the default size), and the smaller dot should be something like tree-s. I think this is only for Walkabout now.

I've committed the assets, fixing the ? icons.
But the tree icons should still be renamed.

renamed

https://github.com/tangrams/walkabout-style/commit/4f7710a760fc5c6d8d1332cd0693f5462b61f3ee

Verified.

(This was changed to tree and tree-s.)


git-create-release-commit bumps all available versions in the components

Closes #516
Expected behavior:

reana-dev git-create-release-commit -c reana command will bump all found version files (Helm, Py, JS, OpenAPI) to its next version

-v will enforce the specified version on all version files (PEP440 will be converted to SemVer2 when needed and vice-versa).

Behavior examples:

reana-dev git-create-release-commit -c reana will automatically bump Helm (SemVer2) and Python (PEP440). For git tags - SemVer2

reana-dev git-create-release-commit -c reana-server will automatically bump Python and OpenAPI (PEP440). For git tags - PEP440

reana-dev git-create-release-commit -c reana -v 0.8.1-alpha.1 will bump Helm to 0.8.1-alpha.1 and Python to 0.8.1a1. For git tags - 0.8.1-alpha.1 (SemVer2)

reana-dev git-create-release-commit -c reana-server -v 0.8.1a1 will bump Python to 0.8.1a1. For git tags - 0.8.1a1 (PEP440)

Manual testing: main changes are in bump_component_version. In git_create_release_commit (git.py), comment everything after bump_component_version statement. After, in reana repo, install update code with pip install -e . Run command and check if all version is properly updated.
After the review, I will squash commits into one.

Codecov Report

Merging #537 (99c0ad3) into master (0414fc1) will increase coverage by 0.05%.
The diff coverage is 29.03%.

@@            Coverage Diff             @@
##           master     #537      +/-   ##
==========================================
+ Coverage   15.00%   15.05%   +0.05%
==========================================
  Files          17       17
  Lines        1533     1534       +1
==========================================
+ Hits          230      231       +1
  Misses       1303     1303

Impacted Files
Coverage Δ

reana/reana_dev/git.py
0.00% <ø> (ø)

reana/reana_dev/utils.py
34.55% <29.03%> (+0.09%)
:arrow_up:

Squashed and rebased on top of master. Ready for merge.