Tweak default of "add statement" to insert just before last statement

The worked example for 2+2=4 convinces me that the current default for "add statement" is wrong when no statement is selected. If no statement is selected and there's at least one statement, the new statement should be added just before the last statement. As long as you add the goal first (as recommended) this is the most likely place that the user wants a new statement added.
Currently I believe the default is to add the statement as the last statement. That is usually the right thing to do, but for a prover (like this) I think it's not the best default.
Making this change to the default will make the tool easier to use and easier to explain. It would, for example, eliminate a lot of steps in the 2+2=4 example.

 But I think wanting to add a new statement to the very end is an unusual event.

2+2=4 example convinced me too that this should be improved. I don't want to hardcode this automation, so I am planning to fix this issue (and another - #10 ) by adding two new settings:

"Initial statement label"

description: when you add a new statement and there are no other statements in the editor, this will be the label for the statement;
default value: qed

"Always move statement labeled as [     ] to the bottom"

description: if there is a statement labeled as specified by this setting, this statement will be kept at the bottom.
default value: qed

Maybe settings look unusual but this should fix the issue. Setting them to an empty value will disable this automation and the editor will work as it works now.

The problem with this approach is that if you rename the goal statement label, it quietly doesn't go to the end.
Here's an alternative: Instead of "H" or "P", have 3 types: "H", "P", or "G" (goal). A "goal" is a P-type that is kept at the bottom. If you set any other statement to the goal, any other goal is changed to "P".

Note: This is related to #10

What do you think about instead of G statements, adding a boolean attribute for each statement "stick to the bottom"? This way more than one statement could be kept at the bottom (if needed).

"Stick to the bottom" is okay.  Presumably if more than one sticks, then they'd stay in the same order. The problem is showing that status - it'd stick to use up valuable horizontal real estate.
As an alternative, you could use my "G" (goal) idea. However, instead of having "stick to the bottom" semantics, it would simply affect the default location when you add a new statement and no statement is selected. That way, you can move statements around to your heart's content, including moving statements after qed (e.g., if you think you don't want to use them but aren't sure).

Ok. Currently G statements look more promising for me. I will analyze the problem a bit more and either implement something or return with more questions.


Changes in the mei-Mensural.xml customization to make it compliant with the decisions made by the mensural-ig

Three main changes:

New attribute @dur.quality for <note> elements to indicate whether the note is perfect / imperfect / altered / etc. and, therefore, be comprehensive in the durational information of the note (given that in mensural notation, the note shape is not enough to indicate the length of a note). The new attribute can have the following six values: perfecta, imperfecta, altera, maior, minor, and duplex. The last three are used in Ars antiqua: maior and minor are used for semibreves and duplex is used for longae.

New values for the attribute @dur for the <rest> elements: two-breve rests ("2B") and three-breve rests ("3B").

New <stem> element to be used as children of the <note> element. Notes can have more than one stem. Therefore the introduction of the <stem> element as a children of <note>, allowing to associate multiple stem elements to a single note, each stem with its own form, direction, etc. Attributes of <stem>: pos, length, form, dir, flag.pos, flag.form, x, and y.

Two small changes:

Change in the description of the @dur attribute

Added a new stem-related attribute @stem.form to be encoded within the <note> element.

These are all (but one) of the changes that were discussed and approved by the mensural-ig in the 2018 meeting. The one change I did not include has to do with the encoding of the mensuration sign, because (based on the notes) further discussion is needed.
[The discussion can be seen in the attached file.]
MEI-Mensural IG - Approved MEC 2018 Pending Implementation.pdf

Hi @kepper. So:

I will remove all comments (erase the personalized ones and move the more informative ones into either <desc> or <remark>).
I know there have been issues regarding the naming of the attribute as @dur.quality, but in the end (after several discussions in the mensural-ig) no other name has been proven more appropriate. And yes, the idea is that it would only be included within the mensural module. And also the documentation shown when you are adding the attribute (in Oxygen) shows that this is an attribute for mensural notation.
So, just to be clear, should I include these changes in the customization file or the source file at this point? I will redo the pull-request to remove the comments, so I can make the changes in the appropriate file as well.

Please let me know if there is anything else needed before the 29th. I will try to have everything ready so that this PR can be approved. Thanks!

About the individual points:
#1 - the IG has debated for months about the best and concise attribute name, and "quality" has been approved as the most appropriate. There is no Latin original for this. "Quality" in English is "a distinctive attribute or characteristic possessed by someone or something" so in this case we want to distinguish a specific characteristic of "duration". Note that if we wanted to split hairs, what we encode with "dur" in mensural terms is not really a "duration" in the same way it is for CMN; but we don't want to use a completely different system to represent how time is "measured", right? I think that mensuralists should compromise in order to keep a core set of tags common to all modules, and this is what is happening here. "Quality" is an excellent compromise and a term generic enough that everybody will understand. The Guidelines will explain.
#2 - I am not a fan of "2B" and "3B" but these values work for what we need, and people seem to like these values. Also in this case the discussion led to agree about this so I hope that this can be introduced.
#3, 5 - As the description says (and as the original document of the IG further explains) notes can have more than one stem, with associated flags of various shapes. I cannot think to a simplest way than an element to represent this.
The original document approved by the IG suggests that in order not to bother people not encoding mensural stuff, special the use of elements or attributes that can generate confusion can be restricted via schematron. How useful to have notationtype.
I have a question about the procedure. Wouldn't it be more practical to have one pull request per each feature, so that each of them can be separately discussed, if needed? This PR deal with too different matters to be discussed together, examples made.

As discussed in the ODD Friday, I would prefer that someone else (other than me) would actually play around with the resulting scheme. This is my first time editing the ODD and I would want to double-check that these changes don't have, as you call them, unintentional side effects. Thank you for offering to take a look into this in a few weeks, @kepper. I will proceed to include some example images to show the intended use of the introduced features (to make this task a little easier).

The first change indicated in the pull request is about the @dur.quality attribute, the description in the PR indicates:

New attribute @dur.quality for  elements to indicate whether the note is perfect / imperfect / altered / etc. and, therefore, be comprehensive in the durational information of the note (given that in mensural notation, the note shape is not enough to indicate the length of a note). The new attribute can have the following six values: perfecta, imperfecta, altera, maior, minor, and duplex. The last three are used in Ars antiqua: maior and minor are used for semibreves and duplex is used for longae.

This is what I expect:

It is one of the available attributes of a <note> element

And these are all the available values of the attribute. The guidelines, as well as <desc> for each of these values in the schema, will indicate when using each of these values (e.g., major and minor should only be used for semibrevis in Ars antiqua).

The second change indicated in the pull request reads:

New values for the attribute @dur for the <rest> elements: two-breve rests ("2B") and three-breve rests ("3B").

This is what I expect:
The rests have these extra values (2B and 3B) for the @dur attribute.

While these values are not available in the notes.

The third change indicated in the pull request reads:

New <stem> element to be used as children of the <note> element. Notes can have more than one stem. Therefore the introduction of the <stem> element as a child of <note>, allowing to associate multiple stem elements to a single note, each stem with its own form, direction, etc. Attributes of <stem>: pos, length, form, dir, flag.pos, flag.form, x, and y.

The values for the @form, @flag.pos, and @flag.form were defined from scratch in this pull request. The values of the other attributes are taken from pre-existing data types.
dir

form

pos

flag.form

flag.pos

And the length, x, and y attributes use their regular values.

There are two other pull requests regarding the Mensural notation module: #541 and #537. About each of them in relation to this pull request:

The #541 pull request proposes to remove mensur- and proper-related attributes from <staffDef> and <scoreDef> elements. There are no conflicts between the present PR (#634) and #541.

The #537 pull request introduces support for , there were some issues raised for this proposal, which I think can be resolved by moving the attributes that are related to mensuration signs into the visual domain. This was proposed by @rettinghaus in https://github.com/music-encoding/music-encoding/pull/537#issuecomment-409260333:

So why is the sign attribute part of the logical domain? The sign itself doesn't have to carry a meaning. And the values "O" and "C" are just imitating the look of the used sign. "O" and "C" are a pretty straight forward encoding method nevertheless. I think @sign and @dots should be in the visual domain.

