Swagger object ignore undeclared

I am not sure this is the right fix. The Strava API's JSON fails with
     Hashie::CoercionError:
       Cannot coerce property "responses" from Hash to {String=>Swagger::V2::Response}: The property 'content' is not defined for Swagger::V2::Response.
     # /Users/dblock/.rvm/gems/ruby-2.5.1/gems/hashie-3.6.0/lib/hashie/extensions/coercion.rb:40:in `rescue in set_value_with_coercion'
     # /Users/dblock/.rvm/gems/ruby-2.5.1/gems/hashie-3.6.0/lib/hashie/extensions/coercion.rb:37:in `set_value_with_coercion'
     # /Users/dblock/.rvm/gems/ruby-2.5.1/gems/hashie-3.6.0/lib/hashie/extensions/indifferent_access.rb:107:in `indifferent_writer'
     # /Users/dblock/.rvm/gems/ruby-2.5.1/gems/hashie-3.6.0/lib/hashie/dash.rb:199:in `block in update_attributes'
     # /Users/dblock/.rvm/gems/ruby-2.5.1/gems/hashie-3.6.0/lib/hashie/dash.rb:198:in `each_pair'
     # /Users/dblock/.rvm/gems/ruby-2.5.1/gems/hashie-3.6.0/lib/hashie/dash.rb:198:in `update_attributes'
     # /Users/dblock/.rvm/gems/ruby-2.5.1/gems/hashie-3.6.0/lib/hashie/dash.rb:192:in `initialize_attributes'
     # /Users/dblock/.rvm/gems/ruby-2.5.1/gems/hashie-3.6.0/lib/hashie/dash.rb:120:in `initialize'
     # ./lib/swagger/swagger_object.rb:17:in `initialize'

on
{"description"=>"A GPX file with the route.", "content"=>{"application/gpx+xml"=>{"schema"=>{"type"=>"string", "format"=>"binary"}}}}

Relaxed undefined properties 🤷♂

Someone wants to merge this?


docs: add a11y docs

Add docs around SvelteKit's accessibility features and what developers need to do to play nicely with them.
I focused these docs on SvelteKit-specific concerns (route announcements, focus management) instead of general a11y practices (e.g. skip link, button vs link, etc). In the future, a "Guides" section on learn.svelte.dev may be a good place to go deeper into general a11y best practices, or integrated into the official SvelteKit tutorial.
I'm looking for feedback on prose, accuracy of information, and thoughts on anything else we want to include (or exclude).
Leaving in draft for now until the dust settles on the big routing changes.
Prior art:

Next.js
Remix
Ember

Context around route announcement/focus management: https://github.com/sveltejs/kit/issues/307

Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

[ ] It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
[x] This message body should clearly illustrate what problems it solves.
[ ] Ideally, include a test that fails without this PR but passes with it.

Tests

[ ] Run the tests with pnpm test and lint the project with pnpm lint and pnpm check

Changesets

[ ] If your PR makes a change that should be noted in one or more packages' changelogs, generate a changeset by running pnpm changeset and following the prompts. All changesets should be patch until SvelteKit 1.0

@geoffrich this is a great start, and the snippets you have included are really helpful.
My only caution is that getting a11y right requires a lot more thought, and I wonder if this needs to be more explicit in the documentation? i.e., whilst Svelte/SvelteKit provides some really good helpers, on their own they don't make an a11y app.
You're already thinking about this with the proposed 'Guides' section on learn.svelte.dev, but helping people be aware of the built-in capabilities as well as understand that these alone don't make an accessible app would be a really open approach to building a better AX.

My only caution is that getting a11y right requires a lot more thought, and I wonder if this needs to be more explicit in the documentation? i.e., whilst Svelte/SvelteKit provides some really good helpers, on their own they don't make an a11y app.

@accuser would something to this effect in the intro be what you're looking for? "Keep in mind that while SvelteKit aims to provide an accessible foundation, you are still responsible for making sure your application code is accessible. If you're new to accessibility, see the "Further Reading" section of this guide for additional resources."
I had something similar to that in one of my drafts, but it got lost along the way.

The big +page PR merged, so this is ready for review now.


python310Packages.pyoverkiz: 1.5.5 -> 1.5.6

Description of changes
https://github.com/iMicknl/python-overkiz-api/releases/tag/v1.5.6

Things done

Built on platform(s)

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

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

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

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

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

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 198088 run on x86_64-linux 1

3 packages built:

home-assistant-component-tests.overkiz
python310Packages.pyoverkiz
python39Packages.pyoverkiz


[Issue]: Treasury Report Adjustments

Why is this issue important?
Needs to be adjusted in order to be uploaded correctly to the Treasury portal.
Current State
Dates in the treasury report are displaying with incorrect date formatting and also a time stamp - YYYY-MM-DD 00:00:00 (i.e. 2024-02-11 00:00:00)
Blank values are displaying as "None"
Expected State
Date formatting for any date values needs to be updated to MM/DD/YYYY (i.e. 02/11/2024)
When a value is blank, it should reflect as blank
Implementation Plan
The following functions need to be added...
Relevant Code Snippets
No response

https://github.com/usdigitalresponse/cpf-reporter/pull/437

Tested in project files and this looks great in staging. Waiting to test subrecipient file as well


Fix Enumerable#contains deprecation warnings

As of ember 2.8.0-beta.1, Enumerable.contains() has been depreciated
in favor of Enumerable.includes(). Semantic-UI-Ember uses the
depreciated function in several places, this simply replaces those
usages. http://emberjs.com/deprecations/v2.x/#toc_enumerable-contains
Thanks #Panman8201 for the initial pull request #121

Thanks for the pull request. This was the initial route we were going to go, but I think a cleaner approach now is using this addon https://github.com/rwjblue/ember-runtime-enumerable-includes-polyfill. If you can update it using that we can merge it in.

I have added the addon as dependency to the package json. Unfortunately i didn't know that such an addon existed. This solution is much cleaner, thanks for the hint/info about this addon/polyfill!
Build is in progress :)

No problem, I actually saw it on accident the other day. I think the only change you need to make is just change contains to include now. Since the addon will polyfill that.

Oh i forgot, thanks! Build is running :)

👍  Great thank you. Could you compress that to one commit so we don't have the extra history of the add and remove and i'll merge it in. Thanks for your help on this

done! 👍


multiple wasm backends (aka interpreter)

link in the Binaryen interpreter from the version installed as part of our build script into the wasm interface and allow hot swapping between that and the jitter (currently defaulting to the jitter but perhaps not for long?)
Note, this creates a code link to binaryen's 1.37.x release as the embedding API has changed at some point after that.

@heifner Travis is failing because the OCI repo has binary versions of binaryen but not the src directory needed
@ericiles It looks like Jenkins is failing because the previous version of the installer doesn't survive the parts of binaryen we need (the new installer does)

Since we're basically dipping our fingers in to what is considered private source -- not the publicly defined API for the library -- why not just bring the source in as a submodule? It's bizarre and confusing for us to still depend on the external source tree of binaryen after doing a make install of binaryen. This isn't how it works for any other library.

We have decided to kill Travis build since we now have Jenkins in place.

So, the new Jenkins error, reproducible locally on Ubuntu 16.04 seems to have something to do with compiling binaryen as a dependency with the system compiler (aka GCC 5.4 on ubuntu 16.04) and linking those libraries to our executable compiled with ClangX.   Using GCC 7.x shows no problem and using Clang to build binaryen also shows no problem.
The net result is that I will be passing the buck to @spoonincode (sorry) to link Binaryen is a a submodule instead of a build dependency.  This is probably more apropos as we were not using the released libraries/headers as is and were techincally linking against internal libraries.
Marking this PR as in progress as a result.

looking to the FindBinaryen you coded it seems you are trying to add the targets generated by Binaryen build using a Find*.cmake syntax.
Actually it is very confusing cause Find*.cmake paradigm is used to find installed packages (headers, binaries, and libs) not internal libraries.
It suggest you to add the Binaryen source into EOS source (submodule + add_subdirectory) or use cmake paradigm: ExternalProject

@asiniscalchi yes that's exactly what we're going to do; binaryen source (from eosio fork) will be included as submodule

Be advised -- there is still much work to be done to clean this up. And WAVM is still the runtime used. But I think we can merge this now and clean up via smaller PRs based on trunk.


site support request: gazeta.ru

Can you please add support, example url http://www.gazeta.ru/video/main/zadaite_vopros_vladislavu_yurevichu.shtml
youtube-dl -vg http://www.gazeta.ru/video/main/zadaite_vopros_vladislavu_yurevichu.shtml[debug] System config: []
[debug] User config: []
[debug] Command-line args: ['-vg', 'http://www.gazeta.ru/video/main/zadaite_vopros_vladislavu_yurevichu.shtml']
[debug] Encodings: locale UTF-8, fs UTF-8, out UTF-8, pref UTF-8
[debug] youtube-dl version 2014.11.16
[debug] Python version 2.7.3 - Linux-3.2.0-69-generic-pae-i686-with-LinuxMint-13-maya
[debug] exe versions: ffmpeg 2.4.2, ffprobe 2.4.2, rtmpdump 2.4
[debug] Proxy map: {}
WARNING: Falling back on generic information extractor.
ERROR: Unsupported URL: http://www.gazeta.ru/video/main/zadaite_vopros_vladislavu_yurevichu.shtml; please report this issue on https://yt-dl.org/bug . Be sure to call youtube-dl with the --verbose flag and include its complete output. Make sure you are using the latest version; type  youtube-dl -U  to update.
Traceback (most recent call last):
  File "/usr/local/bin/youtube-dl/youtube_dl/extractor/generic.py", line 609, in _real_extract
    doc = parse_xml(webpage)
  File "/usr/local/bin/youtube-dl/youtube_dl/utils.py", line 1319, in parse_xml
    tree = xml.etree.ElementTree.XML(s.encode('utf-8'), **kwargs)
  File "/usr/lib/python2.7/xml/etree/ElementTree.py", line 1301, in XML
    parser.feed(text)
  File "/usr/lib/python2.7/xml/etree/ElementTree.py", line 1643, in feed
    self._raiseerror(v)
  File "/usr/lib/python2.7/xml/etree/ElementTree.py", line 1507, in _raiseerror
    raise err
ParseError: undefined entity: line 81, column 19
Traceback (most recent call last):
  File "/usr/local/bin/youtube-dl/youtube_dl/YoutubeDL.py", line 536, in extract_info
    ie_result = ie.extract(url)
  File "/usr/local/bin/youtube-dl/youtube_dl/extractor/common.py", line 199, in extract
    return self._real_extract(url)
  File "/usr/local/bin/youtube-dl/youtube_dl/extractor/generic.py", line 996, in _real_extract
    raise ExtractorError('Unsupported URL: %s' % url)
ExtractorError: Unsupported URL: http://www.gazeta.ru/video/main/zadaite_vopros_vladislavu_yurevichu.shtml; please report this issue on https://yt-dl.org/bug . Be sure to call youtube-dl with the --verbose flag and include its complete output. Make sure you are using the latest version; type  youtube-dl -U  to update.

Support for gazeta.ru should be available in the next release of youtube-dl. Thanks for the report!


Cant figure out how to Create Pull Request

I want to push my branch to the main branch.
cant seem to figure out how

If you are on your own branch:
git push origin my-branch-name

Then on github, create a new pull request and select your branch:

Got it, the reason that didnt show, was because i had a old pull request. I had to close that one first.
Can I merge the pull request as well? or was that for you only to do?
Tuyen and dan, and ryhs need whats in my branch to do there parts that we hope to get done before monday.

Merged. Also, watch out for your C# code style. Braces should be on the opening statement.


message queue processing code should not perform local actions

for the host player, the message queue processing code is what updates the local scene based on the message that was received. this is a problem because it mixes the concerns of dispatching messages to all clients and handling messages for our own "client" (the local player on the host machine). this makes refactoring more difficult than necessary. instead, there should be a separate queue for updates that need to be performed locally, much as there is one for each connected client

does this imply there should be two scenes on the host after all? one visible one and one "authoritative" one? that doesn't seem right


Update es.json

Changed some incorrect terms and typos!

Can you rebase off rji/dev branch instead of main?

Closing because dupe of https://github.com/Rayji96/foundry-V5/pull/90


Bot sticks on new blocks in MC 1.18.1

