Search does not work as described

I can match on exact URL, but partial does not match nor does matching on name (title). Keepass 2.41 and most recent KeepassHTTP. I looked though KeepassHTTP source and it does not seem anything but full URL matching is possible.

Will look into this, but it's probably an issue on pfn/keepasshttp side, as the matching is quite a mess...
https://github.com/pfn/keepasshttp/blob/master/KeePassHttp/Handlers.cs#L117
In the meantime can you provide an example of a url and title missmatch ?

For me it will match on an exact URL or exact Title match, but not the partial part. I looked over the code here, and tests and saw it was not an issue here directly. But I saw the claim of partial search and was very hopeful to integrate with the Plasma desktop and not have to open the app to search. Thanks, I'll keep an eye out here.

Ok, tested it, and i'm still puzzled on how KeePassHTTP does the matching ...
"""
    For an entry like:

    title: "Example"
    url: "https://my.example.com/test"
"""
import keepasshttp
kph = keepasshttp.KeePassHTTP()

kph._request("get-logins", Url="Example") # Matches title exactly (case sensitive)
kph._request("get-logins", Url="*") # Finds most entries, no clues why some are left or why this works
kph._request("get-logins", Url="example.com") # fails
kph._request("get-logins", Url="my.example.com") # matches
kph._request("get-logins", Url="my.example.com/test") # matches
kph._request("get-logins", Url="my.example.com/te") # fails
kph._request("get-logins", Url="https://my.example.com/te") # matches
kph._request("get-logins", Url="https://my.example.com/wtf") # matches
kph._request("get-logins", Url="wtf://my.example.com/wtf") # matches

So basically:

Title matching is case sensitive and requires complete exact match
Url matching is not case sensitive
Url matching must have full domain
Url matching can have any path only when a protocol is specified
Url matching can have any protocols


Won't sync after v2 migration

Abstract
After migrating to the new Selfhosted Livesync v2 model, all devices are now unable to sync. The remote database isn't locked, any changes in any devices won't reflect in any other.
I've tried overwriting the remote DB on one device and reinstalling Obsidian on all others to just fetch from scratch, but to no avail. They'll get the updated files once, but anything after the first fetch will no longer sync.
This was all working across all devices prior to the v2 migration.
All 4 devices involved (Windows, Mac, iOS, Android) have up to date Obsidian installations and Selfhosted Livesync plugins.
Expected behaviour

Changes to files and addition of new files should sync to other devices.

Actually happened

Changes to files in one device won't propagate those changes to the others.

Reproducing procedure

One device chose "update to v2" when updating Selfhosting Livesync.
After that one was updated, I did the same on my other 3 devices.

Report from the LiveSync
For more information, please refer to Making the report.

 If still not fixed, please try to make the issue happen in the Sandbox Vault or disable community plugins.

Mac
SYSTEM INFO:
	Obsidian version: v1.4.16
	Installer version: v1.4.16
	Operating system: Darwin Kernel Version 22.5.0: Thu Jun  8 22:22:20 PDT 2023; root:xnu-8796.121.3~7/RELEASE_ARM64_T6000 22.5.0
	Login status: not logged in
	Insider build toggle: off
	Live preview: on
	Legacy editor: off
	Base theme: dark
	Community theme: none
	Snippets enabled: 1
	Restricted mode: off
	Plugins installed: 6
	Plugins enabled: 5
		1: Self-hosted LiveSync v0.20.7
		2: Periodic Notes v0.0.17
		3: Excalidraw v2.0.2
		4: Templater v1.18.1
		5: Sortable v0.3.1

RECOMMENDATIONS:
	Custom theme and snippets: for cosmetic issues, please first try updating your theme and disabling your snippets. If still not fixed, please try to make the issue happen in the Sandbox Vault or disable community theme and snippets.
	Community plugins: for bugs, please first try updating all your plugins to latest. If still not fixed, please try to make the issue happen in the Sandbox Vault or disable community plugins.

Plug-in log
We can see the log by tapping the Document box icon. If you noticed something suspicious, please let me know.
Note: Please enable Verbose Log. For detail, refer to Logging, please.

Plug-in log
Device 1 - edits file
11/20/2023, 1:53:17 PM->Content saved:sdaisd.md ,chunks: 1 (new:1, skip:0, cache:0)
11/20/2023, 1:53:17 PM->DB <- STORAGE (plain) sdaisd.md
11/20/2023, 1:53:22 PM->Scanning hidden files.
11/20/2023, 1:53:22 PM->Hidden files scanned: 2 files had been modified

Device 2 - Just after opening obsidian, waiting to see the updated file
11/20/2023, 1:53:17 PM->Content saved:sdaisd.md ,chunks: 1 (new:1, skip:0, cache:0)
11/20/2023, 1:53:17 PM->DB <- STORAGE (plain) sdaisd.md
11/20/2023, 1:53:22 PM->Scanning hidden files.
11/20/2023, 1:53:22 PM->Hidden files scanned: 2 files had been modified

Other information, insights and intuition.
Devices include iOS, Android, Mac and Windows. I chose to disable customization and hidden file sync on that pop-up that showed up after that force overwrite I mentioned above, just to see if they were the issue. I answered the same to the popups on all devices. The customization option was initially on back when I was on v1.
I have yet to try to rollback to the old format, I'll probably try to do that next to at least get a working plugin.

Hi. I just had a quick look at the log, and I'm afraid it's not an essential point, but a very detailed point that I'm trying to make.
Plug-in log
Plug-in log shows that sdaisd.md is DB <- STORAGE at 1:53:17 for both Device 1 and Device 2.
If I edit anything on Device 1, should I see DB -> STORAGE in the log to ensure that the edit is saved on Device 2 according to the correct procedure?
Make report

liveSync: false
/node_modules/, /.git/, /obsidian-livesync/, which are excluded from synchronization, but workspace.json is synchronized. Skip pattern files for Cross-Platform are not excluded.

That is all.
I apologize that this is not at all essential advice, but it is for your information.
I wish you good luck

Turning LiveSync on did fix it. I hadn't touched that pane at all in any device, which is why I didn't want to touch it. But it is indeed fixed.


Kana input

Using an XKB keyboard layout with kana keys, anthywl already works, but everything is katakana.
The plan is: allow switching conversion mode between hiragana/katakana/halfwidth-katakana/halfwidth-latin/fullwidth-latin in romaji mode, and then just go through the same process for keys input directly in kana.

I got around to checking how ibus-anthy does this. Once you select the typing method as kana it maps the keys based on a table to kana. There's a section in the ibus-anthy preferences where you can select the Kana key table.


Duplication bug when breaking Extended Drawers with a backpack equipped

Loader: Fabric
MC Version: 1.20.1
Mods:
Fabric API - 0.91.0+1.20.1
Beans Backpacks - 0.7-v2
Extended Drawers - 2.1.1+mc.1.20.1
https://github.com/BeansGalaxy/Beans-Backpacks-2/assets/88632676/10d59e57-e5bc-46ac-b95a-f5f924b3f442
When I have a backpack equipped and I pick up one drawer, it works fine. But, when I pick up another drawer, it stacks with the first one, voiding the contents of the second drawer and duplicating those of the first.

Oops... I was only checking if you picked up the same Item regardless of the nbt. I'll have to fix this in the next update

Fixed in v2-0.8 for 1.20.2. Will port changes to 1.20.1 soon.


Export Reports

Hi,
Can we Export the delivered report ??How??

At the minute this is not a feature of Postal, there are various issues open about monitoring and exporting information from Postal so hopefully this is on a roadmap somewhere.


Change spec isYYY to "access" and "display"

The boolean spec properties isService/Public/Standalone are burdensome. The new approach will be access {external, internal}, which determines whether a NodePort is created and display {stack, standalone}, which determines how a service is displayed.

This should now be fixed.


⚠ ClamAV has degraded performance

In fc23a4a, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 93 ms

Resolved: ClamAV performance has improved in 9f60104.


automate action definition updates

Every time we do a release, we need to update action.yaml before the semver tag is applied so that the action definition correctly references the new image that will be cut during the release process.
This is "chicken and egg" problem in a certain respect because the update has to happen before the release to reference something that doesn't exist yet, but will be produced by the release.
Currently, this update happens manually, but it's too easy to forget.
I'm thinking through how to deal with this still, but didn't want to lose track of the issue.

@krancour Can we use the latest tag for the images?


$meteor.object should accept CollectionFS collection

As with https://github.com/Urigo/angular-meteor/issues/72, AngularMeteorObject doesn't accept CFS collection as input. The same fix should be applied in the first place, then every functions like save or delete should be tested and eventually fixed, since they may not be compatibles.

I'm not sure I did it the best possible way, but it seems to work fine on almost any point. I tried to avoid coupling the code with CFS concepts. I updated my example application (https://github.com/epotvin/thumbnail-example) to comply with my last commit and every crud functions work, except when we have custom properties on the document that are not auto updated.
I added a "description" property to my "image" collection with a binded field on the page. When auto update is set, everything is ok, the value is automatically changed in the database. But when it is set to false, it can't even be changed on the screen. Actually it is set back to the current value instantly. I spent 2 hours trying to find the reason but I didn't.
If the false parameter is removed from this line : https://github.com/epotvin/thumbnail-example/blob/master/client/example.js#L43, everything is fine.
Setting it on collection doesn't seems to change anything.

@epotvin why won't you pull request the repo?
You can change and fix stuff on top of it...

Closed in https://github.com/Urigo/angular-meteor/pull/293


Linearized dynamics

Hello,
I'm wondering if Pinocchio has methods to output the linearized dynamics of the system. I see CppAd and Casadi are dependencies of the library, thus wondering if this has been used to obtain either analytical or numerical linearized dynamics.
Thank you,
Roberto

Dear @rshum19,
Indeed, Pinocchio provides the analytical derivatives of standard algorithms for computing forward and inverse dynamics, as well as the derivatives of the kinematic quantities.
There is some tiny example in the example folder.

In addition, if you need more derivatives, I may take some time to implement them.

Hi @jcarpent
Great I think this is exactly what I was looking for. I’ll look more into this derivative.
Thank you!


CP-22609: Create Beta Chart Github Action

Description
This PR allows users to create beta tags for charts by adding a new Github Actions workflow.
References
Testing
Not sure there's a good way to test locally?
Checklist

[x] I have added documentation for new/changed functionality in this PR
[x] All active GitHub checks for tests, formatting, and security are passing
[x] The correct base branch is being used, if not main