I will make this changes and submit another pull request for this (I don't want to mix it with this one in case there are some otehr issues to be rasied)
Further discussion might be needed for #537, so I will include these changes on another pull request (fixing the issues raised on #537).

Just a question about the procedure. Does "changes approved" and "all checks have passed" mean that the discussion is closed, and that all the proposed changes are now part of the specification? @kepper @martha-thomae

Hi @giulianodibacco. Let me explain. So, @kepper accepted all the changes trusting that the IG had checked that there were no unintentional side effects introduced with these changes. I asked Johannes to please take a look in more detail to the PR because this is my first time editing ODD. So, no, the changes are not part of the schema yet. Hopefully, they will be incorporated soon.

I've requested a couple of minor changes upstream over at https://github.com/martha-thomae/music-encoding/pull/1. Nothing serious…

I've requested a couple of minor changes upstream over at martha-thomae#1. Nothing serious…

Thank you very much, @kepper, for the time you took evaluating this proposal. Thanks for the pull request you made, all the minor changes you asked in that PR have been included (previous commit).

Hi @kepper! Just to let you know that all the things discussed in the last ODD Thursday are now corrected here. I added a few in-line comments with questions on the code of the last commit to evaluate if the last change requested was implemented alright. Please let me know if there is anything that I have to change.
This (#634) and pull requests #541 and #657 complete all the changes for the mensural module. There are no conflicting changes between any of these pull requests. The documentation associated with the modified specs (in these 3 pull requests) can be found in the guidelines https://github.com/music-encoding/guidelines/pull/156 PR. Everything is ready for tomorrow's ODD Friday. Please let me know if there is anything I can do. Thanks! See you tomorrow.
Oh, and when the changes on this (#634) pull request are accepted, I can move things from customization to the source files (as we agreed).

Everything in this PR has been double-checked and accepted, except for the last commit about the multi-breve rests. @kepper, you asked me to change their implementation: substituting the schematron rule by the use of two datatype classes (see commit message). I hope I have done this correctly, I added a comment on that just after that commit.
I have already moved all the approved changes into the source files (instead of using the customization file as happens in this PR), as can be seen in this branch. As soon as the multi-breve rest implementation is evaluated, I will also move these changes into the source files (at that new branch) and finalize the PR.


Create rch.toml

Discord: ches#0494
Element: rch
Telegram: @rdchas
Github: https://github.com/rchas
Twitter: https://twitter.com/rdchasey
I am a professional validator in many project (Obol, Sei, Sui, Stride, Quicksilver mainnet, Planq mainnet, Rebus mainnet, Bundlr, Kyve, Subspace, Oasys, Peaq, Haqq, Masa, Massa, Transformers, Exorde, Taiko, Humans, Uptick, Joystream, Nibiru, Ziesha, Defund, Minima and many other).
I use only high-quality servers with high uptime (in various locations in Amsterdam, London, New York, Bangalore, Singapore) I securely store the keys in several copies, and I also always keep one more node synchronized, for unforeseen circumstances, I connect monitoring and status tracking to each node, I can put in a relayer to do the ibc transmission, put in a faucet and explorer.

Discord: ches#0494
Element: rch
Telegram: @rdchas
Github: https://github.com/rchas
Twitter: https://twitter.com/rdchasey
I am a professional validator in many project (Obol, Sei, Sui, Stride, Quicksilver mainnet, Planq mainnet, Rebus main, Bundlr, Kyve, Subspace, Oasys, Peaq, Haqq, Masa, Massa, Transformers, Exorde, Taiko, Humans, Uptick, Joystream, Nibiru, Ziesha, Defund, Minima and many other).
I use only high-quality servers with high uptime (in various locations in Amsterdam, London, New York, Bangalore, Singapore) I securely store the keys in several copies, and I also always keep one more node synchronized, for unforeseen circumstances, I connect monitoring and status tracking to each node, I can put in a relayer to do the ibc transmission, put in a faucet and explorer.

merged manually into public-testnet-3


Custom attribute types

I notice that in this official blog post from Facebook, there is an attribute of the type fbid.
How does Facebook define this type, and how can we do the same?

Hack feature, not XHP-specific: https://docs.hhvm.com/hack/type-aliases/introduction

Sorry, hadn't noticed that! Many thanks, Fred -- great work here too. :tada:

Also, any class or enum will work. The only thing I don't think will work is inline shape declarations, eg attribute shape('foo' => string) bar

Thank you! Much appreciated.


New HWRP to configure the Jenkins HTTP proxy

In most setups, the Jenkins server is behind a proxy/firewall, which can be a problem as Jenkins requires internet access to download plugins and updates. If you need to go through an HTTP proxy server, the connection details can easily be configured with this new resource provider.

@rexut Can you remove recipes/_master_proxy (per @schisamo's comment above), and anything related to that recipe, and also please rebase?
Thanks!

Sorry for the delay. I'll do it as soon as possible.


Restore specific incremental in the chain

Description
The user will chose the appropriate id to restore in the incrementalàs chain.
Use case
With this feature the user can control the specific point in time to recover, even if this point is in the middle of the incrementalàs chain.
Interface Changes
In susnstone, when the restore interface is showed, add the value to chose the id from the chain to restore/create the image.

Progress Status

[ ] Code committed
[ ] Testing - QA
[ ] Documentation (Release notes - resolved issues, compatibility, known issues)

Hi,
Do you have any manual procedure to restore a specific incremental backup ?
I don't understand why you have add the feature of incremental backup on 6.6.0 if it's not possible to choose a specific date...
I hope you have a manual procedure to resolve this BIG issue.
kind regard

Hi,
As workaround, you can customize this behavior in the downloader.sh script inside remotes folder for datastores_mad.
You can download as many pieces as you want to rebase the first full.
Sadly can't be done by the Sunstone Web page nor Fireedge, because is not implemented yet on the XML-RPC.

@nachowork90 is completely right, We are working to get this ready for 6.6.1. This feature was postponed to 6.6.1 to not delay 6.6.0 more.
The snippet refer by @nachowork90 is:
https://github.com/OpenNebula/one/blob/master/src/datastore_mad/remotes/downloader.sh#L600
Didn't try myself but if you create an image using PATH in that URL format:
rsync://100/0:8a3454,1:f6e63e//var/lib/one//datastores/100/6/8a3454/disk.0.0
And include the increments of interest in the list it will only restore those. You need to manually gather the IDs, though
We understand this is an important feature and we'll do our best to include it in 6.6.1


add GH Action to check commits conform to Conventional Commits

https://www.conventionalcommits.org/en/v1.0.0/

fixed by #34


Testing consumers that need to get send endpoints with TestConsumeContext

Currently the GetSendEndpoint() method in TestConsumeContext throws a NotImplementedException in Marten.TestFramework (v3.6). Would there be any interest in a PR that would add the ability to add send endpoints that can be used?
The inability to use GetSendEndpoint in unit tests are making some things are to test in my current project.

I guess, making the tests use the actual InMemoryTestHarness would be smarter, since it provides a full in-memory simulation of the bus, to make it a real test. And they're as fast as any unit test since it's entirely in-memory (the slow part of these tests is talking to Postres anyway).

Alright. Thanks for the tip. I'll look into it and see if I can whip something together.

Not sure where you're seeing this, I looked at the Marten tests and they're not using the TestConsumeContext...

So the guidance is to use the TestHarness, and not the TestConsumeContext. This should probably be removed from the TestFramework package, honestly.

I misread you completely. Thanks for the info. Will rewrite tests to use the in-memory bus.

Marten tests are based on some other persistence library tests. There was no test harnesses available at the time.

TestConsumeContext is used in both MassTransit.Tests and MassTransit.Automatonymous.Tests to test stuff that just needs a consume context, without any bus. I doubt we can just remove it. Harnesses are bound to the bus.
@ogrman may be it is time to close this issue?


Changes to json_fields don't invalidate cached results

When we deploy a new version of our codebase that includes changes to a json_fields declaration (e.g., adding a new field), any cached data for that model should be invalidated. Instead, the stale data continues to be returned and a full cache clear is required before the correct fields are returned.
This could take the form of an additional version option that's simply incremented by developers upon making changes that should invalidate cached results. (I'm not sure how to cleanly offer the option without potentially colliding with the model's actual field definitions, but it seems we already do something like this with hide_as_child_json_when). A more sophisticated approach might be to include a hash of the json_fields definition in the cache keys. This would change when the definition changes, automatically invalidating any previously cached data.

:+1:

It seems to me that the current versioning system allows for this.. do we just not want to increment the version of each item in the json_fields block?

@wrgoldstein I think you're correct that that would work, but it's just impractical to declare a new version and update all the as_json calls each time the schema changes. I was hoping for something that would "just work" (hopefully without being too complex).

@wrgoldstein and I worked on this a little. Automatically "fingerprinting" the json_fields declaration is impractical because of all the lambdas... I don't know of a way to consistently digest their definitions into a string representation. Alternatives include:

Fingerprint just a subset of the definition (e.g., just the keys or the declaration excluding lambdas)
Add an optional version to the whole json_fields declaration (requiring developers to add/increment the version when they intend to invalidate previously-cached values)
Do nothing

Let me know if you think any of these are worthwhile. I'm not sure (1) or (2) are worth the complexity.

I vote to do nothing, however this is an interesting problem. The original problem is that we have new code and are serving old data. There're two scenarios:
Clients Must Change
This is a schema change to JSON responses, so I think you want to treat it as a migration, and invalidate the appropriate caches part of the deployment. The more atomic alternative is (2) IMO, (1) seems like a lot of work and hard to debug cache invalidations on deployment.
Clients Roll Change
Clients are OK with old data but we don't want to wait our cache invalidation lifetime (eg. 24 hours). A possible "solution" is to create a strategy by which upon deployment lifetime of objects is decreased, so maybe caches will invalidate over the next 15 minutes instead of 24, but still not at once.

This is a great issue.
What I've generally done (and of course always forgotten :smile: ), is to explicitly invalidate the cache for any affected object where I've changed the JSON representation. I agree that this is a lot of work - modifying the json for AdditionalImage means busting the cache for every image!
In terms of your second point, I would be willing to rely on that, however I regularly see objects that persist in the cache for much longer than 24 hours.
For example, I deploy a code changing the JSON schema for a class, yet several days after that deploy, I'm still seeing stale JSON coming thru the cached json. Shouldn't that not happen if the cache was being expired?
I don't see where (in this gem), an expires_in or such type of parameter is being used, and the default Rails.cache is to never expire unless explicitly told so, and to instead rely on normal cache eviction by your caching server.

So I guess my question (hit 'Enter' too early above), is what's the proper way to use cache expiration time here? The shortest cache we can get away with the better, and I have a hunch we're currently (in production) not expiring this cache (we are invalidating however).
I think we can fix our specific issue by modifying our config/memcached.yml to include an expires_in set from an ENV var, for example.


virus warning!

this contain many virusses dont install plss!

i mean that the application is very good that i can play any skin i like but can you make sure that no virussses in that file and can you explain that trojan file What is it really?

i mean that the application is very good that i can play any skin i like
but can you make sure that no virussses in that file and can you explain
that trojan file What is it really?
Vào Th 5, 31 thg 10, 2024 vào lúc 12:21 hydy100 @.***>
đã viết:

Closed #195 https://github.com/hydy100/R3nzSkin/issues/195 as completed.
—
Reply to this email directly, view it on GitHub
https://github.com/hydy100/R3nzSkin/issues/195#event-15025392792, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/BMQRLAG4VC76C3OQN2QGWTLZ6G46BAVCNFSM6AAAAABQ37Q4YCVHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMJVGAZDKMZZGI3TSMQ
.
You are receiving this because you authored the thread.Message ID:
@.***>

after 1 week use it again i dont get any viruses , it's very good , I would
be very happy if you continue to develop upcoming versions in the future.
Vào Th 5, 31 thg 10, 2024 vào lúc 20:15 hydy100 @.***>
đã viết:

It's easy to claim something is a virus, but proving it isn't can be
extremely difficult. Showing there's no malicious behavior is hard, whereas
identifying just one harmful action would prove it is a virus. So, let's
use a proof by contradiction—please provide your evidence of any malicious
behavior that would classify it as a virus.
—
Reply to this email directly, view it on GitHub
https://github.com/hydy100/R3nzSkin/issues/195#issuecomment-2449817211,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BMQRLAC57NNBDJLEJJSLHGDZ6IUN7AVCNFSM6AAAAABQ37Q4YCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINBZHAYTOMRRGE
.
You are receiving this because you authored the thread.Message ID:
@.***>


feat(TDI-40129) Upgrade to CXF 3.2.2

What is the current behavior? (You can also link to an open issue here)
For https://jira.talendforge.org/browse/TDI-40129
Upgrade CXF version for netsuite components
What is the new behavior?
Upgrade CXF from 3.2.1 to 3.2.2
Please check if the PR fulfills these requirements

[x] The commit message follows Talend standard
[ ] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features) ?
[ ] The code coverage on new code >75%
[x] The new code does not introduce new technical issues (sonar / eslint)

What kind of change does this PR introduce?

[ ] Bugfix
[x] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build / CI related changes
[ ] Other... Please describe:

Does this PR introduce a breaking change?

[ ] Yes
[x] No

Pull request test result: success :star:
Sonar results

Failed check is caused by other problem.


drivers: video: add isx019 camera sensor

Summary
ISX019 has the DOL-HDR feature, which combines images with different exposure so that
both bright and dark data of high-contrast subject can be viewed at the same time.
Impact
Camera driver
Testing
Spresense

please ignore the false nxstyle error

@pkarashchenko thanks


Zoom Sliders can't drag by touch

open
http://openlayers.org/en/latest/examples/zoomslider.html?q=slider
Zoom Sliders can't drag by touch
￼and test by Chome developer tools has same problem

test v3.16.0 or v3.14.0 Zoom Sliders can't drag by touch,
test v3.13.0 ok
http://openlayers.org/en/v3.13.0/examples/zoomslider.html?q=slider

can't touch drag map as well.

We encounter the same problem for touch.
After some investigation:
The ol.control.ZoomSlider.prototype.handleDraggerDrag_ is subsequently fired by mouse, touch and pointer events (at least in chrome). Touch events have the clientX and clientY in the touches and changedTouches properties of the event object, while mouse and pointer have them available in the event object.
If no clientX and clientY is available it causes a crash.
Assertion failed: calculated resolution outside allowed bounds (%s <= %s <= %s) 0.02625 NaN 3440.64
Assertion failed: calculated value (%s) ouside allowed range (0-1) NaN

When not using touch events (by commenting out the draglistener for touchmove and touchend) it works (in Chrome).
Tested in:
Chrome version 56.0.2924.76 beta (64-bit)
FF version 51.0.1 (32-bit)  (no support for pointerevents and touchevents)
Edge version 38.14393.0.0 works fine.
Tested with: http://openlayers.org/en/latest/examples/zoomslider.html?q=slider&mode=raw

Is this fix also part of the current 4.0.1 version? I'm still experiencing the issue in FireFox 51.0.1 (32-bit). Both mouse drag and pointer drag don't work.

#6422 is part of the 4.0.0 release so yes

By the way, we are using pep.js polyfill which may be interfering here I suppose. Let's see if I can find out.


Change observatory according to with FITS standard, fixes #148

@lmohrmann done

@adonath @registerrier Does this change require some adaptions in Gammapy? I guess the tools should support both the old and new keywords for the time being.


Add ping-pong response

https://pusher.com/ is occasionally calling websocket_handle({:ping, raw_message}, _conn_state, state) which throws an error. This commit seems to fix it.

We need to update the project to the newest elixir and probably update the websocket_client to use the hex.pm version

Indeed. I have no experience with maintaining public elixir libraries but I found another issue when I wanted to deploy prod release:

exjsx application is not started
websocket_client application is not started

The fix was pretty simple. Add exjsx and websocket_client to extra_applications in mix.exs
I'll see if I manage to open another PR with deps upgrade and application start strategy.

Cool no worries. I will have some time later this week to help with these changes. Thanks for starting this discussion 👍


Explicit Http Credentials for HttpWebRequest?

What do people think about adding parameters for explicit username and password?
I have a scenario (TeamCity) where I need to make a REST-ful POST request from the build, but the server only supports basic HTTP authentication, so I would need to provide a NetworkCredential with a specific user name and password.
I know having passwords in the build file would be considered less than ideal, but in my case TeamCity actually provides build properties for the server's credentials that I would use, so I wouldn't need to have a clear text password anyway in my case.

There's other places where passwords are provided in MSBuildExtensionPack, so I think it's reasonable.  I think it's really up to the consumer to determine how they wish to secure the password not the framework.
I hope that the basic authentication is at least over SSL.

I think this is alreadysupported. Just pass in U/P
            if (this.UseIntegratedAuthentication)             {                 request.Credentials = CredentialCache.DefaultCredentials;             }             else if (!string.IsNullOrEmpty(this.UserName))             {                 request.Credentials = new System.Net.NetworkCredential(this.UserName, this.UserPassword);             }


Update homepage in gemspec

Codecov Report

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

@@           Coverage Diff           @@
##           master     #321   +/-   ##
=======================================
  Coverage   33.77%   33.77%
=======================================
  Files           2        2
  Lines         228      228
=======================================
  Hits           77       77
  Misses        151      151

Continue to review full report at Codecov.

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


Added support for programmatically  change ViewfinderView mask color

I could be nice to be able to change the mask colour programmatically. As commented on #432

Thanks - made minor changes and merged.

@rkistner sorry, I didn't get the notification sonner


App crashes when opening

A merchant was trying to use the Shopify Theme Tool using Sublime, and it keeps crashing as soon as it's opened. Here's an example:

Logfile:
[15:08:49:460] [Ti.Host] [Information] Loaded module = app
[15:08:49:463] [Ti.Host] [Information] Loaded module = codec
[15:08:49:467] [Ti.Host] [Information] Loaded module = database
[15:08:49:471] [Ti.Host] [Information] Loaded module = filesystem
[15:08:49:473] [Ti.Host] [Information] Loaded module = media
[15:08:49:476] [Ti.Host] [Information] Loaded module = monkey
[15:08:49:492] [Ti.Host] [Information] Loaded module = network
[15:08:49:495] [Ti.Host] [Information] Loaded module = platform
[15:08:49:500] [Ti.Host] [Information] Loaded module = process
[15:08:49:516] [Ti.Host] [Information] Loaded module = ui
[15:08:49:520] [Ti.Host] [Information] Loaded module = worker
[15:08:49:687] [Ti.Host] [Information] Loaded module = php
[15:08:49:693] [Ti.JavaScript] [Information] Loading JS path=/Applications/Shopify Theme.app/Contents/modules/filesystem/1.3.1-beta/tifilesystemmodule.js
[15:08:49:714] [Ti.Host] [Information] Loaded module = tifilesystem
[15:08:49:714] [Ti.JavaScript] [Information] Loading JS path=/Applications/Shopify Theme.app/Contents/modules/network/1.3.1-beta/tinetworkmodule.js
[15:08:49:717] [Ti.Host] [Information] Loaded module = tinetwork
[15:08:49:717] [Ti.JavaScript] [Information] Loading JS path=/Applications/Shopify Theme.app/Contents/modules/process/1.3.1-beta/tiprocessmodule.js
[15:08:49:718] [Ti.Host] [Information] Loaded module = tiprocess
[15:08:50:221] [Ti.API] [Information] Fixing perms on: /Applications/Shopify Theme.app/Contents/Resources/lib/watch_server.rb
[15:08:50:226] [Ti.API] [Information] No upgrade required
[15:08:50:818] [Ti.API] [Information] appView: Initializer
[15:08:50:822] [Ti.API] [Information] appView: render
[15:08:50:823] [Ti.API] [Information] render shop id:hermosa-dev
[15:08:50:823] [Ti.API] [Information] ShopView: initializer
[15:08:50:825] [Ti.API] [Information] Render Shopview
[15:08:50:906] [Ti.API] [Information] Port Available. Starting Watcher...
[15:08:50:907] [Ti.API] [Information] Watch Theme: 99992647 on port: 45623
[15:08:50:910] [Ti.API] [Information] Watch process launched: 9253
[15:08:50:910] [Ti.API] [Information] Watch process running: true
[15:08:51:914] [Ti.API] [Information] Connecting socket theme: 99992647 on port 45623
[15:08:51:918] [Ti.API] [Information] {"event":"connect"}

[15:09:20:477] [Ti.API] [Information] {"event":"update","base":"/Users/michaelsanger/Documents/Sites/HERMOSA/SHOPIFY DEV/hermosa-dev-99992647","relative":"layout/theme.liquid"}
[15:09:20:477] [Ti.API] [Information] asset:send listener
[15:09:20:478] [Ti.API] [Information] IO:sendAsset: layout/theme.liquid
[15:09:20:506] [Ti.API] [Information]

[15:09:22:128] [Ti.API] [Information] PUT: Failure
[15:09:22:129] [Ti.API] [Error] 404d
[15:09:22:129] [Ti.API] [Error] Not Found
[15:09:22:132] [Ti.Network.HTTPClient] [Error] Request to message : "Result of expression 'response' [null] is not an object.", line : 28d, sourceId : 1.74189e+08d, sourceURL : "app://com.meeech.shopify_theme2/js/handlers/asset-send.js", expressionBeginOffset : 872d, expressionCaretOffset : 880d, expressionEndOffset : 887d, name : "TypeError"}

Using Mac OS X 10.11.3. @meeech do you have any idea what's going on here - or is there anymore information we can grab that would be more indicative to what the issue is? :smile:

@audition You should really scrub log before posting. Anyone can now use the token posted to modify the site. Please make sure to revoke this token/api pw combo right away

does it crash for every file? or just tcertain ones. It seems to be getting a 404 on the PUT
Have they tried re-checking out the theme? Maybe they have renamed/moved it so the data the app has for the ID is incorrect.

Hey @meech - looks like every file. API keys scrubbed. Missed that - apologies.

its 3 eees btw :) So have them re-download the theme and then see.

@audition i would suggest you invalidate the keys. once you post them publicly assume they are compromise.

Thanks @meeech - will suggest this. I'll let you know how it goes!


Feature/find target objects populate

If the request is for an add or remove blueprint then populate needs to be used instead of find.  This is so the parentid and id are parsed correctly.
Without this change the id from the relation is used by find to look up the parent model.

The rabbit hole got a bit deep here.  Would really like to get blueprints with associations working.  I think this could be a good start, but I'm willing to pull this back as it is hitting more and more code.
This also might be a dup of issue #5


Reorganize FIAM's Resources for FIAM

FIAM was not working on SPM because the resource bundle was not generating.
There was a lot of experimentation here so I wanted to make note of some realizations/learnings:
• In order for SPM to generate a bundle for a target, the target's resources need to be in the target's Sources directory.
• The Package manifest will attempt to compile and build all targets (an issue for targets with platform-specific resources).
• FIAM only provides default UI implementations for iOS (so I've removed the blank tvOS storyboard)
• SPM generates target bundles in a single directory. So if target B is listed as a dependency of target A and both targets defines resources in their declarations, then SPM will generate a Target_B.bundle and a Target_A.bundle at the same directory level (this was against my intuition as I thought target B's bundle would be within target A's bundle since A depends on B).
Note on SPM & platform specific resources:
• There currently isn't a clear cut way to define platform specific resources. See the conversation on the Swift forums here. The workaround here is to do something similar to what was done in SPM for Analytics by creating a new target containing FIAM's iOS resources that is conditionally depended on in the primary FIAM target.
Future work:
Translating FIAM's default UI implementations from storyboards to programmatic UIKit should make this type of problem easier to fix in the future because we can use preprocessor directives (which we can't use in storyboards). Plus, programmatic UI's should be easier to maintain and update.
Fixes #7715.

I see 🟢
I'll run tests on this today and approve if we're looking good.

We're looking good. FIAM still works on iOS and tvOS via CocoaPods. FIAM iOS works via Swift Package Manager, not on tvOS. @ncooke3 this is expected, right?

@ncooke3 Great investigation, thank you for doing it!
I may be worth creating a doc like this for the platform-specific resource in SPM with a summary, conclusions and recommendations for teams that use or plan to such resources. I can be done as a follow up for the PR.

Tested this on SPM and CocoaPods for iOS and tvOS. Everything's working.


Players drop a heart too.

When you kill a player, I gain a heart, however a heart gets dropped by the player as well.

Also I noticed that "redeem" is spelt incorrectly in the item description.

Currently it is "radeem"

On it, will update tomorrow
Thanks

Fixed
Modrinth: https://modrinth.com/mod/lifesteal-smp/version/1.2.0
Curseforge: https://www.curseforge.com/minecraft/mc-mods/lifestealsmp/files/5589524


so many files “missing"

How did you install the Amplify CLI?
curl -sL https://aws-amplify.github.io/amplify-cli/install | bash && $SHELL
If applicable, what version of Node.js are you using?
n/a
Amplify CLI Version
12.10.1
What operating system are you using?
Mac
Did you make any manual changes to the cloud resources managed by Amplify? Please describe the changes made.
no manual changes made
Describe the bug
after the amplify init and the amplify pull then creating the directory amplify/generated/models that fails to be created and then the amplify pull (which still fails to put anything in the models folder,
the xCode project is modified to require a bunch of files that don’t exist
Showing All Messages
.../amplify/hooks/post-push.sh.sample: No such file or directory
.../amplify/hooks/pre-push.js.sample: No such file or directory

and puts in duplicate compile commands
Showing All Messages
Multiple commands produce ‘.../amplify-meta.json'
Multiple commands produce ‘.../root-cloudformation-stack.json'
Multiple commands produce ‘…/tags.json'

Expected behavior
modification of Xcode project should not make it uncompilable
Reproduction steps
amplify init
amplify pull
mkdir -p amplify/generated/models
amplify pull

(xcode project is tweaked)
Project Identifier
Project Identifier: b9f58993952c779454856d6c2fc263b7
Log output

# Put your logs below this line

Additional information
No response
Before submitting, please confirm:

[X] I have done my best to include a minimal, self-contained set of instructions for consistently reproducing the issue.
[X] I have removed any sensitive information from my code snippets and submission.

Hey @pixeled 👋 thanks for raising this!, it appears the codegen command maybe failing on the pull. I'm going to transfer this over to our codegen repository for better assistance 🙂.


Fixes needed to support OptiX 7.4

Signed-off-by: Larry Gritz<EMAIL_ADDRESS>

@chellmuth (and I'll make an MR for the same changes on the renderer side internally)


README doc for LongClassNameCheck

PR-Codex overview
This PR focuses on addressing long class names. It includes the following changes:

Added an example of a valid class name (PgUser)
Added an example of a broken class name (AbstractDatabaseConnection)
Suggested using a configuration parameter (maxClassNameLen) to set the maximal reasonable length of class names

✨ Ask PR-Codex anything about this PR by commenting with /codex {your question}

@h1alexbel thank you for your Pull Request. I'll assign someone to review it soon.
If this PR solves a todo from the code, please don't forget to remove it.

@l3r8yJ take a look, please

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (df7864b) 73.29% compared to head (1a7371b) 73.29%.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff            @@
##             master      #93   +/-   ##
=========================================
  Coverage     73.29%   73.29%
  Complexity       61       61
=========================================
  Files            16       16
  Lines           191      191
  Branches          3        3
=========================================
  Hits            140      140
  Misses           46       46
  Partials          5        5

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

@rultor merge

@rultor merge

@l3r8yj OK, I'll try to merge now. You can check the progress of the merge here

@rultor merge

@l3r8yj Done! FYI, the full log is here (took me 2min)


optimize: Brent (and some issues)

What are you trying to do?
Trying to add a Brent optimization method to Gonum.
What did you do?
Attempted to write the implementation. Ran into some issues. Specifically, the Brent optimization function requires access to the evaluation function in order to build its brackets in the initialization stage.
However, the code as I understand it, does not expose Problem.Func anywhere.  And there are no clever workarounds to do so.
The only other solution would be to pass in the function into the Brent struct. Which would lead to frankly quite a terrible API:
fn := func(x []float64) float64 { ... }
problem := optimize.Problem {Func: fn} // <---- this
method := &optimize.Brent {
    Func: fn, // <----- this needs to be the exact same function as the above. this is terrible API-wise
}

optimize.Local(problem, []float64{...}, nil, method)

This solution is terrible because when initializing the Brent struct, you'd have to pass in the function for the Init method to calculate the correct brackets. Failing to pass in the same exact function as the problem would lead to weird results.
Ideally, when the Brent struct is initialized, it will be given the Problem.Func from minimize.
This however, requires modifying minimize to check for the Method type. That's not very nice.
Proposal
A new interface should be created and checked in minimize. I propose something like this:
type RequiresFn interface {
    InitWithFn(fn func ([]float64)float64)
}

Thoughts welcome

@btracey solved the issue offline. Thanks. Sketching out solution now

To expand upon this a bit, the implementation of NelderMead is a good example of how to use the Location struct to make several evaluations before "starting" the optimization.

@chewxy . I am trying to implement Brent optimization method. Since this issue was not possible. Can you explain me the workaround for this. I am trying to use it to imitate this https://github.com/cranmer/fast-asimov-utils/blob/master/fasimov/init.py#L163 in golang.
Thanks in advance.

@jaybatra26 here's my unmerged working. I don't recall how @btracey and I solved this offline, but I recall forgetting to do merge, or was asked to hold off because of new APIs... either way, long time ago. The kernels can still be used, so feel free to crib as much as you want.
https://github.com/chewxy/gonum/blob/cb9987b6d9c0f4762b9269fcd25ca00c4abd3dd5/optimize/brent.go
Diff:
https://github.com/gonum/gonum/compare/master...chewxy:brent


cant find the function  setDistributeEvenly in SlidingTabLayout.java

i cant find the function  setDistributeEvenly in SlidingTabLayout.java which makes the tabs even

This sample has been deprecated/archived (check README for more information on newer samples related to this technology).
As recommended by GitHub, we are closing all issues and pull requests.


CosmosDB Firewall - Remove old portal IPs

Remove reference to old Azure Portal IP's

@seesharprun
Can you review the proposed changes?
Important: When the changes are ready for publication, adding a #sign-off comment is the best way to signal that the PR is ready for the review team to merge.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

@seesharprun @Jak-MS gentle ping on this

@seesharprun - can you take a look? thanks!

I don't have a way to review the technical accuracy of this article.
Is there an Azure Cosmos DB engineer that can review this, @sajeetharan?
Also, if this is a contribution from a Microsoft FTE, this is not the correct repository for this type of contribution.


Fix unstable mpsc buffer test

This is fractionally more likely to pass, but not a real fix.

coverage: 97.3% (+0.09%) from 97.211% when pulling 1a98eeef0f4136505b522ff51f9196b7e373af8c on users/alexpeck/mpscteststab2 into f6fec6cf97d6921b048fedecfed3d24e8c9c0c86 on main.

It could be that this is caused by the timeout attribute:

TimeoutAfter taken from here.


TypeError: cannot unpack non-iterable VisImage object

thanks for this work,i'm very gratefuly to help me to fix this error:
Traceback (most recent call last):
File "/content/TextFuseNet/demo/icdar2015_detection.py", line 135, in
prediction, vis_output, polygons = detection_demo.run_on_image(img)
File "/content/TextFuseNet/demo/predictor.py", line 64, in run_on_image
vis_output, polygons = visualizer.draw_instance_predictions(predictions=instances)
TypeError: cannot unpack non-iterable VisImage object

Hi, I encountered the same error running icdar2015_detection.py. I suspect it might be something to do with the fact that I am not running TextFuseNet-Detectron due to CUDA 10.1 being incompatible with my GPU but here's the fix that is working for me right now:
In icdar2015_detection.py, change line 135 from
prediction, vis_output, polygons = detection_demo.run_on_image(img)
to
prediction, vis_output = detection_demo.run_on_image(img)
and comment out line 139.
Then, in predictor.py, change line 64 from
vis_output,polygons = visualizer.draw_instance_predictions(predictions=instances)
to
vis_output = visualizer.draw_instance_predictions(predictions=instances)
and comment out , polygons in line 66.
My guess is that their TextFuseNet-detectron's visualizer function works differently than the one in stock Detectron2. Hope this helps.

pip uninstall detectron2
uninstall detectron2
in TextFuseNet folder：
python setup.py install
pip install fvcore-master.zip

pip uninstall detectron2

uninstall detectron2

in TextFuseNet folder：

python setup.py install

pip install fvcore-master.zip

Hi, I encountered the same error running icdar2015_detection.py. I suspect it might be something to do with the fact that I am not running TextFuseNet-Detectron due to CUDA 10.1 being incompatible with my GPU but here's the fix that is working for me right now:
In icdar2015_detection.py, change line 135 from prediction, vis_output, polygons = detection_demo.run_on_image(img) to prediction, vis_output = detection_demo.run_on_image(img) and comment out line 139.
Then, in predictor.py, change line 64 from vis_output,polygons = visualizer.draw_instance_predictions(predictions=instances) to vis_output = visualizer.draw_instance_predictions(predictions=instances) and comment out , polygons in line 66.
My guess is that their TextFuseNet-detectron's visualizer function works differently than the one in stock Detectron2. Hope this helps.

There would still be problems in save_result_to_txt as it takes in polygons as an argument.

Hi, I encountered the same error running icdar2015_detection.py. I suspect it might be something to do with the fact that I am not running TextFuseNet-Detectron due to CUDA 10.1 being incompatible with my GPU but here's the fix that is working for me right now:
In icdar2015_detection.py, change line 135 from prediction, vis_output, polygons = detection_demo.run_on_image(img) to prediction, vis_output = detection_demo.run_on_image(img) and comment out line 139.
Then, in predictor.py, change line 64 from vis_output,polygons = visualizer.draw_instance_predictions(predictions=instances) to vis_output = visualizer.draw_instance_predictions(predictions=instances) and comment out , polygons in line 66.
My guess is that their TextFuseNet-detectron's visualizer function works differently than the one in stock Detectron2. Hope this helps.

There would still be problems in save_result_to_txt as it takes in polygons as an argument


Setting the string for Fixed label

I have a keypad with eight generic switches and each has a Fixed Label. Say I want to name them "SW1"..."SW8". mfg_tool has this:
sage: mfg_tool.py [-h] [-n COUNT] [-s SIZE] [--passcode PASSCODE] [--discriminator DISCRIMINATOR] [-cf {0,1,2}] [-dm {0,1,2}]
                   [-cn CN_PREFIX] [-lt LIFETIME] [-vf VALID_FROM] [-c CERT] [-k KEY] -cd CERT_DCLRN [--dac-cert DAC_CERT]
                   [--dac-key DAC_KEY] [--paa | --pai] [-v VENDOR_ID] [--vendor-name VENDOR_NAME] [-p PRODUCT_ID]
                   [--product-name PRODUCT_NAME] [--hw-ver HW_VER] [--hw-ver-str HW_VER_STR] [--mfg-date MFG_DATE]
                   [--serial-num SERIAL_NUM] [--enable-rotating-device-id] [--rd-id-uid RD_ID_UID]
                   [--calendar-types CALENDAR_TYPES [CALENDAR_TYPES ...]] [--locales LOCALES [LOCALES ...]]
                   [--fixed-labels FIXED_LABELS [FIXED_LABELS ...]] [--product-label PRODUCT_LABEL] [--product-url PRODUCT_URL]
                   [--csv CSV] [--mcsv MCSV]

So how does "--fixed-labels FIXED_LABELS [FIXED_LABELS ...]] " map to the generic switches? Is this mapped by the order I create the Fixed Labels? Or are these multiple labels for translations and you don't handle multiple clusters with fixed labels?
Does it need --fixed-labels-1 ... --fixed-labels-8 ?
Scene keypads like this....

There is a problem here with locales and fixed-labels. If you set a different locale, you need a different set of fixed labels.

How are those dependent? Both are in different clusters.

As per the specification, fixed labels are read-only attributes, so I am not sure how you want to change it.
But, you can have a list of fixed labels on you device and based on locale the commissioner/controller should figure out the one it wants to use.
Also, the options in the mfg_tool lets to add supported_locales and not the active locale.

When the controller sets the active locale into the device, shouldn't the fixed labels change to match that locale?

Then this is not just about fixed-labels or extents to every possible string the controller can read.
I am not sure how to maintain that in the SDK.

Boris wrote back to me -- the labels are truly fixed, they don't change to match locale.    But... there are proposals to change this.

Probably once we have some clarity on that we can incorporate that into the script.


Cleanup

Fixed formatting. Sorry.

 Please only do atomic commits: one commit that fixes the specific bug without touching any other code. Also, please include unit tests that check to make sure your code works.
Cheers.

I will try. Please cancel my pull requests please.
 Please only do
atomic commits: one commit that fixes the specific bug without touching any
other code. Also, please include unit tests that check to make sure your
code works.
Cheers.

Reply to this email directly or view it on GitHub:
https://github.com/sbisbee/sag/pull/36#issuecomment-2683668

Also, this made me finally sit down and write a quick guide to contributing to Sag. I hope you find it useful! Feedback is appreciated.
https://gist.github.com/1352319

Coolio.
On Nov 9, 2011 1:36 PM, "Sam Bisbee" <
<EMAIL_ADDRESS>wrote:

Also, this made me finally sit down and write a quick guide to
contributing to Sag. I hope you find it useful! Feedback is appreciated.
https://gist.github.com/1352319

Reply to this email directly or view it on GitHub:
https://github.com/sbisbee/sag/pull/36#issuecomment-2685163

Oh, I found another bug. If couch does a 301 redirect it craps the response
header parsing so I had to rewrite that too.
On Nov 9, 2011 1:36 PM, "Sam Bisbee" <
<EMAIL_ADDRESS>wrote:

Also, this made me finally sit down and write a quick guide to
contributing to Sag. I hope you find it useful! Feedback is appreciated.
https://gist.github.com/1352319

Reply to this email directly or view it on GitHub:
https://github.com/sbisbee/sag/pull/36#issuecomment-2685163

Glad that you're finding these issues. :) Please put each into its own ticket in the issues section: https://github.com/sbisbee/sag/issues


Showing two columns with same name

Hello,
I'm using Room Persistence Library and Stetho for an android app.
When i inspect db from chrome://inspect it is showing two primary key "id" columns.
Anyone can tell me why ?
Stetho debug :

User class :

Thank's (:

I truly am not sure why this is happening.

Same here. I can't believe that there are no more responses to this issue


Replace Path backslashes in makeSettingsPatch on Windows

Fixes https://github.com/rnpm/rnpm/issues/113
Builds on and replaces https://github.com/rnpm/rnpm-plugin-link/pull/36 that seems abandoned

Oh nice one! Looks cool, @Kureev ?

After thinking about it for a while, I am actually going to merge it since it implements all that's been said in #36.


changed over all PE parent to be consistent with DWMA

@xgui3783 I've realized one inconsistency in the SWMA PEs in comparison to DWMA PEs:
Overall parent should be "superficial white matter" instead of "SWMA superficial fibre bundles". I've updated the PEs.

looks good to me.


drivers: pinctrl device interface (Linux-like) and STM32F0 driver

The PR provides a new device interface for pin controllers. As a proof of concept the interface is implemented and tested for the STM32FOx SoC.
The Zephyr pin controller follows the concepts of the Linux PINCTRL (PIN CONTROL) subsystem.
The Zephyr pin controller does not provide the full scope of the Linux PINCTRL subsystem. Also the PINCTRL interface is specific to Zephyr and not compatible (but similar) to the Linux PINCTRL interface.
As a major goal the device tree bindings are kept compatible to the Linux pinctrl bindings as much as possible.
Review
This is the master pull request.
To ease commenting and review several review/ RFC pull requests are available that focus only on specific aspects. Please use these PRs instead of this one. I will do my best to keep them in sync.

TBD

Some patches are extracted for independent inclusion into master:

doc: sphinx: Add Pygment lexer for DTS (#6397)

Features

The PINCTRL device driver provides applications and other drivers access:

to the drivers control properties sich as pins, groups, pinctrl states,
and functions,
to pin configuration,
to pin multiplexing, and
to pin state setting.

The driver also provides initial setup of pin configuration and pin multiplexing controlled by the device tree pinctrl state information (the "default" state). This obsoletes the SoC specific pinmux.c.

PINCTRL device driver API and usage documentation is added.
Relates to #4830

The PINCTRL device interface provides also the PINMUX interface as a generic shim. For more sophisticated configuration the PINCTRL interface can be used directly.
Fixes #2288, #6084

The PINCTRL device interface provides a superset to the GPIO configuraton properties with well understood configuration properties. It can be used instead of the GPIO configuration interface.
Relates to #4506.

The new GPIO-PINCTRL driver (GPIO that uses the PINCTRL driver as backend) provides GPIO pin number to PINCTRL pin number mapping controlled by device tree info (gpio-ranges).

Documentation for PINCTRL API and for extensions to the GPIO API, and PINCTRL and GPIO usage documentation is added.
Relates to #4829

Design
PINCTRL driver interface
The PINCTRL driver interface API is added in include/pinctrl.h. Defines that may be used in the device tree and in the interface are in include/pinctrl_common.h. That way they can be included from the interface and from the device tree bindings (e.g include/dt-bindings/pinctrl_stm32.h). Within include/pinctrl.h a generic shim that maps the PINMUX interface to the PINCTRL interface is added.
GPIO driver interface extensions
For GPIO-PINCTRL drivers (GPIO drivers that use the PINCTRL driver as backend) generic PIN number defines are introduced. These PIN number defines allow to describe a set of pins by just or-ing the defines. Such operations on a set of pins of a port can easily be described and implemented.
Due to the new gpio-ranges device tree directive a mapping from GPIO pin numbers to PINCTRL pin numbers is possible.
Extraction of PINCTRL info from device tree
Extraction of device tree info is - as usual - done by the extract_dts_includes.py script. To allow modularization of the monolitic script all global data and functions are factorized to a python module that can be imported by other modules. The extraction of pinctrl directives and gpio-ranges directives is added as separate python modules.
For a pin controller node extract_dts_includes.py extracts five data sets:

FUNCTION
For all active client nodes that reference a pin-controller by pinctrl-x(&pinctrl, ...) FUNCTION defines are generated.     The function equals the client node.
STATE_NAME
For all pinctrl names of pinctrl-x directives of active client nodes STATE_NAME defines are generated. This is mostly to allow deduplication of commonly used state names such as e.g. "default".
PINCTRL_STATE
For all pinctrl-x directives of active client nodes PINCTRL_STATE defines are generated. The pinctrl state references the FUNCTION (aka. node) it is given in. The pinctrl state also references the STATE_NAME given in the pinctrl-names directive associated to the pinctrl-x directive. All the pins that a pinctrl state controls are regarded to be a pin group. The name of the pin group is the same as the name of the pinctrl state.
PINCTRL
For all subnodes of pin configurations referenced by active client nodes, pinctrl-x(&xxx, pinconf_a, ...), PINCTRL defines are generated. The pinctrl references the FUNCTION (aka. node) it is referenced from. The pinctrl also references the PINCTRL_STATE it is referenced from.
GPIO_RANGE
For all gpio-ranges directives of active GPIO nodes GPIO_RANGE defines are generated.

For the clients of pin controllers extract_dts_includes.py extracts two data sets:

PINCTRL_CONTROLLER
For all pin controllers that are referenced in a pinctrl-x directive PINCTRL_CONTROLLER defines are generated.
PINCTRL
For all subnodes of pin configurations referenced by active client nodes, pinctrl-x(&xxx, pinconf_a, ...), PINCTRL defines are generated. The pinctrl references the PINCTRL_CONTROLLER given in the pinctrl-x directive. The pinctrl also references the PINCTRL_STATE the pin controller associates to this pinctrl.

Generic library for PINCTRL driver implementation
To simplify driver implementation a library for the hardware independent pinctrl driver functions and all driver data structures and content is added.
The pin controller library provides the equivalent to a C++ template for pin controller driver implementation. The template parameters are given by simple defines. The template is expanded by the C preprocessor with the help of the CHAOS preprocessor macro library. The template generates the appropriate data structures and fills them using the information provided in generated_dts_board.h.
The library fully encapsulates the macro usage. The whole functionality is controlled by a set of simple defines. No knowledge of CHAOS is necessary to use the library. The usage of the PINCTRL library itself is also optional. The same result may be achieved by a python script that generates C code.
Preprocessor Macro Library
To allow for sopisticated C macros without the risk of too many usage faults the CHAOS preprocessor macro library is added. It is a header only library.
STM32F0 Driver Implementation

New STM32 PINCTRL driver

New STM32 GPIO driver using the pinctrl driver as a backend

STM32 SPI driver update to take parameters from device tree

Testing
Samples were executed sucessfully on the NUCLEO F091RC board:

hello
basic/blinky
basic/button

Driver tests were also executed on the NUCLEO F091RC board:

tests/drivers/gpio/gpio_basic_api
tests/drivers/spi/spi_loopback
tests/drivers/uart/uart_basic_api

Unit tests were created and executed for:

tests/unit/scripts/extract_dts_includes
tests/unit/drivers/pinctrl

Transition Strategy
Pinctrl Driver
The pinctrl interface and driver is independent from other drivers.
STM32F0x is switched to the pinctrl driver. Others may switch at any time.
Other Drivers
Strategy is to have two driver variants during transition time. The new/enhanced driver is started as a pure copy of the current one to enable easy tracking of changes. After all driver users have switched to the new driver variant it should replace the current one and only one driver should be there to maintain.
Patches

PINCTRL driver interface and related GPIO driver interface

drivers: pinctrl: Add pinctrl driver interface

Extraction of PINCTRL and related info from device tree
(with some preparatory work)

dts: bindings: add generic binding for pinctrl devices
dts: bindings: extend device bindings by pinctrl
scripts: extract_dts_includes.py: factorize globals for module usage
scripts: extract_dts_includes.py: new pinctrl and related directives

General tools/ libraries for pinctrl driver implementation/ test/ documentation

ext: lib: Add Chaos preprocessor library
ext: lib: Update build system to support Chaos preprocessor lib
cmake: dts: allow default dts bindings dir to be overwritten
doc: sphinx: Add Pygment lexer for DTS (#6397)
doc: doxygen: predefine DOXYGEN to enable ifdef guards for docu

Library to support driver implementation using device tree info

drivers: add driver library

Library specifically for pinctrl driver implementations

drivers: pinctrl: add pinctrl driver library

STM32F0 pinctrl driver implementation as proof of concept

drivers: pinctrl: Add STM32 pinctrl driver and DTS

STM32F0 GPIO driver with PINCTRL driver backend as proof of concept

drivers: gpio: Prepare STM32 GPIO driver with pinctrl backend
drivers: gpio: Add STM32 GPIO-PINCTRL driver and DTS

STM32F0 SPI driver with device tree support as proof of concept

drivers: spi: Prepare STM32 SPI driver with pinctrl DTS support
drivers: spi: Add STM32 SPI driver with pinctrl DTS support

STM32FO device tree

dts: STM32F0: extend gpio, spi, i2c, pinctrl nodes

STM32F0x based boards configuration set to pinctrl as proof of concept

boards: STM32F0x: switch to usage of pinctrl, gpio-pinctrl

Testing - Unit Tests

test: scripts: extract_dts_includes.py pinctrl directive
test: drivers: unit test pinctrl lib API

Testing - Drivers

tests: drivers: gpio: support NUCLEO F091RC and F030R8 boards
tests: drivers: spi: support NUCLEO F091RC board

Testing - Samples

samples: button: support gpio device with pinctrl backend

Documentation

doc: api: add pinctrl and gpio-pinctrl interface
doc: pinctrl: Add pinctrl driver documentation
doc: pinctrl: Add STM32 pinctrl driver documentation
ext: lib: Add Chaos preprocessor library documentation
ext: lib: Fix typo in Chaos preprocessor library documentation
doc: subsystems: Add Chaos preprocessor library documentation
doc: boards: update NUCLEO F091RC doc

Todo

-- NEXT --

todo: squash xxx-prepare patches after acceptance
todo: mark internal functions @internal
todo: indent parameters properly (indent against last '(' + 1 space)
todo: doc: Improve usage documentation for GPIO
todo: doc: chaos: convert tables from xml
todo: doc: chaos: provide all information of derivated macros
TBD: pinctrl: constify some references in the pinctrl interface

Change History

2018-02-25

extract_dts_includes: handle compatible directive
driver_lib: added macros for check against compatible directive
kconfig: replaced GPIO_LEGACY_API config by check against GPIO compatible string
spi_stm32: guarded driver source compilation by compatible check and squashed DTS and driver patches
pinctrl_stm32: guarded driver source compilation by compatible check and squashed DTS and driver patches
gpio_pinctrl_stm32: guarded driver source compilation by compatible check and squashed DTS and driver patches
pinctrl: moved kconfig pinctrl infrastructure setup to STM32 pinctrl driver patch.
boards: NUCLEO F030R8: fix spi requesting the same pin as usart2

2018-02-21

boards: completely switch STM32F0x boards to pinctrl (removed any board specific pinmux.c)
pinctrl_stm32: fix gpio data initialization if intermediate GPIO is missing (e.g. GPIOE of STM32F030)
doc: chaos: fix file open with pathlib object in python 3.5 in chaos_pp sphinx directive
doc: chaos: sort documentation files before generating documentation

2018-02-20

driver: Add generic driver implementation support macro library driver_lib.h
pinctrl: Add convenience functions to distinguish function numbers for device and pinmux.
spi_stm32: Generate driver variant spi_stm32 for STM32F0x and keep stm32_spi_ll for all other.
gpio_pinctrl_stm32: Base driver on gpio_stm32 to allow easy tracking of changes.
gpio: Use GPIO_LEGACY_API kconfig similar to SPI
doc: Generate CHAOS preprocessor lib documentation by sphinx directive
doc: Support DTS in code-block directives, fixes #6029

2018-01-28

dts bindings: extend generic bindings for pinctrl, gpio-pinctrl, and spi to make the device-controller directives mandatory.
dts bindings: extend STM32 specific bindings for pinctrl, gpio-pinctrl, and spi to include the device-controller directive.
extract_dts_includes: extract device-controller directives
extract_dts_includes: unit test also device-controller directive extraction
pinctrl_lib: make checkpatch happy about some unusual macros.
pinctrl_lib: make enable mux request a library parameter.
pinctrl_stm32: use the pin-controller directives. This obsoletes the respective defines in soc.h.
gpio_pinctrl_stm32: use the gpio-controller directives. This obsoletes the respective defines in soc.h.
gpio_pinctrl_stm32: no need to check for active nodes anymore, the information is now provided by the gpio-controller directive.
spi_ll_stm32: use the spi-controller directives. This obsoletes the respective defines in soc.h.
stm32f0: gpio: added st,bank-name DTS directive to get a port (bank) indication that is independent from the label directive.
stm32f0: moved default configuration to Kconfig.defconfig.series
nucleo_f091rc: moved default configuration to Kconfig.defconfig
nucleo_f091rc: made documentation updates a separate commit
doc: updated pinctrl and gpio usage docs to describe new device-controller directive usage.

2018-01-24

Initial PR

Signed-off-by: Bobby Noelte<EMAIL_ADDRESS>

The chaos preprocessor documentation should not be part of the Zephyr project.  I'd recommend the very old https://github.com/rofl0r/chaos-pp repo is the place for this documentation, and it would be easy to publish the build_docs folder as a github pages site that we can refer to as needed.  It also looks like this patch is updating the chaos documentation too, which would be better done there (or in a new repo if that repo has been abandoned).  Right @nashif ?

@dbkinder @nashif

The chaos preprocessor documentation should not be part of the Zephyr project. I'd recommend the very old https://github.com/rofl0r/chaos-pp repo is the place for this documentation.

I created a sphinx directive that converts from the CHAOS xml documentation to restructured text (not pushed yet) that can be included in the Zephyr documentation without too much documentation bloat. Maybe this is a viable option.
Anyway I would love Zephyr to set up a policy how to handle (external) documentation.
If Zephyr is still targeting safety and security certification configuration management has to be done for source code and documentation. In my experience in assessing and certifying safety software you have to be able to keep the source code and the associated documentation in sync. There may be several methods to achieve that and you may restrict this to the safety/security core that is for certification. If pinctrl gets accepted some macros of CHAOS will definitely be part of the safety core.  A Zephyr user in the safety context will have to also collect all relevant documentation when he freezes the code base and documentation for certification. An "unversioned" link does not really help for configuration management in this case.
For me Sphinx directives are a good way to handle external documentation with some logic behind. In the directive script you can even download a versioned documentation set and add it to the Zephyr documentation. This way you have documentation and source code in sync and you are also able to reproduce a specific baseline for e.g. certification later on.
I also think CHOAS has the potential to replace the mostly undocumented code-generation macros in include/misc/util.h.
Just my thoughts. Waiting for your decision.
Bobby

@galak
hope we can break some of this up
I plan to keep this pull request as the master pull request and generate some RFC pull requests that only contain specific commits. This should ease and focus comments/ review to specific aspects. @erwango already suggested this:
RFC: pinctrl - driver interface
pinctrl driver interface
pinctrl driver infrastructure
pinctrl api documentation
pinctrl usage documentation
RFC: pinctrl - extract dts includes
Generic device tree bindings for pinctrl and other devices
extract_dts_includes.py
unit test for extract_dts_includes.py
RFC: pinctrl - pinctrl driver library
pinctrl driver library
unit test for pinctrl library
RFC: CHAOS preprocessor library
CHAOS preprocessor library
CHAOS library documentation
RFC: pinctrl - STM32F0 proof of concept implementation
STM32 pinctrl, pinctrl-gpio, spi drivers
NUCLEO F091RC
Tests
Is this ok for you?
understand better what some of the tools you've pulled in do.
There is only one tool pulled in: CHAOS - a preprocessor library. It is only used in driver implementation but not in any interface. Drivers could also be implemented without CHAOS as mentioned. It basically provides some nice macros for recursion and conditional expansion.
I extended extract_dts_includes.py. I tried to make the change minimal invasive but had to shift some of the functions and data to a global python module. The functions and data is shifted but not changed.

I think that's a good start.  Was going to ask @erwango about his thoughts on updating and moving the DTSs to at least contain the pin info per linux pinctrl binding.

@lpereira

The proposed API seems to consider that only 32 GPIO pins will exist.

The library assumes a maximum of 32 pins per GPIO port. The SoC may have an undefinite number of GPIO ports.

In general and without looking too much into the details I like this...

You are right, only a small subset of the chaos-pp library is used. I was searching for better alternatives with an appropriate license but could not find one. For me it is a litlle bit like the HALs

well, it is not like a HAL. If we switch to this, it will be a core dependency, a major one and will be used by everyone, so it might end up as non-optional, given the license and the fact it is a huge piece of software, this might be a problem.
We have been using python for generating code, did you look at this as an alternative?

In general and without looking too much into the details

Ok, let´s sort out - what is the problem:

I don´t like Macros
I don´t like Mondays
Macros are error prone
That is what libraries like CHAOS are for, prevent errors by using something already working.
The license
CHAOS is licensed "Boost Software License - Version 1.0". Basically you can do anything with the software. So no problem. This was one major reason to choose CHAOS.
The CHAOS code base is too big. Only a small part is used.
As this is no technical problem, it may become a maintenance problem. CHOAS as a header only macro library does not induce anything into the final code. No maintenance needed for unused macro code. Still there is a big part of code sitting around that may be used und gives some risk, but this is the same with other libraries.
CHAOS is not in wide spread use
This is true, but in itself it doesn´t say anything about the code quality. But it is a risk.
The same can be achieved with a X (e.g. python) without using CHAOS.
This is always true but doesn´t help. In my view Zephyr with it´s philosophy needs sophisticated support for compile time configuration  (vs. Linux that does a lot at boot time). To gain flexibility and freedom in compile time configuration you need more than just a predefined code generation (which you can do using a python script); you need a kind of compile time configuration "language".  So you ether make the python script more complex by adding a compile time configuration "language" to be parsed by it or you take the macro approach and you create the language on the C preprocessor side.  On the C preprocessor side you do not have to invent the "language" basics and the "language" is automatically parsed during compilation, that is why I have chosen this approach. You still have to add features to the "language" which I have done using CHAOS as a more elaborate basis. So, yes I "did ... look at" python "as an alternative" and came to the solution I need both. The python script does the basic work of generating the configuration data from DTS, and CHAOS is used as one basis to get the "language" features I assume to be necessary.

Looking at the above I can think of the following solutions:

compile time configuration "language" (python vs. C preprocessor) (ad. 6)
This should not be a X vs. Y. The Zephyr infrastructure should be expanded to allow for several solutions to be plugged in. After a review process the most appropriate solution(s) should be selected. This way innovation is supported.
CHAOS as macro library for the compile time configuration "language"

Use it as it is (ad 4, 5)
My favourite !-) The maintenance risk is in my view acceptable due to the nature of the header only library. If anybody uses a macro that was not used before a test has to be done anyway.  All macros are documented. The documentation can be integrated into Zephyr.
Reduce code base (ad 4)
Only take the header files that are necessary for the compile time configuration "language".  Has to be done by somebody that really knows the internals. That is just what  I wanted to avoid. A lot of effort for no technical benefit.
Use another macro library (ad 4, 5)
I was searching the internet for alternatives. The major thing is the license, the alternatives are usually licensed GPL, which is not acceptabel to Zephyr.
Write your own macros (ad 4, 5)
Basically that is what I have already done. The driver implementer uses the macros from driver_lib.h and pinctrl_lib.h. These macros completely hide CHAOS. But there is still CHAOS and the C preprocessor behind, which provides the flexibility to create new "language" features or just find a specific solution for this specific driver.

Thx.
Bobby

Major changes as of 2018-02-21/25

The compile time configuration "language" is now defined in driver_lib.h. @erwango hope that simplifies configuration. @tbursztyka do you need more abstraction as you wanted to get rid of DEVICE_AND_API_INIT alltogether? You may have a look at one of the drivers to see the current approach.
The compatible directive is now also extracted from the DTS. This allows to do a compile time compatibility check by DRIVER_COMPATIBLE. Using the macro as a guard around the source code could replace a lot of Kconfig and allows to fully control the instantiation of drivers by the DTS. All proof of concept drivers are already guarded by  DRIVER_COMPATIBLE.
The STM32F0x are now completely switched to PINCTRL.
The CHAOS documentation can now be retrieved by a sphinx directive. @dbkinder this reduces the documentation size, but not the content. Maybe this is a viable way if CHAOS is accepted.

Thank you for your comments. I hope I addressed all of them. Some are not implement by now. Please see the TODO list for them.
Please review.
Thx.
Bobby

You'll really need to split-up your RFC as requested previously.
Also, I see very interesting stuff done in extract_dts_includes.py that could be part of a stand-alone PR (global stuff and DTDirective class).
The DEVICE_ macro removal is about future stuff that are really not going to happen soon.
I understand your point on chaos_pp, it was your choice on on pinctrl (which is probably one of the less trivial to get generic properly) but the problem is chaos_pp itself as noticed earlier by others: there might be better/easier solutions. Morever other devices are not as complex to initialize as pinctrl ones.

@tbursztyka

but the problem is chaos_pp itself as noticed earlier by others: there might be better/easier solutions.

Would cogapp.py https://nedbatchelder.com/code/cog/ be a "better/easier" solution?
It is a python script that executes python code that is embedded in source files, which in turn generates C code that is inserted into the source file (or another file). The idea is that extract_dts_includes.py generates the header file and the key value file. Within the python part of the source file the keyvalue file is read in and the C code is generated by the python snippet in the source file. CMake will be expanded by a rule that converts *.cog" files to *.c" files using cogapp.py. The benefit is the generated code is visible and the compile time configuration language is python. cog is available by pip3.
It would be nice to get some pre-evaluation of the concept before I again invest a lot of time in a solution.
Thx.
Bobby

@b0661 Let's discuss tooling issue in #6293 I don't know if an external module or the standard Template one would do. (cog seems to be able to embed python in the template at least)

@galak

Does #6760 cover this PR, ie can we close this one?

#6760 is a cut-out of this PR. Here it is shown that it all fits together - this is a proof of concept.


Running AppSource Validation with AppSourceCop - Missing File

Describe the issue
Iam trying to run ALValidation with AppSourceCop to get my .app ready for AppSource. ALValidation and AppSourceCop is starting perfectly, but AppSourceCop throws an error that a certain file is missing. I dont understand atm what this file is doing and how to fix the error. Please help.

Thank you a lot.

I cannot see the script / the image.
This is likely caused by a wrong parameter value, so I would need to se how you call the function?

$validationResults = Run-AlValidation
-licenseFile "license.flf"     -previousApps @( "" )
-apps @( "localpath/file.app" )     -validateCurrent
-countries "de"     -affixes "xyz"
-supportedCountries "de"`

Reformatted your message.
If you don't have any previousApps, you should leave out the parameter.
Is localpath/file.app an absolute path?

Its like : C:\dir dir\Dir2\appfile1.17.201208.0.app
I think this is a relative path.

Needs to be absolute like:
C:\dir\Dir2\appfile1.17.201208.0.app

I have removed all spaces in the path. Error is still the same after rerunning the script with updated filepaths.

I need the full script and the full output - if you cannot print it here, you can email it to freddyk at microsoft dot com

I think this is caused by this issue: https://superuser.com/questions/1524767/powershell-uses-the-short-8-3-form-for-envtemp
I cannot repro this, but given this message, I have changed all occurances of $env:temp to a function, which doesn't used the 8-3 notation.
I will check this in and a new preview version should be available later this afternoon with this fix.

I will post a message here once a preview version is available and close it when a released version is ready

Shipped in 1.0.17


roscpp_core: 0.6.2-0 in 'kinetic/distribution.yaml' [bloom]

Increasing version of package(s) in repository roscpp_core to 0.6.2-0:

upstream repository: git@github.com:ros/roscpp_core.git
release repository: https://github.com/ros-gbp/roscpp_core-release.git
distro file: kinetic/distribution.yaml
bloom version: 0.5.23
previous version for package: 0.6.1-0

cpp_common

No changes

roscpp_serialization
* fix warning when compiling with -Wpedantic (#53 <https://github.com/ros/roscpp_core/issues/53>)

roscpp_traits
* fix warning when compiling with -Wpedantic (#53 <https://github.com/ros/roscpp_core/issues/53>)
* fix warning about unused parameters (#52 <https://github.com/ros/roscpp_core/issues/52>)

rostime

No changes

Waiting for other releases...


Use in conjunction with other video_player implementation

Describe the bug
I'd like to use FVP only for Linux builds.
For MacOS I'm fine with the default video_player implementation so i can just not include it in the register_with call.
For Windows, instead, I'm trying to experiment with the video_player_win package; this is sadly not possible since FVP implements all the interfaces at once, leading to the following error:
Plugin video_player:windows has conflicting direct dependency implementations:
  fvp
  video_player_win
To fix this issue, remove all but one of these dependencies from pubspec.yaml.

Please resolve the plugin implementation selection errors

Expected behavior
Some way to be more specific about which platform to include plugin-wise.

both fvp and video_player_win implement video_player, you must choose one, I can do nothing.

Maybe is possible to split fvp into a main core and some "addons" like fvp_windows, fvp_linux and so on, and one includes only the needed ones? idk maybe its just too complicated and out of scope

Maybe is possible to split fvp into a main core and some "addons" like fvp_windows, fvp_linux and so on, and one includes only the needed ones? idk maybe its just too complicated and out of scope

then the project will not be maintainable, because about 95% code are the same, the only difference is rendering code. what if a plugin supports all platforms and share the same code? i think it's a flaw of flutter. you can fork the repo and modify pubspec.yml to keep only linux platform

try master branch

Hi, it seems like just by adding fvp to my pubspec, even if i register it only to other platforms still activates on windows
registerWith(options: {'platforms': [ 'linux' ] })

flutter: AsyncSnapshot<dynamic>(ConnectionState.done, null, UnimplementedError: init() has not been implemented., #0      VideoPlayerPlatform.init (package:video_player_platform_interface/video_player_platform_interface.dart:43:5)
#1      _videoPlayerPlatform (package:video_player/video_player.dart:34:21)
video_player.dart:34
#2      VideoPlayerController.initialize (package:video_player/video_player.dart:440:25)

Do i nee to specify something else in the pubspec?
dependencies:
  video_player_win: # should take care of video playback on windows
  fvp:
    git: https://github.com/wang-bin/fvp.git

What's your flutter version? is the error same as fvp 0.28.0?

flutter: AsyncSnapshot(ConnectionState.done, null, UnimplementedError: init() has not been implemented., #0      VideoPlayerPlatform.init (package:video_player_platform_interface/video_player_platform_interface.dart:43:5)

no plugin is used, both video_player_win and fvp are not included. what about removing fvp in dependencies?

What's your flutter version? is the error same as fvp 0.28.0?

flutter --version
Flutter 3.27.1 • channel stable • https://github.com/flutter/flutter.git
Framework • revision 17025dd882 (4 days ago) • 2024-12-17 03:23:09 +0900
Engine • revision cb4b5fff73
Tools • Dart 3.6.0 • DevTools 2.40.2

No the error is different. Using the main version it fails the entire pub get phase. Using the master branch it successfully gets the packages but at runtime it is loaded anyway.
When i remove fvp from the dependencies video_player_win automatically kicks in and its used without any other code modification. Since the same project also compiles for linux it'd be perfect to leave it (fvp) there and expect it to just to be enabled for linux

what about removing registerWith?

platforms = [ "linux" ]
Platform.operatingSystem = "windows"
!platforms.contains(Platform.operatingSystem) == true # so enters the if

VideoPlayerPlatform.instance is a WindowsVideoPlayer before the assignment, after it gets the value of _prevImpl which is a _PlaceholderImplementation

_prevImpl should be null. can you find out when _prevImpl is set to _PlaceholderImplementation and show me the call stack from debugger?

you can use stack_trace package, or throw sn exception instead of print, then you can see call stack.
what about removing dartPluginClass lines in pubspec.yml? currently i only remove implements line. all these lines was added to register fvp automatically by dart_tooling generated code.

hm nop i'm just getting the trace below by throwing an exception there, maybe vscode needs some special configuration to debug dart code invoked by the plugin automagic thing.
flutter: `fvp` threw an error: Exception: Test. The app may not function as expected until you remove this plugin from pubspec.yaml

By commenting out the line with dartPluginClass for windows it is not called twice and _prevImpl is null when I manually call registerWith. The application then works as expected by not registering it for the windows platform (since its not in the list)

another try: do not remove dartPluginClass lines, but change if (_prevImpl != null) to if (_prevImpl != null && VideoPlayerPlatform.instance is MdkVideoPlayerPlatform), it should also work.

This way the first round of registerVideoPlayerPlatformsWith invoked by the plugin thing still executes fine, the second round invoked manually by registerWith does not satisfy the if and does not override VideoPlayerPlatform.instance so it works fine if the platform is not specified in the list. Specifying the platform in the list instead makes the previous if fail and let the function continue normally.
Little sidenote: in android this dual invocation appears not to occur, idk why but on my invocation of registerWith, _prevImpl is still null.
Anyway this seems to be the intended behaviour. Awesome :)

Little sidenote: in android this dual invocation appears not to occur, idk why but on my invocation of registerWith, _prevImpl is still null.

because official implementation is preferred, so I didn't add dartPluginClass for android and not auto registerWith


Merge multiple images to one sprite

Hello guys,
I recently wanted to create a character designer, where you choose your body in different colors and then choose beards, eyes, clothes, etc, like in https://sprite-generator.herokuapp.com/#
In Kaboom you can only load one image for any sprite, so you would have to create images for all possible characters combinations to be able to load them eventually.
So I extended loadSprite and loadSpriteAtlas to accept an array of url-strings and merge them together to one image, which is then treated as usual.
I created the demo (spriteMerged) where you can see two sprites (body and armor) and then the merged one and can move them.
Greetings

The mergeImg-function is definitly more intuitive than the array.
Should I remove the array-parameter from loadSprite and loadSpriteAtlas? Because it saves some code, if you know the trick.
And in both function, you can give only one sprite name, so it should be clear, that the result is one sprite. Only the way the function does it, is not obvious.
I think the #410 is perfect for a swinging sword or shield and in this case, I would use two different loadSprite-calls.
But if you have a hat, which is "walking" with the character, always stick to the same walking frame and changes it looks the same way as the characters frame, I think the rendering is faster, if you don't use the gameobject-tree and instead merge the images.
And in the sword case, you maybe want a different colliding behavior, than the hat-case. So the objectgame-tree makes more sense.

You're right, if you don't need other things merging would be a better way.
What I'm not sure about is if this should be core function bundled into kaboom, or should it be a third party helper 🤔

I removed the changes in loadSprite and type SpriteLoadSrc, exported the mergeImg-function and updated the example.

What I'm not sure about is if this should be core function bundled into kaboom, or should it be a third party helper 🤔

Imho, if you don't include this function, the only "standard" option will be the gameobject-tree. Which will result in the example case (https://sprite-generator.herokuapp.com/#) in an object-tree with over 25 childs for character.  (I know, that this will not be the standard case)
So hopefully, the developer thinks of a better ways to do it and checks in documentation, that the src-Attribute of loadSprite also accepts GfxTexData which itsself consists of ImageData. Now he has the option to search for an third party helper or write the merge-function by himself.
Long story short, I think, many people thinking about an alternative solution, will not find the fitting third party helper fast enough or think about the existance for this little specific function and stick to the tree, if they don't find a well documented function or an example, where they see this option.
Maybe, if you provide a way to let these third party-helpers present themselves with examples near your kaboom documentation, like your "Playground".

I see, I thought it's more of a niche use case but maybe it's more common than I think. I think keep it in a demo would be a good for now 👍

Should I change something in my code?

Yeah, can you move the mergeImg function to demo/spriteMerged.js?

I have reverted my changed files and moved mergeImg to demo/spriteMerged.js


Look at making the middleware counters per app instance

Currently each session creates a server object which creates a counter object.  Some of these servers instance are not actually booted up but instead requests are served by an existing server object.  This results in sessions that query the incorrect counter to see that requests have ended.  If we make the counter tied to the app instance and accessible based on that  it would potentially solve this issue.

Doing this may actually end up creating deadlocks during reset of sessions with multiple sessions accessing the same server - not sure if this is a good idea or not -- one way around it would be to split resetting the session and waiting for the requests to all finish - so that all sessions could first be reset and then wait for all the sessions requests to finish


Do not works with PHP 7.2?

After installing and login succesfully I get
ErrorException in 848f5cb076f09c2c022ca47012713908eaad38c7.php line 33:
count(): Parameter must be an array or an object that implements Countable (View: /var/www/html/test/test1/vendor/crocodicstudio/crudbooster/src/views/sidebar.blade.php) (View: /var/www/html/test/test1/vendor/crocodicstudio/crudbooster/src/views/sidebar.blade.php) (View: /var/www/html/test/test1/vendor/crocodicstudio/crudbooster/src/views/sidebar.blade.php)
I read some threads somewhere were exist a workaround from sidebar.blade.php, but then the problem is in vendor/crocodicstudio/crudbooster/src/views/default/table.blade.php.
Exist some way of fix them?
Thanks.

me too

me too

Hi, I'm havin this issue on php 7.4. is there any updates or fixes for it?


Support file loader?

I use it in pair with uvu to transpile typescript. When I'm trying to test a file than imports, for instance, a png file (which is set up as --loader:.png=file in my esbuild cli), node throws with
TypeError [ERR_UNKNOWN_FILE_EXTENSION]: Unknown file extension ".png" for /blabla/star.png
    at defaultGetFormat (internal/modules/esm/get_format.js:71:15)
    at getFormat (file://node_modules/esbuild-node-loader/loader.mjs:162:10)

It's obviously not a problem of this loader, but I'm stuggling to understand how to properly apporach it. Since esbuild supports file loader, maybe it makes sense to somehow support it inside this loader? Or it's better to chain loaders via https://github.com/lukeed/loadr and provide some fake one for certain extensions. I'd appreciate some guidance

@saitonakamura
AFAIK,

Similar thing

http protocol
https://github.com/antfu/esbuild-node-loader/blob/main/loader.mjs#L100
add new extension .mts
https://github.com/antfu/esbuild-node-loader/blob/main/loader.mjs#L10

There is not yet able to chain loaders, written nodejs v1 and v2 api loader api

Oh, that was dumb of me to assume it worked. I only tested with a single loader.
Thanks, will revisit later. Hopefully it'll be part of the redesign.

Maybe someone can chain up multiple custom loader api, expose to one v2 loader api? Have't seen one yet.


[WIP] Increase Brokers and Triggers for CI test

Signed-off-by: Pierangelo Di Pilato<EMAIL_ADDRESS>

/test 410-br-p10-r3-ord-upstream-nightly-aws-ocp-410

/retest

/test 410-br-p10-r3-ord-upstream-nightly-aws-ocp-410

Hyperfoil controller API responded with 504 while checking for termination:
Doing request /run/0000/stats/total
Traceback (most recent call last):
  File "./bin/run_benchmark.py", line 213, in <module>
    await_termination(run_id)
  File "./bin/run_benchmark.py", line 169, in await_termination
    while is_terminated(run_id) is False:
  File "./bin/run_benchmark.py", line 181, in is_terminated
    info = get_run_info(run_id)
  File "./bin/run_benchmark.py", line 110, in get_run_info
    raise Exception(f"failed to get run info, status code {response.status}")
Exception: failed to get run info, status code 504

/test 410-br-p10-r3-ord-upstream-nightly-aws-ocp-410

subscription.operators.coreos.com/hyperfoil-bundle created
error: state is not found

Hi @rvansa @willr3 is the high memory consumption of the Hyperfoil cluster controller expected? https://github.com/openshift-knative/eventing-hyperfoil-benchmark/pull/52#issuecomment-1165737053
We have at least 100 pods connected to the Hyperfoil cluster controller, each sending metrics every second, what would you recommend to lower memory consumption?

  * could not initialize namespace: couldn't create secret registry-pull-credentials: secrets "registry-pull-credentials" is forbidden: unable to create new content in namespace ci-op-5t43dh6n because it is being terminated
  * ```
/retest-required


Sonarqube Workflow Configuration

IMPORTANT: Where possible all PRs must be linked to a Github issue
SonarQube integration for the static analysis of code quality
Engineer Checklist

[x] I have written Unit tests for any new feature(s) and edge cases for bug fixes
[x] I have added any strings visible on UI components to the strings.xml file
[x] I have updated the  CHANGELOG.md file for any notable changes to the codebase
[x] I have run ./gradlew spotlessApply and ./gradlew spotlessCheck to check my code follows the project's style guide
[x] I have built and run the FHIRCore app to verify my change fixes the issue and/or does not break the app

Code Reviewer Checklist

[ ] I have verified Unit tests have been written for any new feature(s) and edge cases
[ ] I have verified any strings visible on UI components are in the strings.xml file
[ ] I have verifed the CHANGELOG.md file has any notable changes to the codebase
[ ] I have verified the solution has been implemented in a configurable and generic way for reuseable components
[ ] I have built and run the FHIRCore app to verify the change fixes the issue and/or does not break the app

@ndegwamartin is there a place/way to see the results of the check presented? Also there's this warning/error from the run, not sure if it matters
Unable to import Android Lint report file(s):
- /home/runner/work/fhircore/fhircore/android/quest/build/reports/lint-results-questDebug.xml
The report file(s) can not be found. Check that the property 'sonar.androidLint.reportPaths' is correctly configured.

@pld yeah the results are currently available via the portal of the internally deployed SonarQube instance. I can share the dets via DM . The idea is to have the reports exported and available on an instance of DefectDojo for efficiency in management.
Additionally, it is possible to have SonarQube decorate the PR with the vulnerabilities found per PR but we probably don't want those public until we fix them cc @bonfaceshisakha

@ndegwamartin is there a place/way to see the results of the check presented? Also there's this warning/error from the run, not sure if it matters
Unable to import Android Lint report file(s):
- /home/runner/work/fhircore/fhircore/android/quest/build/reports/lint-results-questDebug.xml
The report file(s) can not be found. Check that the property 'sonar.androidLint.reportPaths' is correctly configured.

Looks like it might be picking the file path of the wrong variant, we can set that explicitly in the gradle properties file once we determine what the correct one is. Probably lint-results-questRelease.xml
Also note, since it is a Warning level log it could be one of the paths that was tried and failed but eventually got the correct one.

yea true true, if the results are coming through, this doesn't really matter, we can revisit it after the kts conversion pr is merged AND it's actually problem