Generation not Working

Exception in Tkinter callback
Traceback (most recent call last):
File "C:\Users\Dell\Downloads\Tkinter-Designer-master\Tkinter-Designer-master\tkdesigner\designer.py", line 21, in to_code
frame = Frame(f, self.figma_file, self.output_path, self.frameCounter)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\Dell\Downloads\Tkinter-Designer-master\Tkinter-Designer-master\tkdesigner\figma\frame.py", line 29, in init
self.elements = [
^
TypeError: 'NoneType' object is not iterable
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "C:\Program Files\Python312\Lib\tkinter_init_.py", line 1968, in call
return self.func(*args)
^^^^^^^^^^^^^^^^
File "C:\Users\Dell\Downloads\Tkinter-Designer-master\Tkinter-Designer-master\gui\gui.py", line 72, in btn_clicked
designer.design()
File "C:\Users\Dell\Downloads\Tkinter-Designer-master\Tkinter-Designer-master\tkdesigner\designer.py", line 32, in design
code = self.to_code()
^^^^^^^^^^^^^^
File "C:\Users\Dell\Downloads\Tkinter-Designer-master\Tkinter-Designer-master\tkdesigner\designer.py", line 23, in to_code
raise Exception("Frame not found in figma file or is empty")
Exception: Frame not found in figma file or is empty
I Get this error when i press "Generate"

Tkinter Designer detects the frame element in figma as a base. You need to first create a frame and then add other elements like buttons, texts in it


fix: download site bundle correctly if site name has special chars

What does this PR do?
Fixes the bug when site name contains special chars and we need to download site bundle
What issues does this PR fix or reference?
@W-16552899@

We will also need to backport this to the 252-patch branch

Closing this forked repo PR. Will create a new one.


Delegate sign_in_after_reset_password to resource class

Allows resource class scopes to overrides the global configuration for sign in after reset password behaviour.

Thanks!


Fixing intel14/libstdc++4.4

This pull request un-breaks the compilation of all of our examples and tests.

[19:36]	hkaiser: we should merge the intel fixes and the shortlength test asap
[19:36]	hkaiser: that will improve the colors on buildbot
[19:36]	K-ballo: I don't wanna look at the intel fixes, just merge them


pull request for e2e test at 01/24/2017 20:26:09

:white_check_mark: Validation status: passed
For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Feature CP 83

Addresses OC-90 and the related CP-83

Whoops, this also needs to be filed against develop, not master.  Can you please adjust the PR, or close and re-file if you can't?

Hrm.  Looks like that was a non-trivial pull request move because of the state of develop.  You might be better off not fighting Git and re-doing those commits starting from the current state of develop.  Feel free to force-push to your branch.  This patch series should ideally have just one or two commits, and not record a jaunt from the master branch.
Separately, I see the pyshacl issue, which was resolved in upstream issue 93 a few hours ago.  (That is a residual of the use_2to3 / rdflib-jsonld situation from last week.)  But apparently CI isn't picking up the new release.  Let's see if CI fails again on pyshacl after your rework.


How to disable minify HTML?

I only write HTML and CSS, after I finish my work, I need to provide my colleague the highly readable HTML.

Hey @f3liiix,
to disable CSS and HTML minification, try creating a .parcelrc file in the root of your project with this content:
{
    "extends": "@parcel/config-default",
    "optimizers": {
        "*.css": [],
        "*.html": []
    }
}

You should then find non-minified files in dist/. Let me know if that works!


Add ability to generate cpu and mem profiling

This adds the ability to generate the pprof cpu and memory profiles for the entire running time of the tool through config options --cpu-profile and --mem-profile.
These are useful to figure out hot paths for performance improvement when running the check: sub-comannds.

If Heimdall is stuck, please click the following link: https://heimdall-public.cbhq.net/v1/pull_request/stuck?pr_number=145&repository=coinbase/rosetta-cli

I can't access the CI environment so I'm not sure what's failing. Lint and tests are passing on my machine.

@matheusd the Salus check is failing with this error:

@matheusd ... Love the ability to profile the rosetta-cli! I think you should revert the exit.Code related changes you made and we can discuss those in another PR. Happy to include the profiling changes in the next release.

Reverting the os.Exit means the mem profile isn't generated because rootPostRun doesn't run after os.Exit is called.
But you do have a point about the exit status.
Here's an alternative: switch the check:data and check:construction commands to use RunE and then return an error on every code path that was resulting in an os.Exit(1) call. Then add the os.Exit() call at a single site, at the top level of the main package.

Reverting the os.Exit means the mem profile isn't generated because rootPostRun doesn't run after os.Exit is called.

Ahhhh my bad, yeah that makes sense.

Here's an alternative: switch the check:data and check:construction commands to use RunE and then return an error on every code path that was resulting in an os.Exit(1) call. Then add the os.Exit() call at a single site, at the top level of the main package.

Let me put up a PR that cleans this up.

Updated. I had to forgo using PersistentPostRun and hook the rootPostRun() directly on Execute() because when the subcommand fails, the corresponding PersistentPostRun isn't executed.


Unknown error on ARM template extension

Does this occur consistently?
Repro steps:

Action: startArmLanguageServer
Error type: Error
Error Message: This extension requires .NET Core for full functionality, but we were unable to download and install a local copy for the extension. If this error persists, please see https://aka.ms/vscode-armtools-dotnet for troubleshooting tips.
Details: dotnet.acquire returned undefined
Version: 0.13.0
OS: win32
OS Release: 10.0.19041
Product: Visual Studio Code
Product Version: 1.51.1
Language: en

Call Stack
Object.wrapError extension.bundle.js:166:60234
Object.<anonymous> extension.bundle.js:239:55780
fulfilled extension.bundle.js:239:54595
processTicksAndRejections task_queues.js:94:5

Please do F1 and then run the following command:

That will report the issue to the correct team.  Thanks!


[SPARK-14769][SQL] Create built-in functionality for variable substitution

What changes were proposed in this pull request?
In order to fully merge the Hive parser and the SQL parser, we'd need to support variable substitution in Spark. The implementation of the substitute algorithm is mostly copied from Hive, but I simplified the overall structure quite a bit and added more comprehensive test coverage.
Note that this pull request does not yet use this functionality anywhere.
How was this patch tested?
Added VariableSubstitutionSuite for unit tests.

Test build #56414 has started for PR 12538 at commit 02274e7.

Test build #56414 has finished for PR 12538 at commit 02274e7.

This patch passes all tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
class VariableSubstitution(conf: SQLConf)

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/56414/
Test PASSed.

LGTM

Thanks - merging in master.


Full implementation of detection of identifier hiding

Detect identifier hiding for various structures, including expressions, functions, parameters, arguments, lets, aliases, etc
Detect such hiding for both exact matches and case insensitive matches
Output compiler warnings referencing the structure in question
Ensure the context of the structure is considered.  For example, remove from consideration an alias once the function body has been compiled
Tons of new tests and some updated tests.

Closes https://github.com/cqframework/clinical_quality_language/issues/426
Closes https://github.com/cqframework/clinical_quality_language/issues/721
Closes https://github.com/cqframework/clinical_quality_language/issues/1254

In review we split out a couple of additional stories here:
#598
#1280


fix: update types entry in package.json

After installing latest version of @sentry/profiling-node the types are not detected:

Seems like after recent changes tsconfig.base.json uses outDir: lib/types

But package.json is not updated:

Thank you @sitek94, not sure how we didn't notice that one.


Not an actual issue

I couldn't find another way to contact you directly, figured this might be a good option. I'm not sure if you're aware of this, but someone else on GitHub is putting out 4 identical mods (suspiciously look like RATs) under your name. They tried to get me to download one and made sure I knew it was an AltPapier mod, but couldn't tell me where they got it. All 4 mods have the exact same size, and from what I could tell at a cursory glance, the exact same folder structure within the .jar file. I didn't do a deep dive into them though. I didn't want them on my PC longer than needed.
https://github.com/AltPapierMods

most likely a rat I have no idea who tries to impersonate me there but I highly recommend not downloading anything from their repos

also reported his profile to github will see what happens


Cache made on Ubuntu works on Ubuntu but fails on windows

Hi,
Today I have got the odd error, that when I'm trying to retrieve cache from ubuntu on windows it just fails. When I'm trying to get the same cache on Unbutu - everything works fine. The same YAML code was working yesterday, I even rescheduled that builds and a problem also occurred for them.
I'm using action/cache@v3 some logs are below:
Received 0 of 267052384 (0.0%), 0.0 MBs/sec
Received 88080384 of 267052384 (33.0%), 42.0 MBs/sec
Received 192937984 of 267052384 (72.2%), 61.3 MBs/sec
Received 267052384 of 267052384 (100.0%), 54.4 MBs/sec
Cache Size: ~255 MB (267052384 B)
"C:\Program Files\Git\usr\bin\tar.exe" --use-compress-program unzstd -xf D:/a/_temp/df67cde0-09e7-4980-809c-f3c3e3712478/cache.tzst -P -C D:/a/mono-repo/mono-repo --force-local
tar (child): unzstd: Cannot exec: No such file or directory
tar (child): Error is not recoverable: exiting now
/usr/bin/tar: Child returned status 2
/usr/bin/tar: Error is not recoverable: exiting now
Warning: Failed to restore: Tar failed with error: The process 'C:\Program Files\Git\usr\bin\tar.exe' failed with exit code 2

Hi @GC-Configit
Could you please more information such as

are you using hosted runner or did the workflow run on self-hosted runner?
If the workflow is running on a public repo, could you share the link? If not, is it possible to share the debug logs for this step?
What is the version of the tar used in ubuntu vs windows?

I have found the issue. When I forced actions/github to use @3.0.5 it's working. So I see the issue with the lasted release. For @3.0.5 build is working fine

I'm using host runner
I'm not sure if I can provide for you debug logs, I need to ask my management
I'm using ubuntu-lastest and windows-2022

This might have been caused by https://github.com/actions/cache/pull/887 . We are looking into it. Thank you.

@GC-Configit Can we get the workflow file (cache relevant parts only) which you are using? Thank you.

#just the step that is used for create cache ${{inputs.CACHE_KEY_BASE}} contains only base part of the key

name: Cache sub-domain-name
uses: actions/cache@v3
with:
key: ${{inputs.CACHE_KEY_BASE}}-sub-domain-name
path: test-binaries/sub-domain-name

next here I retrive cache by using this set of actions

if: ${{ runner.os == 'Windows' }} # Workaround required when using cache action across operating systems. See https://github.com/actions/cache/issues/591
name: Use GNU tar not BSD tar
shell: cmd
run: |
echo "Adding GNU tar to PATH"
echo C:\Program Files\Git\usr\bin>>"%GITHUB_PATH%"

name: Cache test binaries
uses: actions/cache@v3 # if I swtich in that place to<EMAIL_ADDRESS>my workflows are fine
id: downloadCache
with:
path: ${{inputs.path}} #so here path and key will be the same like above
key: ${{inputs.key}}

Hi @GC-Configit, I see you are using this step as a workaround.
- if: ${{ runner.os == 'Windows' }} # Workaround required when using cache action across operating systems. See https://github.com/actions/cache/issues/591
 name: Use GNU tar not BSD tar
 shell: cmd
 run: |
   echo "Adding GNU tar to PATH"
   echo C:\Program Files\Git\usr\bin>>"%GITHUB_PATH%"

It should not be required as the cache action should work as it is on both environments. If you could try to run your workflow after removing this step?

@pdotl
I've tried with out that workaround and it still failing for windows and for ubuntu its fine. Just output is like it not hitting cache key but that's odd because the same cache key is used in ubuntu and there is working fine
Prepare all required actions
Getting action download info
Download action repository 'actions/cache@v3' (SHA:f4278025ab0f432ce369118909e46deec636f50c)
Run ./.github/actions/download-cache
  with:
    path: test-binaries/sub-domain-name
    key: tests-726495f1916ed5a215b939f19cabab2efa7ef1be-156-sub-domain-name
    cacheHitCheck: true
  env:
    CACHE_KEY: tests-726495f1916ed5a215b939f19cabab2efa7ef1be-156
Run actions/cache@v3
  with:
    path: test-binaries/sub-domain-name
    key: tests-726495f1916ed5a215b939f19cabab2efa7ef1be-156-sub-domain-name
  env:
    CACHE_KEY: tests-726495f1916ed5a215b939f19cabab2efa7ef1be-156
Cache not found for input keys: tests-726495f1916ed5a215b939f19cabab2efa7ef1be-156-sub-domain-name

I have the same issue. The only difference I create cache on windows-latest and restore it on macos-latest. It stopped working today. Removing workaround didn't help.

@pgrivachev I just downgraded the version, just try to change from the actions/cache@v3 to<EMAIL_ADDRESS>(previous release) for last release 3.0.6 the cache is just not working  :/

I've also encountered the issue.
I created cache on ubuntu and it is available for ubuntu and macOS but not Windows. I've created a matrix for my cache creation job and now the two caches seem to be distinct while having the same cache keys.
So whatever changed it seems to only affect windows runners.

@mladedav just try to add this workaround for windows before you are  using actions/cache@v2 , it should be probably working:
- if: ${{ runner.os == 'Windows' }} # Workaround required when using cache action across operating systems. See https://github.com/actions/cache/issues/591
 name: Use GNU tar not BSD tar
 shell: cmd
 run: |
   echo "Adding GNU tar to PATH"
   echo C:\Program Files\Git\usr\bin>>"%GITHUB_PATH%"

@GC-Configit @mladedav, so without using the workaround(using gnu tar instead of bsd tar in windows), the expected behaviour is caching on windows can cause a different cache save even with same key due to difference in compression algorithm used. Please see here in README. So you were correct that the above workaround is required to reuse the same cache across windows.
However, it is clear that the workaround is now broken in the latest release. Please use the previous version v3.0.5 incase this is causing an issue in your workflow while we are looking into resolving this issue.

@GC-Configit @mladedav we have patched the latest version of actions/cache to work again with the above workaround. Please test with the latest version using actions/cache@v3 to see if it works for you.

On my workflows the problem was solved, thanks @pdotl

#888


ERROR SSL connection has been closed unexpectedly

Hello,
Using django-q 1.3.2, i suddenly have this error:
[Q] ERROR SSL connection has been closed unexpectedly

Looking into issues, i see a similar thing in a 2016 issue.
Does anyone experience this and solve it ?
Thanks for help :-).
Regards