This looks right - how was it tested?

@josephbarnett That's what I mentioned in our internal channel, I'm not sure there's a good way to test this from a Branch. My understanding is you can only run the workflow once it's on develop.


Add cluster label to shard metric

Almost all the other metrics have this label, so it becomes a norm to have it on this metric as well

@sysadmind Can you please have a look at this?

So, we have like 100 of ElasticSearch clusters and we are running this exporter in each node and collecting metrics in a single prometheus storage.
We want cluster label so that we can distinguish between multiple clusters. We have one grafana dashboard with cluster as a variable which we are passing in queries. This specific metric doesn't have it, so I raised the Pull Request.

I'm on board with this change, but I would like to remove the dependency on Nodes to get the cluster name. There is some existing work to have collectors receive updates to the cluster info: https://github.com/prometheus-community/elasticsearch_exporter/blob/master/main.go#L208. It's not the prettiest functionality, but it will cut down on API calls for those user that care about that type of thing. It would also mean if we refactor in the future, we have a common set of functionality to consider.

@sysadmind I have updated the code. Please review

@SuperQ  Can you please review it?

Your comment/screenshot is for _cat/shards, but the exporter doesn't use this URL in that way. Your screenshot shows data in a formay that the exporter doesn't see. The URL that the exporter uses is _cat/shards?format=json

@sysadmind I have added the screenshots from correct API.

@sysadmind @SuperQ Please review

@sysadmind  @SuperQ  Please review and merge

@sysadmind Please review. I'm really blocked by this

@sysadmind @SuperQ Gentle reminder


UnicodeDecodeError when dumping with read_dumpfile

Used example script  flowwriter.py to collect some data
Then tryed to run it with example script read_dumpfile
getting :
...
        "code": 200,
        "content": Traceback (most recent call last):
  File "read_dumpfile", line 16, in <module>
    json.dump(f.get_state(), sys.stdout, indent=4)
  File "/usr/lib/python2.7/json/__init__.py", line 189, in dump
    for chunk in iterable:
  File "/usr/lib/python2.7/json/encoder.py", line 434, in _iterencode
    for chunk in _iterencode_dict(o, _current_indent_level):
  File "/usr/lib/python2.7/json/encoder.py", line 408, in _iterencode_dict
    for chunk in chunks:
  File "/usr/lib/python2.7/json/encoder.py", line 390, in _iterencode_dict
    yield _encoder(value)
UnicodeDecodeError: 'utf8' codec can't decode byte 0x8b in position 1: invalid start byte
...

Example file that was collected with flowwrite.py is attached. I filltered out one http response that causes this bug

md5sum logfile
fc0285d300cccc88b757e4ff70bf128b  logfile

Tested with mitmproxy commit adf2877020c563fa9dc9a4df26bfd8b243e8e41a

Hi there,
Could you please test with a recent checkout of mitmproxy? Reading the dumpfile you attached works with no error in the latest master.
If the issue is still there, please re-open and specify your platform, mitmproxy version and any other details that could help us reproduce.
Aldo

Hi, ofcourse it works without "no error". There is just try/catch used. Problem was I think becouse
if you have some binary file like image then it contains non printable characters. While json.dump couldnt
dump it it stil valid file/packet. This error happened with files that have in headers Contet-Type specified compression format and in content compressed content. Probably now some one will expirience non-dump valid packets.

Hi Arthur. Further to our email just now, base64 encoding to make binary data JSON-safe is the way to go. Let's get a working test case up and running here, so we can see exactly what we're dealing with. Using the test dump you provided, and the example script in the repo, I don't see the error. The output is as expected, and an error is not hidden by a try/catch block.

How yo provide more info that you may need to debug here i collected what I think could help you need:
mitmproxy commit 9286f5b5b4d9483d0d8e7fa0fb4c27961cd236be
Python 2.7.10
3a38ff399b634c4fa6393cc8a4df9db1  log.txt
```

```
git branch -a
* master
  remotes/origin/0.10
  remotes/origin/0.8
  remotes/origin/HEAD -> origin/master
  remotes/origin/conn-management
  remotes/origin/integrate_honeyproxy
  remotes/origin/master
  remotes/origin/mitmconvert
  remotes/origin/mouse
  remotes/origin/multiple_views
  remotes/origin/proxy-refactor
  remotes/origin/proxy-refactor-cb

export LANG=en_US.UTF-8
python2 ./read_dumpfile log.txt

