GFX console?

@L-Leite hello. I see that you have implemented Source console. That's nice.
I want to point out that there is already a CSO2 console in game built in GFX file. It is also fully designed and animated. Have you tested it? Does it even work or it was not used by Nexon? I think it can be opened by modifying GFX file or by patching the engine. You can take a look at it if you want to.
Screenshot of GFX: usually scripts that starts with "CSO..." are related to old UI. And there are 2 of them. So I think the console was created for old UI (CSOConsoleApp) and for new UI (systemConsoleApp).

CSOConsole is a debug console for the scaleform UI, it allows you test and profile some UI components with it
you can enable it by editing the P-Code of CSO2UI::setupUI with JPEXS decompiler: move the call to this.uiConsole.fnConsoleOpen(); out of the if(Extensions.isGFxPlayer) statement
it looks like this:

@L-Leite I think this console is perfectly included in the game

@L-Leite First of all, a million thanks for getting this version of the console working. very comfortable and beautiful for my eyes. already leaving the compliments.
seeing what @organnerx posted, would there be the possibility of "converting" the Source console using ScaleformUI? I say this as a possibility to fix the problem that the console is under the UI of CSO2

@Valen7789 I do not think it will worth the amount of time spent on creating a complex thing like this one. It requires both GFX editing and game patching, a really hard thing to do.
@L-Leite Thanks for showing us how that UI console looks like

CSOConsole is a debug console for the scaleform UI, it allows you test and profile some UI components with it
you can enable it by editing the P-Code of CSO2UI::setupUI with JPEXS decompiler: move the call to out of the statement
it looks like this:this.uiConsole.fnConsoleOpen();``if(Extensions.isGFxPlayer)

And how do I need to enable it if I just changed it 0


Symbol/icons support for Polyline

Would it be possible to add support for symbols, ie. to achieve the affect shown below:
https://developers.google.com/maps/documentation/javascript/examples/overlay-symbol-dashed
?

Duplicate: https://github.com/SebastianM/angular2-google-maps/issues/721

Right. Thanks, abalad.


Enforce coding standards

Migrated formatting over to Biome, with linting turned off. Biome is crazy fast…


BubbleWrap house style is using an older version

There is a blue line (country boundary in the water) appearing in the demos. Looking at your code it looks like you're doing everything correctly which means I probably missed a step during cartography release management. Filing this here since we should fix this for the library, but it's probably an upstream / configuration changed fix.

I assume this can be closed with #237  ? @nvkelso ?

Yes, when I load https://mapzen.com/products/maps/ I no longer see the blue line and looking at network traffic on that page I see it's sourcing correctly now from:

https://mapzen.com/carto/bubble-wrap-style/4/bubble-wrap.yaml


adding test for low_power_mode

Pull Request Functional Test Report for #2785 / 1e034da938ebd70d872f0ef1a6361d32866d4dc0
Virtual Devices

Device
Test
Test Documentation
Job
Raw Log

Arista cEOS

TRANSCEIVER-13: Configuration: 400ZR Transceiver Low Power Mode Setting.
f33d31c6
Log

Cisco 8000E

TRANSCEIVER-13: Configuration: 400ZR Transceiver Low Power Mode Setting.
c333a26e
Log

Cisco XRd

TRANSCEIVER-13: Configuration: 400ZR Transceiver Low Power Mode Setting.
3404e1a0
Log

Juniper ncPTX

TRANSCEIVER-13: Configuration: 400ZR Transceiver Low Power Mode Setting.
f8e2c030
Log

Nokia SR Linux

TRANSCEIVER-13: Configuration: 400ZR Transceiver Low Power Mode Setting.
16108c84
Log

Openconfig Lemming

TRANSCEIVER-13: Configuration: 400ZR Transceiver Low Power Mode Setting.
7f253657
Log

Hardware Devices

Device
Test
Test Documentation
Raw Log

Arista 7808

TRANSCEIVER-13: Configuration: 400ZR Transceiver Low Power Mode Setting.

Cisco 8808

TRANSCEIVER-13: Configuration: 400ZR Transceiver Low Power Mode Setting.

Juniper PTX10008

TRANSCEIVER-13: Configuration: 400ZR Transceiver Low Power Mode Setting.

Nokia 7250 IXR-10e

TRANSCEIVER-13: Configuration: 400ZR Transceiver Low Power Mode Setting.

Help

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 54.484%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
1847

Relevant Lines:
3390

💛  - Coveralls


Move all steadystate functions into a dedicated file

I moved the steady state functions to a dedicated file called steadystate.jl to make the code clearer.

Great!


feat(check-group): add method for full selection and reverse selection

背景描述

CheckGroup增加全选/全不选和反选功能 #648
主要改动

CheckGroup增加接口方法toggleAll
toggleAll(true) // 全选
toggleAll(false) // 全不选
toggleAll() // 反选

需要注意

禁用的选项，需保持初始化时的状态，调用toggleAll后不会改变

Codecov Report

Merging #650 into dev will increase coverage by 0.08%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##              dev     #650      +/-   ##
==========================================
+ Coverage   84.47%   84.55%   +0.08%
==========================================
  Files          98       98
  Lines        2776     2791      +15
  Branches      531      539       +8
==========================================
+ Hits         2345     2360      +15
  Misses        287      287
  Partials      144      144

Continue to review full report at Codecov.

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


Take user:admin scope in to account as rootscope during jwt creation

https://github.com/itsyouonline/identityserver/commit/61742e3b833f20979d2f4156f9c1e13820512c4a


Event for tile load queue change on QuadtreePrimitive

This adds a property tileLoadProgressEvent on QuadtreePrimitive (and proxied through Globe) that allows client code to subscribe to changes in the length of the tile load queue. This enables the creation of incremental loading indicators such as the one proposed here:
https://github.com/TerriaJS/terriajs/issues/539

Thanks @AlexGilleran!
@bagnell or @kring can you review this?


Find package by family name and wildcard support

Modified code to enable search by package family name. Also , enabled searching by wildcards(*(match any character) and ?(match single character)).
When packageFullName or packageFamilyName is passed using wildcards, such as,
msixmgr.exe -FindPackage photos,
msixmgr.exe -FindPackage *adplus_8wekyb3d8bbw? (PackageFamilyName using wildcards)
it should return the appropriate results.

add some tests to either (or both) the powershell script or the tests in the test dll.

Also, update the readme.md which serves as our documentation for what wildcards we support and maybe give an example too.

Added tests to the PowerShell script for FindPackageByFullName, FindPackageByFamilyName, FindPackageByFullName with wildcards, FindPackageByFamilyName with wildcards and FindPackage returns No Packages found cases.

Updated ReadMe with explanation and examples.


Mocking cf context don't works

What version of Hono are you using?
hono
What runtime/platform is your app running on?
Bun with Vitest for testing
What steps can reproduce the bug?
Simple repro repository
https://github.com/MatteoGauthier/hono-repro-context-cf-mock
bun test:ui

What is the expected behavior?
Using this syntax
    const req = new Request(`http://localhost/context`, {
      cf: {
        timezone: "Europe/Paris",
      },
    })

    const res = await app.request(req, {})

It should be possible to mock the ctx.raw.cf
What do you see instead?
undefined
Additional information
No response

Hi @MatteoGauthier
This is not a Hono-side issue, but you can refer to this implementation: https://github.com/honojs/vite-plugins/blob/main/packages/dev-server/src/adapter/cloudflare.ts#L31-L40


Add error output to enable backups page

If you disable and then re-enable backups, the API tells you to wait 24 hours before enabling, but the manager doesn't report this back to the user.

It would be more useful if we could just not show the button if they weren't allow to press it.

True


fix: handle emptylines for languages with semantic whitespace

fixes: https://github.com/getgrit/gritql/issues/84
lines containing only whitespace will be rewritten as empty lines

Summary by CodeRabbit

Refactor

Improved modularity and readability of range adjustments in code.

Tests

Added tests for Python support with empty lines in code snippets.

I'm not sure we actually want to do this. The root cause of that issue looked like a problem in Monaco, not anything in GritQL.

I'm not sure we actually want to do this. The root cause of that issue looked like a problem in Monaco, not anything in GritQL.

the code is valid regardless of the whitespace on the empty line, I ran the python. I'm sure people have empty lines in their codebases in the middle of a code block I don't see why we shouldn't support that.


WIP: Changes to help reason about how idle time works

Jesse,
This is not intended for submission and is against branch 2.7: I want to check a few things with you. I found the ConnectionPool / StreamAllocation / RealConnection arrangement in 2.7 hard to reason about. Apparently there is a bug in the OkHttp on N (~2.5) due to the use of Long.MAX_VALUE to initialize the old equivalent of idleAtNanos.
The arithmetic to work out whether a connection was idle would fail if System.nanoTime() returned a value > 0 and < keepAliveNanos. Generally I think the use of any absolute "can never happen" or "in far future" timestamp is probably bogus when dealing with nanoTime(): no guarantees about sign or magnitude, only really useful for elapsed time or ordering comparisons.
I believe that bug has gone away with subsequent commits which now check whether but I found it hard to prove to myself. This change includes additional docs and assertions. Do you agree with them?
It's possible that streamCount should also be guarded by the connection pool monitor, though that's not currently the case.
Not sure if an equivalent change would transfer to OkHttp 3: a lot of it looks similar.
(Ignore the pom.xml change too)

Wanna submit a PR to master?

PR for master: https://github.com/square/okhttp/pull/2763


Unhandled pattern matching in delete_from_session_list/4

Hi, I recently received exception in delete_from_session_list/4 function: https://github.com/danschultzer/pow/blob/c0c68e9c32e1e42b455710417e67c33972c2cc4e/lib/pow/store/credentials_cache.ex#L114
It seems like in this case we assume that Base.get(config, backend_config, key) will return a map with the user key. In my case, it returned :not_found, which is one of the possible return values https://github.com/danschultzer/pow/blob/c0c68e9c32e1e42b455710417e67c33972c2cc4e/lib/pow/store/credentials_cache.ex#L99
I'm using the master branch from this repo.

Oh, right, this exception highlights the weakness of the current setup in master. It really should be that keys can only be inserted or deleted, not updated.
The custom logic in the credentials cache wasn't used before I fixed it in #286, so I'm taking this opportunity to also make the cache store more efficient and Erlang friendly using match specs.
I'm refactoring the whole cache store setup that I will try to finish before releasing v1.1.14: https://github.com/danschultzer/pow/compare/refactor-credentials-cache
It's a pretty heavy PR though, but I think it'll be worth it. It should be working out of the box if you're using ETS or Mnesia, but I'm working on keeping it backwards compatible so custom implementations like Redis cache will still work.
Since this bug only exists in master I think I'll wait till I can merge in the cache refactor rather than trying to fix the current setup.