Steps to Reproduce (as best as you can)
run @gamer
Expected Behavior
walk across the blocks
pass by the blocks
Actual Behavior
stick on new blocks in MC 1.18.1
keep turning around
move around again and again
Crashlogs and Screenshots (if applicable)
(you may drag + drop text logs and images here, thanks GitHub)
latest.log

Other mods (if applicable)
sodium
starlight
baritone
fabric api
iris
Discord username (if you want updates)
Developer Notes (leave this blank)
Difficulty: __
Estimated Time Required: __
Once development starts.

it cant do anything until u break the block

This is due to there being a bunch of water behind it. Baritone doesn't like water. In general, the bot will resolve must pathing issues on its own.
I would appreciate a more detailed report though just in case. Take a look at my example issue in the issues page.

no even when there is no water it wont move just stays stuck like that experienced it abut 30xtimes already

I believe this won't be an issue in 1.18.2. Some of the way block tracking works changed and a little bit with avoiding oceans. Let's circle back and see if this still happens.

this is still a problem even without water behind it. altho it can be fixed by adding azalea in blocks to avoid list.


[Feature Request] Allow glob pattern for exclude paths

Describe the feature you'd like

Atm it is not possible to exclude files by a pattern, i.e. *tests*.
Which means that each path needs to be added explicitly to the exclude list.
While this might be ok for very small projects, it gets quite nasty for bigger projects.
Is your feature request related to a problem?

If you have a project where the tests are part of the package and its subpackages, i.e.:
project/
    tests/
     sub-package1/
         tests/
     sub-package2/
         tests/

You would need to add project/tests, project/ sub-package1/tests and project/ sub-package2/tests to be excluded, if you want to exclude all tests.
Additional context

The desired behaviour could be quite easily achieved by checking the path to exclude with fnmatch, this would at the same time solve #51 and could be included in #56 .
In [1]: from fnmatch import fnmatch

In [2]: test_paths = ["/home/project/tests", "/home/project/tests/test_file", r"C:\project\tests", r"C:\project\tests\test_file"]

In [3]: [fnmatch(test_path, "*tests") for test_path in test_paths]
Out[3]: [True, False, True, False]

In [4]: [fnmatch(test_path, "*tests*") for test_path in test_paths]
Out[4]: [True, True, True, True]

In [5]: [fnmatch(test_path, "*/tests*") for test_path in test_paths]
Out[5]: [True, True, True, True]

In [6]: [fnmatch(test_path, "/home/project/tests*") for test_path in test_paths]
Out[6]: [True, True, False, False]

In [7]: fnmatch(r"project\tests\test_file.py", "project/tests")
Out[7]: False

In [8]: fnmatch(r"project\tests\test_file.py", "project/tests*")
Out[8]: True

In [9]: fnmatch(r"project\tests", "project/tests")
Out[9]: True

I agree - we already have --ignore-regex  & --whitelist-regex for code-based regexes. Would be good to have two similar flags for paths.
This fall is a bit busy for me - if you (or any lurkers) wish to take this on, I'd be very happy to take a pull request. Otherwise, it may be a little while (a week or two) before I can get to this.

IMHO for the case of file paths, --exclude should be enough.
If people just want to ignore specific files in a folder, they can just use a glob pattern with a higher specificity.
I.e. you want to exclude the tests themselves, but enforce that you fixtures got docstring
project/
    tests/
     sub-package1/
         tests/
             conftest.py
             test_func1.py
             test_func2.py

With the above project structure you would run
interrogate -e "project/sub-package1/tests/test_*" project


proposal: split inject/extract baggage prefix in zipkin/propagation.go

Proposal - what do you suggest to solve the problem or improve the existing situation?
How about split inject and extract baggage prefix instead of common prefix?
For example, suppose we receive x-project-id and x-project-token from another server
and we just want to propagate x-project-id only.
If i set baggage prefix to empty string, then propagate all, "x-" prefix also.
How can i propagate only x-project-id via baggage items without any additional code?

Please try to use more descriptive issue titles in the future (describe problem, not solution), your title seems barely related to the content of the question.
The baggage api has an iterator and the ability to unset the values, so you can implement any kind of custom filtering in your own code, it does not need to be a feature of the jaeger client.

@yurishkuro thx for answer, i'll do that next time :)
How can i unset the values from span or span context? i just found iterator and set items.

set to bank values

set to blank values

I though there is a way to delete baggage
How about adding a baggage filter in zipkin/propagation.go?
Then it is helpful propagate my custom header only not all such as x-request-id, x-account-id and etc. :D

Setting to blank value should delete the entry

thx for ur kindness :) but in my case, it is not working.
Here are my full code,  Is there any misuse in my code?
(in this case, i just want to propagate x-request-id only and delete x-custom
ctx := context.Background()
propagator := zipkin.NewZipkinB3HTTPHeaderPropagator(zipkin.BaggagePrefix(""))
tracer, closer := jaeger.NewTracer("test",
    jaeger.NewConstSampler(false),
    jaeger.NewNullReporter(),
    jaeger.TracerOptions.Injector(opentracing.HTTPHeaders, propagator),
    jaeger.TracerOptions.Extractor(opentracing.HTTPHeaders, propagator),
)
opentracing.SetGlobalTracer(tracer)
defer closer.Close()

// 2) extract span from request
reqHeader := make(http.Header)
reqHeader.Set("x-b3-traceid", "520074fd2207a4e3")
reqHeader.Set("x-b3-spanid", "2983658a41996bad")
reqHeader.Set("x-b3-parentspanid", "7cf2b60cc11b4db3")
reqHeader.Set("x-request-id", "66e45b9f-85d6-4791-913b-71a10cc16a72") // want to propagate only
reqHeader.Set("x-custom", "custom-value")                             // want to delete baggage

wireContext, err := tracer.Extract(opentracing.HTTPHeaders, opentracing.HTTPHeadersCarrier(reqHeader))
assert.NoError(t, err)
span := opentracing.StartSpan("/root", opentracing.ChildOf(wireContext))
span.Context().ForeachBaggageItem(func(k, v string) bool {
    switch strings.ToLower(k) {
    case "x-request-id":
    default:
        span.SetBaggageItem(k, "")
    }
    return true
})
defer span.Finish()
ctx = opentracing.ContextWithSpan(ctx, span)

// 3) start child span
currentSpan := opentracing.SpanFromContext(ctx)
childSpan := opentracing.StartSpan("/child", opentracing.ChildOf(currentSpan.Context()))
childHeader := make(http.Header)
tracer.Inject(childSpan.Context(), opentracing.HTTPHeaders, opentracing.HTTPHeadersCarrier(childHeader))
for k, values := range childHeader {
    fmt.Println("Key:", k, ", Values:", strings.Join(values, ","))
}
// Output
//Key: X-B3-Traceid , Values: 520074fd2207a4e3
//Key: X-B3-Parentspanid , Values: 799790be7bbe8988
//Key: X-B3-Spanid , Values: f1994a95284d02b
//Key: X-B3-Sampled , Values: 0
//Key: X-Request-Id , Values: 66e45b9f-85d6-4791-913b-71a10cc16a72
//Key: X-Custom , Values:

I see that there's no special code to remove keys with empty/nil values as we do in some other Jaeger SDKs. Feel free to add a PR.
https://github.com/jaegertracing/jaeger-client-go/blob/fe3fa553c313b32f58cc684a59a4d48f03e07df9/span_context.go#L325-L338
On a separate note, this looks like a patently bad idea:
propagator := zipkin.NewZipkinB3HTTPHeaderPropagator(zipkin.BaggagePrefix(""))

If you don't use a prefix for baggage, every possible HTTP header will be treated as baggage and propagated.

Added a new pr #562 :)
I know it is a bad idea to configure "" baggage prefix.
So how about adding a BaggageFilter in zipkin.Propagator?
I think it is more flexible if provide a filter like below
type BaggageFilter interface {
	// InjectFilter returns a parsed key to propagate this baggage item and true if inject these key,value.
	InjectFilter(k, v string) (string, bool)
	// ExtractFilter returns a parsed key to set in baggage and true if extract these key,value.
	ExtractFilter(k, v string) (string, bool)
}

type PrefixBaggageFilter struct {
	prefix string
}

func (p *PrefixBaggageFilter) InjectFilter(k, _ string) (string, bool) {
	return p.prefix + k, true
}

func (p *PrefixBaggageFilter) ExtractFilter(k, _ string) (string, bool) {
	if !strings.HasPrefix(k, p.prefix) {
		return k, false
	}
	return k[len(p.prefix):], true
}

type Propagator struct {
	baggageFilter BaggageFilter
}


konqueror and freshplugin

Hi Rinat,
just for info I tried to use freshplaerplugin with Konqueror KDE4 but
apparently no flash is shown, only white page.
thanks

Tested a bit in Konqueror. Flash movies from outer pages fail to load, an error message is displayed. But for some reason test page from <IP_ADDRESS> works fine. I also tried to remove file /usr/lib/kde4/libnsplugin.so and plugins started to work, which surprised me.
And I still don't get how KDE applications tied together, and how to debug them.

weird, on my side I just removed all plugins but the last fresh but
nothing is loaded, no error message, just white page like no flash sits there

Have you tried to temporarily remove /usr/lib/kde4/libnsplugin.so?

as I have a fedora 21 64bits it was at /usr/lib64/kde4/libnsplugin.so
now I can see the flash, but if I right click... booom it crashes konqueror ;)

As you mentioned crashes, I had Konqueror crashing too, until I disabled NPAPI Flash. But then context menu worked fine.
As I found on some Internet page, if you start application with KDE_DEBUG=1 environment variable set, apps then will just crash, without using KDE's crash reporter. It then create core dump file, if ulimit -c unlimited is executed before or some core dump collector service is running. Could you try to get backtrace of the crash then?

yes, here it is
backtrace.txt

Looks like after libnsplugin.so removal, Konqueror leaves plugin management to QtWebKit.

Crashes somewhere inside GTK+ internals, I can say from backtrace. Although it should work fine, since QtWebKit have GLib mainloop support which is required for NPAPI Flash.
If you're still interested in further debugging, next step will be getting debugging symbols for GTK+ libraries. I guess Fedora have them in a separate package?

yes, I just installed it
but never debugged gtk so adivce appreciated

If you still have core file from a previous crash, backtrace in gdb should show you line numbers in gtk functions now. If you don't have it, a new one will work just fine too.