...
    "error": null,
    "id": "fcb5ecbf-0503-4a9f-8a87-adb9d9889ffd",
    "type": "http",
    "response": {
        "code": 200,
        "content": Traceback (most recent call last):
  File "./read_dumpfile", line 18, in <module>
    json.dump( state, sys.stdout, indent=4, ensure_ascii=True)
  File "/usr/lib/python2.7/json/__init__.py", line 189, in dump
    for chunk in iterable:
  File "/usr/lib/python2.7/json/encoder.py", line 434, in _iterencode
    for chunk in _iterencode_dict(o, _current_indent_level):
  File "/usr/lib/python2.7/json/encoder.py", line 408, in _iterencode_dict
    for chunk in chunks:
  File "/usr/lib/python2.7/json/encoder.py", line 390, in _iterencode_dict
    yield _encoder(value)
UnicodeDecodeError: 'utf8' codec can't decode byte 0x8b in position 1: invalid start byte
```

Here is file with 3 packets that fails with that error.
![log](https://cloud.githubusercontent.com/assets/214155/9325494/a5e054c8-458a-11e5-8106-75f2455e23da.png)

Could it be helpfull to collect much more data?

I think we should just change the example script to use pprint - JSON does not support binary contents, so we should leave an explanatory comment and use something else.


Support infinite TMX maps Closes #5764

Tiled The Editor have strange behaviour with infinite map size. In some cases my code may not load some tiles that go beyond the map size limits. I opened an issue on it's project about this.

This looks probably fine, but I am not very familiar with it. Anyone else to comment if this makes sense?

This code is not ideal: it supports "infinite" tmx-maps which stores tiles in randomly located chunks in "finite" manner - one two dimensional array that represented rectangle that contains all tiles. It is not optimal: there are many elements in this array not contains data.
And for optimization, in this code there are no many checks for indexes going out of bounds.
if I can find the time, then I will try to implement similar chunks in LibGDX.

For anyone taking a look at this PR years later.
I thought I would try and take a look real quick and run some tests to help out, so we know where this stands many years later. Sadly, Bjorn is correct.
When using the infinite tilemap feature you usually end up with negative positions in the expanded chunks. And after looking through the codebase with how libGDX sets cells within MapLayers. Each layer contains our cells in a simple 2D Cell array designating their position. So unless I am mistaken, we would never be able to keep a 1 to 1 match to the tile positions in relation to the tiled editor unless we made some big changes.
While nklbdev did a great job to start, as it stands the code as submitted doesn't quite work, even disregarding the negative positions there are a few others issues as well and we would probably need a large overhaul to some other sections of the codebase. Though if anyone wants to tackle that, go for it!
But for now, sadly, it seems like the best workaround for users who want to make use of Tiled's infinite map feature would be to just uncheck it and set it back to a finite map, when they are ready to bring it into libGDX.


chore: 🤖 Get query and withContent from environment

Follow up from #1
Read the environment to customize the query and to get the full content
stored in Omnivore

Thanks @jsanz. I have updated the script a bit more, you can now pass everything as command line options as well.

Oh, that's even better, thanks!


runtime: STW GC stops working on arm64/mips64le

What version of Go are you using (go version)?

$ go version
2545323c633136a28aa57b000b81e95780cbac13

Does this issue reproduce with the latest release?
no. Go1.13 doing fine.
What operating system and processor architecture are you using (go env)?
linux/arm64
linux/mips64le
What did you do?

import (
        "fmt"
)

func main() {
        for i := 0; i < 10000; i++ {
                n := 150
                r := deferHeapAndStack(n)
                if r != n*2 {
                        fmt.Println(i, r)
                }
        }
}

// deferHeapAndStack(n) computes 2*n
func deferHeapAndStack(n int) (r int) {
        if n == 0 {
                return 0
        }

        if n%2 == 0 {
                // heap-allocated defers
                for i := 0; i < 2; i++ {
                        defer func() {
                                r++
                        }()
                }
        } else {
                // stack-allocated defers
                defer func() {
                        r++
                }()
                defer func() {
                        r++
                }()
        }

        r = deferHeapAndStack(n - 1)
        escapeMe(new([1024]byte)) // force some GCs
        return
}

// Pass a value to escapeMe to force it to escape.
var escapeMe = func(x interface{}) {}

What did you see instead?
GODEBUG='gctrace=1,gcstoptheworld=1' ./defer

runtime: checkdead: find g 1 in status 1
fatal error: checkdead: runnable g

runtime stack:
runtime.throw(0xd0caf, 0x15)
        /root/godev/src/runtime/panic.go:1116 +0x54
runtime.checkdead()
        /root/godev/src/runtime/proc.go:4489 +0x43c
runtime.mput(...)
        /root/godev/src/runtime/proc.go:4906
runtime.stopm()
        /root/godev/src/runtime/proc.go:1879 +0x9c
runtime.findrunnable(0x4000022800, 0x0)
        /root/godev/src/runtime/proc.go:2413 +0xa2c
runtime.schedule()
        /root/godev/src/runtime/proc.go:2613 +0x31c
runtime.preemptPark(0x4000000180)
        /root/godev/src/runtime/proc.go:2851 +0xb4
runtime.newstack()
        /root/godev/src/runtime/stack.go:1026 +0x1e0
runtime.morestack()
        /root/godev/src/runtime/asm_arm64.s:308 +0x70

goroutine 1 [runnable]:
main.deferHeapAndStack(0x281, 0xd5d90)
        /root/defer.go:41 +0xd8
main.deferHeapAndStack(0x282, 0x40004979b0)
        /root/defer.go:40 +0xbc
main.deferHeapAndStack(0x283, 0xd5d90)
        /root/defer.go:40 +0xbc
main.deferHeapAndStack(0x284, 0x40004979a0)

Might relate to #34736

/cc @mknyszek @aclements

Hi @mengzhuo , is it a random issue?
I tried on several arm64 machines with both 2545323c63 and the latest commit 5a706d163d but failed to reproduce the crash.
But I did observe a (random) deadlock if running your case by 'go run'.

@shawn-xdj  I can reproduce on my linux/arm64 box at 201cb046b745f8bb00e3d382290190c74ba7b7e1
Did you run with GODEBUG='gcstoptheworld=1' ?

@mengzhuo Yes, I followed your steps, 'go build <test.go>', 'GODEBUG='gcstoptheworld=1' '.
Just verified your case on all available machines, running 100 times each, arm64 didn't witness any problem, but the same crash was hit on one of x86 machines.
...
gc 435 @0.648s 2%: 0.010+0.21+0.020 ms clock, 0.48+0/0.35/0.21+0.89 ms cpu, 4->4->0 MB, 5 MB goal, 44 P
runtime: checkdead: find g 1 in status 1
fatal error: checkdead: runnable g
runtime stack:
runtime.throw(0x4c2a5b, 0x15)
/home/ent-user/ci-scripts/golang/src/runtime/panic.go:1116 +0x72
runtime.checkdead()
/home/ent-user/ci-scripts/golang/src/runtime/proc.go:4489 +0x39a
runtime.mput(...)
/home/ent-user/ci-scripts/golang/src/runtime/proc.go:4906
runtime.stopm()
/home/ent-user/ci-scripts/golang/src/runtime/proc.go:1879 +0x97
runtime.findrunnable(0xc00008d000, 0x0)
/home/ent-user/ci-scripts/golang/src/runtime/proc.go:2413 +0xa0b
runtime.schedule()
/home/ent-user/ci-scripts/golang/src/runtime/proc.go:2613 +0x324
runtime.mstart1()
/home/ent-user/ci-scripts/golang/src/runtime/proc.go:1157 +0x8e
runtime.mstart()
/home/ent-user/ci-scripts/golang/src/runtime/proc.go:1115 +0x6e
goroutine 1 [runnable]:
main.deferHeapAndStack(0x24, 0xc0004c0258)
/home/ent-user/ci-scripts/test.go:41 +0x117
main.deferHeapAndStack(0x25, 0x4c7c50)
/home/ent-user/ci-scripts/test.go:40 +0xf7
main.deferHeapAndStack(0x26, 0xc0004c0248)
/home/ent-user/ci-scripts/test.go:40 +0xf7
main.deferHeapAndStack(0x27, 0x4c7c50)
/home/ent-user/ci-scripts/test.go:40 +0xf7
main.deferHeapAndStack(0x28, 0xc0004c0238)
/home/ent-user/ci-scripts/test.go:40 +0xf7
....
....

I can reproduce, and with GOTRACEBACK=crash it looks like this is coming from the following chain of events (at least on linux/amd64):

A G allocates, and at the end of allocation realizes it needs to start a GC.
It acquires worldsema, stops the world, does everything it needs to do, disables user goroutine scheduling due to GODEBUG=gcstoptheworld=1, and starts the world again.
It goes to release worldsema and notices a preemption request. It then goes into the scheduler becomes runnable, but user goroutine scheduling is disabled so it stops its M, checkdead is called, all Ms are idle, and there's a runnable G left over -> assumes deadlock.

It likely relates to the fact that we release worldsema now instead of holding onto it across the mark phase. It's possible that the problem here is just that there's a preemption point before the worldsema release now where there wasn't before. Maybe the trick is this comment:
// In STW mode, we could block the instant systemstack
// returns, so don't do anything important here. Make sure we
// block rather than returning to user code.

That systemstack block referred to there is the one containing startTheWorldWithSema. Perhaps the semrelease should happen on the system stack? It's a little tricky because there's a goyield inside semrelease, but luckily that codepath will never get hit because handoff=false. That's a little fragile, so we could instead defensively increment acquirem to enforce that there are no preemption points between the startTheWorld and Gosched.
I'll try that and see if I can still reproduce the problem.

Yeah I think I have a fix. Hasn't crashed yet. @mengzhuo can you verify?

Also, this is related to #19812, noting it for bookkeeping purposes.

Yeah I think I have a fix. Hasn't crashed yet. @mengzhuo can you verify?

Thanks your CL, https://github.com/golang/go/commit/03ba6b070d625bf00eac5350c4f363e5e87828b2 fixed the issue.


Rotate tool?

Hi, I cant find how I rotate the selection or the layer. There is some rotate tool or isnt implemented yet? If there isn't, do you guys pretend to add this feature? In my opinion rotate tool is great to make animations easier and fast instead of drawing all over again. I started using this program and I am loving it! Can't believe it's free O/
thanks and great work for the developers!

Hi and thanks for the nice feedback.
There is a very basic rotate feature, which rotates the current layer/frame/animation of 90 degrees clockwise or counterclockwise.

Free rotation is more complicated to implement, but that would be a nice new feature!

Hi there! I don't think that Free rotation is needed per se, but since the rotation tool makes an even 90 degrees, it only gives 3 options before it goes back to zero. It would help a lot if we had been more options, so if the rotation tool could rotate to just 15 degrees, it would be a great improvement already. This way, people have a wider range options.

It would be nice to have other rotation angles, but it would be extremely hard to implement because when you rotate a pixel image by any other angles than 90, 180, etc., it becomes blurry and not crisp like the usual pixel image.

Hi! I think Mouse Rotation would be nice too, you block the image and the option to rotate blocked image pop out on blocked image border, similar like gimp, paintdotnet, photoshop.

Would anyone know where I could find an open source code that uses the rotation feature that you wish to add? I'd like to learn more about this and perhaps I could try making it, because even if rotating blurs the image slightly, a few minor adjustments with the eraser and draw tool can fix this and save us time in the long run.

@Plasmarift , I think the best way I know to accoplish what you describe (with what little experience I have with image manipulation) is to recolor each pixel according to a pixel that "preceeds" it in the rotation.
I'll see if I can explain:
If we want to rotate the image by an arbitrary ammount (say 20 degrees) about an arbitrary origin (say the center pixel), then we start going through each pixel one by one and chose a new color by this algorythm:
Convert the pixel's relative position to the origin to polar coordinates.
Transform the polar coordinate by the reverse of the given degree of rotation. (so -20 degrees in our example)
Convert the new polar coordinate back to absolute coordinates and grab the color from the underlying pixel.
Put that color on the original pixel in a copy grid (so we can still get the original color on that spot for another pixel)
Repeat this for each pixel on the canvas.
Now, I have no idea how this would be implemented in the piskel app, and I have no idea if it's practical for large animations or previews (it would take no less than 4 trig function calls per pixel as far as I know.)
Hope that helps!

One thing that can be painful here are transparent pixels. Piskel doesn't support colors with an alpha channel due to performance issues.
If you rotate a layer which contains transparent pixels, all the pixels sitting next to transparent pixels would need to become semi transparent after the rotation. Since we can't do that at the moment the end result will be a bit rough.

If someone is interested, the algorithm that Aseprite uses for free rotation is "RotSprite" by Xenowhirl (2007).
Here's the link to the original thread where he talk about with more info on page 2 [1], the link to the website about the algorithm [2] and the "always requested" Wikipedia entry about it [3].
[1] http://forums.sonicretro.org/index.php?showtopic=8848
[2] http://info.sonicretro.org/RotSprite
[3] https://en.wikipedia.org/wiki/Pixel-art_scaling_algorithms#RotSprite
Basically, it makes the image 8X bigger, linear rotation, and a 8X reduction, keeping the color palette intact.

How about something that rotates just the selected instead of the whole frame?

How about something that rotates just the selected instead of the whole frame?

The best way to incorporate such a function, that I can think of, is if a selection is made and the user holds a certain key while they rotate (like shift, alt/opt, ctrl/cmd).
But then there comes the question of whether you are trying to rotate around the center of the frame or around the center of the selection, which gets complicated.

I think the biggest problem would be how the pixels morph to fit the new image when rotated at a degree other than a right angle. If they could implement the pixels to morph so it fits the new rotation, they could simply add a text input that lets you input what rotation angle the sprite should be at. For instance, if I put in 60 for the rotation, it should rotated 60 degrees clockwise. If I input -120 degrees, it should rotate 120 degrees counterclockwise. (Also, if I got the clockwise and counterclockwise mixed up, my mistake)


add service mailhog to docker-compose

Q
A

Branch?
1.x

Bug fix?
no

New feature?
no

Deprecations?
no

Tickets
Fix #289

License
MIT

@imdhemy

This container is supposed to be used only for development.
docker-compose.yml file is used for production. docker-compose.override.yml file is used for development.

I changed it.
I moved the service mailhod from docker-compose.yml to docker-compose.override.yml
is it ok ?

@Moemen-Gaballah Could you please have a look on this PR #295


MemoryError from tensorflow.contrib.learning.datasets in Python3

System information

Have I written custom code (as opposed to using a stock example script provided in TensorFlow):
OS Platform and Distribution (e.g., Linux Ubuntu 16.04): Linux Ubuntu 17.04
TensorFlow installed from (source or binary): binary
TensorFlow version (use command below): v1.4.0-rc1-11-g130a514 1.4.0
Python version: 3.5.3
Bazel version (if compiling from source): NA
GCC/Compiler version (if compiling from source): NA
CUDA/cuDNN version: NA
GPU model and memory: NA
Exact command to reproduce: python -c "import tensorflow as tf; tf.contrib.learn.datasets.load_dataset('dbpedia', size='full')"

Describe the problem
The command results in an MemoryError, even though the dataset easily fits into my memory (64GB), and also works with Python 2.
Source code / logs
Here is the traceback:
Traceback (most recent call last):
File "", line 1, in
File "/home/james/python3.5-ve/lib/python3.5/site-packages/tensorflow/contrib/learn/python/learn/datasets/init.py", line 71, in load_dataset
return DATASETS[name](size, test_with_fake_data)
File "/home/james/python3.5-ve/lib/python3.5/site-packages/tensorflow/contrib/learn/python/learn/datasets/text_datasets.py", line 65, in load_dbpedia
train_path, target_dtype=np.int32, features_dtype=np.str, target_column=0)
File "/home/james/python3.5-ve/lib/python3.5/site-packages/tensorflow/contrib/learn/python/learn/datasets/base.py", line 72, in load_csv_without_header
data = np.array(data)
MemoryError

Any update on this?

I think we'd need a bit more info about the code you're using.

I just tried with 1.4.0, I cannot reproduce this. I'll close, please reopen if you have more information.

Please use the below files to recreate the issue. Use following command(copy rnn_tc.txt as rnn_tc.py first):
$python3 rnn_tc.py
We got following messages:
$ python3 rnn_tc.py > tc.log4
Traceback (most recent call last):
File "rnn_tc.py", line 62, in
'dbpedia', size='big')
File "/usr/local/lib/python3.4/dist-packages/tensorflow/contrib/learn/python/learn/datasets/init.py", line 71, in load_dataset
return DATASETS[name](size, test_with_fake_data)
File "/usr/local/lib/python3.4/dist-packages/tensorflow/contrib/learn/python/learn/datasets/text_datasets.py", line 65, in load_dbpedia
train_path, target_dtype=np.int32, features_dtype=np.str, target_column=0)
File "/usr/local/lib/python3.4/dist-packages/tensorflow/contrib/learn/python/learn/datasets/base.py", line 72, in load_csv_without_header
data = np.array(data)
MemoryError
rnn_tc.txt

python3 tensorflow version:
1.3.0

Since you're running an old version of TensorFlow, this may be fixed in 1.4. Can you check whether this is fixed in 1.4? It works fine for me, but I am using Py2. That's the only difference I can think of. How much memory is in the machine you're using?

Oh wait, you said that. Sorry. I take that back. Let me test again with Py3.

I just tried with TF 1.4 and Py 3.6.3, and I don't see this failure.

Did you get the error (using rnn_tc.txt)  with TF 1.3 and Py3 and did not get that error with TF 1.4 and Py 3.6.3 ?? Is this what you are saying?

I did not get the error (using your repro python -c "import tensorflow as tf; tf.contrib.learn.datasets.load_dataset('dbpedia', size='full')") in TensorFlow 1.4, Python 3.6.3.

OK, but the 1.5G maximum resident set size still does not explain the MemoryError since this happens when there is > 10G of unused memory. Also the error only occurs with python3 and not python2.
Yes, the dataset should be way smaller than a G, but I haven't had a chance to look into fixing it.

If somebody sill have the issue
https://stackoverflow.com/a/49824034/604530


Can't connect ValueInputs to Writes/DynamicWrites/ImpulseWithDatas that match Types

When I spawn a Write/DynamicWrite for example Chirality I can create a ValueInput from the Write, but I can't connect it to the Write node.
If I create a Write or DynamicWrite for a Type that's different from my ValueInput's Type, and I connect it, the Write/DynamicWrite changes and will work with the ValueInput.
I've tryied DynamicWrite,Write,DynamicImpulseWithData, and for enums I've tried Chirality,Key,BodyNode
Video showcasing this:
https://github.com/badhaloninja/EnumDropdown/assets/53709818/41556d7b-aa54-49a6-99e9-15a4997ec3dc

Could you upload a log of this happening? I will try to replicate this later today.

I have not been able to reproduce this, does this still happen with v2.1.1?

Seems like its all good now! Amazing! And thank you for the mod ^^

Seems like its all good now! Amazing! And thank you for the mod ^^


Footnote definition does not end

extern crate pulldown_cmark as cmark;

use cmark::{Options, Parser};

fn main() {
    for e in Parser::new_ext("Hello, [^goo]\n\n\
                              [^goo]: world.\n\n\
                              Follow [link][ref]",
                             Options::all()) {
        println!("{:?}", e);
    }
}

The above code outputs (footnote definition extending until the end):
Start(Paragraph)
Text("Hello, ")
FootnoteReference("goo")
End(Paragraph)
Start(FootnoteDefinition("goo"))
Start(Paragraph)
Text("world.")
End(Paragraph)
Start(Paragraph)
Text("Follow ")
Text("[link]")
Text("[ref]")
End(Paragraph)
End(FootnoteDefinition("goo"))

I sent a PR to take a look at. One question I have is, how should the following be handled:
a: [^b]

[^b]: * a
* b

* c

d

Here we have a conflict between two rules: the footnote should be closed by one blank line, but the list (which is inside the footnote) is closed by two. With the code in the PR, the list [a, b] is inside the footnote def, while c gets its own list. This seems reasonable but I want to think about whether it's truly the best behavior.
Alternatively (since the spec doesn't nail this down), we can dictate that footnotes and lists are both consistently ended by two blank lines.

I (personally) don't see this as a bug. If you look in specs/footnote.txt, multi-paragraph footnotes are deliberately supported, and footnotes are already ended on two blank lines.

multi-paragraph footnotes are deliberately supported

I see... I did not "expect" that (or lists) in footnotes. Generally, footnotes are a single paragraph of text.

since the spec doesn't nail this down

If we are going to take the route of making footnotes end with a single blank line (which is probably what most people might expect, and markdown is about being intuitive, right?), then deny lists inside it (for consistency in number of blank lines). I'm against it because it will look kinda ugly if footnote definitions (containing lists) are rendered as a numeric list (as in wikipedia).

When I thought about it, there's an almost backwards compatible way to add back list and multi-paragraph support if there's popular demand.
Relaxing the restriction: After an empty line, in order to continue the footnote definition, indent:
[^b]: * a
* b

      * c

d

Regardless of indentations of adjacent lines following the first line of definition, the line after a blank has to be aligned with the first (non-whitespace) character of the definition body. The definition body can start in the next line too:
[^b]:
  * a

  * b

d

If it starts in the next line without any indentation, then there must be 2 blank spaces in order to terminate it, or another footnote definition.
Here's a kinda counter-intuitive restriction:
[^b]: * a
  * b

    c

d

b and c will not be in the same bullet point. c should be displayed as codeblock outside of footnote def. To include c inside b's bullet, it should align with a.
I don't know how much increase in complexity this specification will bring about. Either way, I would suggest not to include this feature now. More the features, more the abuse!! If there's really a demand for multi-para footnotes, then we can add it with a similar spec like this.

FWIW, the reason the spec acts the way it does is because, whatever is most common in writing contexts, multi-paragraph footnotes are a genuine need. (I have from time to time used them myself.) Just as importantly in many ways, pretty much all existing implementations with footnote support treat footnotes as a(n indented) block type, which allows them to have multiple paragraphs within them. So whatever is most purely "intuitive" may not be what's best in this case.

Regarding the list within footnote issue above:

but the list (which is inside the footnote) is closed by two.

This appears to have changed between CommonMark 0.26 and 0.27.
0.26:

list items may be separated by single blank lines, but two blank lines end all containing lists

0.27:

list items may be separated by any number of blank lines

So it is clear that the c list item must in all cases be a part of the list that contains the b list item.
It looks like this footnote spec is homegrown rather than part of the CommonMark spec.  How open is it for change?
I would not have expected list item b to be part of the [^b] footnote definition at all.  Why aren't the contents of a multi-line footnote definition required to be indented to at least the same level as the first non-whitespace character after the [^b]:? That seems like it would be consistent with what CommonMark does with, for example, list items.

Follow-up from https://github.com/google/pulldown-cmark/pull/21#issuecomment-290334612:
It looks like this footnote spec is homegrown rather than part of the CommonMark spec.  How open is it for change?
I would not have expected list item b to be part of the [^b] footnote definition at all.
It appears as though a footnote definition should treated as a container block -- all indications in this thread are that footnotes are expected to support multiple paragraphs, lists, and other blocks.
If a footnote definition is a container block, it should act very much like list items do in CommonMark.  Continuing lines in a footnote definition should be indented to the same level as the first non-whitespace character after the [^b]: item.  The rules to end a list item should apply to a footnote definition.
Is there an argument against treating footnotes as an additional type of container block similar to a list item?

foot[^note1], foot[^note2]

[^note1]: text1
[^note2]: text2

Generates:
[
    Start(Paragraph),
    Text("foot"),
    FootnoteReference("note1"),
    Text(", foot"),
    FootnoteReference("note2"),
    End(Paragraph),
    Start(FootnoteDefinition("note1")),
    Start(Paragraph),
    Text("text1"),
    SoftBreak,
    FootnoteReference("note2"),           # note this
    Text(": text2"),
    End(Paragraph),
    End(FootnoteDefinition("note1"))
]

Instead of:
[
    Start(Paragraph),
    Text("foot"),
    FootnoteReference("note1"),
    Text(", foot"),
    FootnoteReference("note2"),
    End(Paragraph),
    Start(FootnoteDefinition("note1")),
    Start(Paragraph),
    Text("text1"),
    End(Paragraph),
    End(FootnoteDefinition("note1"))
    Start(FootnoteDefinition("note2")),
    Start(Paragraph),
    Text("text2"),
    End(Paragraph),
    End(FootnoteDefinition("note2"))
]

Which can be generated if there is a blank line between footnote definitions. Is this intentional?

Which can be generated if there is a blank line between footnote definitions. Is this intentional too?

It appears to be intentional as that is covered specifically by a test case in the footnotes.txt spec.  I would have expected your example to be two separate footnote definitions if I hadn't read that spec first.

I just made it up.

After going through the spec for lists once again, and keeping the goal to maximize intuitiveness, I rewrote the spec I proposed earlier (in-place). Please take a look. I tried to make it consistent with the current style of specs.

This example:
[^long-footnote-name]:
  inside footnote
  * list item inside footnote
outside footnote

Would be all one list item due to lazy continuation rules.  The "outside footnote" text would be part of the "list item inside footnote" (see here)
Considering your second example as a list item rather than a footnote, it seems fine.  However, this version should probably all be one footnote due to laziness:
[^b]: text
inside footnote

I agree with your third example.
It seems like the one place this still differs from list items is dealing with a long footnote name.  Subsequent blocks inside a list item need to be indented as far as the first non-whitespace character after the list marker.  If the footnote name is very long, this is impractical.
I think the discussion starting with "Would it help to adopt a two-space rule?" under 5.2.1 Motivation in the CommonMark spec may be relevant here.
Perhaps a two-space rule can be justified by something like "The [^ is the footnote definition indicator, so everything should be indented past that." Not sure. Seems a little messy still.

@ScottAbbey You're right, that's indeed an inconsistency. I'll update the proposal soon.

What's the status on this? I just ran into this problem with the following reference-list:
[^foo]: foo
[bar]: bar

This generates the following events, which make the parser not being able to find the link definition and call the broken_link_callback:
Start(FootnoteDefinition("foo")),
Start(Paragraph),
Text("foo"),
SoftBreak,
Text("[bar]: bar"),
End(Paragraph),
End(FootnoteDefinition("foo"))

Looking at the proposed spec here, and this one is probably not quite right:

If a sequence of blocks should be contained within a footnote definition, indent it to align with the first non-whitespace character in the definition body.

[^b]: * list item1 inside footnote
      * list item2 inside footnote
* list item outside footnote

The indentation rule here is unnecessarily different from the rules for other container types. Most of them allow this variation instead
A paragraph of text to host a footnote.[^b]

[^b]: Here is a paragraph in the footnote, and then a list.

    * list item1 inside footnote
    * list item2 inside footnote

* list item outside footnote

This is how pandoc renders it

A paragraph of text to host a footnote.1

list item outside footnote

Here is a paragraph in the footnote, and then a list.

list item1 inside footnote

list item2 inside footnote

↩

That is, roughly (given the limitations of GH's HTML rendering):

A paragraph of text to host a footnote.1

list item outside footnote

Here is a paragraph in the footnote, and then a list.

list item1 inside footnote
list item2 inside footnote

↩

What's more, it renders the same regardless of the amount you indent within the block as long as there is no end to the contained block—for example, with a list immediately following.
Without suggesting that Pandoc's implementation is normative, it's nonetheless fairly representative. There's some variation on the treatment of the * list item outside footnote bit in other implementations, as well as on what indentation is required. Pandoc footnotes don’t require indentation at all as long as there is no double-newline ending the block. Most other implementations I’m aware of do require indentation, of whatever size is required to start/continue a new block child in the implementation generally.
That means rule 3 should actually be something like:

If a sequence of blocks should be contained within a footnote definition, indent it as a block continuation (the same as continuing a list).

[^fn-def]:
    * list item1 inside footnote
    * list item2 inside footnote
* list item outside footnote

This could/should be a bit more precise: it would be best to match up that indentation rule with the normal block continuation rules from the CommonMark spec.

Note for folks following this thread: I am (albeit very slowly) working my way toward a solution to alllll the footnote issues over on #544. Honestly, it’ll likely be the end of the year before I have something working (at earliest!) but I really, really want “standard” footnotes to just work in pulldown-cmark, so I’m going to keep pushing on it, however slowly.

It also breaks this example from GitHub's GFM docs...
[^1]: My reference.
[^2]: To add line breaks within a footnote, prefix new lines with 2 spaces.
  This is a second line.

...and renders multiple footnote definitions in a group incompatible with Prettier, which collapses away any blank lines you manually insert between them and likely will insist that you're in the wrong if you don't bow to their decision that different Markdown dialects must have non-standard extensions.
(At least, that was their opinion when I asked for a config option to support how Doxygen draws semantic distinctions between certain synonymous Markdown constructs that Prettier currently normalizes.)
...as such, I can't currently use footnotes in any context where more than one definition is grouped together in sequence because my Prettier-on-save will induce pulldown-cmark to produce corrupted output.

This one stumped me for a long time. I really hope there will be a fix at some point.
Currently, I have to:
[^1]: Def for 1

\

[^2]: Def for 2

Which would be fine, except it adds a lot of spacing in the resultant HTML


Make the dinosaur animation responsive

Modify the dinosaur animation by adding media query in it.

hi , i will like to work on this issue

Hi @Godwindaniel10, I assigned this issue to you.

aiit, thanks

Any update on this issue?

Planned on working on the issue today

Okay, waiting for it @Godwindaniel10

aiit

Tell me when you're done @Godwindaniel10

@vinzvinci , i have submitted a PR


UnitTesting Aggregates fails because of versioning changes

Describe the bug
I have a private project where i upgraded from Eventuous 0.8.X to 0.10.4. Everything went smooth and fine. But now all my unit tests fail. But to be honest, this even may be a wrong apporach on my side. ;)
The problem is, that after this massive commit the Apply method of Aggregate.cs is not counting uncommited changes to the aggregate version anymore. This leads to the problem, that all aggrgate commands which utilize EnsureExists fail, if no events have been loaded.
Maybe calling a sequence of commands on the aggregate is the wrong approach to setup an aggregate state for testing? One could argue that i should create a list of domain events and feed them into the aggregate via Load(). But using these methods at least was quite convenient.
To Reproduce
I have created a small reproducer
Expected behavior
Unsure if the old or new behavior is to be expected.

I guess it's a bug in EnsureExists. I will add your test.

I already have a test for this, and it is failing. I really need to set up the automatic run in the CI...

https://github.com/Eventuous/eventuous/releases/tag/0.10.5

That was :zap: fast! Thanks! Works fine now. :)


Instance has been daemonized and initialized successfully (pid: 12644)rendering has finished with errors

Hello.
I have been using the jsreport without problems, but the application has started to have the follow exception in release server (test server no problem).
Please, could you help me? Any help would be appreciate.
"Error rendering report: instance has been daemonized and initialized successfully (pid: 12644)rendering has finished with errors:A critical error occurred while trying to execute the render command (2). spawn UNKNOWN (1). caused by error (2):-> stackError:    at onCriticalError (D:\snapshot\jsreport\node_modules\jsreport-cli\lib\commands\render.js:302:19)    at D:\snapshot\jsreport\node_modules\jsreport-cli\lib\commands\render.js:256:14    at processTicksAndRejections (internal/process/task_queues.js:97:5)caused by error (1):-> stackError:    at Client.render (D:\snapshot\jsreport\node_modules\jsreport-client\lib\client.js)    at processTicksAndRejections (internal/process/task_queues.js:97:5)    at async startRender (D:\snapshot\jsreport\node_modules\jsreport-cli\lib\commands\render.js:319:24)    at async D:\snapshot\jsreport\node_modules\jsreport-cli\lib\commands\render.js:226:22    at async Commander.executeCommand (D:\snapshot\jsreport\node_modules\jsreport-cli\lib\commander.js:242:22)Remote stack: Error:    at ChildProcess.spawn (internal/child_process.js:407:11)    at Object.spawn (child_process.js:548:9)    at Object.childProcess.spawn (pkg/prelude/bootstrap.js:1496:27)    at Launcher.launch (D:\snapshot\jsreport\node_modules\puppeteer\lib\Launcher.js:132:40)    at async getBrowser (D:\snapshot\jsreport\node_modules\jsreport-chrome-pdf\lib\dedicatedProcessStrategy.js:13:21)    at async D:\snapshot\jsreport\node_modules\jsreport-chrome-pdf\lib\conversion.js:4:19    at async execute (D:\snapshot\jsreport\node_modules\jsreport-chrome-pdf\lib\dedicatedProcessStrategy.js:10:22)    at async Object.execute (D:\snapshot\jsreport\node_modules\jsreport-chrome-pdf\lib\chrome.js:69:20)    at async D:\snapshot\jsreport\node_modules\jsreport-core\lib\render\render.js:149:5"

It seems it has problems with launching chrome.
Please try the following:

stop jsreport daemon processes by deleting "node.exe" processes.
remove jsreport temp files, its typically here c:\Users\xxx\AppData\Local\Temp\jsreport\,
try to render again

Wonderful... it worked.
Many thanks for your help e fast reply!!!

it worked after killing "node.exe" from task manager and then removing temp files. tx

Maybe something is partially corrupting the temp directory and it would be better to use another safe dir.
You can try to use another safe dir if the problem reoccurs.
https://jsreport.net/learn/dotnet-local#temp-files
It could help me to have some insights if you share the jsreport temp folder content with me when the problem occurs.

Thanks for responding. I had a look at the copy of the temp folder that was failing, and the only recently updated files were in the autocleanup folder (a bunch of html and json files) and then the debug.log file in compile\jsreport-2.9.0-SJEB3Pyev\chrome.
The debug.log file had some entries (about PruneCrashReportDatabase) but they had been occurring for over a year (and the service has been running fine until just last week).
If we hit the issue again, perhaps we'll periodically clean up the temp folder.

It seems it has problems with launching chrome. Please try the following:

stop jsreport daemon processes by killing "node.exe" processes.
remove jsreport temp files, its typically here c:\Users\xxx\AppData\Local\Temp\jsreport\,
try to render again

Worked like a charm. Thank you.


Create guidance document for SDK code generation (JS management plane)

This task involves creating a comprehensive guidance document for generating SDK code and package in the JS language. The document should be applied to both manual and automated generation processes.
Purpose
The document will serve as a reference for the service team, detailing the steps for SDK code generation while the automation process is still under development. Once finalized, the guidance will be linked to the release planner app and used by the service team as the primary resource.
Requirement
It should provide clear instructions, examples, and relevant best practices to ensure consistent and reliable SDK generation.
References
Generation script

ETA
[PLANING]
Consideration

[LONG TERM] cli using automation_init/generate.sh with simpler inputs

input: base on generate_inut.json to add guidance
ouput:  [DESIGNING]

Added the linked issue @wanlwanl is working on:
https://github.com/Azure/azure-sdk-for-js/issues/31670


[Bug]: Cipher Group recreating even if exists

Summary
When I create a cipher group, the initial add works. If i run the playbook again, it doesn't find the group it just created and tries to create it again, which fails.
Issue Type
Bug Report
Component Name
netscaler.adc.sslcipher
Python Version
$ python --version # or python3 --version
Python 3.10.12

Ansible Version
$ ansible --version
ansible [core 2.15.5]

Ansible Configuration
$ ansible-config dump --only-changed

netscaler.adc Collection Version
$ ansible-galaxy collection list netscaler.adc
Collection    Version
------------- -------
netscaler.adc 2.4.0

Target NetScaler Version
> show ns version
14.1

Equivalent NetScaler CLI Command

Steps to Reproduce

- name: Cipher Group
  delegate_to: localhost
  netscaler.adc.sslcipher:
    nsip: "{{ inventory_hostname }}"
    ciphergroupname: ciphertest
    state: present

Run twice
Expected Results
The first one succeeds and creates the cipher group. The second run errors out because the group already exists, instead of reporting "ok".
Actual Results

Additioinal Notes
No response

This has been fixed in the above PR #358
You can install the unreleased netscaler.adc collection with this fix by below command
ansible-galaxy collection install "git+https://github.com/netscaler/ansible-collection-netscaleradc.git" --force


Support for suppression

A tool like dep-scan inevitably produces false positives due to aliasing and SBoM generation lifecycle.
While tools like trivy offer ignore files and rego policies to support advanced filtering, depscan could offer a toml based solution instead.
Regarding file naming and folder structure, it might be wise to adopt dot-config instead of spoiling the root folders of every repo.
https://dot-config.github.io
So suppression lists could be kept under .config/depscan/*.toml with an optional --config-dir to override this directory for integration use cases.

@prabhu Is there a purpose for the depscan folder under .config since dot-config is talking about a .config directory at the repository level?
To clarify the --config-dir option, should this be to not use a suppression list or do you mean an alternative toml path to load?


Food saturation/level drain event

Currently there is no clean way to cancel the food saturation or food level going down. An event for this would be nice

I think that's what ChangeDataHolderEvent is for.

It's not implemented, though.

Closing this as it is encompassed into ChangeDataHolderEvent.


sph_harm issues

Kind of similar to #4887, I found an inconsistency in sph_harm, but it appears on Python 3.4 (e.g., on Anaconda scipy=0.16 or scipy=0.15) but not on Python 2.7 with equivalent numpy/scipy versions. Running this command in a Python 3.4 Anaconda virtual environment I get:
$ python -c "from scipy.special import sph_harm; print(sph_harm(1, 1, 1., 1.))"
(-0.290723302201-2.02129965364e-310j)

But the correct result is what I get on Python 2.7 (verified using calculations from [here] (https://github.com/mne-tools/mne-python/blob/master/mne/preprocessing/maxwell.py#L251):
(-0.157078470549-0.24463522341j)

It does work on my system Python3 when using the Ubuntu-packaged scipy 0.14.1:
(-0.15707847054880641-0.24463522340968866j)

And when I build scipy myself, latest master with MKL or maintenance/0.16.x using system BLAS, they both give the same correct result:
(-0.157078470549-0.24463522341j)

Any idea why it could break for 3.4 and not 2.7? And only some builds (apparently Anaconda)? This is a weird one.
cc @jennystone @argriffing since you were on the last PR merge related to this
cc @wronk

Whatever compiler they are using has miscompiled the Cython-generated routine
__pyx_f_5scipy_7special_8sph_harm_sph_harmonic
so that it returns the wrong value.
Probably only the anaconda guys can help you out with this.

Cool, I'll bother them instead. Is it easy to describe how did you isolated the problem to that function?

That's the innermost function that actually does the calculation.
Although the debug symbols are missing, you can see on fin from that function that the returned value has the incorrect imaginary part.

Thanks!

This was also noted on stackoverflow: http://stackoverflow.com/questions/33149777/scipy-spherical-harmonics-imaginary-part


Integrate Arduino Uno Wifi Rev2

As the Wifi Rev2 edition of Arduino seems not to work with our current Uno plugin we have to adapt a specific one for the Wifi Rev2 edition.

[x] Add as Arduino group plugin
[x] Adapt CompilerSetupWorker
[ ] Add resources

[x] Linux
[ ] Windows
[ ] OSX

[ ] Compiler

[ ] Linux
[ ] Windows
[ ] OSX

[x] Add to Connector

[x] Linux
[ ] Windows
[ ] OSX

Similar to the festobionic implementation a different compiler is needed.
As the atmega4809 specs and libs are not part of the default avr-gcc implementation of Ubuntu, we need the modified one from Arduino. A link to the compiler can be found here in the ArduinoIDE packages.
With these commands I added it to my path:
cd ~
wget http://downloads.arduino.cc/tools/avr-gcc-7.3.0-atmel3.6.1-arduino5-x86_64-pc-linux-gnu.tar.bz2
mkdir -p ~/avr-gcc
cd ~/avr-gcc
tar -xf ~/avr-gcc-7.3.0-atmel3.6.1-arduino5-x86_64-pc-linux-gnu.tar.bz2
rm ~/avr-gcc-7.3.0-atmel3.6.1-arduino5-x86_64-pc-linux-gnu.tar.bz2
echo "export PATH=\$PATH:\$HOME/avr-gcc/avr/bin" >> ~/.profile

Next, I uninstalled our recommended avr-gcc to use the custom one instead.
I also added functionality to the robot.plugin.compiler.linux.dir property which can be used to have both compilers running at the same time.
However, all of our integration tests run with the newer compiler version as well so we could replace it altogether (after more testing of course).
As the Arduino Uno Wifi Rev2 inbuilt LED is not on pin 13 but on 25 and 25 is not available on the board, I also added a new entry to the LED dropdown BUILTIN_LED, similar to the Arduino constant used in e.g. the Blink example.

The avrdudes working with the Wifi Rev2 are also linked in the package index:

Linux ARM 32
OSX
Linux 64
Linux 32
Windows

Compilers for OSX, Windows and Linux ARM 32 can also be found there.

I tested the compiler and avrdude on Windows, both worked with standard Uno and Uno Wifi Rev 2. Additional compiler resources are not needed.

Linux ARM compiler also seems to work, tested on a Raspberry Pi 4 and compiled for all avr-gcc robots.

Connecting via Raspberry also works.
For the IMU the additional library Ardunio_LSM6DS3 is necessary.

The previously mentioned library does not include the inbuilt temperature sensor, because of that the library by SparkFun will be used instead.

The gyro and accelerometer blocks can be added to the program with CTRL-6. This will create the two program and config blocks.

works fine with latest openroberta-connector


Update logic to find threading library

Fixes #5412 and #4942.
Removes the custom logic for adding pthread flags and uses FindThreads exclusively. The manually added pthread flags were interfering with CMake's detection for if -pthread should be added. However, the manually added flags were also not in the public interface, leading to linker errors in certain configurations.
Removing the manually added flags also lead to a different path in FindThreads.cmake which was triggering #4942. I've added a workaround for that, which is to filter out the Threads::Threads target from the pkgconfig file generation. This may mean that pkgconfig file users have to add -pthread manually. @stevenrbrandt is this an acceptable workaround for you?
@kordejong this is mostly the same changes that you tested earlier, but since I did reshuffle things a bit I'd be grateful if you could give these changes a try as well.

@msimberg I installed the Ubuntu libasio-dev package, built HPX and my hello-world target now links fine, as before.
BTW, do you recommend using the system's Asio or fetching a (newer?) version of Asio?

@msimberg I installed the Ubuntu libasio-dev package, built HPX and my hello-world target now links fine, as before.
BTW, do you recommend using the system's Asio or fetching a (newer?) version of Asio?

Thanks for checking!
I think all relatively recent versions of Asio will be fine. I've tested 1.16 myself and it works fine. We have 1.18.X as the tagged version when it's fetched. However, we use only a small subset of Asio that changes relatively raraely, so older versions are likely to work as well.


Toggle sidebar visibility and minor visual improvements

Pull Request
Description

Adds ability to toggle left sidebar open and closed to save screen space
Adds new icons for the top submenu
Change subheadings to PascalCase

Related Issue
Adds #274.
Checklist

[x] I have added commit messages that are descriptive and meaningful.
[x] I have tested the changes locally.
[x] I have reviewed the code changes.

Screenshots
Menu, set to be opened on default, with new icons:

Closed menu:

Tested and changes look good, thank you for the menu ideas!


Do not create request builder classes in parallel

This causes quite severe corruption of the CodeModel. Many threads concurrently start creating the same models and start adding properties. The result is undefined for larger models and will be different on every run.
This probably fixes (or at least improves the situation for) #2442.
I ran into this trying to build an SDK with the fix for the renaming of properties, which sometimes worked and sometimes didn't work.

I really do not see any way to guarantee consistency when the CodeModel is built in a concurrent way. At the moment, multiple threads start creating the same CodeClasses and start building on those partly generated classes further on. Getting this to be thread safe will require a lot of explicit locking around building types, which will very likely remove any benefit from running this in parallel. For our API (about 10% the size of the Graph API), I didn't notice any change in performance. Generation is still done in just a few seconds. Generating the Go code does not take any longer than compiling it. IMHO the benefits of parallelism at this point do not outweigh the caveats of all the concurrency issues.

My simple benchmark on my gigantic machine :grin: (yes, it is and my colleagues think I'm mad carrying such a heavy 'laptop'), gave about the following results:
With parallelism: Total generation for Go takes a little over 30 seconds, of which about 11-12 is spent in step 7.
Without parallelism: Total generation takes about 60 seconds, of which 40 is spent in step 7.
So the speedup on my machine is roughly 30 seconds or 50%. But, the instability also counts. I had several runs with parallelism that crashed with an error. Given the unpredictability, I would blame the concurrency. Also, none of the runs with parallelism produced compiling code. The runs without parallelism did produce working code.
Compiling the Go code takes about 30 seconds. IMHO this must be added to the total build time. This reduces the speed gain to about 33%.

These are the proplems I've spotted for the creation of properties:

KiotaBuilder.CreatePropertiesForModelClass can be run by multiple threads at the same time for the same type. This results CodeClass.AddProperty to start resolving conflicts for identical properties.
CodeClass.AddProperty searches through the type hierarchy for existing properties, but has no guarantee that these types are actually built entirely. This often results in it not picking up properties, because the super type did exist, but its properties hadn't been created yet.

However, during my runs I've also seen problems building inheritance chains and I've got infos about unused types being pruned even though I'm sure they are being used in the API.
Building a complex, highly interconnected data structure concurrently really is asking for trouble if you ask me. I'd much rather have a tool that's highly reliable but a bit slower than a tool that's fast but spits out incorrect results every now and then. These concurrency issues will continue to haunt you and they will be very hard to find and nearly impossible to reproduce.
What's more, the concurrency causes code paths to be executed in unpredictable ways. This can cause Kiota to make different decisions depending on which happens first. Even if all concurrency issues get fixed, this can still cause Kiota to generate different code on subsequent runs on the same input. IMHO this should never happen in a tool like Kiota.

I've spent this morning further troubleshooting inconsistent results and most can be directly related to parallelism. For example, the Parallel.ForEach calls in TrimInheritedModels, GetDerivationIndex and GetInheritanceIndex result in missing types (quite frequent) and even the following stacktrace every now and then:
      System.AggregateException: One or more errors occurred. (Value cannot be null. (Parameter 'key'))
       ---> System.ArgumentNullException: Value cannot be null. (Parameter 'key')
         at System.ThrowHelper.ThrowArgumentNullException(String name)
         at System.Collections.Concurrent.ConcurrentDictionary`2.TryGetValue(TKey key, TValue& value)
         at Kiota.Builder.KiotaBuilder.<>c__DisplayClass91_0.<GetDerivedDefinitions>b__0(CodeClass x) in /home/papegaaij/vscode/kiota/src/Kiota.Builder/KiotaBuilder.cs:line 1750
         at System.Linq.Enumerable.SelectManySingleSelectorIterator`2.ToArray()
         at Kiota.Builder.KiotaBuilder.GetDerivedDefinitions(ConcurrentDictionary`2 models, CodeClass[] modelsInUse) in /home/papegaaij/vscode/kiota/src/Kiota.Builder/KiotaBuilder.cs:line 1750
         at Kiota.Builder.KiotaBuilder.<>c__DisplayClass91_0.<GetDerivedDefinitions>b__1(CodeClass x) in /home/papegaaij/vscode/kiota/src/Kiota.Builder/KiotaBuilder.cs:line 1751
         at System.Linq.Enumerable.SelectManySingleSelectorIterator`2.MoveNext()
2
         at System.Linq.Enumerable.UnionIterator`1.MoveNext()
         at System.Linq.Enumerable.OfTypeIterator[TResult](IEnumerable source)+MoveNext()
         at System.Linq.Enumerable.SelectManySingleSelectorIterator`2.MoveNext()
         at System.Collections.Generic.HashSet`1.UnionWith(IEnumerable`1 other)
         at System.Collections.Generic.HashSet`1..ctor(IEnumerable`1 collection, IEqualityComparer`1 comparer)
         at System.Linq.Enumerable.DistinctIterator`1.ToArray()
         at Kiota.Builder.KiotaBuilder.GetRelatedDefinitions(CodeElement currentElement, ConcurrentDictionary`2 derivedIndex, ConcurrentDictionary`2 inheritanceIndex, ConcurrentDictionary`2 visited, Boolean includeDerivedTypes) in /home/papegaaij/vscode/kiota/src/Kiota.Builder/KiotaBuilder.cs:line 1757
         at Kiota.Builder.KiotaBuilder.<>c__DisplayClass86_0.<TrimInheritedModels>b__1(CodeClass x) in /home/papegaaij/vscode/kiota/src/Kiota.Builder/KiotaBuilder.cs:line 1695
         at System.Linq.Parallel.SelectManyQueryOperator`3.SelectManyQueryOperatorEnumerator`1.MoveNext(TOutput& currentElement, Pair`2& currentKey)
         at System.Linq.Parallel.HashRepartitionEnumerator`3.EnumerateAndRedistributeElements()
         at System.Linq.Parallel.HashRepartitionEnumerator`3.MoveNext(Pair`2& currentElement, Int32& currentKey)
         at System.Linq.Parallel.UnionQueryOperator`1.UnionQueryOperatorEnumerator`2.MoveNext(TInputOutput& currentElement, Int32& currentKey)
         at System.Linq.Parallel.PipelineSpoolingTask`2.SpoolingWork()
         at System.Linq.Parallel.SpoolingTaskBase.Work()
         at System.Linq.Parallel.QueryTask.BaseWork(Object unused)
         at System.Threading.ExecutionContext.RunFromThreadPoolDispatchLoop(Thread threadPoolThread, ExecutionContext executionContext, ContextCallback callback, Object state)
      --- End of stack trace from previous location ---
         at System.Threading.ExecutionContext.RunFromThreadPoolDispatchLoop(Thread threadPoolThread, ExecutionContext executionContext, ContextCallback callback, Object state)
         at System.Threading.Tasks.Task.ExecuteWithThreadLocal(Task& currentTaskSlot, Thread threadPoolThread)
         --- End of inner exception stack trace ---
         at System.Linq.Parallel.QueryTaskGroupState.QueryEnd(Boolean userInitiatedDispose)
         at System.Linq.Parallel.AsynchronousChannelMergeEnumerator`1.MoveNextSlowPath()
         at System.Linq.Parallel.QueryOpeningEnumerator`1.MoveNext()
         at System.Collections.Generic.HashSet`1.UnionWith(IEnumerable`1 other)
         at System.Collections.Generic.HashSet`1..ctor(IEnumerable`1 collection, IEqualityComparer`1 comparer)
         at System.Linq.Enumerable.ToHashSet[TSource](IEnumerable`1 source, IEqualityComparer`1 comparer)
         at Kiota.Builder.KiotaBuilder.TrimInheritedModels() in /home/papegaaij/vscode/kiota/src/Kiota.Builder/KiotaBuilder.cs:line 1695
         at Kiota.Builder.KiotaBuilder.CreateSourceModel(OpenApiUrlTreeNode root) in /home/papegaaij/vscode/kiota/src/Kiota.Builder/KiotaBuilder.cs:line 588
         at Kiota.Builder.KiotaBuilder.GenerateClientAsync(CancellationToken cancellationToken) in /home/papegaaij/vscode/kiota/src/Kiota.Builder/KiotaBuilder.cs:line 207
         at Kiota.Builder.KiotaBuilder.GenerateClientAsync(CancellationToken cancellationToken) in /home/papegaaij/vscode/kiota/src/Kiota.Builder/KiotaBuilder.cs:line 228
         at kiota.Handlers.KiotaGenerationCommandHandler.InvokeAsync(InvocationContext context) in /home/papegaaij/vscode/kiota/src/kiota/Handlers/KiotaGenerationCommandHandler.cs:line 124

Other points of parallelism cause errors like duplicate properties and descriptions being different. For us, parallelism is only a hindrance. We really do not want those inconsistencies in the output. Actually, we don't want Kiota to run things in parallel at all, because we will mainly be running it on our CI/CD environment where runtime is less of an issue but high CPU usage is. Also, for our case the actual speedup isn't even measurable.
I decided to take a different approach: allow the number of threads to be specified via an environment variable. This gives the user the freedom to choose stability or speed. It also allows for easy testing of some of the bugs regarding unstable results.

Thank you for taking the time to collect the metrics and for sharing your experience.
Our vision with kiota is that it's fast enough to be added as part of a local build tool chain (e.g. gradle task) without impacting the experience negatively. Part of that is achieved through the lock file and skipping unnecessary generations, part of that is achieved through ensuring we use resources efficiently.
I can tell your machine is powerful without knowing the specs, on my machine the parallels version for beta takes about 2.5 minutes. Goes in the 10+ minutes without it. And my machine is far from being substandard.
For properties getting added twice: this is something I solved, at least partially in this PR if defects are remaining, let's iron them out.
Again, removing parallelization will reduce the likeliness of race conditions, but not eliminate them. That's because the OpenAPI.net parsing library doesn't guarantee any kind of order in the object model when parsing a document. The better thing to do is to implement the generation in such a way it doesn't assume order when it's reading some information.
Yes, kiota right now has some race conditions going on (especially for TypeScript) which I'm trying to fix before our upcoming release. But Microsoft Graph (v1) has 2000+ models, with multiple levels of inheritance, interconnected properties all over the place, used in over 5000 endpoints. And we use the main line (not the public release) to generate our full SDKs every week.
As you can see in the latest Go pull request the vast majority of changes come from comments (which are scrapped from our public docs). Other than that we get a couple of changes from metadata changes, but we're not getting radical differences from one week to another that'd indicate a major race condition in the code.
Now, I'm not saying the current race conditions cannot have a larger impact on different descriptions, but rather than overhauling the parallels processing and seriously degrading performance, let's instead go after them.
I hope that lengthy explanation helps providing context.

The biggest problems that still remain with the parallelism are with the property conflict resolution, which will really require some form of locking on the CodeClasses. A thread must only start building properties on a CodeClass when properties on all super classes are completely built. I think this can be implemented in AddModelDeclarationIfDoesntExist and AddModelDeclaration. These methods must both not return incomplete existing classes, but block instead. I do fear a potential for deadlocks though.
Another major issue is in the generation of the inheritance tree (see my previous comments). This algorithm either misses out on types or crashes.
Can this change please be merged. That would at least allow me to continue my work on my own product without having to work on a branch of Kiota. Our OpenAPI spec is smaller than the Graph spec, but a lot more interconnected. This results in totally incorrect results all the time, making Kiota completely unusable. The changes in this PR should not affect the parallelism by much. You can tweak the default of 5, maybe -1 for unlimited? The change to drop AsParallel() in TrimInheritedModels didn't seem to impact performance on my machine, but maybe you know of a way to have it follow the configured number of threads?
BTW. I'm also working on more changes to get the output more stable. I've already identified a spot where a type name was incorrectly capitalized, which could result in changes in comments, like in models/group.go in the PR you linked. At the moment I'm tracking down a changing type description. My goal is to have Kiota generate fully stable code and I'm quite close.

Also for context this comment was written at about the same time of your prior one, and I had not seen it when I posted mine :) (GitHub still doesn't do systematic refresh...)

Thanks for wrapping this up. I had to go out running yesterday.


How to stop and resume training

Do you have to do anything specific to stop the training if you want to test the model? can I just close the command prompt? How do you resume training when you stop it?

To stop usually I just kill .
To restore you have to use the argument --restore_from and appoint the last version of yout model at the logdir folder.

I tried this, but I am seeing no indication that it worked. The step number reset back at 0 and the loss shot back up to early training levels.


Unable to retrieve tag from local registry

Bug description
I am running a local registry on my host Windows 10 machine.
After purchasing and enabling the Registry Manager Extension, I'm able to visualize the repository with different image tags that I have pushed.
However, if I click into any of the repository and refresh the page, it gives me an error saying: "FAILURE: Unable to retrieve tag "
The repositories are still there, just unable to retrieve the images with tags.
I first thought it might be the registry, so I tried to "docker pull" images from the local registry and I am able to do that.
Expected behavior
I'm expected to have visual on all of the images with the tags so I can manage them.
Steps to reproduce the issue:
Steps to reproduce the behavior:

Run the local registry by running:

docker run -p 5000:5000 --name registry -e REGISTRY_STORAGE_DELETE_ENABLED=true -v <directory_of_the_local_registry>:/var/lib/registry registry:2

Assuming the Registry Manager extension is enabled, use "Custom Registry" to setup the registry
Enter a registry name and enter the URL which is the URL of the local registry: <ip_address>:5000
Click on "Add registry"
Push an image with different tag names, for example, I pushed the hello-world image to the local registry with different tags:

docker tag hello-world localhost:5000/hello-world:latest
docker tag hello-world localhost:5000/hello-world:lts
docker tag hello-world localhost:5000/hello-world:1.0.0
docker push localhost:5000/hello-world:latest
docker push localhost:5000/hello-world:lts
docker push localhost:5000/hello-world:1.0.0

Go back to Portainer, click on "Registry" then "Browse", then "hello-world"
You should be ble to see all the images, but refresh the page.
you should see that all the images disappeared and the error "FAILURE: unable to retrieve tag latest", "FAILURE: unable to retrieve tag lts", "FAILURE: unable to retrieve tag 1.0.0"

Technical details:

Portainer version: v1.20.1
Docker version (managed by Portainer): 18.09.2
Platform (windows/linux): Windows 10
Command used to start Portainer (docker run -p 9000:9000 portainer/portainer):

docker run -d -p 9000:9000 -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer

Browser: Microsoft Edge

Additional context

I can confirm this for v1.20.2 as well.
Using Portainer we get the following error(s):

Using Docker Registry UI it works:

This error seems to be coming from the browser. It works fine using Chrome, but it doesn't work for Microsoft Edge

First response was from edge, second from firefox.
Sorry, no love for Chrome this time :)