getting same on heroku, unfortunately. googling says it might be related to the connection being started before the fork

Any word on this issue? Also on Heroku.

I fixed it (today) by setting 'CONN_MAX_AGE to 0 in my production settings.
if PYTHON_ENV == "production":
    import django_heroku
    django_heroku.settings(locals(), logging=False)
    locals()['DATABASES']['default']['CONN_MAX_AGE'] = 0


fix: requst form data and error handling

:tada: This PR is included in version 1.0.6 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


OpenSSL: get selected ALPN protocol

Get the selected protocol for a socket after one has been negotiated through ALPN.

Merged as 97011f3de7b7eb35d6557a876173eee8d1b3b359
Thank you!


[sFlix] cannot play videos due to type "Null"

Extension information
sFlix
Steps to reproduce

search "the big bang theory"
choose any of the episodes.
Watch and click the play button

Miru version
1.8.1
Other details
it said
type 'Null' is not a subtype of type 'Map<String,dynamic>'

Acknowledgements

[X] I have searched the existing issues and this is a new ticket, NOT a duplicate or related to another open issue.

what extension are you using?


How fit should be the bounding box to the object?

I am trying to work on my own dataset using YOLO3.
I have a couple of questions related to it.

How close should the annotation bounding boxes to the original object in the image. Right now, I am using bounding boxes leaving a couple of pixels around the perimeter.

There are almost half of the objects that are not predicted as objects. How to minimize the false negatives? Any suggestions are welcome.

Any suggestions on detection of small images that are not seen in training dataset (out of range for anchor boxes)

Thanks in advance!

Hi @aravind3134

The closer the better, but even you have more pixels around, during the training the model should fitting/understand.

a) More samples, the more images the better, helps the model generalize.
b) More epochs, sometimes the model takes time to fit
c) In config.json, increment "train_times", keras-yolo3 implementation uses data augment to each image, then you when incrementing "train_times" it is like to have more samples.

Is easier if you increment the dataset to train with small images.


Finalize or seal all case classes

Look for case classes that aren't final or sealed abstract (a technique to hide undesired apply and copy methods), and make them so.  There is no reason to allow inheritance of case classes.

Hey there @richashworth and me are looking at this


Resurrect SD card operation

Combining CIPO lines directly without regard to Chip Selects is risky, and in particular the line appspi_d1 from the flash is tri-stated without a pullup resistor on the FPGA board.
Modifications to the top_verilator implmentation to match the top_sonata implementation more closely, and paving the way for the introduction of the microSD card DPI model (already built and operational).
Without these changes the flash works only by virtue of the fact the the Sonata FPGA board carries a pullup on microSD card CIPO line, and the SD card is unusable because the flash CIPO does not. With these changes in place, and appropriate updates to the software that drives the microSD card and LCD, both the reading of SD card filing systems and the basic video player are operational once more.
@elliotb-lowrisc FPGA build remains timing clean (v2022.2), but it would be worth giving it the once over, please.

I'm fine with CIPO selection being returned to the pinmux; it's only implemented in sonata_system presently because all of the signals to/from that SPI controller have been removed from the pinmux.

On point 2. I imagining most uses of the pinmux will see things get setup immediately after RTOS boot so for this SPI you'd mux to the SD card and leave the flash non-connected. This then gives the  pleasing property that the software cannot modify the boot medium.

For what it's worth, the current changes don't seem to have caused a drop in overall QoR when building with Vivado 2021.1

Closing this as it's been solved by #326


On widget added to editor return a reference to DOM element

On widget added to editor return a reference to the widget first DOM element

addWidget method returns undefined

Use ...Closes #issue... or ...Fixes #issue... instead of ...Implements #issue... to close github issues automatically.

It is not closed! See my previous comment

Weird, code seems ok... could you provide a snapshot of the widget's DOM?
thanks
2016-05-10 10:40 GMT+02:00 Antonio Tapiador<EMAIL_ADDRESS>
Reopened #152 https://github.com/P2Pvalue/swellrt/issues/152.
—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
https://github.com/P2Pvalue/swellrt/issues/152#event-655442811


It should also have an option to change screenshots into text saying what was bought/sold
Sent with GitHawk

Screenshots are removed in v2


New pixel twilio

Checklist

[ ] I ran npm test locally and it passed without errors.

[x] I only edited the _data/pixels.json file.

[ ] I entered the username in the pixels.json that I'm also using to create this pull request.
[ ] I acknowledge that all my contributions will be made under the project's license.

new pixel


Close IOUringEventLoop wakeup/eventfd close shutdown race

Motivation
There is a race condition when shutting down the event loop where the eventFd write performed in the wakeup() method may actually hit a different fd if it's closed and reassigned in the meantime.
This was already encountered and addressed in the epoll case.
Modifications
Similar to what's done for epoll, in IOUringEventLoop:

ReinstatependingWakeup flag which tracks when there is a wakeup pending (CAS of nextWakeupNanos performed by other thread in the wakeup() method)
Add logic to the cleanup() method to wait for corresponding READ CQE before closing the eventFd
Remove unused fields from IOUringCompletionQueue (cleanup)

Result
No event loop shutdown race

@netty-bot teat this please


Is json null value not supported?

So if my property is nil object mapper emits nothing.  null is a valid json value.  Is there a configuration of objectmapper that supports this?

Doesn't look like it currently. The solutions in #263 might help point you in the right direction for a solution specific to you.

You can manually set the Mapper to include null values like so:
let json = Mapper<T>(context: nil, shouldIncludeNilValues: true).toJSON(object)
where T is your Mappable type.

@alum is correct.


how to install