arrgh, no I deleted it :(
will do it again tonight

I'm not familiar with gdb, how can I backtrace what you need in a file?

There are two useful commands:

set logging on enabled logging into a file (named gdb.txt by default);
set pagination off makes gdb print command output at once, without dividing into pages.

Ok please tell me how to run konquror in gdb console

how to run konquror in gdb console

You need to specify program name when you launch gdb: gdb konqueror.
But why do you ask that? Didn't you posted backtrace earlier? It definitely was generated by gdb.

yes but i did manually like
gdb /usr/bin/konqueror coredump
and copy and paste the result
I want to know how to run gdb and automatically print on a file

I want to know how to run gdb and automatically print on a file

Commands set logging on and set pagination off should suffice. I was just confused when you asked about how to start application under gdb. I thought since you've generated backtrace earlier, you already know how to either load coredump into gdb or how to launch application under gdb. Both ways are fine.

well, my question was when and how you run these commands
if I run KDE_DEBUG=1 /usr/bin/konqueror and after
gdb /usr/bin/konqueror coredump?

You first launch KDE_DEBUG=1 /usr/bin/konqueror, reproduce the bug.  In that prompt you enter command set logging on, then set pagination off, then thread apply all bt. Then you can quit gdb by entering command q.
There should appear file gdb.txt in a current directory.

mmhmm it's what I did and made a blank file.
I do it again now

ok here it is
gdb.txt

I don't see line numbers there. Maybe gtk2-debuginfo is not installed, or maybe there are no enough debug information in that package.

there are these packages I did not installed yet
gtk2-devel-docs           x86_64      2.24.28-1.fc21        updates      2.4 M
gtk2-engines-devel        x86_64      2.20.2-9.fc21         fedora        21 k
gtk2-immodule-xim         x86_64      2.24.28-1.fc21        updates       22 k
gtk2-immodules
gtk+-devel            x86_64       1:1.2.10-79.fc21         fedora       302 k
gtk+extra             x86_64       2.1.2-15.fc21            fedora       313 k
gtk+extra-devel
which one must I install?

If there are no packages with "dbg", "debug", or "debuginfo" in their names together with "gtk", then there is no debug information available. The only way to get line information is to compile from source.

there is kdbg I just installed it

kdbg is a GUI frontend for gdb. That's not what I talked about.
I use Debian, and here we have libgtk2.0-0 package, which contains GTK+ libraries, and libgtk2.0-0-dbg package, which contains debug information. But not all packages are using that scheme. Some do not have debug information at all. But if they have, package name ends with "-dbg".
Unfortunately, I'm not familiar with Fedora, so I don't know is there debug info for GTK+ libraries or not. Perhaps there is some similar naming convention, perhaps not. Not sure.

is it better like this?
I used break gtk_init in gdb
gdb.txt

No it won't work that way either. Look into output. There are multiple thread's backtraces. Each have a number of entries, a history about how functions called another functions to get to the current point. There are: frame number (#0, #1, #2 and so on), address of an instruction, then name of the function and its origin.
Sometimes name of function is not available, and there is nothing (most functions in libpepflashplayer.so). Sometimes, name is known, but there is no debug information:
in g_async_queue_pop_intern_unlocked () at /usr/lib64/libglib-2.0.so.0

You see library name here. But if debug information is available, you'll see:
in ppb_flash_message_loop_run (flash_message_loop=3162) at /home/src/freshplayerplugin/src/ppb_flash_message_loop.c:81

Note there is a source file name, and a line number where call was made.
As for crash in GTK+, you see there:
#0  0x000000378ae7ac07 in gdk_window_enable_synchronized_configure () at /usr/lib64/libgdk-x11-2.0.so.0

From that one can say something went wrong in gdk_window_enable_synchronized_configure(), but where exactly, is unknown. (By the way, crashing inside GTK+ doesn't mean it's a GTK+ bug. Many functions expect sane input values, and if they are wrong, there will be a crash).

ok gotcha... so should I remove gtk2 package and install the source with -g option?

Ok I found the beast
debuginfo-install konqueror-15.04.3-1.fc21.1.x86_64
515MB, ouch...

Here is a part of last gdb.txt:
Thread 1 (Thread 0x7fc555e7f880 (LWP 4095)):
#0  0x000000378ae7ac07 in gdk_window_enable_synchronized_configure () at /usr/lib64/libgdk-x11-2.0.so.0
#1  0x000000378b48b1f7 in gtk_window_realize () at /usr/lib64/libgtk-x11-2.0.so.0
#2  0x0000003f7980fe84 in _g_closure_invoke_va (closure=closure@entry=0x2486230, return_value=return_value@entry=0x0, instance=instance@entry=0x255d060, args=args@entry=0x7ffd9ce10e20, n_params=<optimized out>, param_types=0x0) at gclosure.c:831
#3  0x0000003f79829b00 in g_signal_emit_valist (instance=0x255d060, signal_id=<optimized out>, detail=0, var_args=var_args@entry=0x7ffd9ce10e20) at gsignal.c:3218
#4  0x0000003f7982a34f in g_signal_emit (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>) at gsignal.c:3365
#5  0x000000378b47e089 in gtk_widget_realize () at /usr/lib64/libgtk-x11-2.0.so.0
#6  0x000000378b47e1a9 in gtk_widget_realize () at /usr/lib64/libgtk-x11-2.0.so.0
#7  0x000000378b352787 in gtk_menu_popup () at /usr/lib64/libgtk-x11-2.0.so.0
#8  0x00007fc4f7ba295c in menu_popup_ptac (p=0x255b0b0) at /home/src/freshplayerplugin/src/ppb_flash_menu.c:226
#9  0x00007fc4f7b9c90a in call_on_browser_thread_comt (user_data=0x23aec30, result=<optimized out>) at /home/src/freshplayerplugin/src/ppb_core.c:108
#10 0x00007fc4f7ba6a93 in ppb_message_loop_run_int (message_loop=<optimized out>, flags=<optimized out>) at /home/src/freshplayerplugin/src/ppb_message_loop.c:323
#11 0x000000311292b21b in WebCore::PluginMainThreadScheduler::dispatchCallsForPlugin(_NPP*, WTF::Deque<WebCore::PluginMainThreadScheduler::Call, 0ul> const&) () at /usr/lib64/libQtWebKit.so.4
#12 0x000000311292c5ac in WebCore::PluginMainThreadScheduler::dispatchCalls() () at /usr/lib64/libQtWebKit.so.4
#13 0x000000311386cd1f in WTF::dispatchFunctionsFromMainThread() () at /usr/lib64/libQtWebKit.so.4
#14 0x0000003113876b81 in WTF::MainThreadInvoker::event(QEvent*) () at /usr/lib64/libQtWebKit.so.4
#15 0x0000003f837c7efc in QApplicationPrivate::notify_helper(QObject*, QEvent*) (this=this@entry=0x1944f50, receiver=receiver@entry=0x1cc4580, e=e@entry=0x7fc4d822b060) at kernel/qapplication.cpp:4565
#16 0x0000003f837ce958 in QApplication::notify(QObject*, QEvent*) (this=this@entry=0x7ffd9ce118f0, receiver=receiver@entry=0x1cc4580, e=e@entry=0x7fc4d822b060) at kernel/qapplication.cpp:4351
#17 0x000000310c64ee0a in KApplication::notify(QObject*, QEvent*) (this=0x7ffd9ce118f0, receiver=0x1cc4580, event=0x7fc4d822b060) at /usr/src/debug/kdelibs-4.14.12/kdeui/kernel/kapplication.cpp:311
#18 0x0000003f8118622d in QCoreApplication::notifyInternal(QObject*, QEvent*) (this=0x7ffd9ce118f0, receiver=receiver@entry=0x1cc4580, event=event@entry=0x7fc4d822b060) at kernel/qcoreapplication.cpp:953
#19 0x0000003f811894f1 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) (event=0x7fc4d822b060, receiver=0x1cc4580) at kernel/qcoreapplication.h:231
#20 0x0000003f811894f1 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) (receiver=receiver@entry=0x0, event_type=event_type@entry=0, data=0x1909f20) at kernel/qcoreapplication.cpp:1577
#21 0x0000003f81189983 in QCoreApplication::sendPostedEvents(QObject*, int) (receiver=receiver@entry=0x0, event_type=event_type@entry=0) at kernel/qcoreapplication.cpp:1470
#22 0x0000003f811b53ee in postEventSourceDispatch(GSource*, GSourceFunc, gpointer) () at kernel/qcoreapplication.h:236
#23 0x0000003f811b53ee in postEventSourceDispatch(GSource*, GSourceFunc, gpointer) (s=0x192bf30) at kernel/qeventdispatcher_glib.cpp:300
#24 0x0000003f778497fb in g_main_context_dispatch (context=0x1946090) at gmain.c:3111
#25 0x0000003f778497fb in g_main_context_dispatch (context=context@entry=0x1946090) at gmain.c:3710
#26 0x0000003f77849b98 in g_main_context_iterate (context=context@entry=0x1946090, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3781
#27 0x0000003f77849c4c in g_main_context_iteration (context=0x1946090, may_block=1) at gmain.c:3842
#28 0x0000003f811b555e in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) (this=0x190b8a0, flags=...) at kernel/qeventdispatcher_glib.cpp:450
#29 0x0000003f8386b176 in QGuiEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) (this=<optimized out>, flags=...) at kernel/qguieventdispatcher_glib.cpp:207
#30 0x0000003f81184d81 in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) (this=this@entry=0x7ffd9ce11720, flags=...) at kernel/qeventloop.cpp:149
#31 0x0000003f811850e5 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) (this=this@entry=0x7ffd9ce11720, flags=...) at kernel/qeventloop.cpp:204
#32 0x0000003f8118a7c9 in QCoreApplication::exec() () at kernel/qcoreapplication.cpp:1225
#33 0x0000003f837c639c in QApplication::exec() () at kernel/qapplication.cpp:3823
#34 0x000000310f6ba936 in kdemain(int, char**) (argc=<optimized out>, argv=<optimized out>) at /usr/src/debug/kde-baseapps-15.04.3/konqueror/src/konqmain.cpp:227
#35 0x0000003f7501ffe0 in __libc_start_main (main=0x400870 <main(int, char**)>, argc=1, argv=0x7ffd9ce11a98, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffd9ce11a88) at libc-start.c:289
#36 0x000000000040089e in _start ()

As you can see, Konqueror part now have line information, but relevant part, gdk_window_enable_synchronized_configure() still haven't. Crash was somewhere inside that function, but it's unknown where exactly it was.

ok could you know where this function come from?
maybe I should install another debugger

It's from GDK, which is a part of GTK+ libraries.
What you need to do is to get GTK+2 source code, unpack it, run ./configure --prefix=/tmp/5, then compile with make and install with make install. You can do all these steps from an ordinary user, no root required. Resulted libraries are installed into /tmp/5/lib.
Then you need to launch application with KDE_DEBUG=1 LD_LIBRARY_PATH=/tmp/5/lib konqueror.
LD_LIBRARY_PATH variable can be used to give library loader a hint where to search for libraries. Since /tmp/5/lib will have newly compiled GTK+ libraries, those will be loaded instead of system ones.

more simple I did debuginfo-install gtk2
and got gtk2-debuginfo in the list :)

here it is I think it's ok now
gdb.txt

I guess gdk_window_new() called in gtkwindow.c:4843 returns NULL, which is then passed gdk_window_enable_synchronized_configure() where that NULL is dereferenced. Next step is to determine why gdk_window_new() returns NULL.

well, you're probably right ;)
the weird thing I know is konqueror asks to activate the plugin with a start button
so maybe something is missing in their process when right click is activated
or maybe I'm out of subject too

Since GTK+ menu is a window, it needs a parent. Probably code fails to find a parent, and subsequently fails to create a window. There is a code that uses browser window as a parent, and I was thinking that due to missing NPAPI entry it failed to acquire window handle. But it turned out, menu code doesn't use it at all. I just call gtk_menu_popup() with all NULL parameters, and it does its magic.
Don't know, maybe that was wrong. But why it's working in other browsers then? I once tested something QtWebKit-based, and it worked there too.

mmhmm weird. but wait, it could come from the fact I'm using Fedora from my server through vnc?
or maybe because my server does not have any sound and webcam?

ok right click works well with firefox and seamonkey in the same conditions

I've installed 64-bit Fedora 21 into virtual machine and tried Konqueror there. At first it failed to open plugin, but after I deleted libnsplugin.so and installed kwebkitpart, worked fine. Context menus are also working fine, no crashes. So, I can't reproduce the same bug.

Hi
Testing Konqueror 4.14.3 here (KDE 4.41.5) under up-to-date Mageia 5, went to https://www.adobe.com/fr/software/flash/about/ (but any site with flash makes it crash) and got the following crash (see below).
Application: nspluginviewer (nspluginviewer), signal: Segmentation fault
Using host libthread_db library "/lib64/libthread_db.so.1".
[Current thread is 1 (Thread 0x7fec8c636780 (LWP 27144))]
Thread 8 (Thread 0x7fec6c8d9700 (LWP 27147)):
[KCrash Handler]
#5  0x0000000000000000 in ?? ()
#6  0x00007fec7946fcfc in ppb_core_call_on_browser_thread (instance=, func=0x7fec79482430 <set_text_input_type_ptac>, user_data=0x15b7b60) at /home/fred/compil/freshplayerplugin/src/ppb_core.c:154
#7  0x00007fec6975e451 in ?? () from /home/fred/compil/freshplayerplugin/build/libpepflashplayer.so
#8  0x00007fec6973bc58 in ?? () from /home/fred/compil/freshplayerplugin/build/libpepflashplayer.so
#9  0x00007fec69726f8d in ?? () from /home/fred/compil/freshplayerplugin/build/libpepflashplayer.so
#10 0x00007fec6a1a1151 in ?? () from /home/fred/compil/freshplayerplugin/build/libpepflashplayer.so
#11 0x00007fec79463dab in call_plugin_did_create_comt (user_data=0x15b7790, result=) at /home/fred/compil/freshplayerplugin/src/np_functions.c:171
#12 0x00007fec79479dc3 in ppb_message_loop_run_int (message_loop=message_loop@entry=2, flags=flags@entry=2) at /home/fred/compil/freshplayerplugin/src/ppb_message_loop.c:323
#13 0x00007fec79479e9a in ppb_message_loop_run (message_loop=message_loop@entry=2) at /home/fred/compil/freshplayerplugin/src/ppb_message_loop.c:200
#14 0x00007fec79466e87 in fresh_wrapper_main_thread (p=0x1478430) at /home/fred/compil/freshplayerplugin/src/main_thread.c:58
#15 0x00007fec87cc05bd in start_thread () from /lib64/libpthread.so.0
#16 0x00007fec88d645cd in clone () from /lib64/libc.so.6
Thread 7 (Thread 0x7fec63fff700 (LWP 27148)):
#0  0x00007fec88d58d1d in poll () from /lib64/libc.so.6
#1  0x00007fec8b530eb4 in g_main_context_iterate.isra () from /lib64/libglib-2.0.so.0
#2  0x00007fec8b531232 in g_main_loop_run () from /lib64/libglib-2.0.so.0
#3  0x00007fec78eb49b6 in gdbus_shared_thread_func () from /lib64/libgio-2.0.so.0
#4  0x00007fec8b556d75 in g_thread_proxy () from /lib64/libglib-2.0.so.0
#5  0x00007fec87cc05bd in start_thread () from /lib64/libpthread.so.0
#6  0x00007fec88d645cd in clone () from /lib64/libc.so.6
Thread 6 (Thread 0x7fec5bfff700 (LWP 27149)):
#0  0x00007fec88d5ecd9 in syscall () from /lib64/libc.so.6
#1  0x00007fec8b57420f in g_cond_wait_until () from /lib64/libglib-2.0.so.0
#2  0x00007fec8b506999 in g_async_queue_pop_intern_unlocked () from /lib64/libglib-2.0.so.0
#3  0x00007fec8b506f8b in g_async_queue_timeout_pop () from /lib64/libglib-2.0.so.0
#4  0x00007fec8b5577bc in g_thread_pool_thread_proxy () from /lib64/libglib-2.0.so.0
#5  0x00007fec8b556d75 in g_thread_proxy () from /lib64/libglib-2.0.so.0
#6  0x00007fec87cc05bd in start_thread () from /lib64/libpthread.so.0
#7  0x00007fec88d645cd in clone () from /lib64/libc.so.6
Thread 5 (Thread 0x7fec53fff700 (LWP 27153)):
#0  0x00007fec8b573fe4 in g_mutex_unlock () from /lib64/libglib-2.0.so.0
#1  0x00007fec8b530dd6 in g_main_context_iterate.isra () from /lib64/libglib-2.0.so.0
#2  0x00007fec8b530fbc in g_main_context_iteration () from /lib64/libglib-2.0.so.0
#3  0x00007fec8b530ff9 in glib_worker_main () from /lib64/libglib-2.0.so.0
#4  0x00007fec8b556d75 in g_thread_proxy () from /lib64/libglib-2.0.so.0
#5  0x00007fec87cc05bd in start_thread () from /lib64/libpthread.so.0
#6  0x00007fec88d645cd in clone () from /lib64/libc.so.6
Thread 4 (Thread 0x7fec681dc700 (LWP 27154)):
#0  0x00007fec87cc567f in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1  0x00007fec6973cfbb in ?? () from /home/fred/compil/freshplayerplugin/build/libpepflashplayer.so
#2  0x00007fec6973d2a5 in ?? () from /home/fred/compil/freshplayerplugin/build/libpepflashplayer.so
#3  0x00007fec6999cddc in ?? () from /home/fred/compil/freshplayerplugin/build/libpepflashplayer.so
#4  0x00007fec6973cbbc in ?? () from /home/fred/compil/freshplayerplugin/build/libpepflashplayer.so
#5  0x00007fec6973cc28 in ?? () from /home/fred/compil/freshplayerplugin/build/libpepflashplayer.so
#6  0x00007fec6973ce21 in ?? () from /home/fred/compil/freshplayerplugin/build/libpepflashplayer.so
#7  0x00007fec87cc05bd in start_thread () from /lib64/libpthread.so.0
#8  0x00007fec88d645cd in clone () from /lib64/libc.so.6
Thread 3 (Thread 0x7fec6819b700 (LWP 27155)):
#0  0x00007fec87cc567f in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1  0x00007fec6973cfbb in ?? () from /home/fred/compil/freshplayerplugin/build/libpepflashplayer.so
#2  0x00007fec6973d2a5 in ?? () from /home/fred/compil/freshplayerplugin/build/libpepflashplayer.so
#3  0x00007fec6999cddc in ?? () from /home/fred/compil/freshplayerplugin/build/libpepflashplayer.so
#4  0x00007fec6973cbbc in ?? () from /home/fred/compil/freshplayerplugin/build/libpepflashplayer.so
#5  0x00007fec6973cc28 in ?? () from /home/fred/compil/freshplayerplugin/build/libpepflashplayer.so
#6  0x00007fec6973ce21 in ?? () from /home/fred/compil/freshplayerplugin/build/libpepflashplayer.so
#7  0x00007fec87cc05bd in start_thread () from /lib64/libpthread.so.0
#8  0x00007fec88d645cd in clone () from /lib64/libc.so.6
Thread 2 (Thread 0x7fec47ffe700 (LWP 27156)):
#0  0x00007fec88d58d1d in poll () from /lib64/libc.so.6
#1  0x00007fec765f5c81 in poll_func () from /lib64/libpulse.so.0
#2  0x00007fec765e7891 in pa_mainloop_poll () from /lib64/libpulse.so.0
#3  0x00007fec765e7ece in pa_mainloop_iterate () from /lib64/libpulse.so.0
#4  0x00007fec765e7f80 in pa_mainloop_run () from /lib64/libpulse.so.0
#5  0x00007fec765f5c33 in thread () from /lib64/libpulse.so.0
#6  0x00007fec71f57198 in internal_thread_func () from /usr/lib64/pulseaudio/libpulsecommon-5.0.so
#7  0x00007fec87cc05bd in start_thread () from /lib64/libpthread.so.0
#8  0x00007fec88d645cd in clone () from /lib64/libc.so.6
Thread 1 (Thread 0x7fec8c636780 (LWP 27144)):
#0  0x00007fec88d5ecd9 in syscall () from /lib64/libc.so.6
#1  0x00007fec8b57420f in g_cond_wait_until () from /lib64/libglib-2.0.so.0
#2  0x00007fec8b506999 in g_async_queue_pop_intern_unlocked () from /lib64/libglib-2.0.so.0
#3  0x00007fec8b506f8b in g_async_queue_timeout_pop () from /lib64/libglib-2.0.so.0
#4  0x00007fec79479c1a in ppb_message_loop_run_int (message_loop=, flags=flags@entry=3) at /home/fred/compil/freshplayerplugin/src/ppb_message_loop.c:341
#5  0x00007fec79479eaa in ppb_message_loop_run_nested (message_loop=) at /home/fred/compil/freshplayerplugin/src/ppb_message_loop.c:206
#6  0x00007fec79465253 in NPP_New (pluginType=, npp=, mode=, argc=, argn=, argv=, saved=0x0) at /home/fred/compil/freshplayerplugin/src/np_functions.c:574
#7  0x000000000040b760 in NSPluginInstance::NSPluginInstance(_NPPluginFuncs*, KLibrary*, QString const&, QString const&, QStringList const&, QStringList const&, QString const&, QString const&, bool, QObject*) ()
#8  0x0000000000413a78 in NSPluginClass::newInstance(QString const&, QString const&, bool, QStringList const&, QStringList const&, QString const&, QString const&, bool) ()
#9  0x000000000041f552 in ClassAdaptor::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) ()
#10 0x000000000041f6d3 in ClassAdaptor::qt_metacall(QMetaObject::Call, int, void**) ()
#11 0x00007fec8ba1cb06 in QDBusConnectionPrivate::deliverCall(QObject*, int, QDBusMessage const&, QList const&, int) () from /lib64/libQtDBus.so.4
#12 0x00007fec8ba1dc49 in QDBusConnectionPrivate::activateCall(QObject*, int, QDBusMessage const&) () from /lib64/libQtDBus.so.4
#13 0x00007fec8ba1e698 in QDBusConnectionPrivate::activateObject(QDBusConnectionPrivate::ObjectTreeNode&, QDBusMessage const&, int) () from /lib64/libQtDBus.so.4
#14 0x00007fec8ba1e81b in QDBusActivateObjectEvent::placeMetaCall(QObject*) () from /lib64/libQtDBus.so.4
#15 0x00007fec894bfd61 in QObject::event(QEvent*) () from /lib64/libQtCore.so.4
#16 0x00007fec89eb279c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /lib64/libQtGui.so.4
#17 0x00007fec89eb8e40 in QApplication::notify(QObject*, QEvent*) () from /lib64/libQtGui.so.4
#18 0x00007fec8abe525a in KApplication::notify(QObject*, QEvent*) () from /lib64/libkdeui.so.5
#19 0x00007fec894a7cad in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /lib64/libQtCore.so.4
#20 0x00007fec894aabe1 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /lib64/libQtCore.so.4
#21 0x00007fec894d4cae in postEventSourceDispatch(_GSource*, int ()(void), void*) () from /lib64/libQtCore.so.4
#22 0x00007fec8b530c6d in g_main_context_dispatch () from /lib64/libglib-2.0.so.0
#23 0x00007fec8b530f18 in g_main_context_iterate.isra () from /lib64/libglib-2.0.so.0
#24 0x00007fec8b530fbc in g_main_context_iteration () from /lib64/libglib-2.0.so.0
#25 0x00007fec894d4e1e in QEventDispatcherGlib::processEvents(QFlagsQEventLoop::ProcessEventsFlag) () from /lib64/libQtCore.so.4
#26 0x00007fec89f504f6 in QGuiEventDispatcherGlib::processEvents(QFlagsQEventLoop::ProcessEventsFlag) () from /lib64/libQtGui.so.4
#27 0x00007fec894a6931 in QEventLoop::processEvents(QFlagsQEventLoop::ProcessEventsFlag) () from /lib64/libQtCore.so.4
#28 0x00007fec894a6c45 in QEventLoop::exec(QFlagsQEventLoop::ProcessEventsFlag) () from /lib64/libQtCore.so.4
#29 0x00007fec894abe59 in QCoreApplication::exec() () from /lib64/libQtCore.so.4
#30 0x0000000000408d42 in main ()

I'm curious how konqueror manage flash plugin. sounds weird

did you try to make a right click?

@jccardot, from backtrace I can guess ppb_core_call_on_browser_thread() function called something at address NULL which caused crashing. The only function called by pointer that could be NULL is npn.pluginthreadasynccall. That function is provided by a browser. It can be NULL if browser part doesn't support that API yet.
Source for nspluginviewer used in Debian have NPAPI version 0.14, while required asynchronous thread calls and NPObject-related function were added only in 0.19 and 0.18 respectively. I'd say nspluginviewer code is very old (despite the fact it's in the kde-baseapps-15.08.2). Hence error message about NPNVPluginElementNPObject and subsequent crash.
There is no way PepperFlash could be made compatible. It extensively uses threading and interacts with a browser via Javascript.
That's why I proposed to delete /usr/lib/kde4/libnsplugin.so (or maybe /usr/lib64/kde4/libnsplugin.so). If you have kwebkitpart installed, Konqueror will switch to QtWebKit-based engine, which have required NPAPI support.