Fixed in master

Thanks, @danschultzer!


Update in-process-server-threading-issues.md

fix a broken comma

@David-Zhiyuan-Zhu : Thanks for your contribution! The author(s) have been notified to review your proposed change.

@mcleanbyron : Thanks for your contribution! The author(s) have been notified to review your proposed change.


FIREBREAK:  🔥 Rebuild of the acronyms service

Background
The acronyms service has been made unavailable because the website was hosting information that poses a reputational risk to the MOJ department and Corporate comms requested this service to be taken down.
Since then, some MOJ employees were asking via slack why the service is unavailable.
Questions / Assumptions

Can we set up acronyms service as a Flask app that allows users to add new acronyms
Can we store acronyms in a simple DB
Can we add a search functionality to look up acronyms
Can we add sentiment analysis to validate acronyms to ensure that users submit acronyms with a neutral sentiment, rejecting any potentially offensive or negative entries.

What hypothesis do we want to test?/What do we want to learn?
Can we automatically validate acronyms based on sentiment analysis and only allow those that convey neutral sentiments
Definition of done

[ ] New repository with flask app created
[ ] Flask app created with main view and add-acronyms endpoints
[ ] Basic templates added (main_acronyms_view, create_acronym_form)
[ ] DB service to store the data added and data migrated
[ ] Sentiment analysis service added to reject inappropriate acronyms
[ ] Validation for the create_acronym_validation implemented
[ ] Demo completed
[ ] Decision made on whether to progress Firebreak work
[ ] Does next steps require User Research?


Question on installation

I think I must be doing something wrong here, I can't get validate-commit-msg to run.
The relevant bits of my package.json are;
{
  "config": {
    "commitizen": {
      "path": "./node_modules/cz-conventional-changelog"
    },
    "ghooks": {
      "commit-msg": "validate-commit-msg",
      "pre-commit": "fixpack && npm run lint && npm test"
    },
    "validate-commit-msg": {
      "types": [
        "feat",
        "fix",
        "docs",
        "style",
        "refactor",
        "perf",
        "test",
        "chore",
        "revert"
      ],
      "warnOnFail": false,
      "maxSubjectLength": 100
    }
  },
  "devDependencies": {
    "cz-conventional-changelog": "1.1.5",
    "ghooks": "1.0.3",
    "validate-commit-msg": "2.1.0"
  },
}

I run npm install etc and example usage is;
touch temp.txt
git add .
git commit -m "this message should fail validation"

I'd expect the validator to throw, but nothing happens. I added;
console.log('hello from validate-commit-msg');
process.exit(1)

to the top of node_modules/validate-commit-msg/index.js to be sure, but this doesn't appear. While in there I noticed;
/**
 * Git COMMIT-MSG hook for validating commit message
 * See https://docs.google.com/document/d/1rk04jEuGfk9kYzfqCuOlPTSJw3hEDZJTBN5E5f1SALo/edit
 *
 * Installation:
 * >> cd <angular-repo>
 * >> ln -s ../../validate-commit-msg.js .git/hooks/commit-msg
 */

Am I just missing this installation step? I'm expecting though that ghooks would be handling this part.
Again, pretty sure I'm doing something wrong — can anyone help?
Thanks.
Jamie / @fold_left

Hmmm... That comment is dated and should be removed. ghooks should install the commit hook for you. My guess is that it's a ghooks issue. Does your pre-commit hook run?

Thanks @kentcdodds, I created an isolated test case which does work — so something else is going on in my setup.
Closing, thanks for your help :+1:


Fixed heavy CPU usage due to byte array allocation

Moved fullBuffer byte array allocation to outside of the loop. If it's
in the loop, CLR Garbage Collector runs too frequently and causes high
CPU usage (even intermittent freezes). In my case, I was using
BinaryBufferSize of 81920 (80KB). With this fix, the new sequence finder
algorithm can work at full speed (12x-14x faster than old algorithm)

Thanks for taking the time to investigate the issue. I'm glad you're seeing such great speed improvements!

You are welcome, just a note though. I think we should also replace fullBuffer.Length references in the loop with a new variable fullLength (see new commit 988d94e5c930adeb3e882dc5c3d2f75109c6e58d)


OAuth2Helper does not provide PUT and PATCH requests

Issue
Currently, the OAuth helper does not provide PUT and PATCH requests. I think it would be nice to add support for those (and possibly also for OPTIONS, HEAD and TRACE).
Solution
This would be a very simple non-breaking change, as the post() method could basically be copied for PUT and PATCH. I currently extend the helper by only adding put() and patch() that are basically identical to post(), but I think it would be better to include those in the OAuth2Helper.
Any thoughts or am I overlooking a reason not to add this? Otherwise I'll make a PR soon.

Hi @DeD1rk, I just added the PUT, PATCH and HEAD methods to the helper class (and refactored it a bit...).
Can you check it out?
Thank you

Hey @okrad, that looks perfect! Also nicely refactored. Thank you!


Sigh: authentication.failed Your session has expired.  Please log in.

New Issue Checklist

[x] Updated fastlane to the latest version
[x] I have read the Contribution Guidelines