Using Chromium I get the same response as for Firefox:
{"errors":[{"code":"MANIFEST_INVALID","message":"manifest invalid","detail":{}}]}

Just updated portainer to 1.21.0 and the agents to 1.3.0 and still got the errors.

Could be related to #2687

Can confirm the problem for portainer 1.22.0.

@x-jokay give a try to portainerci/portainer:pr2648 as it is a rework of the RM UI that will be coming soon.

I can confirm the portainerci/portainer:pr2648 finally works with Safari 13.0.1 on macOS, the previous builds has the same problem as in the description of the issue.
Also tried on Microsoft Edge Beta on Windows 2019 Server, works too.

@ptimar56 Thats great news! Glad to hear it helped you :+1:


Notification repeating

IMPORTANT: Please search the issues, including closed issues, and the FAQ before opening a new issue. The template is mandatory; failure to use it will result in issue closure.
Since a recent update, my alexa announcement are repeating (announced twice in total).

When using "Notifications: Send a notification with alexa_media" and with a type of "announce" and method of "all", try announcing to multiple devices, the announcement is announced twice.
Expected behavior
It announces once
Screenshots

System details

Home-assistant (version):
alexa_media (version from const.py or HA startup):
alexapy (version from pip show alexapy or HA startup):
Amazon 2FA is enabled (y/n). <!---We will not debug login issues if unanswered--->:

Logs
Please provide logs.
Additional context

Please provide logs.

I havent test this yet but I noticed that there were 2 integration entries in my Alexa media configuration. Looks suspicious. I'll try removing one. It may be from a password change that I did recently for Amazon.

Yep that seems to have fixed it.

Glad you figured it out.


Fixed DeleteFileOnController webstack2

CallPost uses "content-type:application/json" and putting raw parameter in data is not ok. need to use query string.

@cielavenir

Do you need to url encode the filename?
Please test against webstack2

I have run mujindeletefile sample against webstack2 environment, but yes, I have not tested url encode.
If I need it, how should I do?

EscapeString

@ziyan I found that _PrepareDestinationURI_UTF8 calls EscapeString internally, so the URL is encoded.
On the other hand, I found that UploadFile must not encode the filename.Why webstack1 accepted encoded filename? Because webstack1 decodes filename field, which is wrong.
This MR itself is OK.
We need to:

Make _PrepareDestinationURI_UTF8's URL encoding optional and disable encoding on UploadFile
Make webstack fileupload not "unquoting" filename

@ziyan clientpy self.UploadFile(open('hello%26delete.txt')) causes creating hello&delete.txt in webstack1.

Make webstack1 fileupload not "unquoting" filename

sent MR series.
But they can be independent with this MR. So please merge this quickly.