But on the other hand, there is a fallback code for older versions. Freshwrapper should not crash, but rather display a placeholder message in that case. Quick test with zeroing npn.pluginthreadasynccall and setting npn.version to 14 confirm that.
Which version of freshplayerplugin are you using? I also definitely fixed that [fresh] [warning] ppb_var_var_to_utf8, 'var' is not a string, (0) warning a while ago.

Very good news, the last freshplugin from git installed on konqueror with nsplugin removed worked like a charm now. right click does not crash anymore. great job!.
I checked freshplugin on seamonkey and firefox, both worked well too.
I will soon go deeper in functions....

I've changed rendering code, it now tests whenever XRender is available and uses software rendering as a fall back. Before that XRender was always used, so if you saw plugin content, XRender was working on your machine. And in turn new code shouldn't behave differently.
Could you ensure those changes are actually fixing the issue?

Yes I confirm it. everything is much more stable. no crash anymore when I right click in konqueror.
but is it necessary to remove nsplugin from konqueror if a user needs to use freshplugin with it?

Yes I confirm it.

I was talking about checking current version from master and then walking back in history in order to find a fixing change. (One could move back by git checkout HEAD^. To return to the master branch: git checkout master).

but is it necessary to remove nsplugin from konqueror if a user needs to use freshplugin with it?