Issue Description
When running sigh to download_all my certificates I get this error.
osx:drivemode jan$ sigh download_all --verbose
INFO [2016-06-02 17:22:06.59]: Starting login with user<EMAIL_ADDRESS>/Library/Ruby/Gems/2.0.0/gems/spaceship-0.27.1/lib/spaceship/client.rb:432:in `parse_response': [!] Apple provided the following error info: (Spaceship::Client::UnexpectedResponse)
	authentication.failed
	Your session has expired.  Please log in.
	from /Library/Ruby/Gems/2.0.0/gems/spaceship-0.27.1/lib/spaceship/portal/portal_client.rb:51:in `teams'
	from /Library/Ruby/Gems/2.0.0/gems/spaceship-0.27.1/lib/spaceship/portal/ui/select_team.rb:35:in `select_team'
	from /Library/Ruby/Gems/2.0.0/gems/spaceship-0.27.1/lib/spaceship/portal/portal_client.rb:67:in `select_team'
	from /Library/Ruby/Gems/2.0.0/gems/spaceship-0.27.1/lib/spaceship/portal/spaceship.rb:37:in `select_team'
	from /Library/Ruby/Gems/2.0.0/gems/spaceship-0.27.1/lib/spaceship/portal/spaceship.rb:81:in `select_team'
	from /Library/Ruby/Gems/2.0.0/gems/sigh-1.8.0/lib/sigh/download_all.rb:7:in `download_all'
	from /Library/Ruby/Gems/2.0.0/gems/sigh-1.8.0/lib/sigh/manager.rb:34:in `download_all'
	from /Library/Ruby/Gems/2.0.0/gems/sigh-1.8.0/bin/sigh:45:in `block (2 levels) in run'
	from /Library/Ruby/Gems/2.0.0/gems/commander-4.3.5/lib/commander/command.rb:178:in `call'
	from /Library/Ruby/Gems/2.0.0/gems/commander-4.3.5/lib/commander/command.rb:178:in `call'
	from /Library/Ruby/Gems/2.0.0/gems/commander-4.3.5/lib/commander/command.rb:153:in `run'
	from /Library/Ruby/Gems/2.0.0/gems/commander-4.3.5/lib/commander/runner.rb:428:in `run_active_command'
	from /Library/Ruby/Gems/2.0.0/gems/fastlane_core-0.46.2/lib/fastlane_core/ui/fastlane_runner.rb:26:in `run!'
	from /Library/Ruby/Gems/2.0.0/gems/commander-4.3.5/lib/commander/delegates.rb:15:in `run!'
	from /Library/Ruby/Gems/2.0.0/gems/sigh-1.8.0/bin/sigh:99:in `run'
	from /Library/Ruby/Gems/2.0.0/gems/sigh-1.8.0/bin/sigh:117:in `<top (required)>'
	from /usr/local/bin/sigh:23:in `load'
	from /usr/local/bin/sigh:23:in `<main>'

It was working a couple of hours ago. I saw other tickets (old ones) that mentioned it got fixed by itself after a while. Like it was an Apple issue. Just wondering if this is the case or I did something wrong.
Configuration Files
Please copy the complete content of your Fastfile and any other configuration files you use below:
Fastfile:
No Fastfile. Just plain old sigh

Environment
fastlane version (run fastlane -v): fastlane 1.93.1
Do you use bundler to execute fastlane (i.e. bundle exec fastlane)? no
Do you use a Ruby environment manager (e.g. chruby, rbenv, rvm)? no

This might be related to http://techcrunch.com/2016/06/02/apple-app-store-goes-down/, let's try again later today 👍

FWIW, we are experiencing this exact same symptom in out CI system, which uses sigh to download provisioning profiles.
[12:47:43][Step 1/1] [!] Apple provided the following error info:
[12:47:43][Step 1/1] 	authentication.failed
[12:47:43][Step 1/1] 	Your session has expired.  Please log in.

We have confirmed that the credentials are valid, when typed in manually on developer.apple.com.

I need to remember to keep checking this page: https://www.apple.com/support/systemstatus/
Several service were down yesterday on that page.
Everything seems to be back to normal now and sigh is working fine again. Thanks Felix for that techcrunch link!


[Logs] Use syslog NILVALUE instead of blank when no structured data is defined

What does this PR do?
Replace tags by - in raw encoder when none are defined.
Motivation
Enable JSON payload to be parsed when no service and no tags are set.

@ajacquemot thanks! Could you provide more details on why we're doing that? For instance, an example of payload with tags, without tags, and what the issue is with JSON?


cma=64M in /boot/cmdline.txt causes libcamera-apps to fail for full resolution image capture

Is there any need to set cma=64M in /boot/cmdline.txt by default any more given that it causes libcamera-apps to fail for full resolution image capture?
https://github.com/agherzan/meta-raspberrypi/blob/c57b464b88769c1336695e48e1eb8f35e258b9ae/recipes-bsp/bootfiles/rpi-cmdline.bb#L16

@tewarid We would need to dig a bit into history to figure that out. I'm not using the camera directly so I haven't checked it out. Are you able to dig a bit into it?

@agherzan Thanks - will do that.

This was added by 8827040d9c218f68ae3ee6a5814929888ed61581 and hasn't been changed since. It sets cma=64M value when RASPBERRYPI_CAMERA_V2 = "1".
Raspberry Pi camera docs and cmdline.txt docs do not mention cma, so whatever the historical reason was to use that particular value no longer seems relevant.
The default cma values in kernel are way higher than the value specified in cmdline.txt
cat /proc/meminfo | grep -i cma
CmaTotal:         262144 kB
CmaFree:          242468 kB

Looks like we can let the kernel handle cma.


[BUG]

Describe the bug
Getting an error in Logic Apps when NumberOfSeats parameter is null. The parse action of the subscription object fails
To Reproduce
Steps to reproduce the behavior:

Create a standard from with a flat fee pricing model
Run the live purchase or cancellation flow (not in test mode)

Expected behavior
The Logic App should run normally and perform any added action
Desktop

OS: Windows
Browser: Edge

Closed by PR. Well done, @dickdijkstra1980!


Put timestamps on event queue

The confirmation planner needs to know at what time events happened. Block numbers are not enough for this as they can't be compared across different chains. We also need to know about the absence of events. It seems natural to put this information on the event queue.
Technically, events don't have a timestamps, but the blocks in which they were raised have. In web3.py we can access this with something like w3.eth.getBlock(event.blockHash).timestamp (note that all events in a block share the same timestamp).
It's probably a good idea to only put objects of a single type on the event queue to avoid confusion.
One approach would be to transform the event_queue to an event_batch_queue and define batch as a tuple of a timestamp and a list of events (the idea being to group all events from a single block in one batch):
class EventBatch(NamedTuple):
    timestamp: int
    events: List[dict]

An alternative would be to define use "artificial" events that only contain a timestamp and no actual event:
class MaybeEvent(NamedTuple):
    timestamp: int
    event: Optional[dict]

The confirmation planner needs to know at what time events happened. Block numbers are not enough for this as they can't be compared across different chains

Why? I can think of a solution that doesn't need a timestamp.

See #272 to related discussion

After discussion we've decided to ignore event timestamps for simplicity.


vehicle_global_position remove redundant data

Split from https://github.com/PX4/Firmware/pull/8234

Once https://github.com/PX4/Firmware/pull/8234 is in this will be rebased.
Should we also remove...

vel_n/vel_e/vel_d

most consumers just use this to calculate ground speed, perhaps we should publish that instead

yaw

duplicate of local position yaw

pressure_alt

why not use sensor_baro directly?

dead_reckoning

unused

Sensor baro is a direct measurement at a data rate and latency not suitable for feedback control whereas pressure_alt is an estimated quantity at a higher rate using fusion with inertial data and suitable for use in flight controllers. In aviation it  is normally the height above sea level assuming an ISA atmosphere model with ATC specified sea level pressure (QNH). However is is not useful the moment because:

At the moment estimators currently set it to the raw sensor data so it cannot be used for flight control, only monitoring.
There is no means of adjusting the assumed sea level pressure, so the altitude reported is not compatible with ATC requirements.

These two issues will eventually need to be addressed for future use in controlled airspace, but at the moment I agree with removing pressure_alt from this topic.

Bug for QNH usage - https://github.com/PX4/Firmware/issues/8252

I would keep the the velocities (vel_n/vel_e/vel_d) and not just use the magnitude of the ground speed. In post processing I am actually using these values and you cannot reconstruct them from just the ground speed magnitude.

@acfloria The vehicle_global_position velocity is copied from vehicle_local_position velocity vx/vy/vz. They're both filled in the same spot of the EKF, published at the time same, and then both logged.
This case is minor, but I'm trying to get rid of as much unnecessary duplication as possible.

Closing as stale. Some of this has already been merged in separate smaller PRs.


[sw] Mark libbase-implemented libc symbols as weak

NOTE: "symbol" here means linker symbol, so it only applies to the names of global variables (not enums!) and functions.
Right now libbase provides a handful of linker symbols that are reserved by C11 for libc. Nominally, this is fine, since OpenTitan device builds don't link in a libc. However, lots of device code is built on amd64, for testing and fuzzing purposes. This hasn't been an issue, since DIFs are super bare-bones, but it probably will be an issue once we start dealing with fuzzing parts of boot_rom2, which relies on logging and memory operations.
I want to propose the following policy to try to preemptively avoid linker errors:

All libc symbols in libbase must be marked as __attribute__((weak)). This is stuff like memcpy.
All libc symbols in libbase which do not exactly satisfy the C11 standard must be given another name, such as prepending base_. For example, base_printf. (I have already been tacitly doing this.)

For device builds, this should have no effect, as long as no one is naughty and tries to override reserved symbols. For amd64 host builds, this means we might not use especially tuned constant-time versions of things, but tests and fuzzing are not sensitive to side channels or performance.
If we do this, I want to see whether it's worth it to have dedicated macros in a libbase header for attributes like weak, align, and so on. If anything, it lets us have our own local documentation for them and what we explicitly expect them to do and what we use them for, rather than whatever potentially inadequate or architecture agnostic documentation GCC has. We already do this for asm, at any rate.

@lenary I especially want to hear your thoughts on this.

NOTE: "symbol" here means linker symbol, so it only applies to the names of global variables (not enums!) and functions.
Right now libbase provides a handful of linker symbols that are reserved by C11 for libc. Nominally, this is fine, since OpenTitan device builds don't link in a libc. However, lots of device code is built on amd64, for testing and fuzzing purposes. This hasn't been an issue, since DIFs are super bare-bones, but it probably will be an issue once we start dealing with fuzzing parts of boot_rom2, which relies on logging and memory operations.
I want to propose the following policy to try to preemptively avoid linker errors:

All libc symbols in libbase must be marked as __attribute__((weak)). This is stuff like memcpy.

Is this to prevent code that was built against the libbase stuff from having conflicts with system-provided symbols of the same name?  And doesn't weak symbols not help for things that are forced inline?

All libc symbols in libbase which do not exactly satisfy the C11 standard must be given another name, such as prepending base_. For example, base_printf. (I have already been tacitly doing this.)

For device builds, this should have no effect, as long as no one is naughty and tries to override reserved symbols. For amd64 host builds, this means we might not use especially tuned constant-time versions of things, but tests and fuzzing are not sensitive to side channels or performance.
If we do this, I want to see whether it's worth it to have dedicated macros in a libbase header for attributes like weak, align, and so on. If anything, it lets us have our own local documentation for them and what we explicitly expect them to do and what we use them for, rather than whatever potentially inadequate or architecture agnostic documentation GCC has. We already do this for asm, at any rate.

@gkelly Yes, avoiding conflicts with the system libc is the main concern. For memcpy and friends, inlining doesn't matter: LLVM always assumes that it is a pure function. I don't think we have any libc symbols marked inline right now?

@lenary suggested that we should instead #ifdef away the symbol definitions based on a HOST_BUILD macro (which could be implemented in terms of the __riscv macro).
I think this is actually the better approach, because now we get linker errors if we're missing a libc on host builds. Thoughts?

@lenary suggested that we should instead #ifdef away the symbol definitions based on a HOST_BUILD macro (which could be implemented in terms of the __riscv macro).
I think this is actually the better approach, because now we get linker errors if we're missing a libc on host builds. Thoughts?

I don't like defining HOST_BUILD in terms of __riscv, it might be right for now but isn't correct in the general case.  Can't we just inject that in the build?

I don't like defining HOST_BUILD in terms of __riscv, it might be right for now but isn't correct in the general case. Can't we just inject that in the build?

Oh actually yeah we can. We can add is as a global -D for native: true.

Nice, I think we all agree that the preprocessor is going to give a better experience than weak symbols for the former issue.
With regards to the latter issue about naming - I have been trying to ensure that we don't use standardised names when we're not implementing standard features - I suppose printf is the one I missed there.  Sometimes this has been lost in subsequent changes (for instance, the function that at one point was called busy_wait or something, which is now back to usleep), but I think we'll get there. This is the sort of thing that I think might need to go into doxygen comments so it is not lost when someone decides to fix/refactor.
As to a dedicated attributes header… we decided against this in the past for individual attributes. I can see there being a good reason to do it for specific groups of attributes, but given we're not going to use __attribute__((weak)) any more, I'm not sure we need this attributes header.


no notification or warning when Docker engine is running low on disk space

Background & motivation
When using Kurtosis locally, the size of my systems tend to be quite large (due to complexity of distributed systems) and when I unexpectedly hit resource limits, I get hard-to-debug errors like:
ERROR[10-27|23:31:21.451] Low disk space.  The instruction can be found at github.com/kurtosis-tech/ethereum-package/src/cl/lighthouse/lighthouse_launcher.star[149:38]
        Caused by: service 'cl-04-lighthouse-geth' requires '256' megabytes of memory but based on our calculation we will only have '174' megabytes available at the time we start the service

This has happened a few times to myself and other users!
Reference:

https://github.com/kurtosis-tech/kurtosis-private/issues/132
https://github.com/kurtosis-tech/kurtosis-private/issues/99
https://discord.com/channels/783719264308953108/1166027977839083530/1168861074162995201
https://discord.com/channels/783719264308953108/1160976910654902397/1166102632474091530

Desired behaviour
Kurtosis warns the user in the terminal (and local EM UI) when the Docker engine is approaching the limit of its available disk space.
Something like:
Docker is nearly out of disk space, which may cause deployments to fail! (95% of capacity)

Implementation wise, I would love for this to be a one-off check each time I run a package at validation/interpretation time (before execution).
How important is this to you?
Nice to have; this feature would make using Kurtosis more enjoyable.
What area of the product does this pertain to?
CLI: the Command Line Interface

On Nov 2, we talked to Nethermind team & they told us that they have experienced this issue multiple times and have built a guard rail around this in their wrapper. Sounds like people are silently hit with Disk Usage issues and attribute that to Kurtosis instability.


@conda-forge-admin,please add bot automerge

[x] I read the conda-forge documentation and could not find the solution for my problem there.

Issue:

Environment (conda list):

$ conda list

Details about  conda and system ( conda info ):

$ conda info

Hi! This is the friendly automated conda-forge-webservice.
I just wanted to let you know that I added bot automerge in conda-forge/parameterized-feedstock#11.

Hi! This is the friendly automated conda-forge-webservice.
I just wanted to let you know that I added bot automerge in conda-forge/parameterized-feedstock#11.


[Feature] Explore CC Header is sliding upon other elements

Description
The Explore CC header on the resources.creativecommons.org page is not styled in the similar way as on creativecommons.org page. On Resources page the header is sliding upon other elements below it, and this behaviour is different from that on creativecommons.org page, where, the sliding down of the header moves down all elements below it. The behaviour and stylings of this Header should be uniform across all web pages of Creative Commons.
Screenshots
resources.creativecommons.org

creativecommons.org

To Reproduce

Visit  resources.creativecommons.org and click on Explore CC button.
Observe the sliding behaviour.
Visit creativecommons.org and click on Explore CC button.
Observe the sliding behaviour.

Alternatives
The header's position could simply be changed from position: absolute to position: relative for the required behaviour along with changings in some other properties. For uniformity some additional stylings could also be changed e.g. Font Size.
Implementation

[x] I would be interested in implementing this feature.

Hi! @possumbilities i created this issue to improve a minor detail, let me know if you think it needs to be improved

Thanks @possumbilities, I will create a PR as soon as possible

I have made the changes, please review this PR. Thankyou

Hi @possumbilities, I created the PR #209 for this issue. Can you please review it, if it resolves the issue?


storage/gcsupload: don't close client and return handles

Handles aren't valid once the client is closed.
See: https://code-review.googlesource.com/16950

PS: I couldn't merge early because the CI hadn't run yet, but thanks for doing that ;)


Unknown Contrast Agent in BIDS

Hello,
We (@adhusch, @MeryemABBAD) are trying to convert several datasets from DICOM to the BIDS format. There are some datasets which use a contrast agent but it's not clear which one was used.
There is the ContrastBolusIngredient field in the meta-data but the documentation states that "Allowed values: IODINE, GADOLINIUM, CARBON DIOXIDE, BARIUM, XENON". Secondly there is the ceagend entity but the documentation states that it represents the ContrastBolusIngredient field. We assume that by using "ce: True" and "ContrastBolusIngredient: UNKNOWN" the dataset would not comply with BIDS anymore. How does BIDS handle these cases?
Thanks!

How does BIDS handle these cases?

I don't think we have to face the issue yet. So this is a first one.
I tested on one of the bids example with some dummy values (see below) and it seems that the validator does not catch those issues... Yet.
Once the validator starts on the schema, those may get flagged as errors
ds001/sub-01
├── anat
│   ├── sub-01_ce-foo_T1w.json
│   ├── sub-01_ce-foo_T1w.nii.gz
│   └── sub-01_inplaneT2.nii.gz

$ cat ds001/sub-01/anat/sub-01_ce-foo_T1w.json

{"ContrastBolusIngredient": "foo"}

Thanks for you answer!
So, if I understand you correctly then this would not be a future-proof way of indicating the contrast agent. Is there a better way to include the information about the contrast agent without (potentially) loosing bids validity in the future?

Maybe adding an "unknown" case in the specification would make sense here. I definitely would not be opposed to it.
@effigies what do you think?

Seems like there's a legitimate use case, so we should support it. Also seems like there should be a none value, to distinguish scans with/without in studies that have both.

Thanks for your help, including these options in the specification would be great!

This is what the new metadata definition would look like:
https://bids-specification--1547.org.readthedocs.build/en/1547/glossary.html#contrastbolusingredient-metadata

those agents are constrained by the DICOM standard (same as PET)

given the list: changes are

barium --> Barium Sulfate
iodine -- well there are many variations just iodine does not look correct
xenon does not look supported ? where is this coming from
none -- fine
UNKNOWN -> contrast agent (there is such a general term in the list)

as a practical matter, I suggest to make a list (json to yml) with explicit reference to DICOM and validated checking values in there


Flash interface parameters

Main changes:

Add Flash information in scripts/Kconfig
So these settings are already known when the card is selected. This step is important because we are still going to add AD9V3, FX609 and Semptian N241 card into this project later.

Please review the selections in following:
+config FLASH_INTERFACE
+        string
+        default "BPIx16" if S121B_BPIx16 || N250S || N250SP || ADKU3 || AD8K5
+        default "SPIx4"  if S121B_SPIx4
+        default "SPIx8"  if RCXVUP
+
+#FLASH_SIZE: in MB, will be used by build_mcs.tcl
+config FLASH_SIZE
+        string
+        default 256 if S121B_SPIx4  || RCXVUP
+        default 128 if S121B_BPIx16 || N250SP || AD8K5 || ADKU3
+        default 64  if N250S
+
+#FLASH_USERADDR: For BPIx16, it is two-bytes address;
+#                For SPI, it is byte address.
+config FLASH_USERADDR
+        string
+        default 0x01000000 if N250S || ADKU3
+        default 0x02000000 if S121B_BPIx16 || AD8K5 || N250SP
+        default 0x08000000 if S121B_SPIx4 || RCXVUP

The second change is to put snap_bitstreams_pre.tcl into each $FPGACARD folder.
 block in one single file.

Updated all S121B defconfigs to S121B_BPIx16 defconfigs:
for f in defconfig/S121B*.defconfig; do fn=basename $f; echo "S121B_BPIx16=y" >> $f; echo yes "" | make $fn; cp -p .snap_config $f ; done

I updated all defconfigs to reflect the latest script/Kconfig changes.
Furthermore I added S121B_BPIx16.*.defconfig and S121B_SPIx4.*.defconfig files, and changed S121B.*.defconfig files to specify the SPIx4 version of the Semptian card.
Triggering the tests now...

Tests for S121B failed. Investigating...

Closing this pull request due to conflicts. I'll rebase the branch and create a new pull request based on the rebased branch...


Undefined method default? for String

class StrictUser < Dry::Types::Struct
  constructor_type(:strict)

  attribute :name, 'strict.string'
  attribute :gender, Dry::Types['strict.string'].default('male')
end

StrictUser.new # => #<NoMethodError: undefined method `default?' for "strict.string":String>