Improve LDAP native implementations

Purpose

LDAP with SSL connection related classes were refactored by removing invalid usages.
Removed most of the JAVA validations, since they are already done at Ballerina layer.
Reformat the existing native implementation.
Improve exception handling.

Check List

[x] Read the Contributing Guide
[ ] Required Balo version update
[ ] Updated Change Log
[ ] Checked Tooling Support (#)
[ ] Added necessary tests

[ ] Unit Tests
[ ] Spec Conformance Tests
[ ] Integration Tests
[ ] Ballerina By Example Tests

[ ] Increased Test Coverage
[ ] Added necessary documentation

[ ] API documentation
[ ] Module documentation in Module.md files
[ ] Ballerina By Examples

Codecov Report

Merging #17913 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master   #17913   +/-   ##
=======================================
  Coverage   15.17%   15.17%
=======================================
  Files          46       46
  Lines        1206     1206
  Branches      188      188
=======================================
  Hits          183      183
  Misses       1009     1009
  Partials       14       14

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 8263b42...a2c8571. Read the comment docs.


debugger get trace incorrect gas costs

When getting the trace using the debugger plugin via client.call('debugger', 'getTrace', hash)
The gas for SSTORE are not correct, for instance https://res.cloudinary.com/key-solutions/image/upload/v1565858494/Screen_Shot_2019-08-15_at_07.21.35_nt71df.png
it says gasCost 0

Opened an issue: https://github.com/ethereumjs/ethereumjs-vm/issues/593


serve: Ensure redis-server saves after signal

This is part one of improved shutdown handling; part two will come in a future commit involving a more graceful shutdown of the main node process itself.
I began to notice that running ./go serve to launch the redis-server, using the app, and then killing the script quickly resulted in data loss. This didn't happen when running redis-server manually, as a signal sent to that process would result in it saving its data before exiting. The problem appeared to be that signals sent to the ./go serve script would be sent simultaneously to the redis-server process, under which circumstances it wouldn't save its data automatically.
The script now launches redis-server in a separate process group so that any signals sent to the script aren't sent to the redis-server process. The custom-links server itself now runs as a background process so that the it can be managed explicitly via a trap on the TERM, INT, and HUP signals. Finally, an EXIT trap sends the shutdown save command to the redis-server and waits for the process to exit to complete a graceful shutdown with all data saved.
The redis-server also now runs with --appendonly yes specified, providing more durability against data loss.
This also marks the first time Bats tests have been added for any of the scripts. These are now included as part of ./go test.
The ./go serve script is pretty well-tested at this point, but a few notes:

scripts/lib/config-json needs tests specific to it
The new helper functions added to tests/scripts/serve.bats, namely run_in_background, wait_for_background_output, and stop_background_run, should get moved into the go-script-bash  framework.
scripts/lib/config-json and parts of scripts/serve might make  sense to move into go-script-bash as well.
Coverage for ./go test scripts isn't yet enabled.

Coverage remained the same at 98.089% when pulling 0634f4151a46c4437d3637d03d606ee4eccb5d72 on save-on-exit into 38ab7f39a8b2bdb74dcce90ee4cbd91f416788f4 on master.

Coverage remained the same at 98.089% when pulling cb848871daedd40c78666d805d68d201cc727cff on save-on-exit into 38ab7f39a8b2bdb74dcce90ee4cbd91f416788f4 on master.

Coverage remained the same at 98.089% when pulling f1260d192af0f183514cab91d35331b69a6e6a36 on save-on-exit into 38ab7f39a8b2bdb74dcce90ee4cbd91f416788f4 on master.

Coverage remained the same at 98.089% when pulling f1260d192af0f183514cab91d35331b69a6e6a36 on save-on-exit into 38ab7f39a8b2bdb74dcce90ee4cbd91f416788f4 on master.

Coverage remained the same at 98.089% when pulling e68f0976e929fc8df1cdce03c6bd678e5b941e87 on save-on-exit into 38ab7f39a8b2bdb74dcce90ee4cbd91f416788f4 on master.


pull request for e2e test at 12/25/2016 04:26:10

: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.


HWKBTM-416 Updated the algorithm to better define the areas for atten…

…tion - but a more sophisticated algorithm will probably be required that can determine where time is spent within intermediate nodes vs their child nodes, etc

Merging as failure was due to npm problem when building the UI.


[firestore-bigquery-export] Cannot install extension: npm error

Extension name: firestore-bigquery-export
Extension version: 0.1.17
Configuration values:

Collection path: edition/{editionId}/event
Dataset ID: appdata
Table ID: events
Partitioning: none
LOCATION: europe-west3
DATASET_LOCATION: eu

Steps to reproduce:
Install the extension either from the CLI or from the Web UI. I tried with two different configurations and both fail.
Expected result
The extension installs and starts sending data to BigQuery.
Actual result
This error occur:
Build failed: npm ERR! cipm can only install packages when your package.json and package-lock.json or npm-shrinkwrap.json are in sync. Please update your lock file with `npm install` before continuing.
npm ERR!
npm ERR!
npm ERR! Missing<EMAIL_ADDRESS>npm ERR!

npm ERR! A complete log of this run can be found in:
npm ERR!     /www-data-home/.npm/_logs/2021-08-20T10_29_43_100Z-debug.log; Error ID: beaf8772

Sometime the installation fails, sometimes succeeds, but the associated cloud function reports the same error in the logs and doesn't start at all.

On a side note the previous version, 0.1.16, works flawlessly.
I could downgrade my existing installation to fix the issue, with this command:
firebase ext:update [Instance ID]<EMAIL_ADDRESS>
you can see the extension Instance ID from the firebase ext command. The command will still work even if you're downgrading and not upgrading, it only asks twice for confirmation.

@ibobo thanks for reporting this. Yes we rolled back to the previous version and are investigating what caused this version to break.

Fixed via https://github.com/firebase/extensions/pull/740 and a related comment added regarding an update to the extension.


Window corners look weird in 4K

Steps to reproduce: Use Hyprland on a 4K monitor with an Nvidia GPU (I have no idea if it could be related).
Expected outcome: Window corners that look good and all the same.
Noted outcome: Some window corners look weird and jagged. It seems to also happen when rescaled to 1440p and 1080p.
4K with AA:

4K without AA:

I've heard about this ever since I added rounded corners. However...

2880x1800 looks like this to me. Don't have a 4K display to test, but iirc also was an issue sometimes on ultrawides...?
I am planning on touching the rounding shader a bit yea, but this is odd and idk where it comes from.

fixed in c78db1212ba0d0e53b8c636d745ac9b8c379d2e4


How to draw the 3D reconstruction results

Hi, Yao,
Thanks very much for your fantastic project.
I wonder how to draw the 3D reconstruction results  shown below:

Should I use matlab or other tools ?

The software meshlab will be OK.

Thx!

The software meshlab will be OK.

Thx!

The software meshlab will be OK.

Thx!

你好，有个问题想请教下您，训练前先要准备uv position map gt，我看代码思路是基于同一个BFM模型生成的uv map。不应该是先得到每个图片对应的BFM,再根据BFM得到uv图么，关于gt制作
这一块，您有什么见解吗？

how to draw the 3D recostruction results with meshlab, I still didn't obtian the picture with a gree 3D mask

Thx
您好，请问您用meshlab实现这种效果了吗？希望大佬能回复一下，非常感激！！

The software meshlab will be OK.

Hi，could you explain how to use meshlab to draw this, i still didn't obtain the picture with green mask too, many thanks to your reply !!!