Yes, since nsplugin wasn't updated to meet changed NPAPI. By the way, Flash 11.2 doesn't work with nsplugin too,

I'm not sure what you are talking about.
I cloned already the master only
git checkout HEAD
M       3rdparty/parson/Makefile
Your branch is up-to-date with 'origin/master
I installed it today

git checkout HEAD

Not git checkout HEAD, but git checkout HEAD^. Notice that ^, it's crucial. HEAD is a special name for current commit, regardless where it is. HEAD^ is a name for a commit before current. HEAD^^ is a name for commit before HEAD^ and so on.

I'm not sure what you are talking about.

There could be other changes, not only changes in freshwrapper. And latter could be unrelated to the issue at all. It's similar to rainmaking dance ritual. If one dances long enough, rain happens, but it's not caused by the ritual, it just happened after.
That's why it's worth to ensure that it's the recent changes in freshwrapper which fixed the issue.
However, it's just a matter of personal taste, of course.

ok my eyes where to tired yesterday.
HEAD is now at d69440d... np_functions: store clipRect geometry

HEAD is now at d69440d... np_functions: store clipRect geometry

You are now at the point in time where no changes of rendering paths were made yet (previous changes were preparations only). Try to compile freshplayerplugin and test Flash in Konqueror again.

recompiled d69440d gives no flash shown in Konqueror.
about:plugins shows
Shockwave flash 19.0 r0 libfreshwrapper-flashplayer.so
:(

Ok, looks like recent changes had an effect indeed.

mmmhm, now I put the last git and the result is the same :(
I just noticed that there was libfreshwrapper-pepperflash.so and libfreshwrapper-flashplayer.so in same time in plugin folder when it was working. but since I removed libfreshwrapper-pepperflash.so no flash is shown on pages

There was a patch that changed name to libfreshwrapper-flashplayer.so. Twitch.tv tested plugin name, and had unwanted behavior if there were "pepperflash" substring.

I think you had two versions of freshwrapper at the same time.

yes it's possible. but when I said it was working and you asked me to downgrade the git version
I check the konqueror plugin configuration and libfreshwrapper-pepperflash was still marked...
I'm confused.

There was a patch that changed name t
yes I noticed it days ago. I just forgot to remove the old freshpepper before to test the new.
anyhow fortunately I have another server with the exact copy and the 2 plugins were still there.
so I tested with the 2 first and konqueror crashed. I removed freshpepper and installed the last git version freshwrapper-flashplayer, launch konqueror and everything is running flawlessly...
so I guess my other server need a reboot to cleanup things in konqueror I guess

Rinat, I just checked something very unusual.
I went on a web page from swfobject to test the flash player version with konqueror to see if anything is ok with freshplugin and stupor, it shows flash player version 11.2.2xx !! Knowing that I remove any official flash player from my hard drive so there is absolutely no trace of flashplayer 11.2 it's quiet unusual to get this result.
attached a screenshot
the link to test your swf version
http://www.bobbyvandersluis.com/swfobject/testsuite_2_2/test.html

@madovsky,
this string, with LNX and numbers divided by commas, is generated by Flash itself, so you definitely have libflashplayer.so somewhere.
I think grep flash /proc/$(pidof konqueror)/maps can help to locate which plugin is loaded into konqueror process.

I confirm that absolutely no trace of libflashplayer.so is on my system.
here is all things there are in the proc folder. no trace of flash
attr             cwd      loginuid    ns             root       statm
autogroup        environ  map_files   numa_maps      sched      status
auxv             exe      maps        oom_adj        schedstat  syscall
cgroup           fd       mem         oom_score      sessionid  task
clear_refs       fdinfo   mountinfo   oom_score_adj  setgroups  timers
cmdline          gid_map  mounts      pagemap        smaps      uid_map
comm             latency  mountstats  personality    stack      wchan
coredump_filter  limits   net         projid_map     stat

ok sorry I was not on a page with flash object
here it is
[root@node228 ~]# grep flash /proc/64648/maps
7feebc145000-7feebd119000 r-xp 00000000 08:03 3146887                    /opt/google/chrome/PepperFlash/libpepflashplayer.so
7feebd119000-7feebd319000 ---p 00fd4000 08:03 3146887                    /opt/google/chrome/PepperFlash/libpepflashplayer.so
7feebd319000-7feebd3db000 r--p 00fd4000 08:03 3146887                    /opt/google/chrome/PepperFlash/libpepflashplayer.so
7feebd3db000-7feebd40f000 rw-p 01096000 08:03 3146887                    /opt/google/chrome/PepperFlash/libpepflashplayer.so
7fef2745c000-7fef274c0000 r-xp 00000000 08:03 918764                     /usr/lib64/mozilla/plugins/libfreshwrapper-flashplayer.so
7fef274c0000-7fef276bf000 ---p 00064000 08:03 918764                     /usr/lib64/mozilla/plugins/libfreshwrapper-flashplayer.so
7fef276bf000-7fef276c2000 r--p 00063000 08:03 918764                     /usr/lib64/mozilla/plugins/libfreshwrapper-flashplayer.so
7fef276c2000-7fef276c4000 rw-p 00066000 08:03 918764                     /usr/lib64/mozilla/plugins/libfreshwrapper-flashplayer.so

ok that's very odd, now it works
[root@node228 ~]# grep flash /proc/64648/maps
7feebc145000-7feebd119000 r-xp 00000000 08:03 3146887                    /opt/google/chrome/PepperFlash/libpepflashplayer.so
7feebd119000-7feebd319000 ---p 00fd4000 08:03 3146887                    /opt/google/chrome/PepperFlash/libpepflashplayer.so
7feebd319000-7feebd3db000 r--p 00fd4000 08:03 3146887                    /opt/google/chrome/PepperFlash/libpepflashplayer.so
7feebd3db000-7feebd40f000 rw-p 01096000 08:03 3146887                    /opt/google/chrome/PepperFlash/libpepflashplayer.so
7fef2745c000-7fef274c0000 r-xp 00000000 08:03 918764                     /usr/lib64/mozilla/plugins/libfreshwrapper-flashplayer.so
7fef274c0000-7fef276bf000 ---p 00064000 08:03 918764                     /usr/lib64/mozilla/plugins/libfreshwrapper-flashplayer.so
7fef276bf000-7fef276c2000 r--p 00063000 08:03 918764                     /usr/lib64/mozilla/plugins/libfreshwrapper-flashplayer.so
7fef276c2000-7fef276c4000 rw-p 00066000 08:03 918764                     /usr/lib64/mozilla/plugins/libfreshwrapper-flashplayer.so

ok that's very odd, now it works

Linux keeps loaded libraries mapped even if you delete them. So it's possible for some process to have libflashplayer.so (NPAPI Flash) still loaded even if you uninstall it. As far as I know, KDE keeps its services running even if user closed all KDE apps. So older Flash could been cached somewhere.

yes, its' what I guessed. anyhow the thing I don't lie on konqueror is everytime you must click on a button "start plugin" on the page...
there is another thing I think konqueror crashes abviously (but must it crash?)
if there is no sound card and you play a movie.

@madovsky, I don't think I get what you're saying.

if there is no sound card and you play a movie.

There is a special sound backend which provides synchronization events if no real sound sink available. Freshwrapper shouldn't crash in that case.

ok, so it must come from konqueror since it does not crash with firefox and chrome

Recent versions of freshwrapper call gdb to get a self-backtrace in case of a crashing. There should be text files in /tmp, with names starting with freshwrapper-backtrace. Perhaps there is still a bug in freshwrapper. But it also possible that freshwrapper tries to access parts of NPAPI that Konqueror not implement. In latter case nothing really could be done, as almost all used parts of NPAPI are required.

right, I attached all of these
freshwrapper-backtrace-1450708329-653.txt
freshwrapper-backtrace-1450652829-32194.txt
freshwrapper-backtrace-1450652844-32238.txt
freshwrapper-backtrace-1450653260-23703.txt

freshwrapper-backtrace-1450708329-653.txt

Crash was caused by X IO error. Those are unrecoverable errors of X11 protocol, which unconditionally lead to program termination. Something happened before, caused it. Hard to tell.

freshwrapper-backtrace-1450652829-32194.txt

Most probably this one was caused by missing NPN_PluginThreadAsyncCall method of NPAPI. From having nspluginviewer string in report, I can guess in that case libnsplugin.so was in use. It have no knowledge of plugins using additional threads. That's impossible to support.

freshwrapper-backtrace-1450652844-32238.txt

Same as in freshwrapper-backtrace-1450652829-32194.txt

freshwrapper-backtrace-1450653260-23703.txt

Crashing somewhere inside KDE libraries. Looks like KParts::BrowserExtension::setPageSecurity had  broken pointer dereference? Can't tell.

Well. Couple of those crashed cannot be fixed. Flash has changed its working compared to times of libnsplugin.so.  Other two are either unrelated to freshwrapper, or were caused by memory corruption (could be caused by any part, including freshwrapper). In latter case, backtraces are not informative, unfortunately.

ok I installed fedora 23 workstation with Gnome desktop on my laptop and usb stick 24Gb and after
satisfied all dependencies freshplugin works very well on seamonkey, firefox and even epiphany.
excellent job Rinat and I wish to you plenty of joy and success for 2016

wish to you plenty of joy and success for 2016

Thanks a lot!

as it works now on konqueror like other browsers I close the issue


Logged In User's Name

Does the username state in sparkpage.tsx get updated accordingly when the user signs in/out? If there is no user signed in, what is the value of username (empty string, null, etc.)?


Reduce size of gadget container image

The default gadget container image is currently 763 MB in size. Since this image must be downloaded by every k8s node against which gadgets are used, making the image smaller would improve deployment time. Furthermore, if the gadget pods are long running, there is value in reducing the attack surface of the image.
IMAGE          CREATED          CREATED BY                                      SIZE      COMMENT
10f080f79008   9 minutes ago    RUN /bin/sh -c rm -f /var/run # buildkit        0B        buildkit.dockerfile.v0
<missing>      9 minutes ago    COPY /tmp/btfs /btfs/ # buildkit                0B        buildkit.dockerfile.v0
<missing>      9 minutes ago    COPY gadget-container/hooks/nri/conf.json /o…   202B      buildkit.dockerfile.v0
<missing>      9 minutes ago    COPY /gadget/gadget-container/bin/nrigadget …   12MB      buildkit.dockerfile.v0
<missing>      9 minutes ago    COPY gadget-container/hooks/crio/gadget-pres…   508B      buildkit.dockerfile.v0
<missing>      9 minutes ago    COPY /gadget/gadget-container/bin/ocihookgad…   14.9MB    buildkit.dockerfile.v0
<missing>      9 minutes ago    COPY gadget-container/hooks/oci/prestart.sh …   324B      buildkit.dockerfile.v0
<missing>      9 minutes ago    COPY /bin/traceloop /bin/ # buildkit            42.8MB    buildkit.dockerfile.v0
<missing>      9 minutes ago    COPY /gadget/gadget-container/bin/gadgettrac…   78.3MB    buildkit.dockerfile.v0
<missing>      13 minutes ago   COPY gadget-container/entrypoint.sh gadget-c…   9.65kB    buildkit.dockerfile.v0
<missing>      13 minutes ago   RUN /bin/sh -c set -ex;  export DEBIAN_FRONT…   70.9MB    buildkit.dockerfile.v0
<missing>      9 days ago       RUN /bin/sh -c apt-get update -y &&   DEBIAN…   454MB     buildkit.dockerfile.v0
<missing>      9 days ago       COPY /root/bcc/*.deb /root/bcc/ # buildkit      17MB      buildkit.dockerfile.v0
<missing>      2 weeks ago      /bin/sh -c #(nop)  CMD ["bash"]                 0B
<missing>      2 weeks ago      /bin/sh -c #(nop) ADD file:ff6963f777661fb16…   72.8MB

Looking at the layers of the image, the main contributor to its size is the fact that we use Debian as a base image. I'm wondering if a SCRATCH image is out of the question. In case an interactive shell is needed for troubleshooting, there are more compact distros which could be considered.
Looks like we're using bcc as the main image, which in turn uses Debian. Do we really need BCC in Inspektor Gadget? What benefit does the BCC project add? Couldn't we compile the BPF programs provided by BCC ourselves using clang and load them using cilium/ebpf? If we could, I think we could switch to a more compact image.

We provide two versions of the container image:
https://github.com/kinvolk/inspektor-gadget/pkgs/container/inspektor-gadget

latest: contains both gadgets based on bcc and gadgets implemented with cilium/ebpf (better compatibility with older kernels)
latest-core: smaller image without bcc.

Right, now I understand why two images are necessary. I guess we can close this then.


Issue #2804 Updated .readthedocs.yml to .readthedocs.yaml

Description
Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change.
Fixes #2804
Type of change
Please add a line in the relevant section of CHANGELOG.md to document the change (include PR #) - note reverse order of PR #s. If necessary, also add to the list of breaking changes.

[ ] New feature (non-breaking change which adds functionality)
[ ] Optimization (back-end change that speeds up the code)
[x] Bug fix (non-breaking change which fixes an issue)

Key checklist:

[x] No style issues: $ pre-commit run (see CONTRIBUTING.md for how to set this up to run automatically when committing locally, in just two lines of code)
[x] All tests pass: $ python run-tests.py --all
[x] The documentation builds: $ python run-tests.py --doctest

You can run unit and doctests together at once, using $ python run-tests.py --quick.
Further checks:

[x] Code is commented, particularly in hard-to-understand areas
[x] Tests added that prove fix is effective or that feature works

@Saransh-cpp I have cherry-picked the changes from develop branch to another branch, now about reset the branch - do I need to open another PR for that or is there some way I can reset the branch in the same PR?

You might have to create a new PR and close this one. I don't think there is any option to reset the branch.

Thanks @Saransh-cpp, I'll do that.


Sw 6370 reassign tasks new endpoint

Codecov Report
Patch coverage: 71.42% and project coverage change: -0.17 :warning:

Comparison is base (f7c1ebc) 57.95% compared to head (632f5a8) 57.78%.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #313      +/-   ##
==========================================
- Coverage   57.95%   57.78%   -0.17%
==========================================
  Files          13       13
  Lines         918      912       -6
==========================================
- Hits          532      527       -5
+ Misses        346      345       -1
  Partials       40       40

Impacted Files
Coverage Δ

internal/sirius/assign_tasks_to_casemanager.go
60.46% <69.23%> (-0.65%)
:arrow_down:

internal/server/workflow.go
67.97% <100.00%> (-0.09%)
:arrow_down:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


LDAP requirement

Please add guidance for GHES running in Azure to use this without requiring LDAP via AADDS.
https://learn.microsoft.com/en-us/azure/active-directory/fundamentals/auth-ldap
Can't use AAD User Provisioning either because of Github SCIM API requirement.
https://learn.microsoft.com/en-us/azure/active-directory/saas-apps/github-provisioning-tutorial

Please add guidance for GHES running in Azure to use this without requiring LDAP via AADDS.
https://learn.microsoft.com/en-us/azure/active-directory/fundamentals/auth-ldap

@oobeLachlan thank you for opening this issue! There is currently an example environment file for running AzureAD without LDAP (.env.example.aad), and it makes use of msal to authenticate. If you use this configuration it will be SAML rather than LDAP.

Can't use AAD User Provisioning either because of Github SCIM API requirement.
https://learn.microsoft.com/en-us/azure/active-directory/saas-apps/github-provisioning-tutorial

This tool will only handle user creation if your GHES instance is configured with Local authentication. Otherwise you will need to leverage the GitHub native feature for user provisioning. The main purpose of this utility is to synchronize GitHub Team membership with users in groups within your directory. In other words, the users should already exist in GitHub and be provisioned through some other means.

@oobeLachlan if you still need help with this, please feel free to reach back out


Fonts with embedded bitmaps are not always rotated

Platform:
All
Architecture:
Windows
I would like you to also make the following fix to jdk 8
https://github.com/AdoptOpenJDK/openjdk-jdk11u/commit/f1bf238b695e0b4d49b8264b83228317ee75ebd3#diff-5c6198e34c46737fc7bf8f0eb5fff8d0

Hi @myamamoto I assume this is an issue with all OpenJDK 8 builds (from Oracle, Azul etc as well?). In that case you will need to make a backport request to the OpenJDK project (We can help you through that process).

Hi, @karianna Could you tell me how to request to the OpenJDK project?

Hi, @karianna Could you tell me how to request to the OpenJDK project?

The first step is to find the bug in the JBS bug database that covers this fix.
You'll want to search on https://bugs.openjdk.java.net/
Once you find that bug post back here and we'll take the next step :-)
You can also join our slack to do this all in real time

This is the bug I told.
https://bugs.openjdk.java.net/browse/JDK-8204929

Hi, @karianna This is the bug I told.
https://bugs.openjdk.java.net/browse/JDK-8204929

OK, that bug report seems to indicate that there is no issue with Java 8?

This is the issue for Java8. https://bugs.openjdk.java.net/browse/JDK-8163278
This issue is closed as duplicated...

Hi @myamamoto - have you tested this with the latest 8u build?
If it's still an issue there then I would post to the 2d-dev mailing list on OpenJDK and ask if someone is willing to apply https://bugs.openjdk.java.net/browse/JDK-8163278 as a backport of https://bugs.openjdk.java.net/browse/JDK-8204929

I tested it and confirmed this bug is not fixed in 8u202.

I tested it and confirmed this bug is not fixed in 8u202.

OK, so the next step will be to post on the 2d-dev mailing list - (you can sign up via http://mail.openjdk.java.net/mailman/listinfo/2d-dev).  And ask if someone is willing to sponsor a backport of https://bugs.openjdk.java.net/browse/JDK-8204929 (and tell them that you think https://bugs.openjdk.java.net/browse/JDK-8163278 could perhaps be the right issue to reopen for this.).
Let us know if you don't get a positive response in 72 hours or so and we'll see if we can find a sponsor at Adopt.

Hi @myamamoto - Sorry you didn't have good experience in the upstream project.  Let me drop a note to our JBS team and see what can be done.

Hi @karianna Could you tell me the status about this issue? Thank you in advance.

Hi @myamamoto - So a better approach is to create a patch (you can create a .patch file =based off our openjdk-jdk8u repo) and then send the contents of that patch to the jdk8u mailing list https://mail.openjdk.java.net/mailman/listinfo/jdk8u-dev - does that make sense?

Hi @karianna Thanks for your advice.
I do not know if that will do well or not.
I expect that adoptOpenJDK will do that including patch file creation and this bug will be fixed.

Hi @karianna Thanks for your advice.
I do not know if that will do well or not.
I expect that AdoptOpenJDK will do that including patch file creation and this bug will be fixed.

AdoptOpenJDK has a "Patches must be applied upstream policy".  If you'd like a company to do this on your behalf then both IBM and jClarity provide commercial support - see https://adoptopenjdk.net/support.html

What does upstream policy mean?

What does upstream policy mean?

AdoptOpenJDK only hosts its own patches in extreme circumstances.  All patches should be patch upstream at OpenJDK (ore Eclipse OpenJ9) as appropriate.  You can opt to make these patches yourself or engage in a commercial support arrangement to have it done for you.

Hi @myamamoto . Just looking for an update on this. Did you get a response from the mailing lists?

Hi @M-Davies
Nothing was known from the mailing lists, but I confirmed that it was fixed
https://bugs.openjdk.java.net/browse/JDK-8225334

Ah excellent. Does the patch work for you? If so, if there's nothing else you need, this can probably be closed 🙂


docker repo migrated

Changes

updated docker repo in image-tag.js
hard coded docker repo version as 0
hard coded platform as base
updated image-tag.test.js
updated docker.test.js to bypass repo version issue

Checklist

[x] Read the contribution guide and accept the code of conduct
[ ] Readme (updated or not needed)
[x] Tests (added, updated or not needed)

I don't know much about unity tests but can the user write build platform dependant tests ? in that case we would need to handle build platform like in the unity-builder action

I can confirm that this fixes at least the issue of missing git lfs when restoring packages on 2020.1 images :+1:

I don't know much about unity tests but can the user write build platform dependant tests ? in that case we would need to handle build platform like in the unity-builder action

You can definitely use things like #if UNITY_ANDROID in code, and want to run tests on specific platforms. There's also the UnityPlatform attribute, which can be used to target tests at specific platforms. I'd see this as a separate issue from what is done in this PR, though :)

I'll merge this after you regenerate action/index.js after rebasing or merging main into this.


Remove multi-fields from the state-vulnerability index template

Description
We have detected that the vulnerability index templates has some multi-fields. Usually, in these cases, the main field is of type keyword, and then there is a <field>.text that usually is of type text.
We assume this is done in purpose by ECS to optimize different kind of searches. For our use case, we do not want to use multi-fields, so we need to remove them from the index template. We'll decide for each of them which of the fields we keep, and its type.
This is also important for future index templates (see #270).
Also, we need to remove agent.host.os.family.

Replaced by https://github.com/wazuh/wazuh/issues/25485


apple-touch-icon support-issue-#2774

Add apple-touch-icon to create iOS home screen shortcuts.
Issue https://github.com/alshedivat/al-folio/issues/2774

There is some piece of code still missing here.


Moving window computations

Hi,
I'm getting some strange behavior trying to do computations that work with a moving window. I'm guessing there's a stateful computation in here somewhere messing things up, but I'm not sure where. What's the right way to do this?
julia> xf = Zip(Map(identity), Drop(1)) |> MapSplat(-)
Map(_zip_init) |>
    TeeZip(
        Map(first) |>
            Map(identity)
    ) |>
    Map(_zip_between) |>
    TeeZip(
        Map(first) |>
            Drop(1)
    ) |>
    Map(_zip_between) |>
    Map(last) |>
    MapSplat(-)

julia> collect(xf, [2,3,5,7,11])
4-element Array{Int64,1}:
 0
 0
 0
 0

If you just want a moving window, you can use Partition:
https://tkf.github.io/Transducers.jl/dev/manual/#Transducers.Partition
However, Partition is too general and not super efficient.  In particular, it's written in a way that the input can be, e.g., filtered by other transducers.  But I think moving window is almost always the first stage of the processing pipeline, right?  In that case, operating on a vector directly is almost always the right thing to do because you can just take a view of it.
I think this kind of computation is better to do at the foldl side.  If you are interested, have a look at this circularwindows example in https://tkf.github.io/Transducers.jl/dev/manual/#Transducers.AdHocFoldable. I've been thinking how to build some consistent way to do this #7 but I still don't know the answer.  Maybe this kind of interface should be built on top of foldl/reduce and transducers (maybe something like Query.jl), not building in Transducers.jl.
FYI, the behavior of Zip(Map(identity), Drop(1)) is actually expected and briefly "mentioned" in the documentation

Head transducers drive tail transducers. Be careful when using it with transducers other than Map, especially the contractive ones like PartitionBy and the expansive ones like MapCat.
--- https://tkf.github.io/Transducers.jl/dev/manual/#Transducers.Zip-Tuple

Yes, I know it's very cryptic and I have to find a better way to explain this other than saying read the code.  In Zip(Map(identity), Drop(1)), transducer Drop(1) "gates" the output from Map(identity).  You can probably see it from the ugly tree printed in the REPL you quoted; Map(identity) comes before Drop(1) in the sequence of |>s.  This is actually useful with Filter:
julia> collect(Zip(Filter(isodd), Map(string)) |> MapSplat(=>), 1:5)
3-element Array{Pair{Int64,String},1}:
 1 => "1"
 3 => "3"
 5 => "5"

Zip in Transducers.jl is more about fan-out than zipping so maybe it's just that I chose really bad name.  Maybe I'll rename it to Tee or something.

tl;dr: At the moment, use:

eachcol + reshape if you need performance.
Iterators.partition if you need to handle edge cases and window size is large (It yields vectors).
IterTools.partition if you only need short windows (it yields tuples).
Transducers.Partition if you need some pre-processing (it's probably not so bad in this case)

But I think moving window is almost always the first stage of the processing pipeline, right?

Not in this case. As a starting point, I was doing this:
function Elbo(p,q)
    sample = Map(a -> rand(q))
    logp = Map(x -> logpdf(p,x))
    logq = Map(x -> logpdf(q,x))
    sample |> Zip(logp,logq) |> MapSplat(-) |> Transducer(Mean())
end

function elbo(p,q)
    xf = Elbo(p,q) # |> Converged()
    mapfoldl(xf, right, 1:1000)
end

f(σ) = elbo(Cauchy(),Normal(0,σ))

Here p and q are Distributions (or Models from Soss, but that's not important).
Rather than fix a number of iterations, I was thinking it could be nice to have some general-purpose combinators for checking if a sequence has converged.

If you are interested, have a look at this circularwindows example...

Oh that's really nice!

Zip in Transducers.jl is more about fan-out than zipping so maybe it's just that I chose really bad name. Maybe I'll rename it to Tee or something.

Oh ok I'm still getting up to speed with the semantics but I'll watch out for this.
From your tl;dr I think I'll have a look at eachcol and reshape, maybe I can get things working with that approach.
Thanks for your help, and for all your work on this package!

Do you mean that it's useful to have Zip in the middle of a chain of transducers?  Or do you need to use some kind of moving window for calculating ELBO?
My comment was about moving window in particular and the way it appear in the code using transducers/iterators.  I do agree Zip is useful anywhere in a chain of transducers.

For Zip, I just need to figure out the semantics. Just some homework for me I think.
ELBO is my current use case, but I was thinking Transducers could be generally useful for separating concerns of specifying some sequence, vs reasoning about its convergence.

OK. Let me know if you find a case where Transducers.Partition is required and other things in the tl;dr didn't work. That would be a nice data point for me to think about how to optimize Transducers.Partition.
BTW, I'm also thinking about the interaction of RNG and Transducers #22. It's still at brainstorming phase, though.
I'm closing this issue for now and track the issue about Zip docs/name in #40.


Improve base weights consistency and make sure they're never zero

Fixes https://github.com/paritytech/substrate/issues/11804
Here's my attempt at fixing the way we generate our base weights. The fix is relatively straightforward:

Grab the minimum time it takes to run the extrinsic.
From all of the benchmark results substract that minimum.
Run the linear regression with the intercept value forced to y=0.
Set the previously calculated minimum time as the base weight.

Here's a sample of how the benchmark results look before this PR:
pallet_contracts/seal_transfer,328713000
pallet_contracts/seal_transfer/r,3335054000

pallet_contracts/seal_transfer,230924000
pallet_contracts/seal_transfer/r,3319470000

pallet_contracts/seal_transfer,281081000
pallet_contracts/seal_transfer/r,3316840000

pallet_contracts/seal_transfer,277473000
pallet_contracts/seal_transfer/r,3386931000

pallet_contracts/seal_transfer,517279000
pallet_contracts/seal_transfer/r,3350051000

pallet_contracts/seal_transfer,193294000
pallet_contracts/seal_transfer/r,3361404000

pallet_contracts/seal_transfer,137453000
pallet_contracts/seal_transfer/r,3380590000

pallet_contracts/seal_transfer,0
pallet_contracts/seal_transfer/r,3452650000

As you can see the base weights are all over the place, and we even have one zero here.
And here's how they look after this PR:
pallet_contracts/seal_transfer,349462000
pallet_contracts/seal_transfer/r,2550642000

pallet_contracts/seal_transfer,349162000
pallet_contracts/seal_transfer/r,2511251000

pallet_contracts/seal_transfer,350352000
pallet_contracts/seal_transfer/r,2537639000

pallet_contracts/seal_transfer,348642000
pallet_contracts/seal_transfer/r,2497103000

pallet_contracts/seal_transfer,349471000
pallet_contracts/seal_transfer/r,2519135000

pallet_contracts/seal_transfer,348562000
pallet_contracts/seal_transfer/r,2466470000

There might be better ways of doing this. This PR is also unfinished and should not be merged as-is - it obviously needs to be actually properly tested to make sure this isn't subtly broken is some way; some tests also still need fixing, and the code to print out errors needs to be added back.
I'm opening this mostly to discuss whether we actually want to fix it in this way, before I invest more time into it.

The steps make sense to me, and seem to not break any assumptions for the benchmarking pipeline overall.
Let me know how I can help here if you need anything.

We have a quite a lot of benchmarks with components that do not start at 0.

So what was the rationale to not run those benchmarks with zero values?

Maybe we can get around this by only applying your intercept-shift-logic if the linear regression reports a negative intercept?

Hmm... well, in some cases that could work, but image that the linear regression returns an intercept of, say, 1 (which is possible), and then essentially we'll have the same problem. So I'm not entirely sure what the best course of action is here...

There's one more problem I've found when digging through the numbers; the slopes can also be zero for some benchmarks! Behold, the benchmark for frame_system/remark when ran on my machine:

The dots are real samples from the benchmark, while the line on the bottom is the cost calculated using the weights. This happens because the slope here is calculated as 0.4102529741049291, which is rounded down to zero. When I regenerate the graph with the proper slope it looks like this:

So, uh, this is pretty bad. Weight calculation shouldn't randomly break down like this.

So what was the rationale to not run those benchmarks with zero values?

In many cases, the 0 value makes no sense. For example, creating a membership group with 0 users. The underlying runtime code probably would reject this extrinsic.
Regarding the slope issue, you must note that when looking at the raw, unaltered data, is is basically zero slope:
https://www.shawntabrizi.com/substrate-graph-benchmarks/old/?p=system&e=remark

Yes, the benchmarking process is truncating really small slopes to zero, but also these effects are nearly zero when compared to the underlying weights here.
Im not against ideas which can bubble these things up accurately, but we should not also say that it is "break"ing. The weights we are generating, even for thinks like remark, are good for what they are used for.

Somehow I also see a linear timing for System::Remark :confused:
cargo r --release --features=runtime-benchmarks --bin substrate -- benchmark pallet --dev --steps=50 --repeat=20 --pallet="frame_system" '--extrinsic=remark' --execution=wasm --wasm-execution=compiled

produces on reference hardware:
Data points distribution:                                                                                [10/685]
    b   mean µs  sigma µs       %
    0     5.419       0.1    1.8%
78643     34.82     0.072    0.2%
157286     63.95       0.1    0.1%
235929     90.53     0.083    0.0%
314572     121.4     0.137    0.1%
393215     150.1     0.176    0.1%
471858     177.3     1.756    0.9%
550501     203.3     0.149    0.0%
629144     231.6     0.161    0.0%
707787     259.8     0.128    0.0%
786430     288.2     0.445    0.1%
865073     316.2     0.145    0.0%
943716     344.4     0.156    0.0%
1022359     380.3     3.213    0.8%
1101002     401.3     0.502    0.1%
1179645     429.3     0.458    0.1%
1258288     457.6     0.191    0.0%
1336931     486.3     1.577    0.3%
1415574     513.9     0.164    0.0%
1494217     542.2     0.296    0.0%
1572860     570.5      0.26    0.0%
1651503     598.8     0.216    0.0%
1730146     634.6     7.387    1.1%
1808789     659.5     10.44    1.5%
1887432     684.4     0.928    0.1%
1966075     712.9     0.922    0.1%
2044718     741.3      0.74    0.0%
2123361     769.1     0.239    0.0%
2202004       798     0.777    0.0%
2280647       832     11.92    1.4%
2359290     865.5     9.494    1.0%
2437933     884.1     1.061    0.1%
2516576     912.2     0.983    0.1%
2595219     942.8     2.526    0.2%
2673862     993.1     14.54    1.4%
2752505      1012     13.67    1.3%
2831148      1028     4.116    0.4%
2909791      1060     7.656    0.7%
2988434      1091     13.12    1.2%
3067077      1113     1.849    0.1%
3145720      1147     11.67    1.0%
3224363      1172     3.371    0.2%
3303006      1200     2.122    0.1%
3381649      1230     4.119    0.3%
3460292      1259     4.096    0.3%
3538935      1288     3.585    0.2%
3617578      1317     4.995    0.3%
3696221      1347     4.183    0.3%
3774864      1377     9.218    0.6%
3853507      1409     8.801    0.6%
3932150      1435     4.814    0.3%

The timing values seem to increase from 5.4µs at b=0 to 1_435µs at maximum b=3932150.
That is quite the difference. Obviously a small slope that we can normally ignore can start to make a difference when it is multiplied with 4 million...

So what was the rationale to not run those benchmarks with zero values?

In many cases, the 0 value makes no sense. For example, creating a membership group with 0 users. The underlying runtime code probably would reject this extrinsic.

So can we assume that if a parameter of zero doesn't make sense and the extrinsic would reject it then in normal use it wouldn't be called with such a parameter anyway? (Or at least wouldn't be called often if the caller is non-malicious.) In which case does it really matter that the base weight would be higher than necessary? I know that in general there is no such guarantee, but it'd make sense to me to basically require that extrinsics are benchmarked with full range of expected inputs to ensure optimal weights, and if you don't benchmark with the full range then you might get slightly higher weights, but you won't risk opening yourself to a potential DoS attack.

Yes, the benchmarking process is truncating really small slopes to zero, but also these effects are nearly zero when compared to the underlying weights here.
Im not against ideas which can bubble these things up accurately, but we should not also say that it is "break"ing. The weights we are generating, even for thinks like remark, are good for what they are used for.

Sorry, I might have used a too strong of a word here. My point was more that it is a subtle landmine that someone could step on without realizing it, since whether this is a problem or not will depend on the exact range the input component can have.

Regarding the slope issue, you must note that when looking at the raw, unaltered data, is is basically zero slope:

Yes, I was looking at the raw, unaltered data. (: And if you only look at the first 16k of the input component it is indeed basically zero and doesn't matter, but the benchmark goes up to 4 million (as @ggwpez confirmed, thanks!) where it seems to start to matter.
Again, whether this is actually a problem in practice for this particular extrinsic - I haven't checked, but even if it isn't it doesn't change the fact that it is a potential subtle correctness issue that might bite someone somewhere without them realizing.
So I see two ways we could fix this: either always round up the weights to 1, or just use higher precision weights. Since our weights are multiplied by 1000 anyway I'm guessing the second option would be preferable?

@koute either solutions sound good to me.
I am still mostly in the camp that the current system is "good enough", we have plenty of full integration benchmarks which show that they are quite accurate (and in the cases they are not, always pessimistic), but happy to have you find these further improvements that can be made :)

Okay, I've increased the precision with which the weights are returned. So now the analysis code returns the extrinsic times' already essentially premultiplied by 1000 instead of multiplying them in the writer.
From my side I think this should be good to go?
As a sanity check here is an example diff comparing weights' outputs before and after this PR:
@@ -62,27 +62,27 @@
 impl<T: frame_system::Config> WeightInfo for SubstrateWeight<T> {
 	// Storage: Recovery Proxy (r:1 w:0)
 	fn as_recovered() -> Weight {
-		(10_050_000 as Weight)
+		(10_110_000 as Weight)
 			.saturating_add(T::DbWeight::get().reads(1 as Weight))
 	}
 	// Storage: Recovery Proxy (r:0 w:1)
 	fn set_recovered() -> Weight {
-		(20_610_000 as Weight)
+		(20_140_000 as Weight)
 			.saturating_add(T::DbWeight::get().writes(1 as Weight))
 	}
 	// Storage: Recovery Recoverable (r:1 w:1)
 	/// The range of component `n` is `[1, 9]`.
 	fn create_recovery(n: u32, ) -> Weight {
-		(41_123_000 as Weight)
-			// Standard Error: 14_000
-			.saturating_add((155_000 as Weight).saturating_mul(n as Weight))
+		(39_920_000 as Weight)
+			// Standard Error: 5_800
+			.saturating_add((182_163 as Weight).saturating_mul(n as Weight))
 			.saturating_add(T::DbWeight::get().reads(1 as Weight))
 			.saturating_add(T::DbWeight::get().writes(1 as Weight))
 	}
 	// Storage: Recovery Recoverable (r:1 w:0)
 	// Storage: Recovery ActiveRecoveries (r:1 w:1)
 	fn initiate_recovery() -> Weight {
-		(48_000_000 as Weight)
+		(47_270_000 as Weight)
 			.saturating_add(T::DbWeight::get().reads(2 as Weight))
 			.saturating_add(T::DbWeight::get().writes(1 as Weight))
 	}
@@ -90,9 +90,9 @@
 	// Storage: Recovery ActiveRecoveries (r:1 w:1)
 	/// The range of component `n` is `[1, 9]`.
 	fn vouch_recovery(n: u32, ) -> Weight {
-		(31_502_000 as Weight)
-			// Standard Error: 15_000
-			.saturating_add((271_000 as Weight).saturating_mul(n as Weight))
+		(30_050_000 as Weight)
+			// Standard Error: 7_087
+			.saturating_add((334_068 as Weight).saturating_mul(n as Weight))
 			.saturating_add(T::DbWeight::get().reads(2 as Weight))
 			.saturating_add(T::DbWeight::get().writes(1 as Weight))
 	}
@@ -101,9 +101,9 @@
 	// Storage: Recovery Proxy (r:1 w:1)
 	/// The range of component `n` is `[1, 9]`.
 	fn claim_recovery(n: u32, ) -> Weight {
-		(41_489_000 as Weight)
-			// Standard Error: 16_000
-			.saturating_add((192_000 as Weight).saturating_mul(n as Weight))
+		(40_270_000 as Weight)
+			// Standard Error: 6_915
+			.saturating_add((229_951 as Weight).saturating_mul(n as Weight))
 			.saturating_add(T::DbWeight::get().reads(3 as Weight))
 			.saturating_add(T::DbWeight::get().writes(1 as Weight))
 	}
@@ -111,9 +111,9 @@
 	// Storage: System Account (r:1 w:1)
 	/// The range of component `n` is `[1, 9]`.
 	fn close_recovery(n: u32, ) -> Weight {
-		(47_169_000 as Weight)
-			// Standard Error: 16_000
-			.saturating_add((240_000 as Weight).saturating_mul(n as Weight))
+		(46_000_000 as Weight)
+			// Standard Error: 8_005
+			.saturating_add((296_745 as Weight).saturating_mul(n as Weight))
 			.saturating_add(T::DbWeight::get().reads(2 as Weight))
 			.saturating_add(T::DbWeight::get().writes(2 as Weight))
 	}
@@ -121,15 +121,15 @@
 	// Storage: Recovery Recoverable (r:1 w:1)
 	/// The range of component `n` is `[1, 9]`.
 	fn remove_recovery(n: u32, ) -> Weight {
-		(44_697_000 as Weight)
-			// Standard Error: 16_000
-			.saturating_add((196_000 as Weight).saturating_mul(n as Weight))
+		(43_940_000 as Weight)
+			// Standard Error: 9_009
+			.saturating_add((169_804 as Weight).saturating_mul(n as Weight))
 			.saturating_add(T::DbWeight::get().reads(2 as Weight))
 			.saturating_add(T::DbWeight::get().writes(1 as Weight))
 	}
 	// Storage: Recovery Proxy (r:1 w:1)
 	fn cancel_recovered() -> Weight {
-		(17_090_000 as Weight)
+		(17_141_000 as Weight)
 			.saturating_add(T::DbWeight::get().reads(1 as Weight))
 			.saturating_add(T::DbWeight::get().writes(1 as Weight))
 	}
@@ -139,27 +139,27 @@
 impl WeightInfo for () {
 	// Storage: Recovery Proxy (r:1 w:0)
 	fn as_recovered() -> Weight {
-		(10_050_000 as Weight)
+		(10_110_000 as Weight)
 			.saturating_add(RocksDbWeight::get().reads(1 as Weight))
 	}
 	// Storage: Recovery Proxy (r:0 w:1)
 	fn set_recovered() -> Weight {
-		(20_610_000 as Weight)
+		(20_140_000 as Weight)
 			.saturating_add(RocksDbWeight::get().writes(1 as Weight))
 	}
 	// Storage: Recovery Recoverable (r:1 w:1)
 	/// The range of component `n` is `[1, 9]`.
 	fn create_recovery(n: u32, ) -> Weight {
-		(41_123_000 as Weight)
-			// Standard Error: 14_000
-			.saturating_add((155_000 as Weight).saturating_mul(n as Weight))
+		(39_920_000 as Weight)
+			// Standard Error: 5_800
+			.saturating_add((182_163 as Weight).saturating_mul(n as Weight))
 			.saturating_add(RocksDbWeight::get().reads(1 as Weight))
 			.saturating_add(RocksDbWeight::get().writes(1 as Weight))
 	}
 	// Storage: Recovery Recoverable (r:1 w:0)
 	// Storage: Recovery ActiveRecoveries (r:1 w:1)
 	fn initiate_recovery() -> Weight {
-		(48_000_000 as Weight)
+		(47_270_000 as Weight)
 			.saturating_add(RocksDbWeight::get().reads(2 as Weight))
 			.saturating_add(RocksDbWeight::get().writes(1 as Weight))
 	}
@@ -167,9 +167,9 @@
 	// Storage: Recovery ActiveRecoveries (r:1 w:1)
 	/// The range of component `n` is `[1, 9]`.
 	fn vouch_recovery(n: u32, ) -> Weight {
-		(31_502_000 as Weight)
-			// Standard Error: 15_000
-			.saturating_add((271_000 as Weight).saturating_mul(n as Weight))
+		(30_050_000 as Weight)
+			// Standard Error: 7_087
+			.saturating_add((334_068 as Weight).saturating_mul(n as Weight))
 			.saturating_add(RocksDbWeight::get().reads(2 as Weight))
 			.saturating_add(RocksDbWeight::get().writes(1 as Weight))
 	}
@@ -178,9 +178,9 @@
 	// Storage: Recovery Proxy (r:1 w:1)
 	/// The range of component `n` is `[1, 9]`.
 	fn claim_recovery(n: u32, ) -> Weight {
-		(41_489_000 as Weight)
-			// Standard Error: 16_000
-			.saturating_add((192_000 as Weight).saturating_mul(n as Weight))
+		(40_270_000 as Weight)
+			// Standard Error: 6_915
+			.saturating_add((229_951 as Weight).saturating_mul(n as Weight))
 			.saturating_add(RocksDbWeight::get().reads(3 as Weight))
 			.saturating_add(RocksDbWeight::get().writes(1 as Weight))
 	}
@@ -188,9 +188,9 @@
 	// Storage: System Account (r:1 w:1)
 	/// The range of component `n` is `[1, 9]`.
 	fn close_recovery(n: u32, ) -> Weight {
-		(47_169_000 as Weight)
-			// Standard Error: 16_000
-			.saturating_add((240_000 as Weight).saturating_mul(n as Weight))
+		(46_000_000 as Weight)
+			// Standard Error: 8_005
+			.saturating_add((296_745 as Weight).saturating_mul(n as Weight))
 			.saturating_add(RocksDbWeight::get().reads(2 as Weight))
 			.saturating_add(RocksDbWeight::get().writes(2 as Weight))
 	}
@@ -198,15 +198,15 @@
 	// Storage: Recovery Recoverable (r:1 w:1)
 	/// The range of component `n` is `[1, 9]`.
 	fn remove_recovery(n: u32, ) -> Weight {
-		(44_697_000 as Weight)
-			// Standard Error: 16_000
-			.saturating_add((196_000 as Weight).saturating_mul(n as Weight))
+		(43_940_000 as Weight)
+			// Standard Error: 9_009
+			.saturating_add((169_804 as Weight).saturating_mul(n as Weight))
 			.saturating_add(RocksDbWeight::get().reads(2 as Weight))
 			.saturating_add(RocksDbWeight::get().writes(1 as Weight))
 	}
 	// Storage: Recovery Proxy (r:1 w:1)
 	fn cancel_recovered() -> Weight {
-		(17_090_000 as Weight)
+		(17_141_000 as Weight)
 			.saturating_add(RocksDbWeight::get().reads(1 as Weight))
 			.saturating_add(RocksDbWeight::get().writes(1 as Weight))
 	}

And here's an example diff of what the benchmarking prints out on the stdout:
 Pallet: "pallet_recovery", Extrinsic: "remove_recovery", Lowest values: [], Highest values: [], Steps: 50, Repeat: 20
 Raw Storage Info
 ========
 Storage: Recovery ActiveRecoveries (r:1 w:0)
 Storage: Recovery Recoverable (r:1 w:1)

 Median Slopes Analysis
 ========
 -- Extrinsic Time --

 Model:
-Time ~=    44.66
-    + n    0.188
+Time ~=    44.38
+    + n    0.078
               µs

 Reads = 2 + (0 * n)
 Writes = 1 + (0 * n)

 Min Squares Analysis
 ========
 -- Extrinsic Time --

 Data points distribution:
     n   mean µs  sigma µs       %
-    1     44.97     0.183    0.4%
-    2     44.75     0.207    0.4%
-    3     45.64     0.173    0.3%
-    4     45.48     0.288    0.6%
-    5     45.94     0.536    1.1%
-    6     45.51     0.134    0.2%
-    7     45.82     0.244    0.5%
-    8     46.18     0.213    0.4%
-    9     46.74     0.408    0.8%
+    1     44.52     0.142    0.3%
+    2     44.68     0.135    0.3%
+    3     44.92     0.364    0.8%
+    4     44.39      0.24    0.5%
+    5     44.61     0.131    0.2%
+    6     44.75      0.27    0.6%
+    7     44.66     0.102    0.2%
+    8      45.8     0.661    1.4%
+    9     45.42     0.377    0.8%

 Quality and confidence:
 param     error
-n         0.016
+n         0.009

 Model:
-Time ~=    44.69
-    + n    0.196
+Time ~=    43.94
+    + n    0.169
               µs

 Reads = 2 + (0 * n)
 Writes = 1 + (0 * n)

@koute can you bump the version of the crate?
Otherwise, looking good, will review

@koute can you bump the version of the crate?

Sure. Do you mean version of frame-benchmarking (from 4.0.0-dev to 6.0.0-dev)? Or do you mean the linregress dependency (since they apparently released 0.5 a week ago)?

Otherwise, looking good, will review

Thanks!

The precision increase to pico-seconds is good, thanks.
About the does-not-start-at-zero benchmarks, I dont think there is a straightforward solution.
Our standard approach would be to round it up to zero, since then we over-estimate and are therefore safe.

bot rebase

/cmd queue -c bench-bot $ pallet dev pallet_contracts

bot merge


Great News: All Bugs Will be Fixed In the Year 2041

It's simple math:

Bugs fixed in version 1.5: 24
Bugs fixed in version 1.4: 16

Makes an average of 20.
Releases are scheduled for about every 6 months - means 40 bugs get fixed in a year.
Current open bugs: 677
677 / 40 = 16.925 years
2024 + 17 = 2041
YAY!
But only if everybody would stop reporting any new ones. If we take that into account:
In the past 12 months, 383 (now open) + 313 (now closed) bugs have been created (https://github.com/microsoft/microsoft-ui-xaml/issues?q=is%3Aissue++label%3Abug+sort%3Aupdated-desc++created%3A>2023-03-07)
Let's take only the open ones to extrapolate. Assuming that in the coming years, 383 bugs will be filed per year which can't be closed, then the count won't be zero, but instead
6,511 Bugs in 2041
Oh....
Something is going very wrong here, to say the least.

What is the one developer who is fixing the bugs, asctually doing on the on the other 4 days each week?

I figured it out: Drawing ASCII art in code comments:
https://github.com/softworkz/microsoft-ui-xaml/blob/7b02acd91e64159e836953d252af4c2427196e11/dxaml/xcp/dxaml/lib/CueRenderer.cpp#L155-L168

Comparing with MAUI
When comparing with the fixes in  the MAUI changelogs from the past 12 months:
WinUI3: 40
MAUI: 783
That's a factor of 20x
Details

Version
Date
Fixes

8.0.7
14 Feb 24:
70

8.0.6
17 Jan 24:
61

8.0.3
Nov 14, 2023
56

8.0.100
Nov 7, 2023
13

8.0.0
Oct 31, 2023
29

8.0.0-rc.2.9373
Oct 10, 2023
48

7.0.96
Oct 10, 2023
26

8.0.0-rc.1.917
1 Sep 12, 2023
74

8.0.0-preview.7.8842
Aug 8, 2023
42

8.0.0-preview.6.8686
Jul 11, 2023
39

7.0.92
Jul 11, 2023
19

8.0.0-preview.5.8529
Jun 13, 2023
49

8.0.0-preview.4.8333
May 16, 2023
69

6.0.553 Service Release
11 Apr 26, 2023
4

7.0.86 Service Release
6 May 9, 2023
3

8.0.0-preview.3.8149
Apr 11, 2023
79

7.0.81 Service Release
4 Apr 11, 2023
35

8.0.0-preview.2.7871
Mar 14, 2023
11

8.0.0-preview.1.7762
Feb 21, 2023
56


fix: Release to trigger CI to asset store

#61  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @AngelOnFira and the rest of your teammates on  Graphite