works if you replace strict.string with Dry::Types['strict.string']

For the record this should raise an argument error.

This issue was moved to dry-rb/dry-struct#11


Bug while applying wallpaper

While setting wallpaper from within the app or otherwise, not only is the wallpaper not set (only a black screen) but also the wallpaper is only seen as long as the screen is tapped. Hence there is a glitch like effect.

I am sorry but I can't reproduce the issue. Since you are running a custom rom and xposed its possible the issue is related to that.


Help with another loss function

Hi @jiangqy,
I am trying to test your model with another loss function for the NUSWIDE dataset, the BCEWithLogitsLoss, however I'm having problem with the size of the input and of the labels. It's giving this error:
ValueError: Target size (torch.Size([64, 21])) must be the same as input size (torch.Size([64, 12]))
I do not understand why the input and the labels should be the same size. Can you help me?

@josianerodrigues I don't understand your problem. You want to use BCEWithLogitsLoss for pairwise similarity (S_{ij}) or label similarity (L_i)?
If you mean pairwise similarity, the size of supervised info. should be batch_size x batch_size, i.e., 64 x 64. If you mean label similarity,  the size of supervised info should be batch_size x #label, i.e., 64 x 21. However, i think you should use MultiLabelSoftMarginLoss rather than BCEWithLogitsLoss.
And the size of output depends on your task.

Sorry, I confused the functions. But I tested the MultiLabelSoftMarginLoss function and got the same error.
ValueError: Target and input must have the same number of elements. target nelement (735) != input nelement (420)

@josianerodrigues I think it based on your goal.
If you want to use binary code as features for multi-label classification task, you should add a layer to project binary code to label space.
Or if you just want to utilize binary code to approximate class label directly, you should change the binary code length as 21 for NUS-WIDE (And set u=2b-1 to constrain the code in {0, 1}). But this strategy seems unreasonable.

Thank you, @jiangqy.

Hi @jiangqy,
Could you please make your model implementation available to the MS-COCO dataset?


Cannot compile some schemas in v1.5

When attempting to compile some schemas, the following stack trace is encountered:
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.5/dist-packages/fastjsonschema/__init__.py", line 80, in compile
    resolver = RefResolver.from_schema(definition, handlers=handlers)
  File "/usr/local/lib/python3.5/dist-packages/fastjsonschema/ref_resolver.py", line 109, in from_schema
    return cls(schema.get('id', ''), schema, handlers=handlers, **kwargs)
  File "/usr/local/lib/python3.5/dist-packages/fastjsonschema/ref_resolver.py", line 98, in __init__
    self.walk(schema)
  File "/usr/local/lib/python3.5/dist-packages/fastjsonschema/ref_resolver.py", line 180, in walk
    self.walk(item)
  File "/usr/local/lib/python3.5/dist-packages/fastjsonschema/ref_resolver.py", line 173, in walk
    self.store[normalize(self.resolution_scope)] = node
  File "/usr/local/lib/python3.5/dist-packages/fastjsonschema/ref_resolver.py", line 45, in normalize
    return urlparse.urlsplit(uri).geturl()
  File "/usr/lib/python3.5/urllib/parse.py", line 328, in urlsplit
    url, scheme, _coerce_result = _coerce_args(url, scheme)
  File "/usr/lib/python3.5/urllib/parse.py", line 115, in _coerce_args
    return _decode_args(args) + (_encode_result,)
  File "/usr/lib/python3.5/urllib/parse.py", line 99, in _decode_args
    return tuple(x.decode(encoding, errors) if x else '' for x in args)
  File "/usr/lib/python3.5/urllib/parse.py", line 99, in <genexpr>
    return tuple(x.decode(encoding, errors) if x else '' for x in args)
AttributeError: 'dict' object has no attribute 'decode'

...I am still trying to get more information about the schemas that cause this.
Example code to trigger problem:
import fastjsonschema
schema = {
  "type": "object",
  "properties": {
    "id": {"type": "integer"}
  }
}
fastjsonschema.compile(schema)

This appears to be introduced in 1.5; not encountered in 1.4.

Thanks for report!
RefResolver bug: It tries to use 'id' property for URI resolution, even it is not actual schema 'id'.
I will commit a fix...

Fix by @Jokipii merged. Will release it later today.

Thanks!


Remove spaces from test bundle identifiers

Bug/issue #, if applicable: rdar://94811638
Summary
Removes spaces from the bundle identifiers using in Swift-DocC tests to work around a bug in macOS Ventura Beta 1 (94747378).
Dependencies
None.
Testing
N/A, not a user facing change.
Checklist

[x] Added tests
[x] Ran the ./bin/test script and it succeeded
[x] Updated documentation if necessary

@swift-ci please test

Should we add an XCTSkip'd test somewhere that is testing this? So we know if this regresses again in the future? (Unclear to me if having spaces in a bundle ID is supported or not)

Given the URL RFC, I think we should actually treat bundle identifiers with spaces as invalid. The bug here is that DocC currently accepts them but shouldn't. I filed https://github.com/apple/swift-docc/issues/290

@swift-ci please test


Add draconic essence drops

Add drops of draconic essences to hard / very hard main story quests.
The visual indicator of the number of essence available is driven by quest_list[].daily_play_count, which we already handle correctly in QuestService.ProcessQuestCompletion. So the only change that needs to be made is checking whether the quest drops essence, and whether our play count is low enough, and then granting it.

Note: I wondered if the daily reset mechanism inside ProcessQuestCompletion needed to be done inside an IDailyResetAction instead, so that players could see the correct number of essences before it gets reset by clearing a quest. However, it looks like the game handles this by using the LastDailyResetTime :)


Tracing Spans of RPCs should follow otel semantic conventions