Hi, maybe silly, but i can't get the plugin running.
requirements are set
ran composer update (in my project, however do not understand what should happen here, nothing's changed in my composer.json)
getting in nvim E117: Unknown function: phpcd
Want to try this out badly, as of lacking in any "real" php autocomplete
I'm on OSX El Capitan
THX
Martin

@wysiecki Please offer you init.vim and the full error message. Thanks.

Hello @wysiecki ?


chore(react-email): Bump render version

fix: upgrade render version to 0.0.9
fix: remove deprecated app dir experiemental flag from next config

Upgrades resend render version from 0.0.7 to 0.0.9 to fix renderToReadableStream issue.
Also removes appDir experimental flag as it is now deprecated

Is it possible to merge this PR, or is there even a way to test this PR?

Thank you for the fix! Can someone merge this?
https://github.com/resend/react-email/issues/1029
The issue above has been present for a month, I believe this fixes it. Thanks!

I've moved to https://github.com/shellscape/jsx-email and it works flawlessly.

Closing this in favor of #1073. This has been released on react-email@canary everyone and should be working without problems.


ModuleNotFoundError: No module named 'pandas'

I tried all the version above >2.1.6 with python version 3.6.9. I am getting issue for pandas binaries as of now. I am not getting any clue though.
This issue is raised earlier by others too. Do we have any plan to fix this bug in future??
Thanks,
Vinay

@vnkesarwani is your issue exactly as described in #1017? If not, please re-open this issue and provide at least an equivalent amount of detail as in #1017 so I can try to reproduce the problem.
As to fixing #1017, That should go out in the Pex 2.1.21 release tracked by #1078 next week.


spi_master example stops updating display after a few seconds (IDFGH-1023)

Environment

Development Kit:      [ESP32-Wrover-Kit]
Kit version (for WroverKit/PicoKit/DevKitC): [v3]
Module or chip used:  [ESP32-WROVER]
IDF version (run git describe --tags to find it):
v4.0-dev-402-ga20d02b7f (also was occurring in v3.3-beta1-4-g23b6d40c5)
Build System:         [Make]
Compiler version (run xtensa-esp32-elf-gcc --version to find it):
xtensa-esp32-elf-gcc.exe (crosstool-NG crosstool-ng-1.22.0-80-g6c4433a5) 5.2.0
Operating System:     [Windows]
Power Supply:         [USB]

Problem Description
SPI_MASTER example display freezes after a few seconds. I added a printf("Frame %d\n",frame);
to display_pretty_colors which shows the frame counter continuing to increase although the display is frozen. The display appears to fleeze somewhere around frame 45.
Expected Behavior
Sinusoidal functions in pretty_effect_calc_lines() should update the display indefinitely.
Actual Behavior
For some reason the updating stops, although the loop continues to execute.
Steps to repropduce
Copy  $IDF_PATH/examples/peripherals/spi_master to working folder
make flash && make monitor
Code to reproduce this issue
https://github.com/espressif/esp-idf/tree/master/examples/peripherals/spi_master

Debug Logs
$ make monitor
Toolchain path: /opt/xtensa-esp32-elf/bin/xtensa-esp32-elf-gcc
Toolchain version: crosstool-ng-1.22.0-80-g6c4433a5
Compiler version: 5.2.0
Python requirements from C:/esp32/esp-idf/requirements.txt are satisfied.
MONITOR
--- idf_monitor on com14 115200 ---
--- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
ets Jun  8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x3a (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:6296
load:0x40078000,len:11308
load:0x40080400,len:6700
entry 0x40080764
I (28) boot: ESP-IDF v4.0-dev-402-ga20d02b7f 2nd stage bootloader
I (28) boot: compile time 22:41:42
I (43) boot: Enabling RNG early entropy source...
I (43) boot: SPI Speed      : 40MHz
I (43) boot: SPI Mode       : DIO
I (45) boot: SPI Flash Size : 4MB
I (50) boot: Partition Table:
I (53) boot: ## Label            Usage          Type ST Offset   Length
I (60) boot:  0 nvs              WiFi data        01 02 00009000 00006000
I (68) boot:  1 phy_init         RF data          01 01 0000f000 00001000
I (75) boot:  2 factory          factory app      00 00 00010000 00100000
I (83) boot: End of partition table
I (87) esp_image: segment 0: paddr=0x00010020 vaddr=0x3f400020 size=0x1ca08 (1172
56) map
I (137) esp_image: segment 1: paddr=0x0002ca30 vaddr=0x3ffb0000 size=0x02190 (  8
592) load
I (141) esp_image: segment 2: paddr=0x0002ebc8 vaddr=0x40080000 size=0x00400 (  1
024) load
0x40080000: _WindowOverflow4 at C:/esp32/esp-idf/components/freertos/xtensa_vecto
rs.S:1779

I (144) esp_image: segment 3: paddr=0x0002efd0 vaddr=0x40080400 size=0x01040 (  4
160) load
I (154) esp_image: segment 4: paddr=0x00030018 vaddr=0x400d0018 size=0x15bb4 ( 89
012) map
0x400d0018: _flash_cache_start at ??:?

I (193) esp_image: segment 5: paddr=0x00045bd4 vaddr=0x40081440 size=0x07f48 ( 32
584) load
0x40081440: esp_dport_access_stall_other_cpu_start at C:/esp32/esp-idf/components
/esp32/dport_access.c:154

I (212) boot: Loaded app from partition at offset 0x10000
I (212) boot: Disabling RNG early entropy source...
I (213) cpu_start: Pro cpu up.
I (216) cpu_start: Application information:
I (221) cpu_start: Project name:     spi_master
I (226) cpu_start: App version:      1
I (231) cpu_start: Compile time:     Apr 22 2019 22:42:57
I (237) cpu_start: ELF file SHA256:  3844daf3cda66e3e...
I (243) cpu_start: ESP-IDF:          v4.0-dev-402-ga20d02b7f
I (249) cpu_start: Starting app cpu, entry point is 0x40080f38
0x40080f38: call_start_cpu1 at C:/esp32/esp-idf/components/esp32/cpu_start.c:267

I (0) cpu_start: App cpu up.
I (260) heap_init: Initializing. RAM available for dynamic allocation:
I (267) heap_init: At 3FFAE6E0 len 00001920 (6 KiB): DRAM
I (273) heap_init: At 3FFB3730 len 0002C8D0 (178 KiB): DRAM
I (279) heap_init: At 3FFE0440 len 00003AE0 (14 KiB): D/IRAM
I (285) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
I (292) heap_init: At 40089388 len 00016C78 (91 KiB): IRAM
I (298) cpu_start: Pro cpu start user code
I (316) cpu_start: Starting scheduler on PRO CPU.
I (0) cpu_start: Starting scheduler on APP CPU.
LCD ID: 00FFFFFF
ST7789V detected.
LCD ST7789V initialization.
Frame 1
Frame 2
Frame 3
...

Other items if possible
spi_master_files.zip

How would I go about troubleshooting this? The main loop is still running. Do I have defective hardware, or has anyone else seen this issue?

No views?

hi ,solve it? i meet also meet it. i want to keep dispay ,but no idea to do


removed unread assignment in sed.c

clang scan-build flags up 'to' as being unread, so clearing from code.

Applied.


Line-of-Sight Structure-Enhanced Ray-Tracing Halos Rendering for External Convergence and Shear

Line-of-Sight Structure-Enhanced Ray-Tracing Halos Rendering for External Convergence and Shear
Description:
This pull request introduces an enhancement to the ray-tracing halos rendering mechanism. It incorporates both large-scale structures using GLASS and small-scale structures via the halo mass function.
Key Features:

Line-of-Sight Structure Rendering: This implementation utilizes the SkyPy halo module for the line-of-sight structure. It's worth noting that the currently used SkyPy halo module has not been merged into the main SkyPy branch, hence we're temporarily making use of Skypy_halos_duplicate.
Ray-Tracing Computations: For a given sky area, this feature generates halos within the corresponding light cone. It then employs ray-tracing techniques to compute the distribution of convergence ( $\kappa_{ext}$ ) and shear ( $\gamma_{tot}$ ).
Negative Mass Sheet Option: Users have the flexibility to generate a negative mass sheet which can be used for kappa correction.
Demonstrative Notebook: A notebook has been added to provide a hands-on demonstration of this feature.

Next Steps:

Testing and Documentation:

Test Functions: Enhance and finalize the test functions to ensure the feature's robustness.
Notebook: Refine the notebook to provide clearer demonstrations and examples.
Documentation: Improve the documentation to ensure comprehensive understanding and ease of use for the users.

Incorporate $\kappa_{ext}$ Correction:

We aim to introduce a correction factor for $\kappa_{ext}$:

$$ 1 - \kappa_{ext} = \frac{(1-\kappa_d)(1-\kappa_s)}{1-\kappa_{ds}} $$
This will ensure a more accurate representation and calculation in our rendering mechanism.
Acknowledgements:

Guidance and assistance from: @sibirrer  .
Feedback and suggestions from: @ajshajib .
Additional help from: @nkhadka21 .

We kindly request a review of this feature, and are open to further feedback and suggestions.

Dependency Mismatch in Pre-commit:
I encountered an error during the pre-commit checks. It seems the hashes for building dependencies don't match. I suspect this might be due to some local modifications I made in Lenstronomy to incorporate new features, particularly the $\kappa_{ext}$, $\gamma_{ext}$ correction. It would be great if someone can help review or suggest a workaround to this issue.

Redshift-based Categorization:
I've updated the method to segregate halos and mass sheet corrections into two distinct categories based on their redshift values: observer-deflector (od) and deflector-source (ds). This change allows for more precise lens modeling and analysis.

In Preparation Updates:
Introduced a correction factor for $\kappa_{ext}$ as follows:
$$ 1 - \kappa_{ext} = \frac{(1-\kappa_d)(1-\kappa_s)}{1-\kappa_{ds}} $$
Additionally, computed the external shear $\gamma_{ext}$ :
$$ \gamma_{ext} = \sqrt{(\gamma_{d1}+\gamma_{s1}-\gamma_{ds1})^2+(\gamma_{d2}+\gamma_{s2}-\gamma_{ds2})^2} $$

Implement correction factors for external convergence and shear
Introduced a correction factor for $\kappa_{ext}$ as follows:
$$ 1 - \kappa_{ext} = \frac{(1-\kappa_d)(1-\kappa_s)}{1-\kappa_{ds}} $$
Additionally, computed the external shear $\gamma_{ext}$ :
$$ \gamma_{ext} = \sqrt{(\gamma_{d1}+\gamma_{s1}-\gamma_{ds1})^2+(\gamma_{d2}+\gamma_{s2}-\gamma_{ds2})^2} $$
In Preparation Updates:

Methods for computing the maps of $\kappa_{ext}$ & $\gamma_{ext}$ for different zd zs

Jupyter Notebook and docstring for new features

Test function and other minor updates (e.g. readme file for halos.yml)

Fix pre-commit problems

Now we can compute the maps of $\kappa_{ext}$ & $\gamma_{ext}$ for different zd zs with the MSD correction
A new Jupyter Notebook is added for above feature

In Preparation Updates:

[ ] A way for inputting $z_d$ & $z_s$ outputting correlated $\kappa_{ext}$ & $\gamma_{ext}$
i.e., finding a map (better probabilistic generative models like VAE or a brute force solution) from a 2D space to a new 2D space with large amout of data like($z_d$, $z_s$, $\kappa_{ext}$, $\gamma_{ext}$)

[ ] Test function and other minor updates (e.g. readme file for halos.yml) & Fix pre-commit problems

Debug for the halos number density
New density visualized plot with different Min_mass (in solar mass)

Current Stage Results
Kappa Gamma joint distribution examples
Without mass sheet correction, for different deflector, source redshifts
comparison between with & without non-linear LOS correction
(halo mass $10^{12}$ to $10^{16}$ , sky area  $0.0001 deg^2$)

With mass sheet correction, the convergence maps from a random halos rendering
(halo mass $10^{12}$ to $10^{16}$ , sky area  $0.0001 deg^2$)

The mass sheet correction is still slightly inaccurate; we will work on improving it later.

This code is good for code review @sibirrer @ajshajib
Key Features:

External Convergence and Shear distributions calculations:

This implementation utilizes the halo rendering module for the line-of-sight structure.
Calculate the distributions w/ or w/o mass-sheet correction, non-linear correction... , redshift maximum, halos mass range...
Contains Code Combining the Large Scale Structure and Halos rendering

Using the distributions for lensing test

Demonstrative Notebook: notebooks has been added to provide demonstration of these feature.

@sibirrer good for review. The mass-sheet updated, the halos_lens class is split.

@sibirrer the notebook is updated, good for further reviews.

@nkhadka21 from my side, TZ's PR is ready to be merged (modulo the minor conflict that will be resolved). Can you look through the files and see whether there are any issues or requests? Thank you!

@nkhadka21 this pull request is good for reviewing, thanks!


{Network} az network application-gateway frontend-ip/frontend-port: Migrate commands to codegen v2

Related command

az network application-gateway frontend-ip
az network application-gateway frontend-port
Description

Total: 12 commands
Testing Guide

History Notes

[Component Name 1] BREAKING CHANGE: az command a: Make some customer-facing breaking change
[Component Name 2] az command b: Add some customer-facing feature

This checklist is used to make sure that common guidelines for a pull request are followed.

[ ] The PR title and description has followed the guideline in Submitting Pull Requests.

[ ] I adhere to the Command Guidelines.

[ ] I adhere to the Error Handling Guidelines.

Network


WIP: Library rewrite

DO NOT MERGE YET
As Flutter has completely changed their code for desktop embedding, I've decided to basically rewrite this library based on the new changes. In its current state, this library will open a GLFW window and render with the latest Flutter beta. Interaction and everything else is not implemented yet and is still being worked on.

Wow, this is fantastic work! I have been thinking about it, but still haven't got the time. BTW, I've moved ffi stuff to flutter-engine-sys and use bindgen to automatic generate bindings. ffi.rs probably isn't needed.

Hey, eagle. I've add you as a collaborator. Thanks for your long term commitment into this project. : )

First of all, thank you for adding me :) I'll close this PR now and push my branch directly to this repo.
Yes, the ffi.rs file isn't needed anymore, but I didn't yet clean up properly as there's still a lot to do.


How to set font for Hint/Tooltip?

Godot version:
Latest release: 3.2.3 stable official
OS/device including version:
Windows10/Windows7/Linux Manjaro
Issue description:
I set the font for a specific button, and the text on it uses that font without problems, but the hint(Tooltip) isn't using it, i tried changing the editor font but it didn't affect it. I said button but i also tired textedit, I think its general
Normally this isn't a problem but I was experimenting with using Kurdish-Sorani characters and they don't appear at all without font
By the way
How is the progress on BiDi/RTL support?
Another question please
I tried fixing the flipped&disjoined Kurdish (or Arabic /Persian/etc...) characters by writing a script that converts them on the fly, Like this:

writing سڵاو in the editor results in و‌ا‌ڵ‌س
So when printing, my script first flips it س‌ڵ‌ا‌و
Then based on context replace the standalone characters with their respective joined versions ﺎوﺳ here is the problem, that ڤ (It isn't he only one) character version which my browser cant render is Private use (according to windows Character Map), it should look like

No problem though since I just need to use the correct font
BUT My Actual Problem is that godot does not accept this character at all, i try putting it in the code editor and it throws (Parser Error: Parse error: Unknown character)
That character is a 3 byte utf-8, is there a fundamental problem here? Godot doesn't accept the full Unicode characters?
Thanks

See https://godotengine.org/article/complex-text-layouts-progress-report-1 and https://godotengine.org/article/complex-text-layouts-progress-report-2.
This work is being done for Godot 4.0 and can't be backported to the 3.2 branch.
You can try @bruvzg's libgdtl for the 3.2 branch, which supports and subset of what's being implemented for Godot 4.0, and can be used as a C++ module (if you build the engine yourself) or GDNative plugin (check the "Releases" page).

Regarding the question on setting the font for tooltips, you have two options:

Change the font theme item for TooltipLabel in your Theme resource. See the recently written documentation about this (not online yet): https://github.com/godotengine/godot/blob/d0a5ef9c7a79e24ec04643ee629f952b4077e6fe/doc/classes/Control.xml#L848-L859 (see Label documentation for a list of its theme properties, which are the same for TooltipLabel).
Make your own custom tooltip with _make_custom_tooltip:
https://github.com/godotengine/godot/blob/d0a5ef9c7a79e24ec04643ee629f952b4077e6fe/doc/classes/Control.xml#L60-L85

That being said, this is an issue tracker for bug reports, and not for user support. Such questions would be best asked and answered on the Godot Q&A.


Question

If I already use Madmagic's client for Quest rich presence (which now has been updated to work with Quest 2 through a SideQuest command line prompt), is installing this client for your Beat Saber mod still necessary? Would it work for me to simply use the other client, or is the mod proprietary to this particular client of yours? Months ago I tried this client and never got it to work, but the other one has been working fine for me. Thanks.

Conversation has been finished on Discord.
TL;DR: There were some issues, which were caused by missing core mods. This was also the cause of this client not working.


[rancher-compose] sidekicks, volumes-from, and links oh my

Running this compose file makes rancher-compose do nothing: https://gist.github.com/stresler/aedf50d266dbc5e24233
My guess is that between the dependencies of sidekicks, volumes-from, and links it is stuck in a loop waiting for itself to finish.

Reported by @stresler on IRC who now wins a kewpie.

Any suggestions how to avoid this bug while fix is not ready?

+1

In this case it is Rancher (or docker?) not handling a circular dependency correctly.  The compose file I had there doesn't actually need the links section because all sidekicks are automatically linked.
However, the presence of them shouldn't stop rancher-compose cold.
The work around is to remove the links section where sidekicks are implemented.

Here's a simplified version that causes to get stuck in a loop:
service1:
  image: nginx
  volumes_from:
    - data
data:
  image: nginx
service2:
  image: nginx
  links:
    - service1
    - data
  labels:
    io.rancher.sidekicks: service1, data

If I remove the links section, it doesn't get stuck in a loop.
$ rancher-compose -p linktest3 up -d
INFO[0000] Creating stack linktest3

Verified with v0.8.0-rc1 and v0.63.1 that this docker-compose.yml works (has similar sidekicks/links/volumes-from)
portal:
  image: nginx
  volumes_from:
    - portal-data
  expose:
    - "7080:7080"
portal-data:
  image: nginx
  volumes:
    - /home/packet/portal
nginx-portal:
  image: nginx
  expose:
    - "9080:80"
  links:
    - portal
    - portal-data
  labels:
    io.rancher.sidekicks: portal,portal-data
  volumes_from:
    - portal-data
Portal-LB:
  restart: always
  ports:
    - "443:9080"
  image: rancher/load-balancer-service
  links:
    - nginx-portal:nginx-portal


please create a 1.1.2 branch

I finally got back to this project, I have a working wrap for 1.1.2

Done.


Disappearing Player Arms

Player's arms become invisible when equipping a bow in the idle stance in first person.

Yes, I see what is wrong. This was my mistake. I can fix it quickly, but I'm not sure how quickly we can do another stealth update.
Alternatively you can try enabling the bThirdPersonArmsBow=1 or in game: Shift+Home->View->General->Third Person Arms Bow, that fixes the disappearing arms when the bow is sheathed, but it then also doesn't use the first person arms when the bow is drawn (but not when you're actually aiming/firing).

I've pushed a super stealth update: https://github.com/ArranzCNL/ImprovedCameraSE/releases/download/v1.0.0/ImprovedCameraSE-<IP_ADDRESS>z

You are amazing. Thank you!


Rmeove LLM Bash and related bash utilities

Deprecate LLMBash and related bash utilities

Keeping the shell tool since it's just a wrapper


Update api.py - Allow null applianceSerialNumber

Allow null applianceSerialNumber

#130

Thank you a lot for your contribution!
Fixes #130

Thank you a lot for your contribution! Fixes #130

Not a problem, couldn't see the serial number referenced anywhere else so don't think it was going to impact anything. Thanks for my first approved PR 🥹


Feat: prometheus and grafana integration for the sidecar

Sorry about this, I once again opened a PR in the main repo instead of our fork


The job never stops

I am new to Python. I want to implement the schedule module in my script. According to the docs to run a job only once is like this:
'''
def job_that_executes_once():
# Do some work ...
return schedule.CancelJob
schedule.every().day.at('22:30').do(job_that_executes_once)
while True:
schedule.run_pending()
time.sleep(1)
'''
My problem is that in this way my script never stops. How can I make the script to stop after executing the job? Thanks for your help!

Return something from job that executes once and have it change the while True to False then it will stop after it's run.

Thank you. I will do that.


Cross Env on Windows (Possibly Other Platforms?)

Laravel Version: v5.4.15 (according to composer info)
PHP Version: 	php-7.1.1-nts-Win32-VC14-x64
Database Driver & Version:

N/A
Description:
Scripts contain:
"dev": "node node_modules/cross-env/dist/bin/cross-env.js NODE_ENV=development node_modules/webpack/bin/webpack.js # more options
I notice that https://github.com/laravel/laravel/blob/master/package.json has:
  "devDependencies": {
    "axios": "^0.15.3",
    "bootstrap-sass": "^3.3.7",
    "cross-env": "^3.2.3",
    "jquery": "^3.1.1",
    "laravel-mix": "^0.8.3",
    "lodash": "^4.17.4",
    "vue": "^2.1.10"
}

But when I updated (with yarn) I see:
  "devDependencies": {
    "axios": "^0.15.3",
    "bootstrap-sass": "^3.3.7",
    "cross-env": "^3.2.4",
    "jquery": "^3.1.1",
    "laravel-mix": "^0.8.1",
    "lodash": "^4.17.4",
    "vue": "^2.1.10"
  }

It seems that cross-env.js has "moved" to:
"dev": "node node_modules/cross-env/dist/bin/cross-env.js NODE_ENV=development node_modules/webpack/bin/webpack.js # more options
i.e. there's a dist directory!
Steps To Reproduce:

Find a Windows 10 system - I use a setup by "http://www.laragon.org" but I suspect any Windows 10 system with "nodejs" and either "npm" or "yarn" would do this;
Run npm run dev (or one of the other scripts)
See result below.

c:\laragon\www\drakes-auth (master)
λ npm run dev

> @ dev c:\laragon\www\drakes-auth
> node node_modules/cross-env/bin/cross-env.js NODE_ENV=development node_modules/webpack/bin/webpack.js --progress --hide-modules --config=node_modules/laravel-mix/setup/webpack.config.js

module.js:471
    throw err;
    ^

Error: Cannot find module 'c:\laragon\www\drakes-auth\node_modules\cross-env\bin\cross-env.js'
    at Function.Module._resolveFilename (module.js:469:15)
    at Function.Module._load (module.js:417:25)
    at Module.runMain (module.js:604:10)
    at run (bootstrap_node.js:394:7)
    at startup (bootstrap_node.js:149:9)
    at bootstrap_node.js:509:3

npm ERR! Windows_NT 10.0.14393
npm ERR! argv "C:\\laragon\\bin\\nodejs\\node.exe" "C:\\laragon\\bin\\nodejs\\node_modules\\npm\\bin\\npm-cli.js" "run" "dev"
npm ERR! node v6.9.4
npm ERR! npm  v3.10.10
npm ERR! code ELIFECYCLE
npm ERR! @ dev: `node node_modules/cross-env/bin/cross-env.js NODE_ENV=development node_modules/webpack/bin/webpack.js --progress --hide-modules --config=node_modules/laravel-mix/setup/webpack.config.js`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the @ dev script 'node node_modules/cross-env/bin/cross-env.js NODE_ENV=development node_modules/webpack/bin/webpack.js --progress --hide-modules --config=node_modules/laravel-mix/setup/webpack.config.js'.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the  package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     node node_modules/cross-env/bin/cross-env.js NODE_ENV=development node_modules/webpack/bin/webpack.js --progress --hide-modules --config=node_modules/laravel-mix/setup/webpack.config.js
npm ERR! You can get information on how to open an issue for this project with:
npm ERR!     npm bugs
npm ERR! Or if that isn't available, you can get their info via:
npm ERR!     npm owner ls
npm ERR! There is likely additional logging output above.

npm ERR! Please include the following file with any support request:
npm ERR!     c:\laragon\www\drakes-auth\npm-debug.log

[composer_package_json.zip](https://github.com/laravel/framework/files/845980/composer_package_json.zip)

How I Fixed It

Insert dist so that cross-env.js can be found.

Note: The attached package.json already has the fixes...

Update your package.json to reflect the changes in https://github.com/laravel/laravel/blob/master/package.json
Notice that we now use cross-env NODE_ENV=development instead of the absolute path.

cross-env invoked without a path only works if it's installed globally. This does not work with 5.4

@slavicd +1. Same issue from WIndows 10.


Adapt istio-installer after testing

Please have a look at the issues we faced during using the istio-installer.

/assgin @costinm

@costinm Could you have a look? Does it make sense?


5.7 - 14: Sửa Webhook - Sửa send actions Annotation deleted

Checked Annotation deleted hiển thị trạng thái on

https://onedrive.live.com/View.aspx?resid=495A9FD49F594800!152&authkey=!AIjA8V7ngGWbw7g


Error in Lab2_part1 code, there is no file other than .gitignore

I just merged in a pull request to solve this problem, please try running git pull to update your local repository.


eksctl: 0.191.0 -> 0.193.0

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/weaveworks/eksctl/releases.
meta.description for eksctl is: CLI for Amazon EKS
meta.homepage for eksctl is: https://github.com/weaveworks/eksctl
meta.changelog for eksctl is: https://github.com/eksctl-io/eksctl/releases/tag/v0.193.0
Updates performed

Golang update

To inspect upstream changes

Compare changes on GitHub

Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 0.193.0 with grep in /nix/store/q4g7y51b57blpcfjcbs7da15xbipcwyl-eksctl-0.193.0
found 0.193.0 in filename of file in /nix/store/q4g7y51b57blpcfjcbs7da15xbipcwyl-eksctl-0.193.0

Rebuild report (if merged into master) (click to expand)

3 total rebuild path(s)

3 package rebuild(s)

First fifty rebuilds by attrpath

eksctl
nuv

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/q4g7y51b57blpcfjcbs7da15xbipcwyl-eksctl-0.193.0 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A eksctl https://github.com/r-ryantm/nixpkgs/archive/14cdc1dfb008996aa0b339ff5aeeb9af0331f431.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/14cdc1dfb008996aa0b339ff5aeeb9af0331f431#eksctl

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/q4g7y51b57blpcfjcbs7da15xbipcwyl-eksctl-0.193.0
ls -la /nix/store/q4g7y51b57blpcfjcbs7da15xbipcwyl-eksctl-0.193.0/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
nixpkgs-review result
Generated using nixpkgs-review.
Command: nixpkgs-review

x86_64-linux

:white_check_mark: 2 packages built:

eksctl
nuv

Maintainer pings
cc @xrelkd @Chili-Man for testing.

[!TIP]
As a maintainer, if your package is located under pkgs/by-name/*, you can comment @NixOS/nixpkgs-merge-bot merge to automatically merge this update using the nixpkgs-merge-bot.

Add a :+1: reaction to pull requests you find important.

@NixOS/nixpkgs-merge-bot merge

@NixOS/nixpkgs-merge-bot merge


Just removed MapTile, using MapTileIndex instead

Tons of classes are impacted.
This is only the first step in the fixing of the "slight pause".

I'm afraid, it doesn't fix... I've got a video showing how it behaves with the code from this branch: slight-pause
What is strange is that the slight pause now happens everytime I zoom in in the same place, whereas before it only happened on the 1st time I zoomed in (then the tiles were already in memory, so the next zoom-ins were smooth). So I think somewhere along this, there was some problem with the overshoot cache. BTW is the overshoot cache still used, with this new approach?

I think I know why there's the slight pause. Actually when you change "integer zoom levels" I perform a kind of garbage collection, but in a sync way. I should do this async, or maybe one tile at the time. It's not a problem of overshoot cache, which doesn't exist anymore (I mean, in this specific PR). Thanks for testing and sorry about not having fixed that yet. I'll work on that from Sunday evening (CET). As agreed with @spyhunter99 it's ok if it's not part of the "official" 6.0.0, but I'd like to get rid of this issue soon.

No problem, this is a minor issue. Thank you for the efforts.
I'm not sure if it is a good idea to get rid of the overshoot cache. I mean, it could live side by side with the tile protection. Instead of only protecting the 3 zoom levels always, depending on the overshoot cache setting we could have more tiles left in memory. The 3 zoom levels might not be enough for someone (like me) who's deep zooming in and out all the time in the same region. But with the overshoot, I could control that. The tile protection would be at least 3 zoom levels, but we could let it grow more than that. When, in a past version, I set the overshoot to the absurd number 300, then I got really smooth zooms all the way down & up!

Oh, I just found an exception happening sometimes using this PR code:
 java.util.ConcurrentModificationException
                                               at java.util.HashMap$HashIterator.nextEntry(HashMap.java:787)
                                               at java.util.HashMap$KeyIterator.next(HashMap.java:814)
                                               at org.osmdroid.tileprovider.MapTileCache.garbageCollection(MapTileCache.java:85)
                                               at org.osmdroid.views.overlay.TilesOverlay$CacheTileLooper.finaliseLoop(TilesOverlay.java:318)
                                               at org.osmdroid.util.TileLooper.loop(TileLooper.java:45)
                                               at org.osmdroid.views.overlay.TilesOverlay$CacheTileLooper.loop(TilesOverlay.java:303)
                                               at org.osmdroid.views.overlay.TilesOverlay.protectDisplayedTilesForCache(TilesOverlay.java:182)
                                               at org.osmdroid.views.overlay.DefaultOverlayManager.onDraw(DefaultOverlayManager.java:124)
                                               at org.osmdroid.views.MapView.dispatchDraw(MapView.java:1136)
more...

The overshoot cache can work only in a LRU like context (which tiles are we supposed to get rid of otherwise?). And I'm afraid the LRU mechanism may be skewed by things like MapTileApproximater.
That being said, we can ignore this PR and fix the slight pause effect by removing tiles from memory in an async mode. Still a tricky part as concurrency exceptions may happen as you know!
Then, we may later create another issue - as an enhancement - more specific about how we would like the cache to work, and not about a bug to fix.

I think I'm close to something good, putting async here and there, for instance on Bitmap recycling. Still testing.

I'll push the (ultimate?) fix tomorrow.

Ok guys, this latest version might be the good one:

stronger java concurrency compliance
async bitmap recycling

Please test it and tell me what you think.

so i ran into a strange issue whereby the wrapped map did not display and momentarily flicker tiles, however it was a gray grid most of the time.

scrolling east (panning towards the left) caused all tiles to disappear
The minimap now flickers a lot, but the main map does seem improved, aside from the disappearing world

I just experienced the gray tiles, will fix that probably today.
Cannot reproduce the minimap flickering though.

I have good news: I managed to reproduce the flickering. On the main map though.
My educated guess: a 1<<zoom modulo to enforce in MapTileIndex for x and y, especially in multi world / intensively scrolled map.

Fixed: it was a world replication side effect.

This PR seems to fix the hang-on-detach issue! I need more tests, but so far so good.
However, the slight pause effect is still there...

confirmed that the world replication effect is fixed. i also took a quick video. On mapnik, it see a momentary full screen flicker when zooming across integer boundaries again. It doesn't appear very often on other tile sources. The minimap's flicker is also greatly reduced.
https://youtu.be/4gVVjjqyxJs

Talking about grey tiles, what do you think about these grey tiles here, that appear and disappear?
grey-tiles
Note that this always happened, it's not new. Don't know in which situations it happens, but seems to be when there are no cached tiles for many zoom levels. Note that the usual grid is not displayed, so it's a different thing.

I mean, these don't seem to be "grey tiles", they seem to be portions of the screen that fail to render. I think they don't quite match the tiles.

@miguel-porto do you think this is tile source specific?

I/TestRunner(  596): java.lang.IllegalArgumentException: MapTileIndex: Y (4) is too big for zoom (2)

I/TestRunner(  596): 	at org.osmdroid.util.MapTileIndex.throwIllegalValue(MapTileIndex.java:69)

I/TestRunner(  596): 	at org.osmdroid.util.MapTileIndex.checkValues(MapTileIndex.java:61)

I/TestRunner(  596): 	at org.osmdroid.util.MapTileIndex.getTileIndex(MapTileIndex.java:20)

I/TestRunner(  596): 	at org.osmdroid.views.util.OpenStreetMapTileProviderDirectTest.test_getMapTile_not_found(OpenStreetMapTileProviderDirectTest.java:61)

@spyhunter99 Thank you for extracting the error log. I just fixed it.

@spyhunter99 I don't know how offensive your https://youtu.be/4gVVjjqyxJs is supposed to be, but Youtube rejects it and I cannot see it.

@spyhunter99 I don't think it's source specific, but I can try other sources. However, I really think it is not a tile issue (those tiles are cached), but a redrawing issue, in which some portions of the screen are not invalidated? I suspect this because the shape of the grey areas is often like an L, irrespective of the region in which I'm zooming out.

hmm what the hell.

But this seems to happen only when you're offline and the only cached tiles you have are from very low resolutions and you're zooming out from a high zoom (so they're very amplified) -  I think you might be able to reproduce it. It's not a very big issue. Oh, and it only happens on zoom out, as if the app forgot to draw the marginal tiles.

memory usage is slightly higher on this branch, but the performance increase is worth it IMO. It's running about 20MB higher than master. Master seems to be running at 100MB at the moment but stable

@miguel-porto You should create a specific issue about your L-shaped gray tiles.
@spyhunter99 To be merged, then?

@monsieurtanuki  Yep, will do it, and make a better video showing the problem, also.

@monsieurtanuki i'm currently binary searching our commit history looking for when slight pausing first occurred. This won't help the christmas tree effect. I kind of feel like you did a lot of work that may not have been necessary.
here's what i have so far...
7eeeeb8 smooth floating zoom with approximateor
0990b70 zoom 29 smooth oct 1st
daa22b0 merge 834 jan 5 smooth
e3bf97 jan 10 smooth
50c275e jan 14 smooth
893dd5c jan 15 smoothish
8953af1 jan 17 pausing
6e75e4a jan 21 reasonable
7738dff jan 21  pausing present
i may have been at fault for this. still trying to narrow it down..

But the christmas tree effect is fixed already (don't remember exactly at which commit).

Yup the christmas tree effect is gone, however i'm now seeing flickering when crossing int zooms and slight pausing. It's the pausing that's bothering me.

I think that's because the overshoot cache is not used any more (I mean the slight pause). I also feel that the code in this PR more frequently shows the slight pause effect than previous versions. I think that's because of the overshoot cache, which now seems to be ignored (@monsieurtanuki correct me if I'm wrong).
@monsieurtanuki what if this PR is split in two, one for fixing the hang-on-detach, and the the rest to be thought later?

so the pausing i'm seeing is a slight jitter on zooming in. I've narrowed down the commit to 2f511b9 from jan 17, fix the zoom to bounding box demo. This has some minor changes in map view and projection. Perhaps they are related

@spyhunter99 Hard to believe the bounding box limits - which are not even used in the default demo - could have an impact on the memory cache.
@miguel-porto Correct, the overshoot cache is not used anymore. As discussed in the "async pre-cache" issue, the solution could be to have a composite cache: partly LRU with overshoot, partly with zooms +-1 protection. But the overshoot=300
statement stinks!

But I'm telling you, those were the smoothest zooms ever! Everything was kept in memory! And as far as I remember, I had no out of memory problems during that time.

@miguel-porto I'm currently coding something to take into account the overshoot. Should be OK by tomorrow.

@miguel-porto Should be OK right now ;)

Just tested it, I see a rather significant pause/lock up when using the built in zoom buttons, but only when zooming in. Zooming out is fine. Same goes for pinch zoom. Zoom in has around 1/4 sec pause. I can take a video if needed

@spyhunter99 I can see a pause when zooming in, but once you're on a specific region there's no pause when you zoom in or out: do you see the same behavior?
1/4 sec? That's a lot! I'll try to use an emulator (supposedly slow) to profile and detect the performance bottleneck.
Thank you guys for running tests, and sorry about their frequency.

That was a guestimate, it's quite noticable though. I'm seeing this on hardware on every zoom in

profiles says there's a lot time spent on the ui thread. it looks like saveTile method of sqltilewriter. Looking at optimizing this now

@spyhunter99 SqlTileWriter.saveTile obviously deserves some optimization:
List<Byte> list = new ArrayList<Byte>();
//ByteArrayBuffer baf = new ByteArrayBuffer(500);
int current = 0;
while ((current = bis.read()) != -1) {
	list.add((byte) current);
}

byte[] bits = new byte[list.size()];
for (int i = 0; i < list.size(); i++) {
	bits[i] = list.get(i);
}

More specifically, the ArrayList<Byte> to be populated byte by byte up for bitmaps around 50Kb is probably not the best choice.
In another project I wrote a piece of code similar to ByteArrayBuffer; I'll see if it's worth integrating it.
And I noticed there are similar pseudo-ByteArrayBuffer codes to optimize.
But I don't think that should impact strongly the slight pause effect in all cases. If I keep zooming in and out on the same area, all the tiles are either in the database or in memory, therefore SqlTileWriter.saveTile isn't called anymore.

First loop only seems to be there to count the size? Could rather be a buffered copy into an
https://docs.oracle.com/javase/7/docs/api/java/io/ByteArrayOutputStream.html
then byte[] bits = ByteArrayOutputStream.toByteArray().

@InI4 Yes, something like that, possibly with byte[ ] versions of read and write. Actually the first loop does not only count but also read each byte from the input stream.

cool, on it

Just wondering: there might be an improvement with HashMap<MapTileIndex, ...> with a custom hash code, something like zoom + x % 2^13 + y % 2^13, which would really discriminate tile indices.

After making the change, the pausing is noticeable reduced.
I'm seeing lots of the following in the log
02-10 08:45:06.713  1612  1677 W Bitmap  : Called reconfigure on a bitmap that is in use! This may cause graphical corruption!
Also, probably a separate issue, when using mapnick and landing on zoom 20 or so, the tile provider chain loops forever trying to load the tile. I recall there being a ticket for this at one point

optimizing the hash function is probably like shuffling the deck chairs on the titanic.
I'm going to start walking through diff's from this branch to the last known commit to master when the zooming was smooth. There's obviously something going on where. There were a few changes related to synchronization between background threads and the ui thread. I'm just guessing but it could be related to that

so interesting performance comparison.
master

with scale tiles on, performance is reasonable
with scale tiles off, very slow zooming in

this branch

with scale tiles on, performance is reasonable
with scale tiles off, performance is reasonable

ya know what. i'm ok with the performance on this branch now. it's definitely better than master. I'll start going through the code changes now... (good work @monsieurtanuki!)
@monsieurtanuki any other changes that you want to make before this is merged?
@miguel-porto any other comments?

optimizing the hash function is probably like shuffling the deck chairs on the titanic.

@spyhunter99 You made my day!
Well, I started coding it anyway. Then it appeared that it was not only perhaps useless - as you wittily noticed - but also counter productive - as I would be forced to create object instances instead of relying on  the Long / long symbiosis. OK, you won.
Nevertheless, I think I know what could be improved. Again. But this time I think it's the good one!
The problem when crossing the integer zoom boundaries is that when we loop on all tiles to be displayed, none of them are in memory and therefore we need to use the providers in order to retrieve them. That's the "slightly slow" part, because either we run a sync code that is potentially a bit slow (and surely includes synchronized statements) or we run an async code in order to do that. For each tile. If we need 16 tiles, we sync'ly create 16 new Runnables and run them async'ly.
My solution would be, in each tile display loop, to store the needed tiles, and to run at the end of the loop a unique Runnable that takes into account the 16 tiles (in the present case).

@monsieurtanuki If i'm understanding your comments on the map tile index, does this mean that all Mobac and similar based sql archives are now no longer valid because of the index change? or does this only effect the "cache" database?

ha we might have to rename this project monsiuerdroid by the time this is done.
hmm regarding the threading...mmm. How did the previous setup work? I know the tiles overlay had a looper/handler setup that would use the tile providers to pull the needed tiles on demand from where ever and that the tile provider itself was multi threaded background tasks.
Can we somehow avoid synchronized calls on the tile looper?

@spyhunter99 The new index computation in MapTileIndex only affects the memory cache.
And it also replaces MapTile every time it was used as a (zoom, x, y) container.
But nothing changed wherever a (zoom, x, y) combination was stored (in database for instance): the old indices are still used, therefore everything should work the same.
We just have now two ways of computing (zoom, x, y) as a long: the new one that is obviously bijective, and the legacy one.
Should we upgrade all legacy indices to the new version: maybe one day, if we drastically change something about the database anyway (e.g. one table per zoom level / per source). Do we have to? absolutely not. Though two different ways of computing a long index from (zoom, x, y) can be confusing.

My solution would be, in each tile display loop, to store the needed tiles, and to run at the end of the loop a unique Runnable that takes into account the 16 tiles (in the present case).

The first results look OK (no slight pause anymore - AFAIK), but I need some time to get a clean version of this.
@spyhunter99 What's the next move then? Merge what we already have, possibly in 6.0.0? Wait a couple of days until I'm done? Merge quietly in 6.1.0?

Are you talking about the hashcode() in MapTile or alike? Hashcodes are another hobby of mine.
Both the existing one and the one suggested above by @monsieurtanuki  do not look optimal to me. The worst is, that they are symmetric in x and y. That sends tile(z,x+1,y) and tile(z,x,y+1) to the same slot. That is not good, cause those tiles are very like to be used on the same screen.
I'd suggest something more mixing with multiplicators: zoom + 0x24A1*x + 0x18289*y . It might be possible to get the multiplicants tuned even better, when one knows, how many tiles are usually/maximally displayed on one screen and in cache. But the above be better than everything I have seen so far.

@InI4 Actually I was in the metro when I typed the suggested hashcode - I had to type fast.
To be accurate, what I had in mind was (zoom<<26) + (x% 2^13 <<13) + y % 2^13, which I believe make a unique hashcode in the conditions we are using map tiles.
Anyway I was trapped into contradictions: either my HashMap key is a Long and I use its build-in neighborhood with long, or I need to create an instance of a new Object everytime I use a HashMap key. Which now that I'm thinking is probably the case, as Long object are not created only for a small range of values that we don't use.
Do you think it's possible, within a HashMap with Long key, to override the Long hashcode?
But as @spyhunter99 remarked, it's not where we should have significative performance gains.

if there's more work required, we can wait for inclusion with v6.0.0

@monsieurtanuki that 2nd formula is of course much better! But, internally HashMaps in Java are restricted to arrays and Java arrays are restricted to int indexes. So, so for Java a feasible hashing should map to integers and not longs. This lets this 26/13 look too large. Also Java HashMaps do not use prime number sizes, but powers of 2, this puts the duty of mixing things over to the hashcode() method. Therefore, if you have time, you might still try to consider the formula I give, or augment your formula by a long->int mapping by a % reminder via a large, but int prime number ...

This version might be the good one!

This lets this 26/13 look too large

Not at all! The max zoom is 29, which needs 5 bits. 26+5=31. 31 < 32.
For the moment there's no strong need anyway to change the hashcode as 1- we rely on Long that provides its own hashcode and 2- there's a fair chance it won't improve our performances that much regarding all the other things we're doing beside using HashMaps.

https://youtu.be/N9NktziTHs4

@spyhunter99 I think we're reaching the performance relevancy limits of async code called in UI thread, and that we shouldn't go further.
I believe the best way to get rid of the slight pause effect is to pre-cache (#930): pre-loading data into memory in order to get the best performances on the UI thread. That will be part of 6.1.0.
We should ignore my latest push and merge just before it, when you said you were OK with the performances.
Btw it looks like I accidentally removed one of your comments. I don't know which one it was and how to put it back. Sorry about that.

Sorry I couldn't keep up with these big changes, but I can't wait to test this code!
BTW, the hang-on-detach issue is fixed with this code (well, the two-days-ago-code), I now tested a lot and never happened, so consider the issue closed (it was never open anyway...)

There's something broken in this code... most of my cached tiles won't load any more. But if I switch back to a past version, they're there, cached.

@miguel-porto are you building this branch from source or using the snapshot on sonatype?

OK it's not the compass, but possibly the scale bar overlay, minimap, or mylocation

Alrighty, the problem with the StartMapFragment is...... (on master and on this branch)
mMapView.setTilesScaledToDpi(false);
That's causing the pausing. There are some minor issues with the compass overlay but those are easy to fix.

@spyhunter99 I'm not an expert, large trout wise, but I think what you see is a threshold effect.
When mMapView.setTilesScaledToDpi(false); the tiles are smaller, therefore it takes more tiles to fill the screen. Remember, the trouble with integer zoom boundaries (assuming the memory cache is empty for the new zoom level) is that we need to refresh the whole screen. We loop on each tile and for each tile we have no quick access to memory cache, therefore we need an additional step to retrieve the tile bitmaps. That's the tally of those additional steps that makes the slight pause possible. And there are more additional steps with smaller tiles.

@spyhunter99 Yes, like @monsieurtanuki I also think that it's a matter of the number of tiles that have to be switched at zoom boundaries. IMO the mechanism finally just becomes visible with mTilesScaledToDpi set to false, because depending on the device there might actually be a multiple of tiles visible / to be switched around when zooming compared to mTilesScaledToDpi = true.
A little off topic, but shouldn't mTilesScaledToDpi = true be the default now? I remember when starting off with osmdroid, I thought it was unusable as everything was just too small, until I discovered setTilesScaledToDpi...

@spyhunter99 I'm building this branch from source, and I'm getting that creepy situation I described, lots of high-res tiles are not loaded at all. But I know I have them cached, cause switching back to an older version of this branch shows no problem.

@miguel-porto I didn't experience what you describe - which looks a bit like @spyhunter99 's video, but I must admit it looks bad.
I'm about to deliver some kind of rollback - probably today.

Will upload a video when possible, showing the behaviour of both versions.

I hope this version will suit you guys (no strange behavior, reasonable performances) and that we'll be able to merge.

The problem is gone (but the slight pause still there).
But are you sure you want to throw away the async loading? I didn't think much about it and didn't keep up with the recent changes, but it looks like a good solution to smooth things up. What I would imagine is, all the tiles load async from the cache DB, and while they're loading, what is displayed is the amplified tile from previous zoom (just like what happens when we're online). When a tile is finished loading, then it will replace the amplified previous zoom tile. We wouldn't need pre-cache this way, and the slight pause as well as the grey tiles would go away.

@miguel-porto Putting MapTileApproximater as the first provider in the list would partially do what you suggest. But the problem is that "having none of the tiles to be displayed in memory cache" causes the slight pause, regardless of the tile provider.
I'd prefer to merge what we have so far to 6.0.0, and deal with whatever pre-cache solution we invent in 6.1.0.

I agree, this PR is too large already. And as it is, it fixes the onDetach() issues, which is a priority IMHO.
Still hoping that the complete async loading will be possible, but that's eventually for another PR.

@spyhunter99 Ready to merge into 6.0.0?

let me test it out. if the studdering isn't fixed, i'm going to start rolling back commits on master until it's fixed, then that will become v6

@miguel-porto any idea what the actual fix was for the detach issue?

after testing, this is much improved on genymotion, still pausing on zoom in on hardware though

alrightly, after backtracking, the pausing looks like it was introduced with commit a622202, the merge of #790 which was merged on Dec 8th. Prior to that commit, the behavior during a pinch zoom, was to due the animation to scale on depend. On touch up, the animation ends, then the new required tiles are loaded.
At that commit, during the pinch animation, tiles are loaded on as they are needed, causing the pause in animation scaling.
That said, this whole pr does a good job of minimizing the pause, but not eliminating it. It's think it's probably the best compromise thus far.

@spyhunter99 The slight pause effect should be fixed by #930.
More memory is used now probably because the cache is bigger: the displayed tiles are protected now (in order to avoid the xmas tree effect) and so are the corresponding tiles of zoom levels +-1.
We'll introduce more flexibility on which tiles to protect in the memory cache (zoom levels +-2), or when to pre-cache tiles (triggered by a pinch-gesture in progress).
The animation scaling used to cause memory and network issues as it required unexpected far away tiles. And I'm sure the slight pause existed at that moment, but the UX wasn't impacted because the slight pause may have looked like a normal "rubber rollback" effect.
My opinion: explicit OK to merge.


[Scheduler Enhancement] Consider binding action when creating or recovering queue.

Description
Currently, binding action is not properly considered while creating or recovering queues.
It makes throttling for package actions work in an original namespace and actions from different namespaces share the same throttling limit.
This change will address the issue.
Related issue and scope

[ ] I opened an issue to propose and discuss this change (#????)

My changes affect the following components

[ ] API
[ ] Controller
[ ] Message Bus (e.g., Kafka)
[ ] Loadbalancer
[x] Scheduler
[ ] Invoker
[ ] Intrinsic actions (e.g., sequences, conductors)
[ ] Data stores (e.g., CouchDB)
[ ] Tests
[ ] Deployment
[ ] CLI
[ ] General tooling
[ ] Documentation

Types of changes

[x] Bug fix (generally a non-breaking change which closes an issue).
[ ] Enhancement or new feature (adds new functionality).
[ ] Breaking change (a bug fix or enhancement which changes existing behavior).

Checklist:

[x] I signed an Apache CLA.
[x] I reviewed the style guides and followed the recommendations (Travis CI will check :).
[x] I added tests to cover my changes.
[ ] My changes require further changes to the documentation.
[ ] I updated the documentation where necessary.

Codecov Report

Merging #5267 (23e7d57) into master (c5970a6) will decrease coverage by 75.68%.
The diff coverage is 0.00%.

@@            Coverage Diff             @@
##           master   #5267       +/-   ##
==========================================
- Coverage   80.27%   4.59%   -75.69%
==========================================
  Files         238     238
  Lines       14066   14079       +13
  Branches      574     566        -8
==========================================
- Hits        11292     647    -10645
- Misses       2774   13432    +10658

Impacted Files
Coverage Δ

...in/scala/org/apache/openwhisk/common/Logging.scala
41.85% <0.00%> (-44.94%)
:arrow_down:

...apache/openwhisk/core/service/WatcherService.scala
0.00% <0.00%> (-91.67%)
:arrow_down:

.../openwhisk/core/loadBalancer/FPCPoolBalancer.scala
0.00% <0.00%> (-33.21%)
:arrow_down:

...ontainerpool/v2/FunctionPullingContainerPool.scala
0.00% <0.00%> (-82.66%)
:arrow_down:

...ntainerpool/v2/FunctionPullingContainerProxy.scala
0.00% <0.00%> (-78.13%)
:arrow_down:

...k/core/containerpool/v2/InvokerHealthManager.scala
0.00% <0.00%> (-75.00%)
:arrow_down:

...e/openwhisk/core/scheduler/queue/MemoryQueue.scala
0.00% <0.00%> (-84.16%)
:arrow_down:

.../openwhisk/core/scheduler/queue/QueueManager.scala
0.00% <0.00%> (-83.02%)
:arrow_down:

.../main/scala/org/apache/openwhisk/core/WarmUp.scala
0.00% <0.00%> (-100.00%)
:arrow_down:

...ain/scala/org/apache/openwhisk/spi/SpiLoader.scala
0.00% <0.00%> (-100.00%)
:arrow_down:

... and 210 more

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 c5970a6...23e7d57. Read the comment docs.

LGTM


[Installation] Add support for proxy configuration

This PR adds support for installation when the server is located behind a proxy server.
I also tried to ease as much as possible the installation process (reducing unnecessary commands, passing variables directly from .env file to Makefile to the docker-compose commands and bash scripts).
I also added a make upAll-rebuild command to the makefile if you ever want to rebuild all containers. This will be used for debugging if ever need to patch the installation.

Just realised I forgot a debug command in api/genetaeJWT.sh:

ls -al config/jwt

Gonna have to remove that.

Any news ?

@Dfte I'm working on this now.

Refer to https://github.com/CMEPW/Smersh/pull/128


Warning: Number of points lower than number of bins

Hi Frank
I got many warning messages like this
Warning: Number of points lower than number of bins.Number of bins was reduced

In CAM2FIB>interpBeamPath (line 382)

Shihong
Originally posted by @worldred99 in https://github.com/frankNiessen/CAM2FIB/issues/1#issuecomment-1066912941

Hi Shihong,
I moved this into a new issue to keep the overview.
This warning is being issues during interpolation of the beampath in function "interpBeamPath". The interpolation is carried out to space out the scanning points evenly and therefore guarantee an evenly distributed beam current density during milling.
In the example, the beam path is interpolated with steps, here called bins, of 6.5 nm. In the case, that the number of points of a G-Code segment (for example an arc) is lower than the number of points generated by using the 6.5 nm bins, the number of bins is reduced to the number of points from the G-Code segment. This is done as otherwise new poinst would need to be generated, which is difficult to control automatically. To warn the user about this, the message "'Number of points lower than number of bins. Number of bins was reduced" is issued.
I hope this helps,
Frank


Native SSH support

And also maybe upgrade of phpseclib fork.

Can I ask does this mean Deployer does not work with SSH public keys by default, e.g. using a public key to login via SSH with the identityFile() method?
If so, that is not clear from the documentation, but certainly doesn't appear to work when I try.
If this is the case can I suggest some changes to the docs at http://deployer.org/docs/servers

Can you make PR to docs?

Just to confirm is using a public key to login via SSH not supported in Deployer without the ssh2 extension? It's still not clear to me!

phpseclib support this too.

OK.. it's not clear from your replies whether Deployer supports public key login to servers without installing the ssh2 extension?
If it can, looks like I'm doing something wrong since I can't get it working (I do not have ssh2 installed locally).

Wow. I'm closing this old issue. 1 year, 4 months, 26 days. I think this is longest time for any of deployer issues.


File deleted from _site/ during watch if not changed

Version
1.17.0
Platform
mac
What steps will reproduce the bug?
This is my minimal repro. _config.js:
import lume from "lume/mod.ts";

const site = lume();
site.copy([".js"]); // it also works if you do terser, for example, and also with css copy or css postcss.
export default site;

create a file a.js with a anything on it and run lume -w.
If you check, there will be a _site/a.js file with the correct content.
Now in a separate terminal, run touch a.js. Lume will show:
Changes detected:
- /a.js

but now the file disappears from _site. If you actually change a.js content, then everything works as expected (the file gets updated).
How often does it reproduce? Is there a required condition?
I tried to look into the code and I have no idea how this can be happening, so maybe is some weird OS-specific, thing? I've created a new project from scratch and I'm always able to repro.
What is the expected behavior?
The file to stay on _site when it changed but the content hasn't changed.
What do you see instead?
The file disappears from _site until I re-run lume.
Additional information
No response

Thanks for opening this issue. I can confirm it's a bug on Lume 1.17, sorry for the trouble.
I will fix it ASAP.

Fixed in v1.17.1.

Btw, I'm still getting errors like this, where the file disappears from _site if it's saved again but was supposed to generate the same output.

Is there any way to reproduce the error?

(btw, I can't re-open the bug)

Fixed in 1.17.4
Sorry for the trouble.


Quantisation

I'm trying to run on bitnet a fine-tuned model of Llama3-8B-1.58-100B-tokens. The model was already quantized dynamically, however it seems mandatory to convert the model to the gguf model format. Let me know if you think I'm doing something wrong.
Looking at the table here, it seems that for running the Llama3-8B-1.58-100B-tokens model on arm is necessary to quantize using tl2, however, when I try to run the setup_env.py I get this:
usage: setup_env.py [-h] [--hf-repo {1bitLLM/bitnet_b1_58-large,1bitLLM/bitnet_b1_58-3B,HF1BitLLM/Llama3-8B-1.58-100B-tokens}]
                    [--model-dir MODEL_DIR] [--log-dir LOG_DIR] [--quant-type {i2_s,tl1}] [--quant-embd] [--use-pretuned]
setup_env.py: error: argument --quant-type/-q: invalid choice: 'tl2' (choose from 'i2_s', 'tl1')

so is it possible to use tl2 for quantization?

Please check the table again, it should be tl1.

OK. Thanks for clarifying.
The table is not easy to read on a dark theme, because the X appear more prominent than the V.


Not changing package name SplashActivity.java

Beside MainActivity and MainApplication I have SplashActivity

When running
react-native-rename "Travel App" -b com.junedomingo.travelapp

the package name is not replaced in SplashActivity.
Probable because of https://github.com/junedomingo/react-native-rename/blob/master/src/config/bundleIdentifiers.js#L19

Solved in fork https://github.com/strdr4605/react-native-rename

There is a significant number of PRs, I'm wondering if the current maintainer still maintain this repo...

Fixed in the last release v2.7.0

Fixed in the last release v2.7.0


Received a non-Vinyl object

the example code:
gulp.task('hello-world', function() {
  return run('echo Hello World').exec()    // prints "Hello World\n".
    .pipe(gulp.dest('output'))      // writes "Hello World\n" to output/echo.
  ;
})

currently return error

[15:04:29] Error: Received a non-Vinyl object in dest()
at DestroyableTransform.normalize [as _transform] (/home/set/www/cloudbeds/jarvis/node_modules/vinyl-fs/lib/dest/prepare.js:16:17)
at DestroyableTransform.Transform._read (/home/set/www/cloudbeds/jarvis/node_modules/readable-stream/lib/_stream_transform.js:184:10)
at DestroyableTransform.Transform._write (/home/set/www/cloudbeds/jarvis/node_modules/readable-stream/lib/_stream_transform.js:172:83)
at doWrite (/home/set/www/cloudbeds/jarvis/node_modules/readable-stream/lib/_stream_writable.js:428:64)
at writeOrBuffer (/home/set/www/cloudbeds/jarvis/node_modules/readable-stream/lib/_stream_writable.js:417:5)
at DestroyableTransform.Writable.write (/home/set/www/cloudbeds/jarvis/node_modules/readable-stream/lib/_stream_writable.js:334:11)
at Pumpify.Duplexify._write (/home/set/www/cloudbeds/jarvis/node_modules/duplexify/index.js:208:22)
at doWrite (/home/set/www/cloudbeds/jarvis/node_modules/readable-stream/lib/_stream_writable.js:428:64)
at writeOrBuffer (/home/set/www/cloudbeds/jarvis/node_modules/readable-stream/lib/_stream_writable.js:417:5)
at Pumpify.Writable.write (/home/set/www/cloudbeds/jarvis/node_modules/readable-stream/lib/_stream_writable.js:334:11)

what I need is to write output of running command in file.

Same problem here. Any solution?


Feature/costmap 2d separation

I have separated the costmap_2d conversion functionality into a separate package (#94). This way, users working only with the standard installation of ROS can use grid_map_ros without installing costmap_2d first.
@stonier: Could you please check if this still works for your projects before I merge? Thanks!

@pfankhauser no longer at Yujin, but I can certainly at least check it keeps working with cost_map and it's tests. Will check it on the weekend once I have some cycles.

Not forgotten. Just a heads up to say sorry - had a guest arrive last weekend. Rescheduled for this weekend which I have free.

Green light here...I have a branch to PR as soon as this goes in.

Great, thanks for checking!


[BUG] Tenancy changes break CI

What is the bug?
The recent tenancy changes have broken all builds. When CI tries to run, it eventually fails on the  TransportUserInjectorIntegTest, TenancyMultitenancyEnabledTests, and others. This behavior can be seen in PR's which make no code changes such as #2660 which shows the change is part of the existing code base.
How can one reproduce the bug?
Steps to reproduce the behavior:
Run any builds on the GitHub runners.
What is the expected behavior?
Runners should pass by default and only fail when a PR is introducing a new issue.
Do you have any additional context?
The tenancy feature was recently modified as part of #2607. This is likely the cause.

@scrawfor99 It's not related to the tenancy changes. Some of the certificates used in SecuritySSLReloadCertsActionTests are expired.
openssl x509 -in src/test/resources/ssl/reload/node.crt.pem -text

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:<PHONE_NUMBER>013 (0x178c3673c1d)
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: DC = com, DC = example, O = Example Com Inc., OU = Example Com Inc. Signing CA, CN = Example Com Inc. Signing CA
        Validity
            Not Before: Apr 12 00:07:08 2021 GMT
            Not After : Apr 12 00:07:08 2023 GMT
        Subject: C = DE, L = Test, O = Test, OU = SSL, CN = node-1.example.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:ad:6c:05:f7:a1:84:2f:7e:0b:f0:43:9f:3b:78:
                    4b:e7:bd:50:b5:cf:c0:dd:eb:70:d1:42:22:78:77:
                    48:d6:81:e3:e3:dd:ae:4d:5e:8d:35:3a:4f:9a:e4:
                    2a:84:64:10:17:a8:ed:cb:ee:c7:79:c5:61:e3:3b:
                    a0:e0:db:d4:43:f3:3b:cc:99:c1:c7:42:0b:56:fa:
                    63:92:d6:63:dd:78:cd:7f:c9:68:36:32:fc:71:98:
                    7a:8a:50:8e:41:3b:12:51:2b:82:95:73:88:f2:62:
                    f9:e9:fc:19:ec:f4:01:2f:18:a6:ff:2a:8e:fd:61:
                    93:8e:8e:cd:2c:c7:68:8d:c4:a2:0f:92:f3:93:b5:
                    11:3c:fe:d6:b7:1f:51:b7:f9:ef:0d:74:33:79:b2:
                    eb:9a:5d:5d:fa:04:70:3c:e7:bb:2a:83:c9:31:07:
                    15:cf:c0:c1:77:e8:38:74:2f:ab:42:50:1f:28:c4:
                    b4:8f:a8:08:18:e9:e4:0d:84:2e:9c:a6:b6:65:f2:
                    b4:25:79:c8:53:ac:eb:30:38:05:53:a5:2d:2d:85:
                    ab:f9:64:5a:d7:e8:8d:4c:0f:9e:ce:e8:4a:2c:01:
                    a1:3a:0b:70:f8:a5:8f:c5:b1:7c:8e:87:13:ae:02:
                    fa:3e:1f:c2:b8:3b:97:5d:03:24:3c:31:e1:2f:9e:
                    c3:05
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Authority Key Identifier:
                keyid:D2:D3:61:E1:E9:A7:5C:60:55:69:B0:74:81:00:66:58:32:FA:06:44
                DirName:/DC=com/DC=example/O=Example Com Inc./OU=Example Com Inc. Root CA/CN=Example Com Inc. Root CA
                serial:02
            X509v3 Subject Key Identifier:
                25:2D:12:49:EC:47:4B:88:42:55:C1:B3:4C:D7:96:9F:ED:25:B7:17
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Key Usage: critical
                Digital Signature, Non Repudiation, Key Encipherment
            X509v3 Extended Key Usage: critical
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 Subject Alternative Name:
                Registered ID:<IP_ADDRESS>.5.5, othername: commonName::node-1.example.com, DNS:node-1.example.com, DNS:localhost, IP Address:<IP_ADDRESS>
    Signature Algorithm: sha256WithRSAEncryption
    Signature Value:
        11:aa:24:d7:e8:c1:9a:5b:af:d0:a2:7c:bf:c6:27:98:f0:65:
        93:c0:99:a7:20:db:d7:73:d7:84:ce:c1:cb:f5:35:8e:a5:0f:
        f4:c3:32:43:7b:39:7a:09:43:68:a4:b4:52:54:30:2c:d6:94:
        a7:9f:e5:a6:31:a2:6d:83:57:98:6c:48:0b:0f:9e:84:c2:cd:
        74:ad:31:bc:89:03:1f:83:26:28:61:53:c1:c9:69:00:5e:99:
        9b:d7:05:da:7d:08:40:89:f0:f4:81:9b:75:21:93:54:58:16:
        f2:68:d1:53:f7:ee:c2:ce:f4:6d:66:12:38:5d:0e:8d:6e:58:
        3d:17:cd:49:11:4e:5a:c9:f6:85:b4:f9:3d:7d:51:d0:0e:08:
        60:e0:c2:52:40:99:af:25:ca:3b:87:18:74:d3:dd:73:23:40:
        9c:54:7e:a4:8b:cd:e6:ff:13:b7:66:13:4c:f2:2e:9d:c1:e4:
        e1:ee:d6:d9:b6:1c:90:e2:ef:67:8d:36:5d:c2:0d:63:7f:2a:
        bd:a8:f2:ca:13:e9:f9:69:48:8a:51:29:59:77:73:ec:15:d5:
        a1:b1:08:23:ec:05:5e:11:59:ee:e1:ac:dd:3f:3f:af:d4:35:
        d0:25:6d:96:d9:93:b5:de:36:f8:5a:d9:bf:48:81:81:cf:b9:
        37:5f:8c:72
-----BEGIN CERTIFICATE-----
MIIE5DCCA8ygAwIBAgIGAXjDZzwdMA0GCSqGSIb3DQEBCwUAMIGVMRMwEQYKCZIm
iZPyLGQBGRYDY29tMRcwFQYKCZImiZPyLGQBGRYHZXhhbXBsZTEZMBcGA1UECgwQ
RXhhbXBsZSBDb20gSW5jLjEkMCIGA1UECwwbRXhhbXBsZSBDb20gSW5jLiBTaWdu
aW5nIENBMSQwIgYDVQQDDBtFeGFtcGxlIENvbSBJbmMuIFNpZ25pbmcgQ0EwHhcN
MjEwNDEyMDAwNzA4WhcNMjMwNDEyMDAwNzA4WjBWMQswCQYDVQQGEwJERTENMAsG
A1UEBwwEVGVzdDENMAsGA1UECgwEVGVzdDEMMAoGA1UECwwDU1NMMRswGQYDVQQD
DBJub2RlLTEuZXhhbXBsZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK
AoIBAQCtbAX3oYQvfgvwQ587eEvnvVC1z8Dd63DRQiJ4d0jWgePj3a5NXo01Ok+a
5CqEZBAXqO3L7sd5xWHjO6Dg29RD8zvMmcHHQgtW+mOS1mPdeM1/yWg2MvxxmHqK
UI5BOxJRK4KVc4jyYvnp/Bns9AEvGKb/Ko79YZOOjs0sx2iNxKIPkvOTtRE8/ta3
H1G3+e8NdDN5suuaXV36BHA857sqg8kxBxXPwMF36Dh0L6tCUB8oxLSPqAgY6eQN
hC6cprZl8rQlechTrOswOAVTpS0thav5ZFrX6I1MD57O6EosAaE6C3D4pY/FsXyO
hxOuAvo+H8K4O5ddAyQ8MeEvnsMFAgMBAAGjggF2MIIBcjCBvAYDVR0jBIG0MIGx
gBTS02Hh6adcYFVpsHSBAGZYMvoGRKGBlaSBkjCBjzETMBEGCgmSJomT8ixkARkW
A2NvbTEXMBUGCgmSJomT8ixkARkWB2V4YW1wbGUxGTAXBgNVBAoMEEV4YW1wbGUg
Q29tIEluYy4xITAfBgNVBAsMGEV4YW1wbGUgQ29tIEluYy4gUm9vdCBDQTEhMB8G
A1UEAwwYRXhhbXBsZSBDb20gSW5jLiBSb290IENBggECMB0GA1UdDgQWBBQlLRJJ
7EdLiEJVwbNM15af7SW3FzAMBgNVHRMBAf8EAjAAMA4GA1UdDwEB/wQEAwIF4DAg
BgNVHSUBAf8EFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwUgYDVR0RBEswSYgFKgME
BQWgGwYDVQQDoBQMEm5vZGUtMS5leGFtcGxlLmNvbYISbm9kZS0xLmV4YW1wbGUu
Y29tgglsb2NhbGhvc3SHBH8AAAEwDQYJKoZIhvcNAQELBQADggEBABGqJNfowZpb
r9CifL/GJ5jwZZPAmacg29dz14TOwcv1NY6lD/TDMkN7OXoJQ2iktFJUMCzWlKef
5aYxom2DV5hsSAsPnoTCzXStMbyJAx+DJihhU8HJaQBemZvXBdp9CECJ8PSBm3Uh
k1RYFvJo0VP37sLO9G1mEjhdDo1uWD0XzUkRTlrJ9oW0+T19UdAOCGDgwlJAma8l
yjuHGHTT3XMjQJxUfqSLzeb/E7dmE0zyLp3B5OHu1tm2HJDi72eNNl3CDWN/Kr2o
8soT6flpSIpRKVl3c+wV1aGxCCPsBV4RWe7hrN0/P6/UNdAlbZbZk7XeNvha2b9I
gYHPuTdfjHI=
-----END CERTIFICATE-----

Certs were updated in opendistro-1.13 for these tests. Details for generating new certs can be found here: https://github.com/opensearch-project/security/pull/1943#issuecomment-1187829493

[Triaging] Closing this issue since #2679 was merged as a fix. Thank you @cwperks!


Review of programatic access to the main preprint repositories

@map0logo , are you still working on that?
or could we already close this issue?


Add support for material-ui

It would be nice to support other ui libraries like material-ui.
The core logic of the components, hooks and utils should be separated to allow using them with material-ui or other ui libraries.
Steps to follow:

Convert to monorepo
Separate core logic from components
Split react-spreadsheet-import package into react-spreadsheet-import/chakra-ui, react-spreadsheet-import/material-ui, react-spreadsheet-import/core.

The idea is inspired by what DevExtremeReactive does: https://github.com/DevExpress/devextreme-reactive/tree/master/packages

Hey @bryanjtc thank you for the suggestion but we are not planning to do that. Feel free to fork the project though!


DoubleWidth Digests

Objectives
This pull request adopts DoubleWidth from the Swift numerics project and conforms it to FNVDigest to expose larger digests and potentially close #20.
Implementation
The UInt128 type alias is currently the only conforming double-width type. Although arbitrary digest lengths are possible, we significantly lose performance as we nest double-width types, and hard-coding fnv_prime and offset_basis values is tedious.
The use case this pull request serves in its current form is XOR-folding for hash sensitivity improvements.
Merge Notes
Since DoubleWidth is not part of a public swift-numerics module, the source file was copied instead. We should not merge this pull request as long as DoubleWidth is in _TestSupport.

More implementation notes from the initial commit - from what I know we can't make a conditional conformance to FNVDigest that looks like this due to to generics constraints:
extension DoubleWidth: FNVDigest where Base : UnsignedInteger { ... }

Since FNVDigest requires the return type of fnvPrime and fnvOffset be Self, we can't actually write a property getter or method that returns the value for a given DoubleWidth bit width. We would be trying to return different types from a single method, some of which aren't compatible with the protocol at all. This is only allowed if the return type is FNVDigest itself, which is not possible given the protocol has Self requirements.
This is a case for reverting to the old hasher design where we have a different hasher type for each digest size. It's not a very pleasant API, but it would allow us to implement large digests using DoubleWidth. The question is whether there are enough use cases for FNV-1 that require digests more than 128 bits. For a hash function designed for checksums and hash tables, I doubt there is.

This pull request will not be merged. The changes ruin the extensibility of DoubleWidth for larger digests.


feat: GitHub Actions PR Notify

Github actions PR Notify {Open, Closed, Reopened, Merged} Events

Test close

Test reopen


Remove install count

Status
Ready/In Progress/In Hold (Reason for hold)
Related Issues
fixes: link to the issue
Description
A few sentences describing the overall goals of the pull request's commits.
Screenshots
Paste here any images that will help the reviewer

Closing until we better understand