A first set of patches to bring our implementation around to the conventions as described. Focuses primarily on spans from HTable and a couple other connection-level methods. Applicable reference is https://github.com/open-telemetry/opentelemetry-specification/blob/3e380e2/specification/trace/semantic_conventions/database.md

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
1m  0s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s
No case conflicting files found.

+1 :green_heart:
hbaseanti
0m  0s
Patch does not have any anti-patterns.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

_ master Compile Tests _

+0 :ok:
mvndep
0m 15s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
4m 26s
master passed

+1 :green_heart:
compile
5m  3s
master passed

+1 :green_heart:
checkstyle
2m  6s
master passed

+1 :green_heart:
spotbugs
4m  4s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 13s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
4m 15s
the patch passed

+1 :green_heart:
compile
5m  1s
the patch passed

+1 :green_heart:
javac
0m 47s
hbase-common in the patch passed.

+1 :green_heart:
javac
0m 55s
hbase-client generated 0 new + 121 unchanged - 1 fixed = 121 total (was 122)

+1 :green_heart:
javac
3m 19s
hbase-server in the patch passed.

-0 :warning:
checkstyle
0m 27s
hbase-client: The patch generated 12 new + 1 unchanged - 0 fixed = 13 total (was 1)

-0 :warning:
checkstyle
1m 13s
hbase-server: The patch generated 5 new + 147 unchanged - 0 fixed = 152 total (was 147)

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

+1 :green_heart:
xml
0m  1s
The patch has no ill-formed XML file.

+1 :green_heart:
hadoopcheck
21m 29s
Patch does not cause any errors with Hadoop 3.1.2 3.2.2 3.3.1.

+1 :green_heart:
spotbugs
4m 27s
the patch passed

_ Other Tests _

+1 :green_heart:
asflicense
0m 33s
The patch does not generate ASF License warnings.

64m 31s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3863/1/artifact/yetus-general-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/3863

Optional Tests
dupname asflicense javac hadoopcheck xml compile spotbugs hbaseanti checkstyle

uname
Linux f170a6f25865 4.15.0-147-generic #151-Ubuntu SMP Fri Jun 18 19:21:19 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / b2571df7ae

Default Java
AdoptOpenJDK-1.8.0_282-b08

checkstyle
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3863/1/artifact/yetus-general-check/output/diff-checkstyle-hbase-client.txt

checkstyle
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3863/1/artifact/yetus-general-check/output/diff-checkstyle-hbase-server.txt

Max. process+thread count
86 (vs. ulimit of 30000)

modules
C: hbase-common hbase-client hbase-server U: .

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3863/1/console

versions
git=2.17.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 26s
Docker mode activated.

-0 :warning:
yetus
0m  3s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ master Compile Tests _

+0 :ok:
mvndep
0m 17s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
4m 42s
master passed

+1 :green_heart:
compile
2m  9s
master passed

+1 :green_heart:
shadedjars
8m 19s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
1m 34s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 17s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
4m 28s
the patch passed

+1 :green_heart:
compile
2m  8s
the patch passed

+1 :green_heart:
javac
2m  8s
the patch passed

+1 :green_heart:
shadedjars
8m 14s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
1m 31s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
2m  5s
hbase-common in the patch passed.

+1 :green_heart:
unit
1m 23s
hbase-client in the patch passed.

-1 :x:
unit
139m  1s
hbase-server in the patch failed.

179m 35s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3863/1/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/3863

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 4fc3f8de33aa 4.15.0-156-generic #163-Ubuntu SMP Thu Aug 19 23:31:58 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / b2571df7ae

Default Java
AdoptOpenJDK-11.0.10+9

unit
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3863/1/artifact/yetus-jdk11-hadoop3-check/output/patch-unit-hbase-server.txt

Test Results
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3863/1/testReport/

Max. process+thread count
4416 (vs. ulimit of 30000)

modules
C: hbase-common hbase-client hbase-server U: .

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3863/1/console

versions
git=2.17.1 maven=3.6.3

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
1m 50s
Docker mode activated.

-0 :warning:
yetus
0m  3s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ master Compile Tests _

+0 :ok:
mvndep
0m 16s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
4m 32s
master passed

+1 :green_heart:
compile
1m 54s
master passed

+1 :green_heart:
shadedjars
8m 24s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
1m 30s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 17s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
4m  5s
the patch passed

+1 :green_heart:
compile
2m  1s
the patch passed

+1 :green_heart:
javac
2m  1s
the patch passed

+1 :green_heart:
shadedjars
9m  6s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
1m 30s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
1m 56s
hbase-common in the patch passed.

+1 :green_heart:
unit
1m 33s
hbase-client in the patch passed.

-1 :x:
unit
159m 35s
hbase-server in the patch failed.

201m 12s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3863/1/artifact/yetus-jdk8-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/3863

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 1332c1fbdd49 4.15.0-65-generic #74-Ubuntu SMP Tue Sep 17 17:06:04 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / b2571df7ae

Default Java
AdoptOpenJDK-1.8.0_282-b08

unit
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3863/1/artifact/yetus-jdk8-hadoop3-check/output/patch-unit-hbase-server.txt

Test Results
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3863/1/testReport/

Max. process+thread count
5296 (vs. ulimit of 30000)

modules
C: hbase-common hbase-client hbase-server U: .

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3863/1/console

versions
git=2.17.1 maven=3.6.3

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

Let's open separated PRs for the different issues? It will be easier to review

Hey @ndimiduk , any change of splitting this into several PRs? We can merge them one by one.
Thanks.

@Apache9 sure, if you prefer, we can do them one-by-one. I thought having the whole change-set on a feature branch / single PR would make it easier for reviewers to evaluate the changes as a whole.

@Apache9 sure, if you prefer, we can do them one-by-one. I thought having the whole change-set on a feature branch / single PR would make it easier for reviewers to evaluate the changes as a whole.

For me, I think the difficulty for the big PR is that, once I point out a problem, it will be a pain to find out which commit should be fixed, and the review process will spend more time, so conflict with the base branch will also be a pain...


Add key512 secondary index

Similar to the key256 secondary index we already have support for.
Needs to be added in the C DB API and then supported in multi_index.

@wanderingbort @arhag Is this still part of the plan for the C API?

@wanderingbort @heifner if I don't hear anything on this, I will presume that it is no longer desired


Use RigidBodyTreed typedef

This PR depends on Drake's PR in RobotLocomotion/drake#3969. That PR must be merged before this one.
This PR simply replaces all the occurrences of RigidBodyTree with RigidBodyTreed. Per RobotLocomotion/drake#3969, RigidBodyTreed simply is a typedef to RigidBodyTree.
When RobotLocomotion/drake#3940 the typedef, from Drake's side, will be updated to RigidBodyTree<double>.

Please undo your changes to ddDrakeModelOH.cpp, that file shouldn't be modified, thanks!

How so? Otherwise Director won't be able to compile after RobotLocomotion/drake#3940 which then causes  linux-gcc-experimental-ros to fail in Drake's CI. After RobotLocomotion/drake#3940 RigidBodyTree will no longer exist. You will either need to use RigidBodyTree<double> or its typedef RigidBodyTreed

The file ddDrakeModelOH.cpp is only compiled when using an old fork of drake.

I see, I just verified that and reverted to use RigidBodyTree (not RigidBodyTreed) for that file only.

director is in the unfortunate position of supporting an old drake fork and drake/master.    All of the incompatibilities are hidden inside ddDrakeModel.  It's important that while you change the api of RigidBodyTree you maintain all the existing funcitonality so that ddDrakeModel can continue to function :)


We can use this with webpack?

To resolve a builtin like fs?

@sebamarynissen

No, this is a module that can be used to import non-js files in Node by using a configuration that is inspired by how webpack does it. More specifically, it makes it easier to compose loaders (see also https://nodejs.org/api/esm.html#loaders).
If you want to resolve Node builtins with webpack, you need to use the fallback config: https://webpack.js.org/configuration/resolve/#resolvefallback


Allow specifying the tag after AAD in CCM mode (2)

In addition to 67c81ec3 which introduced this behavior in CCM mode
docs but only implemented it for AES-CCM.

[x] tests are added or updated

Hi Patrick - there are a few issues with this..

This looks like a feature - so maybe should not be going back ported to 1.1.1?
e_aria.c is going to be deprecated in master and replaced by the provider code so this seems like the wrong file to do this change in. (As the ccm code is shared in the provider it most likely already works with your test change ).

Hi Shane,
i classified it as a 1.1.1 bug because said commit changed the doc, saying setting tag early is possible for CCM mode.
You are right, provider code already handles it correctly and the additional test passes.
(1) Regarding 1.1.1, i would only put it there if its seen as a bug.
(2) Regarding master, i would only put the test case change there, because e_aria.c is deprecated and the change would not even be tested by default because provider code is used instead.
Opinions ?

For master and 1.1.1.

merged.
master: https://github.com/openssl/openssl/commit/f7382fbbd846dd3bdea6b8c03b6af22faf0ab94f
1.1.1: https://github.com/openssl/openssl/commit/a13dddea6b71743116e86e39d446b9fb43e1799e


EventRender missing view parameter

Accordingly to the docs the eventRender callback has three parameters (event, element and view) but only two are implemented here.

Thank you!


v9 release failing to upload; v8 ok

$ bosh -t vsphere upload release https://bosh.io/d/github.com/cloudfoundry/networking-release\?v\=9
Acting as user 'admin' on 'vsphere'
Using remote release 'https://bosh.io/d/github.com/cloudfoundry/networking-release?v=9'

Director task 230582
  Started downloading remote release > Downloading remote release. Done (00:00:00)

  Started extracting release > Extracting release. Done (00:00:00)

  Started verifying manifest > Verifying manifest. Failed: undefined method `each' for nil:NilClass (00:00:00)

Error 100: undefined method `each' for nil:NilClass

But v8 does upload successfully.

Also failed from the git repo:
bosh upload release releases/networking/networking-9.yml
Acting as user 'admin' on 'sw-pr-microbosh'
You are using CLI >= 0.20 with director that doesn't support package matches.
This will result in uploading all packages and jobs to your director.
It is recommended to update your director or downgrade your CLI to 0.19.6
Downloading from blobstore (id=176bd6bc-1ee3-4311-50ea-55ac296dc9d8)...
Downloading from blobstore (id=d7fbfe5e-81c6-4c35-4222-436d8d467253)...
Downloading from blobstore (id=3d83d7a9-03fb-4c39-75e0-089c6e790b24)...
Downloading from blobstore (id=07034dbc-67ba-4b15-4b7b-b46b33e11962)...
Downloading from blobstore (id=32241789-f2ba-4a8d-716a-2dde3380ba07)...
Downloading from blobstore (id=eab77495-1587-4ed1-4c70-75455d0015d6)...
Downloading from blobstore (id=3a3be4bc-26d3-45ea-5998-8d86e502e764)...
Downloading from blobstore (id=9a03da20-9f8d-415a-8daa-717ba6ae44ee)...

Copying packages
----------------

Copying jobs
------------
gateway
iptables
multi_home
nat
port_forwarding
routes
set_mtu

Copying license
---------------
license

Generated /var/folders/wd/xnncwqp96rj0v1y2nms64mq80000gn/T/d20170228-38057-9p45rz/d20170228-38057-1ateaab/release.tgz
Release size: 12.1K

Verifying manifest...
Extract manifest                                             OK
Manifest exists                                              OK
Release name/version                                         OK

Uploading release
release.tgz:    95% |oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo      |  11.6KB 433.6KB/s ETA:  00:00:00
Director task 230585
  Started extracting release > Extracting release. Done (00:00:00)

  Started verifying manifest > Verifying manifest. Failed: undefined method `each' for nil:NilClass (00:00:00)

Error 100: undefined method `each' for nil:NilClass

Task 230585 error
release.tgz:    95% |oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo      |  11.6KB    444B/s Time: 00:00:26

For a more detailed error report, run: bosh task 230585 --debug

$ bosh -t vsphere status
Config
             /Users/drnic/.bosh_config

Director
  Name       sw-pr-microbosh
  URL        https://<IP_ADDRESS>:25555
  Version    1.3262.15.0 (00000000)
  User       admin
  UUID       f635b1ba-5000-48e1-92c8-19471d20e0e4
  CPI        vsphere_cpi
  dns        disabled
  compiled_package_cache disabled
  snapshots  disabled

bumping @cppforlife as no piv tracker bot showed up

The following worked (bosh is v1)
bosh create release && bosh upload release

@drnic can you provide stacktrace at the end of bosh task 230585 --debug

probably https://github.com/cloudfoundry/bosh-cli/issues/39

@dpb587 yup, fixed: https://github.com/cloudfoundry/networking-release/commit/86512e00f4bedd877deded0be9294cb520921568

@cppforlife should v9 on bosh.io work now? or is there a 2nd issue:
Checking whether release networking/9 already exists...NO
Using remote release 'https://bosh.io/d/github.com/cloudfoundry/networking-release?v=9'

Director task 230690
  Started downloading remote release > Downloading remote release. Done (00:00:01)

  Started verifying remote release > Verifying remote release. Done (00:00:00)

  Started extracting release > Extracting release. Done (00:00:00)

  Started verifying manifest > Verifying manifest. Failed: undefined method `each' for nil:NilClass (00:00:00)

Error 100: undefined method `each' for nil:NilClass


Stack too deep

brew config output
HOMEBREW_VERSION: 3.3.3
ORIGIN: https://github.com/Homebrew/brew
HEAD: 64fb3c86f87eaf4a4b2ba64ddec0a5a3f2530b4c
Last commit: 34 hours ago
Core tap ORIGIN: https://github.com/Homebrew/homebrew-core
Core tap HEAD: ac1b30bfd9c124d67297af0c3731acde848591d2
Core tap last commit: 5 minutes ago
Core tap branch: master
HOMEBREW_PREFIX: /usr/local
HOMEBREW_CASK_OPTS: []
HOMEBREW_CORE_GIT_REMOTE: https://github.com/Homebrew/homebrew-core
HOMEBREW_MAKE_JOBS: 8
Homebrew Ruby: 2.6.8 => /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/bin/ruby
CPU: octa-core 64-bit icelake
Clang: 13.0.0 build 1300
Git: 2.30.1 => /Library/Developer/CommandLineTools/usr/bin/git
Curl: 7.77.0 => /usr/bin/curl
macOS: 12.0.1-x86_64
CLT: <IP_ADDRESS>.1.1633545042
Xcode: N/A

brew doctor output
Please note that these warnings are just used to help the Homebrew maintainers
with debugging if you file an issue. If everything you use Homebrew for is
working fine: please don't worry or file an issue; just ignore this. Thanks!

Warning: Some installed kegs have no formulae!
This means they were either deleted or installed with `brew diy`.
You should find replacements for the following formulae:
  bicep
Warning: Calling bottle :unneeded is deprecated! There is no replacement.
Please report this issue to the argoproj/tap tap (not Homebrew/brew or Homebrew/core):
  /usr/local/Homebrew/Library/Taps/argoproj/homebrew-tap/kubectl-argo-rollouts.rb:8

Error: stack level too deep
Please report this issue:
  https://docs.brew.sh/Troubleshooting
/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/pathname.rb:42:in `chop_basename'
/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/pathname.rb:359:in `plus'
/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/pathname.rb:351:in `+'
/usr/local/Homebrew/Library/Homebrew/formulary.rb:310:in `formula_name_path'
/usr/local/Homebrew/Library/Homebrew/formulary.rb:328:in `formula_name_path'
/usr/local/Homebrew/Library/Homebrew/formulary.rb:328:in `formula_name_path'
/usr/local/Homebrew/Library/Homebrew/formulary.rb:328:in `formula_name_path'
/usr/local/Homebrew/Library/Homebrew/formulary.rb:328:in `formula_name_path'
/usr/local/Homebrew/Library/Homebrew/formulary.rb:328:in `formula_name_path'
/usr/local/Homebrew/Library/Homebrew/formulary.rb:328:in `formula_name_path'
/usr/local/Homebrew/Library/Homebrew/formulary.rb:328:in `formula_name_path'
/usr/local/Homebrew/Library/Homebrew/formulary.rb:328:in `formula_name_path'
/usr/local/Homebrew/Library/Homebrew/formulary.rb:328:in `formula_name_path'
/usr/local/Homebrew/Library/Homebrew/formulary.rb:328:in `formula_name_path'
/usr/local/Homebrew/Library/Homebrew/formulary.rb:328:in `formula_name_path'
/usr/local/Homebrew/Library/Homebrew/formulary.rb:328:in `formula_name_path'
/usr/local/Homebrew/Library/Homebrew/formulary.rb:328:in `formula_name_path'
/usr/local/Homebrew/Library/Homebrew/formulary.rb:328:in `formula_name_path'
/usr/local/Homebrew/Library/Homebrew/formulary.rb:328:in `formula_name_path'
/usr/local/Homebrew/Library/Homebrew/formulary.rb:328:in `formula_name_path'
/usr/local/Homebrew/Library/Homebrew/formulary.rb:328:in `formula_name_path'
/usr/local/Homebrew/Library/Homebrew/formulary.rb:328:in `formula_name_path'
/usr/local/Homebrew/Library/Homebrew/formulary.rb:328:in `formula_name_path'
/usr/local/Homebrew/Library/Homebrew/formulary.rb:302:in `initialize'
/usr/local/Homebrew/Library/Homebrew/formulary.rb:547:in `new'
/usr/local/Homebrew/Library/Homebrew/formulary.rb:547:in `loader_for'
/usr/local/Homebrew/Library/Homebrew/formulary.rb:418:in `factory'
/usr/local/Homebrew/Library/Homebrew/formulary.rb:484:in `from_keg'
/usr/local/Homebrew/Library/Homebrew/formulary.rb:457:in `from_rack'
/usr/local/Homebrew/Library/Homebrew/formula.rb:1704:in `block in installed'
/usr/local/Homebrew/Library/Homebrew/formula.rb:1703:in `each'
/usr/local/Homebrew/Library/Homebrew/formula.rb:1703:in `flat_map'
/usr/local/Homebrew/Library/Homebrew/formula.rb:1703:in `installed'
/usr/local/Homebrew/Library/Homebrew/diagnostic.rb:700:in `check_deprecated_disabled'
/usr/local/Homebrew/Library/Homebrew/cmd/doctor.rb:64:in `block in doctor'
/usr/local/Homebrew/Library/Homebrew/cmd/doctor.rb:57:in `each'
/usr/local/Homebrew/Library/Homebrew/cmd/doctor.rb:57:in `doctor'
/usr/local/Homebrew/Library/Homebrew/brew.rb:110:in `<main>'

[X] I ran brew update and am still able to reproduce my issue.
[X] I have resolved all warnings from brew doctor and that did not fix my problem.

What were you trying to do (and why)?
Simply trying to update and then upgrade brew
What happened (include all command output)?
Warning: Calling bottle :unneeded is deprecated! There is no replacement.
Please report this issue to the argoproj/tap tap (not Homebrew/brew or Homebrew/core):
/usr/local/Homebrew/Library/Taps/argoproj/homebrew-tap/kubectl-argo-rollouts.rb:8
Error: stack level too deep
Please report this issue:
https://docs.brew.sh/Troubleshooting
/usr/local/Homebrew/Library/Homebrew/tap.rb:46:in block in fetch' /usr/local/Homebrew/Library/Homebrew/tap.rb:46:in any?'
/usr/local/Homebrew/Library/Homebrew/tap.rb:46:in fetch' /usr/local/Homebrew/Library/Homebrew/formulary.rb:308:in formula_name_path'
/usr/local/Homebrew/Library/Homebrew/formulary.rb:328:in formula_name_path' /usr/local/Homebrew/Library/Homebrew/formulary.rb:328:in formula_name_path'
/usr/local/Homebrew/Library/Homebrew/formulary.rb:328:in `formula_name_path'
What did you expect to happen?
brew to successfully upgrade
Step-by-step reproduction instructions (by running brew commands)
brew update
brew upgrade
brew list
==> Formulae
augeas				dapr-cli			kubectl-argo-rollouts<EMAIL_ADDRESS>azure-cli			dialog				libev<EMAIL_ADDRESS>azure-functions-core-tools@3	gdbm				libnghttp2<EMAIL_ADDRESS>bicep				gh				libuv				readline
brotli				helm				mpdecimal			sqlite
c-ares				icu4c				nghttp2				tcl-tk
ca-certificates			jemalloc			node				xz
certbot				jq				oniguruma

==> Casks
docker-edge		dotnet-sdk		dotnet-sdk3-1-400	github-beta		sfdx

Duplicate of #12370


High-Level Interface

I am about to submit patches for a high-level interface for vcard/icalendar handling.
This is the tracking issue for the progress, as I will submit a series of PRs. The PRs will be as follows:

PR
In Progress
Submitted
Accepted

Refactoring PR
yes
yes
no

Travis Setup PR
yes
yes
no

High level Read-Interface for Vcard
yes
no
no

High level Write-Interface for Vcard
yes
no
no

High level Read-Interface for Icalendar
yes
no
no

High level Write-Interface for Icalendar
no
no
no

Optionally I will rewrite the interfaces for better ergonomics, if I feel that there's need for that:

[x] Rewrite of high-level Interface for Vcard
[x] Rewrite of high-level Interface for Icalendar

About Releases
I, personally, would not release the changes of the first two patches in a new release of the crate. They are just preparings for the other PRs and do not introduce new functionality.
Either way, the Refactoring PR contains breaking changes in the exported error types, as I switch to use error_chain there, so releasing a new version of the crate with this PR merged would not be a patch release but one with breaking changes.
Just for your notice.

Not sure whether we can close this already... what do you mean? The "high-level" interface is mostly generated from macros and not quite as "high level" as I would like it to be (everything is still String in the public API)...

Uh, oh... Ummm... No, I don't think so. Damn, that shouldn't have happened. I will check tomorrow which we should not export and which we can export.

I know how to remove them, but I'd need to know if you want to export any of them.

The parameters!() macro in src/param.rs is useful outside of the crate (and I am using it in another crate, for example). All others don't need to be exported.
As far as I can tell, removing them would alter the public interface of the crate and thus would need us to release a minor update with these changes (0.6.0) rather than a bugfix release (0.5.1) ... what do you think?

@matthiasbeyer sorry, I overlooked this. Yes, this definetly would have to be a minor release.


touch scrolling down

Hello, when I scroll down my page (and touch carousel), banner changes position right or left. your test example has same problem. It looks like a very big bug. How to fix it? Thanks

hi,
It is a known issue but it doesn't effect the carousel. I'm already looking into it.
Thanks

I would be very grateful if this problem will be fixed

@AlexanderGubskyy @eisventura fixed this issue in build v1.3.2. read the changelog file


Multiple same-line memoize calls may return incorrect cached values

Multiple calls to memoize for the same subject on the same source code line will incorrectly re-use the result of the first predicate as the result of the second memoize call.
For example, while this multi-line statement will pass:
assert("XYZ".memoize(\.first)
    == "XYZ".memoize(\.last))

…placing the same command on different lines will fail the assertion:
assert("XYZ".memoize(\.first) == "XYZ".memoize(\.last)) // X == Z?!?!?

This is because the memoize cache is keyed on the file name and call point line of the source code (as well as the Hashable subject), so if all those three things are the same, the cache key will conflict and the wrong value will be returned.
This is a fundamental shortcoming of keying with the call point (at least until Swift includes a #column feature that can be used like #file and #line).

@ZevEisenberg informed me about the #column


Implement Multiselect Block

closes: #390

@BenDenger @MarvinSchramm And one more =)

@wudmer  Do you want to add yourself as a contributor to the publish-meta.gradle.kts ?
If so, please add it to the pull-request and we will merge it.


use mongoose 4.0.0 instead

mongoose connection errors with the current build. use 4.0.0 to avoid them. Happy to submit a PR if you want.

I updated all the dependencies (including Mongoose 4.0.1) and added the v3.0.2 changelog here:  https://github.com/sahat/hackathon-starter#changelog


Define custom renderer

Turbo drive doesn't offer any option to define custom rendering logic AFAIK. The current implementation simply replaces an old node with a new one. This can lead to unwanted side-effects (e.g. flickering content or losing dirty input states). I want to be able to define a renderer that uses a DOM diffing library like morphdom.
The easiest way would have been to use inheritance to create a custom PageView with a custom Renderer, but the necessary classes are not being exported (probably for good reasons).
Is there any clean way to implement a DOM diffing renderer?

@tbo , awesome idea! This will allow transition to turbo frames in a lot of places where previously JS was required.
Looks like someone should try to implement such behavior in separated PR, which will add ability to "register" custom renderer.

@kirin121 I could do that. But I'd like to know from a core developer upfront, if this has any chance to be merged and how they want it to be implemented.

Yes, this is something we'd like to support, but not in the form of custom renderer classes that plug into Turbo core. We'd rather support something like preventDefault() on turbo:before-render events with a mechanism to call back into Turbo when you've finished rendering.

@sstephenson I created a PR for it.


ZIndex for objects

This PR adds the zIndex field to objects and turns off dce, which allows for more classes to be used in scripting

why would you add zIndex whats the benefit

well its an easier method of setting the object order 😄

why would you add zIndex whats the benefit

easier layering, other game engines do have zIndex and it's generally a better way of setting object order

actually can you check if hscript still works? last time this was tried, it completely stopped working altogether

working for me

ah so it should be fine then

didn't shadowmario say he has problems without dce?

pretty sure there used to be problems, but there arent anymore from what i have seen, as it compiles and no errors have come up

oh alr

I'd highly recommend against disabling DCE, DCE prevents Haxe from including cluttered code in the final output for the game, if you need something to be present at runtime, import it somewhere or use @:keep and they'll be forced to compile

ight, ill remove those changes and finish fixing stages since zIndex!!!!!

disabling dce was like the most useful change here 😭

they are right though. disabling dce would just bring cluttered code


Displaying HTML shows a warning CS1701

In the csharp / Docs /  HTML notebook, the cell:
display(HTML("<b style=\"color:blue\">Hello!</b>"));
Will output Hello! but also the following warning:
warning CS1701: Assuming assembly reference 'Microsoft.AspNetCore.Html.Abstractions, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=adb9793829ddae60' used by 'Microsoft.DotNet.Interactive' matches identity 'Microsoft.AspNetCore.Html.Abstractions, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=adb9793829ddae60' of 'Microsoft.AspNetCore.Html.Abstractions', you may need to supply runtime policy

Sorry for the late response:
I have updated now to the latest .NET SDK and dotnet-interactive packages, but still the same issue.
It seems there are multiple issues:
First of all there is an older version of a library referenced/included where a newer one exists in the .NET SDK. I created an issue at the dotnet-interactive repo: dotnet/interactive#1939
Also, this compiler warning is obsolete and should be removed.
And there is at the moment also no possibility to globally suppress warnings: dotnet/interactive#762
Sorry, at the moment I also don't have a workaround.


Delete an Item from a Shopcart

Hi Yuheng,
Thanks for the PR! Ditto in #25.

Thank you, Allen! For some reason, I accidentally deleted _create_items in the last push. Now the problem is fixed.

Fixed. Now it is supposed to work.


template: Add dataFile parameter property for including arbitrary text from files

Sometimes it is desirable to keep a portion of a template in a separate file and include it into the template text.
This can be done with parameters and the dataFile property:
const fast = require('@f5devcentral/f5-fast-core');

const templatesPath = '/path/to/templatesdir'; // directory containing example.data
const dataProvider = new fast.FsDataProvider(templatesPath);
const yamldata = `
    definitions:
        var:
            dataFile: example
    template: |
        {{var}}
`;

fast.Template.loadYaml(yamldata, { dataProvider })
    .then((template) => {
        console.log(template.getParametersSchema());
        console.log(template.render({virtual_port: 443});
    });

The FsDataProvider will pick up on any files with the .data extension in the template set directory.
When referencing the file in a template, use the filename (without the extension) as a key.
Parameters with a dataFile property:

are removed from required
have their default set to the contents of the file
given a default format of hidden

In addition to creating a common BaseDataProvider, I went ahead and did BaseSchemaProvider as well. Now we have an abstract base class for all three provider types. I can move this change into a new PR if desired.
I am a little worried about adding a third provider type now that some other teams are starting to implement their own. It adds some complexity (see how I had to update the new GitHub providers that were added since this PR was first opened) and I don't know how many people actually need this feature. Luckily, both Schema and Data providers are pretty easy to implement and are a fair amount of copy/paste. This does, however, make me wonder if there is a better abstraction to combine providers that just need to get file contents (e.g., Schema and Data) vs loading Templates.

Looks good to me, I had a nit comment that can be deferred..

In addition to creating a common BaseDataProvider, I went ahead and did BaseSchemaProvider as well. Now we have an abstract base class for all three provider types. I can move this change into a new PR if desired.
I am a little worried about adding a third provider type now that some other teams are starting to implement their own. It adds some complexity (see how I had to update the new GitHub providers that were added since this PR was first opened) and I don't know how many people actually need this feature. Luckily, both Schema and Data providers are pretty easy to implement and are a fair amount of copy/paste. This does, however, make me wonder if there is a better abstraction to combine providers that just need to get file contents (e.g., Schema and Data) vs loading Templates.

Agreed that provider types seem to add some complexity and something we may want to review design for and revisit in the future, but for purposes of this MR/feature request, the changes look good, so I've approved.


Handle knex error in TestMessageService destroy

Description
Handle Knex abort error when destroying TestMessageService.
Due to the delay logic in the TestMessageService we often see Knex connection aborted errors in the log.
This makes the logs more annoying to parse. This change simply swallows the error so the logs don't get too polluted.

Checklist:
Code quality

[x] I have written clear commit messages
[x] I have performed a self-review of my own code
[x] This change does not have an unduly wide scope
[x] I have separated logic changes from refactor changes (formatting, renames, etc.)
[x] I have commented my code wherever necessary (can be 0)
[ ] I have added tests that prove my fix is effective or that my feature works, if necessary

Project management

[x] I have applied the appropriate labels
[x] I have linked to all relevant issues (can be 0)
[x] I have linked to all dependent issues (can be 0)
[x] I have assigned myself to this PR
[x] I have chosen the appropriate pipeline on zenhub for the linked issue

Would you be able to point to an example of an aborted knex job? Also, should tests wait for knex operations to succeed before terminating? Do you know why there are ongoing knex operations during test termination?

Closing this as it's superseded by #3423


Refine docstring for newAPI, algorithm, and contrib

Signed-off-by: XuhuiRen<EMAIL_ADDRESS>Docstring
Docstring for newAPI, contrib, and algorithm.
Description
Add docstring for the document and add some function description.
detail description
JIRA ticket: https://jira.devtools.intel.com/secure/RapidBoard.jspa?rapidView=32982&projectKey=ILITV&view=detail&selectedIssue=ILITV-2573&quickFilter=130297

/Azurepipeline run

/Azurepipeline run

/Azurepipeline run

Wrong path added

Done.


Fixed a problem with not closing the file handle before throwing an exception

Hey David,
Fixing #502

Btw, All tests are passing on my machine.


C# JobShop CP Solver: precedence with fixed days

Hi,
I try to setup a jobshop solver that implement standard precedence (conjunctive constraints) but with a particular behaviour.
Some machine can start task at a particular day of week and stop task in another day.
For example:
I have a job with two task, the first one (T1) must be executed on machine 1 (M1) and the second one (T2) must be executed on machine 2 (M2).
M2 can start task only on wednesday  and stop only on friday.
One solution can be T1 on M1 executed and completed on tuesday, T2 started on M2 on wednesday  and  finished on friday.
I try creating a constraint that calculate the day on T1End and then add all necessary day to reach the first wednesday.
There are two problems:

calculating the difference from first wednesday and the day of previous task has a bug and not always return the correct value (for example if previous task end on monday = 1 and I want to start next at wednesday = 3, the difference 3-1 return -2 and if I use abs, return 0...)

DayOfWeek startDay = config.BeginDate.DayOfWeek;
var dayEnd = ((long)startDay + dayPreviousFromBeginning) % 7;
// dayEnd = 1

// weekday request to delivery (constant value = 3)
var cweekdayDelivery = solver.MakeIntConst((long)weekdayDelivery);

var diff =solver.MakeAbs (cweekdayDelivery - dayEnd);
// diff = 0 and without MakeAbs diff = -2 ????

how can I constraint task 2 to start on first FREE wednesday? (the first wednesday may be a festivity day or may be overloaded)

Thank you,
Bye, Nicola

To set an availability schedule on a machine, just add fixed intervals to the no_overlap/disjunctive constraint that will forbid other tasks to execute on those day.
See https://github.com/google/or-tools/blob/master/ortools/sat/doc/scheduling.md#nooverlap-constraint
Now, you can have a look at the gate scheduling problem. In this example, 2 optional intervals var are created for each task, And a boolean variable is created to specify which of the two machines are performing this task.
To implement start schedule, just restrict the domain of the start of the task on m2.
start_on_m2 = model.NewEnumeratedIntVar([first Wed 0:00, first Wed 23:59, second Wed 0:00, second Wed 23:59...]
I use the CP-SAT for this. Does this solve your problem?

Thank you.
I create a set of interval in CP that corrisponds to "no working" time and
than I added to a non overlapping contraint.
Il giorno mer 5 set 2018 alle ore 23:43 Laurent Perron <
<EMAIL_ADDRESS>ha scritto:

To set an availability schedule on a machine, just add fixed intervals to
the no_overlap/disjunctive constraint that will forbid other tasks to
execute on those day.
See
https://github.com/google/or-tools/blob/master/ortools/sat/doc/scheduling.md#nooverlap-constraint
Now, you can have a look at the gate scheduling problem. In this example,
2 optional intervals var are created for each task, And a boolean variable
is created to specify which of the two machines are performing this task.
To implement start schedule, just restrict the domain of the start of the
task on m2.
start_on_m2 = model.NewEnumeratedIntVar([first Wed 0:00, first Wed 23:59,
second Wed 0:00, second Wed 23:59...]
I use the CP-SAT for this. Does this solve your problem?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/google/or-tools/issues/823#issuecomment-418891329,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AoBHQeEbha87RdSCuaPiaHbchX9U34VOks5uYEVsgaJpZM4WEYAf
.


Purge use of old test frameworks

It's happened. I've removed all uses of nose and unittest's self.assert* so that we will be able to in the future use py.test features such as parametrization.
Unfortunately this sits on top of #239 so will have to wait until it's been merged (and as such will also not pass its tests until https://github.com/alphagov/digitalmarketplace-frameworks/pull/349 is merged).
I've also done a bit of an audit of uses of the mock *called* properties/methods switching them to use safer ones. More information in the comment for that commit:
assert_called() does not exist (except in the *absolute latest* mock
packages) and doesn't do anything. assert_not_called() does not exist
(same caveat) and does not do anything. the only way to make absolutely
sure an assertion is being performed is to include the assert keyword. for
similar reasons identity comparisons of .called against True, False are
preferred over just asserting against the property's truthiness/falsiness.

Hold on wait a second I've screwed up my rebase

Ok all better.

:applause: :applause: :applause: :applause: :applause:
So much better now.
:+1:

Many thanks @TheDoubleK basically agreed on all points but I want to hit the big button before I'm made to rebase this again.

I thought that these things could be called just once for all of the tests in a class

I agree some of these things look like they could be. But this was meant as a mostly straight port of the existing setUp method, whose behaviour from the looks of it in the unittest.TestCase docs was akin to setup_method.
Using a class is still useful to group together a whole bunch of tests that are going to need the same things set up for them, even though they want to be isolated from each others collateral damage.
And then sometimes people just use the class as a structural/organizational thing.


ES6 modules unable to export global variables by their identifier

export {console}

$ node_modules/.bin/tsc -m commonjs index

expected:
"use strict";
exports.console = console;

actual:
"use strict";

It is an open question if this is allowed. Per <IP_ADDRESS>.2GetExportedNames( exportStarSet ) Concrete Method#

For each ExportEntry Record e in module.[[LocalExportEntries]], do
Assert: module provides the direct binding for this export.

And in <IP_ADDRESS>.4ModuleDeclarationInstantiation( ) Concrete Method bindings in module are created for VarScopedDeclarations  and LexicallyScopedDeclarations of the module body so there will be no  bindings for global names in the module and assert above presumably should fail //cc @bterlson

It seems you are right. I agree with es spec.

Quoth ES6:

It is a Syntax Error if any element of the ExportedBindings of ModuleItemList does not also occur in either the VarDeclaredNames of ModuleItemList, or the LexicallyDeclaredNames of ModuleItemList.

this should be an early syntax error.

@vladima I am unable to get your defined re-exporting globals error in my reported case, why?

works fine for me using the latest bits from the master
vladima@vladima-W520:~/sources/git/TypeScript$ cat t.ts
export {console};
vladima@vladima-W520:~/sources/git/TypeScript$ node built/local/tsc.js -m commonjs t.ts
t.ts(1,9): error TS2661: Cannot re-export name that is not defined in the module.

sorry, I mistook the path. works well.


RBAC issue with accessing the secret by couchdb-webhook

Describe the bug
The deploy couchdb-webhook fails to run with the following error message in the log.
Failed to list *v1.ValidatingWebhookConfiguration: validatingwebhookconfigurations.admissionregistration.k8s.io is forbidden: User "system:serviceaccount:knative-eventing:couchdb-webhook" cannot list resource "validatingwebhookconfigurations" in API group "admissionregistration.k8s.io" at the cluster scope
E0609 13:06:48.515713

Expected behavior
The deploy couchdb-webhook should be launched with no issue
To Reproduce
Install the couchdb source with the operator on any kubernetes platform.(I did on top of IKS)
Knative release version
0.23 for couchdb source
Additional context
Add any other context about the problem here such as proposed priority

/assign @lionelvillard


x/exp/winfsnotify: delete package

The x/exp/winfsnotify package was moved from the standard library to the x/exp repository in CL 7456047, a little over nine years ago. It has apparently not been touched since then except to add an // import comment in 2014. In 2016, users discussed switching to an externally-maintained alternative (see @nathany's comment in https://github.com/golang/go/issues/17244#issuecomment-250935437).
At least one such alternative, github.com/fsnotify/fsnotify, was still actively maintained at least as of this January (see https://github.com/fsnotify/fsnotify/issues/413), and has a number of volunteers to maintain it going forward.
In the meantime x/exp/winfsnotify has rotted. It has no active owners and its only substantial test is flaky (#49734). The corresponding fsnotify package for Unix platforms was removed in CL 3990, back in 2015.
The packages in the x/exp repository are explicitly experimental. I propose that we declare the x/exp/winfsnotify experiment concluded and delete the package.

Given the overwhelming evidence, I think we can make this a direct accept.

No change in consensus, so accepted. 🎉
This issue now tracks the work of implementing the proposal.
— rsc for the proposal review group

That seems reasonable. Probably we should also add a deprecation notice to the tombstone version, and tag it something like winfsnotify/v0.1.0-deprecated so that it can be resolved from the version list.

This is done: the winfsnotify package no longer exists at HEAD, but remains available in module golang.org/x/exp/winfsnotify at its terminal version v0.1.0-deprecated.
I've also confirmed that the documentation for the final, deprecated version is correctly shown at https://pkg.go.dev/golang.org/x/exp/winfsnotify.


The main character

What needs to be made :

Sprites :
[ ] Character (need to design the cake)
[ ] Running
[ ] Jumping
[ ] Sliding on wall (for wall jump)
[ ] Falling
[ ] Shooting (maybe only two sprites)
[ ] Weapons
Code :
[ ] Constant speed for nervous gameplay
[x] Goes from left to right direction instantly
[x] Does not rotate when hitting some object or some corner (or at least not every time, just for some events like bullet hitting)
[x] Slowly slides when on wall IF in air and IF they're is no rigid nodes 1 tile under.
[ ] No cooldown on jump
[ ] Weapons (not important for now, need to finish the physics)

Insta-going from left to right, no rotations and slow sliding were added in 022720d3b9e2e4deaa96c86ce2d50d2757d17e10

Thank you so much :)
Also, I haven't many active people in @KOBUGE-Games except @alketii . Will it be like this for a long time ? Because it would be easier to be more (especially for graphism and level/character design)


Sometimes different teams will have the same color

I think the team colors are selected randomly so sometimes with multiple players two players will have the same color.

I check it soon InshaAllah =)

It is fixed it now I think and I have provided fix releases for both the game and the server exports. These files should be replaced on the http://conquestgame.online/ web game and the server in the back for the changes to appear.


ci: change gh-pages autocommit message to only include first line with commit sha appended to it

the decision to make the autocommit replicate the message of the actual commit was for a nice git blame view of the resulting documents
(instead of the left side just containing chore: regenerate docs as per <sha256> it has what you'd expect, i.e. the title)
in github, when you add a link leading to an issue or pr (be it in a commit or an issue or pr body), the page of said issue gets notified and now contains a back-hyperlink of it

with the current implementation of the asciidoc github hack this leads to this result which i don't want

(the screenshots are authentic. my windows laptop just accidentally messed up the time [this case -2 hours] like windows always does for me -,-)


ISPN-16308 Auto-detect RESP when SELECT is the first command

https://issues.redhat.com/browse/ISPN-16308

Thanks, @tristantarrant!


Distribute DEP execution using task queue

It is no longer practical to run DEP on one system, but the need is to distribute the tasks to a cluster of systems.  I have done some initial testing with RabbitMQ and its seems doable. So we have this issue now and the following TODO:

[x] split RT/proctor.py into a queue job pusher and queue job executor
[x] The pusher should monitor the queue drain and then allow subsequent processing to happen
[x] move NFS mount of /mnt/idep2 up to bare metal to improve distributed throughput
[x] add nagios check that we have queue workers ready

Usage of threading, twisted, and/or multiprocessing seems above my paygrade at the moment for the client worker, so instead will start one process per worker on the nodes, for now.

Ready to run an operational test.  The standard methodology finished in 5h45m this morning.

Running with iem15=4, iemvs10[0-9]=4, iem30=24 we got about 55/s and finished in 1h20m