Adding Skip-forward ▶ and Skip-backward ◀  to timeline 📅

Is your feature request related to a problem? Please describe.
While using the website to scroll on the timeline to see past or future date records, there is no button to click for going to the previous or next day. Going to the previous/next date is possible only in two ways:

Clicking on the date 📅 below the FastForward button.
Pressing previous/next keys from the keyboard. ( P.S ~ I realised this only when I check the code ) ⌨

Describe the solution you'd like
A Skip forward ( ▶ ) and Skip backward ( ◀ ) button will be added to the Timeline component. Upon clicking on those buttons, users can navigate to previous or next dates.
Describe alternatives you've considered
The alternatives to the solution is by the two possible ways mentioned above. The feature I am trying to add will be the cherry on the cake! 🍒 😄
Additional context
I made the changes in my forked branch and the video 🎥 for same is attached below.
https://user-images.githubusercontent.com/43433334/119225322-b8e07f00-bb20-11eb-9340-b4624121c37e.mp4

@shuklaayush Can you please

@shuklaayush Tagging you here as I saw the Timeline ⌛ component is developed and maintained by you.
Let me know if I can add this feature?

@malay-satapathy Appreciate the request, but this doesn't seem to simplify things. On the contrary, it'll probably add more redundancy. If I have to click on the skip-forward button now to go to the next date, why won't I just click on the date itself?

@shuklaayush Agree with your rationale! It will just increase the cognitive load on the end-user using the application.
I had another feature improvement for the Timeline component. The speed of transition from one date to the end date is slow! We can have speed controls for dates transition. What do you feel about this enhancement?

I think the transition is slow because of the heavy rerender. If you switch between dates quickly without stopping at a date, the transition should be smooth. If you can somehow reduce the rerendering time though, then that would be really welcome.
Also, one can always use the calendar to switch between dates that are far apart.


[release-v1.14]: Watch only our own OIDC-related secrets (#8070)

This is a backport of https://github.com/knative/eventing/pull/8070 to ensure that we use a filtered informer for our own OIDC-related secrets to reduce memory usage.

/cc @matzew @pierDipi

/test 412-test-encryption-auth-e2e-aws-412


Accessibility improvements for top navigation

Description:
Add aria-label attributes to navigation links for screen reader users.
Also add aria-label attribute to "DDOT" navigation link for proper pronunciation.

After discussion with @CR96 on #89 and #91 as well as some A11Y testing in Firefox, we were able to confirm that the top nav links have sufficient context for assistive devices.
Closing this out.


🐛 BUG: Wrangler pages fails to deploy

Which Cloudflare product(s) does this pertain to?
Pages, Wrangler
What version(s) of the tool(s) are you using?
3.97.0 [Wrangler]
What version of Node are you using?
Deno 2.1.4
What operating system and version are you using?
Mac Sequoia 15.2
Describe the Bug
Observed behavior
When deploying to pages via npx wrangler pages deploy dist --project-name=project, wrangler fails at some point when configuring unenv. Not sure why it's trying to load the package.json from the dist subdirectory when it's actually in the parent folder.
Expected behavior
Wrangler should upload pages projects.
Steps to reproduce
Please provide the following:

Try to upload any pages project with wrangler deploy

Please provide a link to a minimal reproduction
No response
Please provide any relevant error logs
✘ [ERROR] ENOTDIR: not a directory, open '.../node_modules/unenv-nightly/dist/index.cjs/package.json'

Thanks for reporting this! We're investigating—in the meantime downgrading to Wrangler 3.96.0 should be a workaround


Feature: picker active state on devtool UI

Currently, devtool  doesn't reflect picker state on EditorInspectorButton.
I think It would be better if it reflects pickerActive state on UI.

For example:
https://github.com/facebook/lexical/assets/40269597/cf114ea3-1cb0-4ee5-a0c9-4c9eaaba4405

@StyleT Hello ! Can I solve this problem ?

@H0onnn Hi I worked this on #6077 😿

Closed with https://github.com/facebook/lexical/pull/6077 will be released with the next extension update


New release

The current release is pinned to base (>=4.6 && <4.10). Please make a new release on Hackage.

I've updated it to >= 4.8 && < 5


Work with Mailers

Wouldn't it be nice if all the methods are also made available in the Mailer?

+1

We implemented a branch for that. So please point to this branch:
gem 'decent_exposure', github: 'decent_exposure', branch: 'expose-to-mailers'

I tested in a dummy application and it seemed to works fine. Please test this and let us know, so we can release a new version.
By the way, the current version of decent_exposure uses a method like #{expoded_thing}_params, so you'll need to set in the mailer instance your params. Check this:
class PostMailer < ApplicationMailer
  attr_accessor :post_id

  expose :posts, -> { Post.last 5 }
  expose(:post, id: -> { post_id })

  def best_posts_ever(post_id = nil)
    self.post_id = post_id
    @greeting = "Hi"

    mail to<EMAIL_ADDRESS>  end
end

Post#best_posts_ever

  <%= @greeting %>, find me in app/views/post_mailer/best_posts_ever.html.erb
  Single Post = <%= post.inspect %>
  Post List = <%= posts.map(&:inspect) %>

Fantastic! That was easy. Thanks!

Super! Thanks for your lightning fast response.


Prevent vertical offset in IE 11

Fix https://github.com/twbs/bootstrap/issues/29245

I think a line-height: 0 would be more flexible than a fixed value here.

Thanks to IE 11. This is a breaking change for many.

Thanks to IE 11. This is a breaking change for many.

Please open a ticket with a demo if this is the case.


[SMALLFIX] Improve documents in docs/cn/index.md

Improve documents in docs/cn/index.md.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/19353/
Test PASSed.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/19418/
Test PASSed.


Fix & break up the test for Part 01 Step 05

Unit tests for Part 01 Step 05 need to broken down to one error per test and the test need to be update to cover all lines of code.  Fix Spotbugs issues as well.

[x] Break up test
[x] Added additional tests
[x] Verified to latest version issued June 24, 2021 Specification


Adds Django 3.0 support

Hi, I saw that @smendes has submitted similar PR #8, but here's the fix that would with any supported Django/Python combination.

ah nice, I'll merge this one thanks!

hey, thanks for the quick merge!


add updrive

The previous commits have some problem, now I have fixed it. #426

I think 426 did the trick. Closing.


Bite 1142

Adds functionality for consul and vault packs to self-configure on top of namespace token creation functionality added in bite-1116.
Validation:
In terraform.tfvars:
st2_branch="bite-1142"
ansible_branch="bite-1142"

Build cluster.
Run bitesize.create_ns action to create a namespace of your choice:
https://stackstorm.mdev.prsn-dev.io/#/actions/bitesize.create_ns/general
Note that read and write tokens are created for both consul and vault and stashed in kubernetes secrets in your new namesapce:
kubectl get secrets --namespace=<your_ns>

See bitesize/bite-1142 PR.

LGTM !

LGTM


Slovenian translation

Helo, guys!
Since i use this card with joy, i translated it to my local language.  Since i'm not skilled in github i don't know what to do to upload new files (two of them: sl.json and sensor.sl.json from translations folder), so some guidance would be nice. I can, say, send them to someone's email, too.
Thanks!

If you want to learn how to contribute to github (could be fun), then you can find some videos or blogs describing that.
In a nutshell, you create a fork - that would basically make a snapshot of the project and make it your own repository.
Then you make the changes - typically you'd make a branch and you add or change the files and commit the changes.
And then you create a pull request to pull it back to the base repository. I'll be notified (similarly to how I got this question), I'll review that, confirm the merge and it will become part of the next release. And you'd be officially the contributor.
If this does not sound like fun, you can just upload them somewhere online (you can even create them as (GitHub Gists)[https://gist.github.com/] and send me the links, I will copy them over manually.
Thanks for your help.

Well, i did "something"...
check out if it's ok...

I see that you already did the update...thanks!
in the meantime i wonder: are language files in folder www/community/garbage-collection-card now obsolete? I've had words "today" and "tomorrow" translated there, but i think that after last update they stopped working (that's why i digged into it and translated whole thing, not just those two words). I gues that you moved language files on new location with latest update, correct?

I do not think they are. The integration does not really deal with the front-end, so the translation is for the configuration. And in case you use verbose state for the today/tomorrow state.
But if you use the garbage collection card, that one has own localization for the front end and is maintained by @amaximus. And in such case I do not think you use the verbose state anyway.

Aha... i think that i "messed up" two different things: your integration and amaximus's custom card. Currently i don't use his card, but i rather use  "custom button card".  And i use verbose mode.
Now it's all clear. Thanks!


[Frontend] Admin Login and Signup Page

There would be a login and signup screen only for admins so in this PR.
We need the Frontend pages for

Login
Signup

@Kajol-Kumari I wanna work on this.

Sure @Aaryan8751 you can go ahead with it.

@Kajol-Kumari I have added the login and signup front-end. The pull request is merged with Issue#10.

Here is the screenshot of the login and signup front-end.

Closing via this PR


Support endpoint for modifying playlist details

I added support for the API endpoint here which allows for the modification of playlist details such as the name and whether the playlist is marked as public and/or collaborative.
I also did some general cleanup. In a few cases, this included modifying args defaulted to mutable values (mostly arg=[]) to avoid the pitfalls described here.
Please review: @plamere

@plamere I needed this change in my project here. Would you mind taking a look at this PR?

@plamere bump

Hey Nathan ... this is looking good. I'd be extra pleased if you could include an example in the examples dir that show how someone could use the feature, and extra points too if you added a test.

Any news on this PR? I'm switching to @nathancoleman branch while this isn't merged.

@carlosedp I just need to add some tests and an example use case. I should be able to get that done today.

@plamere I've added an example use case. A test for this endpoint would require someone maintaining a playlist strictly for running the test and then having the test run as the playlist owner, so I have not included a test for this change. Please review.


Blender 4.0 is not listed

This is solved now. Sorry, this program is not reproducible at all as we are just consuming a service.


Failed to install 'cordova-plugin-filepicker':TypeError: path must be a string or Buffer

While deploying to ipad facing this issue even in the sample demo application it is failed in deployment with the error mentioned above

How did you install the plugin?
Cordova CLI version?

Try with latest version.


Noisefield

I cherry-picked some commits from the measure branch

these commits were reviewed favorably in the other PR, so I'll go ahead and merge


How to mint reserved tokenIDs for specific addresses with ERC721A

I have a collection where my whitelist with around 200 users will hand pick the tokens they want before the contract is deployed
They will pay zero fee for the minting, only the gas price
Since ERC721A does not implement the mint function with a tokenID (amount instead) there is no straightforward way for me to deliver these specific tokens to my whitelist
Could someone suggest a safe approach to do so?
I will have knowledge of both the tokenIDs and their corresponding addresses, I just need to find a way to call some other custom mint/transfer function when they connect to my minting dapp
Initially I was thinking to create the collection with a max supply that does not include the 200 for the whitelist, and leave them as the last tokens on list, for example, say the entire collection has 1000 tokens, I'd put the max supply as 800, and deal with those 200 in a different way.
The easiest obvious way that I thought was to call a transfer function since I'll have their addresses, but paying gas myself for minting the 200 and then also for the transactions is a no go.
Looking at the ERC721A docs I see that the approve function could be used so that they get approved for their specific tokens and then pay for the transfer to themselves, but I would be the one to issue all the 200 approve calls and I bet this would have similar or same gas fee. I would do so only if the fees are zero or irrelevant, but I don't think I can count with that.
Also, I'm not sure if approve could work since I'd have to approve for a token that has never been minted before.

Mint the first 200 to the contract, use ERC721AOwnersExplicit to initialize the slots, and when the users mint, transfer the specific tokens to them.
Or just directly airdrop them when the network gas is low.
Or use OpenZeppelin or Solmate.

Suggestions:

Just let them mint whichever token ID that comes their turn, and set the metadata accordingly to what they have picked.
Directly airdrop them when the network gas is low.
Use OpenZeppelin or Solmate.

Thanks @Vectorized !
Could you expand on 1 and 3?
I'd assume for 1 id call some contract function to get that updated?
I checked some tutorial for soulmate and I guess you mean to call tokenURI in a way that I'd be monitoring which address minted each tokenID then assign the end of the URI to the metadata that this specific user should own to be something like URI://CID/tokenname.json ?

Say, user A has been assigned a NFT with traits (X, Y, Z), then just assign (X, Y, Z) for the metadata of their token ID.

Those are different implementations of ERC721 that can support assigning to arbitrary token ID during mint. You should select the tool that best fits your job. ERC721A may not be suitable for every use case.

I'm really not sure how you can set metadata traits in this case, if that means something to be done in the blockchain.
If it's not on the blockchain, do you mean that I should not upload the metadata json files until after the users have minted, so only after that I can figure out which token IDs those specific users have picked and then name their respective json files matching the IDs they picked? If that's the idea then that sounds very reasonable. I could override _startTokeId() to match the number of those for the whitelist. Is this more or less what you mean?

Thanks got it

My client has a group of premium users (those 200 from the example) that are allowed to select 1 artwork each, they participate in the creation process etc, and they get to choose which one they want. So when artwork is finished they pick one, after the collection is created and contract deployed, they should receive their respective tokens to match those artworks


MIE creates lambda resources that may never be used

MIE creates lambda resources that may never be used.  One solution would be to make individual MIE operator deployments configurable at deploy time.
Related to #227 and #228.
When I spin up the CFN template with the default parameters, see below.

MIE created *50* state machines and 50 lambda functions.
What interesting is that the majority of the state machines were not run. Any reason why they are there? Are they just to store the state definition? Is there any plan to reduce the numbers of resources allocated?"

State machines no longer are created for stages, which reduces the number of automatically deployed state machines to 0.


Markdown extensions to support Math, Tables, etc. not working

Checklist

[x] I am running the latest version. Installing Isso from GitHub from the master branch does not fix my issue
[x] I have checked the troubleshooting guide
[x] I have searched the open issues, but my issue has not already been reported

What is not working?
The documentation here makes note of a number of extensions that can be added to the default Markdown editor, such as "math", "footnotes", "highlight", "tables" etc. However, even after adding them to the configuration, there does not seem to be any change, and no errors in the logs either.
How can one reproduce this issue?
Isso configuration file contains the following [markup] section:
[markup]
options = autolink, fenced-code, no-intra-emphasis, strikethrough, superscript, math, highlight, tables, underline
flags = hard-wrap
allowed-elements =
allowed-attributes =

The "default" ones -- "autolink, fenced-code, no-intra-emphasis, strikethrough, superscript" work correctly and as expected, adding and removing them from the line produces the expected results. However, "math, highlight, tables, underline" produce no effect whatsoever. A demo can be seen on this page, the last comment:
https://mihnea.net/hello-world/#isso-11
Is there something I'm missing from the installation? The Misaka library appears to be present under isso/lib/python3.9/site-packages/misaka and is at version 2.1.1.

Hi, thanks for reporting your issue.
Could you please provide a working example of your config, the text you typed in and the rendered text you expected to see?
(Related: https://github.com/posativ/isso/issues/751)

Hi @ix5, thank you for looking into this.
Here the configuration in use:
[general]
dbpath = <path>/example.com-comments.db
name = example.com
host =
    http://example.com/
    https://example.com/
max-age = 15m
notify = smtp
reply-notifications = true
log-file = <path-to-isso>/sites/example.com.log
gravatar = true
gravatar-url = https://www.gravatar.com/avatar/{}?d=monsterid&s=55&r=x
latest-enabled = false

[admin]
enabled = false
password = please_choose_a_strong_password

[moderation]
enabled = true
approve-if-email-previously-approved = false
purge-after = 30d

[server]
listen = http://localhost:1234
public-endpoint = https://example.com/isso
reload = false
profile = false
trusted-proxies = <IP_ADDRESS>
samesite = Strict

[smtp]
username =
password =
host = localhost
port = 25
security = none
to = webmaster
from = "example.com Comments"<EMAIL_ADDRESS>timeout = 10

[guard]
enabled = true
ratelimit = 2
direct-reply = 3
reply-to-self = false
require-author = true
require-email = true

[markup]
options = autolink, fenced-code, no-intra-emphasis, strikethrough, superscript, math, highlight, tables, underline
flags = hard-wrap
allowed-elements =
allowed-attributes =

[hash]
salt = <salt>
algorithm = pbkdf2

[rss]
base =
limit = 100

You can see the examples in the link I posted, but sure I can add them here as well for clarity:

This code in the comment _underline_ **bold** ~~strikethrough~~ *emphasis* ==highlight==
=> produces this HTML: underline bold strikethrough emphasis highlight

You can see that 'bold/strike/emphasis' have tags added, but the other two 'underline/highlight' don't, despite the extensions being specified in the config

The 'math' extension should parse LaTeX-style code, right? This does not do anything at all (I took the example from https://github.blog/2022-05-19-math-support-in-markdown/ )
When $a \ne 0$, there are two solutions to $(ax^2 + bx + c = 0)$ and they are $$ x = {-b \pm \sqrt{b^2-4ac} \over 2a} $$

Finally, the 'table' extension should parse code like the following, but doesn't appear to do anything either:

| Tables   |      Are      |  Cool |
|----------|:-------------:|------:|
| col 1 is |  left-aligned | $1600 |
| col 2 is |    centered   |   $12 |
| col 3 is | right-aligned |    $1 |

Hope this helps tracking things down, if I can provide more information just let me know.

Hello. Thanks for isso, that's a very nice comments engine.
@ix5 , I ask exactly the same question that was @mgc8's. Is math option works inside isso? Do we need to install something more in order to get equations inside comments? (Same questions for tables and all options that does not work as it was remarked in this thread.) Thanks for your help.

Markdown on Github explains that it works  ```math
For example
The Cauchy-Schwarz Inequality
\left( \sum_{k=1}^n a_k b_k \right)^2 \leq \left( \sum_{k=1}^n a_k^2 \right) \left( \sum_{k=1}^n b_k^2 \right)

but also with '$$' :
$$ \left( \sum_{k=1}^n a_k b_k \right)^2 \leq \left( \sum_{k=1}^n a_k^2 \right) \left( \sum_{k=1}^n b_k^2 \right) $$
Therefore it should works with isso too.

Hi @joseph-vidal-rosset, sorry for the late response. Isso's markdown parser is misaka, which needs some configuration to allow more advanced syntax.
As for LaTeX: You need something to actually render in the browser. misaka simply ignores/doesn't modify anything between $ / $$ and leaves it up to the browser to style it. This differs from GitHub who "magically" do the right thing for you.
https://docs.mathjax.org/en/v2.7-latest/start.html#mathjax-cdn suggests e.g.:

We as the Isso project would do well to make the handling of markdown parsing more intuitive and automatic as well as align it with GHFM. I have tried documenting the current behavior here: docs: Configure how comments are rendered.

As for underline not working: You need to allow the  element in [markup] allowed-elements:
[markup]
options = [...], underline
[...]
allowed-elements = u

As for your table not displaying: That's unfortunately a similar issue, you need to allow the tr HTML tag in allowed-elements. Another contributor is working on simplifying this a bit, see https://github.com/isso-comments/isso/pull/1007
We plan on doing the right thing for you when you enable a markdown extension automatically (e.g. allow all table-related elements when you use the tables extension).

As for underline not working: You need to allow the  element in [markup] allowed-elements:
(...)
As for your table not displaying: That's unfortunately a similar issue, you need to allow the tr HTML tag in allowed-elements. Another contributor is working on simplifying this a bit, see #1007

Hello @ix5 , thank you for the additional information, we finally have a direction to explore on fixing this.
Using your suggestion, I was able to get "underline" to work via the "u" tag, but nothing else. "highlight" still does nothing (what would be the tag for that?), while the "table" also does absolutely nothing. Is this the correct syntax for the allowed-elements option?
allowed-elements = u, tr

I tried adding all the table-related tags there as well, with no difference. Really not sure why tr specifically had been blocked before, but in any case -- what else is needed to get this to work?

We plan on doing the right thing for you when you enable a markdown extension automatically (e.g. allow all table-related elements when you use the tables extension).

That would be great indeed, but until that's in place it would be great to be able to get these extensions working even manually, since right now the documentation you point to at docs: Configure how comments are rendered is a bit misleading since most extensions don't do anything...

Hi @joseph-vidal-rosset, sorry for the late response. Isso's markdown parser is misaka, which needs some configuration to allow more advanced syntax.
As for LaTeX: You need something to actually render in the browser. misaka simply ignores/doesn't modify anything between $ / $$ and leaves it up to the browser to style it. This differs from GitHub who "magically" do the right thing for you.

Hmm, ok, but that's a third-party JavaScript library with no connection to misaka discussed here. Why is there a math extension specifically, if it does absolutely nothing? The documentation you linked to specifically says:
"Parse inline LaTeX-style math blocks, such as inline $equations$ or display $$equations$$ >> Extension name: math"
What kind of "parsing" is meant here?

"highlight" still does nothing (what would be the tag for that?)

That would be the  element

while the "table" also does absolutely nothing

For me, [markup] options = no-intra-emphasis, strikethrough, underline, highlight, tables, math with allowed-elements = u, tr, mark works with the following table:
| Tables   |      Are      |  Cool |
|----------|:-------------:|------:|
| col 1 is |  left-aligned | $1600 |
| col 2 is |    centered   |   $12 |
| col 3 is | right-aligned |    $1 |

As well as with _underline_ **bold** ~~strikethrough~~ *emphasis* ==highlight==

since right now the documentation you point to at docs: Configure how comments are rendered is a bit misleading since most extensions don't do anything...

Yes, the issue is known. We have to decide just how much we want to overhaul the whole system without breaking setups of existing users.

Hmm, ok, but that's a third-party JavaScript library with no connection to misaka discussed here. Why is there a math extension specifically, if it does absolutely nothing? The documentation you linked to specifically says:
"Parse inline LaTeX-style math blocks, such as inline $equations$ or display $$equations$$ >> Extension name: math"

That's due to the underlying misaka library choices: https://github.com/FSX/misaka/issues/71#issuecomment-516033877

we should fix the documentation so that people don't waste time troubleshooting something that was never intended to work...

Feel free to submit a PR

Hi @ix5 ,
Thank you for the clarifications, this was very helpful to finally fix and understand the behaviour here!

"highlight" still does nothing (what would be the tag for that?)
That would be the  element

Done, works fine, thanks!

while the "table" also does absolutely nothing
For me, [markup] options = no-intra-emphasis, strikethrough, underline, highlight, tables, math with allowed-elements = u, tr, mark works with the following table:
(...)

Interestingly, I had to track this for a bit. It seemed to work fine in a new comment, but not in the existing one(s). What eventually turned out to be the problem was that the rendering did not kick in if there was any text right next to the table, it would keep it as 'code' then. Adding a line break made it render fine!

As well as with _underline_ **bold** ~~strikethrough~~ *emphasis* ==highlight==

Yes, all of these work now after adding the missing tags under allowed-elements.

That's due to the underlying misaka library choices: FSX/misaka#71 (comment)

This was pretty unclear to me until spending some time to read the information in that comment. Basically, the math extension doesn't actually do anything, but it marks the LaTeX-style code so that it is skipped by misaka, allowing other (external, third-party, etc.) libraries to parse and render it later. Now I understand.

we should fix the documentation so that people don't waste time troubleshooting something that was never intended to work...

Feel free to submit a PR

Ok, done -- https://github.com/isso-comments/isso/pull/1017 -- I've added the above few notes, hope it's ok!

I am sorry, but for me the situation stays the same: neither  ==highlight==  nor table nor math formula are rendered in isso comments...

I am sorry, but for me the situation stays the same: neither ==highlight== nor table nor math formula are rendered in isso comments...

Maybe if you paste the contents of your [markup] section in the configuration file would help trace what's happening... You do have the allowed-elements = u, tr, mark line, right? And you've restarted uwsgi or the specific WSGI tool you use to run isso?

Sorry, I did not restart isso, and  it works now, for _underline_ **bold** ~~strikethrough~~ *emphasis* ==highlight== as well as for tables. Thanks !
But, unfortunately,  for $$ A \to B $$ the result remains the same: it does not work. Did I miss something ?

Sorry, I did not restart isso, and it works now, for _underline_ **bold** ~~strikethrough~~ *emphasis* ==highlight== as well as for tables. Thanks !

Super, great to hear, also to have that note here in case other people run into the same issue.

But, unfortunately, for $$ A \to B $$ the result remains the same: it does not work. Did I miss something ?

Yes, that is actually expected behaviour, as detailed by @ix5 above. I have a PR attempting to improve the documentation around this -- basically the math extension doesn't actually do anything, it just prevents misaka (or Isso in this case) from interpreting the LaTeX code as Markdown. Actually rendering it as proper equations/formulas is left for a third-party library, they recommend MathJax or KaTeX for that.
I've researched those a bit (both are JavaScript based and also require a consistent amount of custom fonts), and each have some pros and cons: MathJax is a much smaller library (14k or so) and with better compatibility for ancient browsers (we're talking really ancient), but it's also very slow to render and suffers from a nasty FOUC effect (Flash Of Unstyled Content); KaTeX is a significantly "heavier" library (over 200k minified), but it's more modern and lightning fast, avoiding FOUC altogether. Remains up to everyone to choose the best one for their use case (I'd go with KaTeX personally).
Interestingly, there's also the option of parsing the LaTeX server-side: KaTeX for example provides this (but being written in JS, it means you'd need to have an entire NodeJS infrastructure on the server); but there are also Python implementation for this -- for example, mdtex2html, which I've tested on the above equations and comes up very nicely in MathML (supported in all modern browsers without extra fonts or JS necessary):

@ix5 -- would you be interested in pursuing a way to integrate this, or perhaps latex2html directly, into Isso? It could be run only if math is detected in the comments, and would avoid the need for external and heavy libraries and post-processing. Happy to study options if you find it can fit the scope.

MathJax  is very efficient and it is used in my blog. Unfortunately, it is not used in isso. The best, in my opinion, would be the option of using it in comments.

MathJax is very efficient and it is used in my blog. Unfortunately, it is not used in isso. The best, in my opinion, would be the option of using it in comments.

If you already have MathJax running on your blog, then it should just be a matter of getting it to parse the comments after isso. You could either delay its loading and running for until after Isso is done (moving the script to the footer and removing any async tags, for example), or add a bit of JS to specifically run MathJax on the newly created divs. Maybe the MathJax documentation has some help in this regard?

Regarding @mgc8's suggestion about integrating a latex/mathml conversion tool: It would be nice to hear from existing users whether they would be interested in that or if their own control over math rendering is more important.
We should also figure out the order of the following steps:

render markdown (misaka)
clean HTML (bleach)
convert latex to mathml (essentially <math> HTML elements)

I'm not sure whether we could introduce vulnerabilities if we do the latex conversion after the bleach step since perhaps users could do $a gt b $? Is that properly guarded against?

MathJax is very efficient and it is used in my blog. Unfortunately, it is not used in isso. The best, in my opinion, would be the option of using it in comments.

If you already have MathJax running on your blog, then it should just be a matter of getting it to parse the comments after Isso. You could either delay its loading and running for until after Isso is done (moving the script to the footer and removing any async tags, for example), or add a bit of JS to specifically run MathJax on the newly created divs. Maybe the MathJax documentation has some help in this regard?

You are very probably right. I have to look again on MathJax 3 Documentation, how to use MathJax on dynamic contents.

I suggest a help in isso-documentation to use MathJax with isso...

Regarding @mgc8's suggestion about integrating a latex/mathml conversion tool: It would be nice to hear from existing users whether they would be interested in that or if their own control over math rendering is more important.

That makes sense, although I'm not sure how many users read this issue... How about this: we can have the server-side parsing controlled by an option, which would default to the current behaviour if missing or not set, thus not affecting any existing setup? Then, only the users who really want to have that would turn it on.

We should also figure out the order of the following steps:

render markdown (misaka)
clean HTML (bleach)
convert latex to mathml (essentially <math> HTML elements)
I'm not sure whether we could introduce vulnerabilities if we do the latex conversion after the bleach step since perhaps users could do $a gt b $? Is that properly guarded against?

That is a very good point, security is critical in a case like this. I would say that bleach should ideally be run as the last step, in order to sanitise the potential output of latex2mathml as well, though a cursory test shows that none of the MathML tags are allowed by default, so we would need to pass a comprehensive tags list to the bleach.clean() call. This could also be controlled by the previously mentioned option, so the tags would be allowed if and only if the user had server-side math parsing enabled, which should minimise the potential attack surface.
Alternatively, we can also run the latex2mathml conversion last, which appears to be quite resilient to script/tag injection since it treats those as LaTeX anyway -- e.g., your example above would be translated as the following harmless MathML:
<math xmlns="http://www.w3.org/1998/Math/MathML" display="inline"><mrow><mi>a</mi><mo>></mo><mi>b</mi><mo><</mo><mi>s</mi><mi>c</mi><mi>r</mi><mi>i</mi><mi>p</mi><mi>t</mi><mo>></mo><mi>e</mi><mi>v</mi><mi>i</mi><mi>l</mi><mo><</mo><mo>/</mo><mi>s</mi><mi>c</mi><mi>r</mi><mi>i</mi><mi>p</mi><mi>t</mi><mo>></mo></mrow></math>

... though that would still potentially leave some malicious manipulation possible to output HTML; although nothing is perfect, bleach itself seems to be at a bit on impasse right now according to https://github.com/mozilla/bleach/issues/698

Thus further complicating our already byzantine maze of configuration options into which you've already felt yourself getting trapped...

To be honest, I don't think the confusion here stemmed from the configuration options, but rather the unintuitive behaviour of the software behind-the-scenes. Overall, Isso has a pretty succint configuration compared to other similar pieces of software.
With the recent patches that add some more sanity to the way allowed-elements & co. function, I think that will be much less of a problem. I followed your notes on the other issues related to that, and I do agree that the overall Markdown parsing infrastructure in Isso could be improved, but I think having this option here would actually offer a valuable choice to end-users between server-side and client-side parsing (at least for one particular feature).
Of course, if you have already something else in mind as part of future plans for improvement here, let me know and perhaps we can aim for that instead?

bleach itself seems to be at a bit on impasse right now according to mozilla/bleach#698
That's certainly an issue, thank you for raising that (I wasn't aware). People suggest using nh3 so a switch in the future should be investigated.

From what I see in the (many) comments on that, nh3 appears to be much faster (although, probably not very relevant for Isso since comments are typically short), but it does come with certain incompatibilities/strictness errors which have caught some people unawares; we should probably have a good testing suite in place before making the switch. On the other hand, bleach developers appear committed to at least supporting the project with security and Python version updates, so it's not dire yet...

In general, math rendering on the server makes sense, since hooking the mathjax/... calls, especially for the edit/preview fields, is a pain. We currently provide mostly barebones functionality and trust our mostly-technical users to DIY the rest.
If we find a way to make this less painful while keeping Isso simple enough, I'm all for that.

Agreed on all counts, if other people have comments and suggestions on the topic, that would be great to hear.

To be honest, I don't think the confusion here stemmed from the configuration options, but rather the unintuitive behaviour of the software behind-the-scenes. Overall, Isso has a pretty succint configuration compared to other similar pieces of software.
With the recent patches that add some more sanity to the way allowed-elements & co. function, I think that will be much less of a problem. I followed your notes on the other issues related to that, and I do agree that the overall Markdown parsing infrastructure in Isso could be improved, but I think having this option here would actually offer a valuable choice to end-users between server-side and client-side parsing (at least for one particular feature).

You're right in that the markdown handling will be improving a bit, but that may be a bit for naught if we are to change our renderer. I would prefer to expose sensible options to users rather than have them learn the intricacies of our renderer/sanitizer, which might not translate 1-to-1 for the different packages (mistune/... and nh3/...) we might have to replace them with due to deprecations.
We can lessen the confusion of the current markdown configuration via better documentation and improvements to auto-enabling allowed HTML elements when toggling a feature flag, but it'd be much better for existing and especially new users to just make this whole system intuitive.
I'd prefer to make the defaults more like GitHub-flavored markdown (meaning also enabling more extensions by default) and expose extensions to users via generic names (images, tables, links) instead of being tied to misaka's naming.
But that's just my own opinion and I'm willing to be convinced otherwise. Discussing this here is a good first step towards finding a solution.
My idea would be something like this:
[markdown]
line-break = single # hard-warp
raw-html = false # escape

[markdown.features]
tables = true
latex-math = render # or 'skip', 'escape'
images = false
links = true
# Enabled by default
highlight = true
underline = true
strikethrough = true
no-intra-emphasis = true
# ...

As for latex/math handling on the server vs client (via JS), the client isn't really ready for that as I see it. We do not provide a reliable hook mechanism for newly inserted comments (or even the preview field) so that  Mathjax could listen for that - and unless this sorry state of affairs changes, I'd rather simply do the right thing for them on the server.  Let's improve the client and expose extensibility mechanisms and a whole lot of problems suddenly get easier.

From what I see in the (many) comments on that, nh3 appears to be much faster (although, probably not very relevant for Isso since comments are typically short), but it does come with certain incompatibilities/strictness errors which have caught some people unawares; we should probably have a good testing suite in place before making the switch. On the other hand, bleach developers appear committed to at least supporting the project with security and Python version updates, so it's not dire yet...

Good to know.

In general, math rendering on the server makes sense, since hooking the mathjax/... calls, especially for the edit/preview fields, is a pain. We currently provide mostly barebones functionality and trust our mostly-technical users to DIY the rest.
If we find a way to make this less painful while keeping Isso simple enough, I'm all for that.

Agreed on all counts, if other people have comments and suggestions on the topic, that would be great to hear.

[...]

Of course, if you have already something else in mind as part of future plans for improvement here, let me know and perhaps we can aim for that instead?

Perhaps a more focused approach with actionable items might lead to better and clearer results. Right know we're burying the conversation deep in this thread, which was originally a bug report (I'm absolutely guilty of perpetuating this as well).
Suggestions are always great, and we have lots of drive-by contributions with small to medium-sized fixes/improvements, but so far, no features/improvements of a larger scale (as would be required by the overhaul in markdown handling) have been contributed in recent times.
If you feel that you would like to overhaul this system or know someone for whom this would be just the right challenge, go for it! While I personally am neither a great coder nor could design a good system, I'd be happy to review any proposals and contribute docs, migration advisories (from old handling to new) and tests.

Using MathJax 3 dynamically in DOM is not quite easy. If someone would succeed to use MathJax in isso comments, an explanation online would be very welcome....


getWlanLog Function

With this function you can get the last entries from your wlan log file.
e.g. to see the last (dis)connected devices in your wlan

Hi, @derN3rd. Thank you for your contribution. I’m sorry that this is still not merged, currently very busy with work.
The code itself looks fine to me, and I’m sure it’ll also work. The main reason why I don’t just merge it is because I’ll need to find some time to also publish these changes.
If you don’t have any time pressure, I’d try to publish this Saturday.

No problem, take your time.
Another thing that might be interesting for you (if you have the time): Prettier
That would ensure that the code formatting remains the same when multiple people are working on the project. I could do that for you, if you want.

@derN3rd Yes, that’s a good idea. I honestly didn’t notice that this project doesn’t have a prettier config yet. Mine applies globally in my editor when it can’t find one, so it looked fine for me. I’ll add one on Saturday.

@derN3rd I released this with a different (and more powerful) API in 1.2.0. Would be nice if you could check if this still works for your setups. The FRITZ!Box API is pretty weird.


Call to the API route not landing on the Controller

Sorries in advance if this is not related to the package...
This is how my API call looks like
fetch('/api/payme?customer='+customer,
{
    headers: new Headers({
        'Authorization': 'Bearer ' + session_token
    }),
    method: 'GET'
})

The Fetch seems alright to me with 200

For some reason the request is not landing on the Controller. What am I missing here?

When I use POST, I see the below in console:-
POST | https://4fac-2401-4900-1f3a-3638-68e5-f115-d599-8c66.ngrok.io/payme gives a 302
and
GET | https://4fac-2401-4900-1f3a-3638-68e5-f115-d599-8c66.ngrok.io/authenticate/token?shop=tg-test-app-store.myshopify.com&target=/payme which gives a 200

Hi @burfbari
This does not seem to be an issue with the package.
Closing it for now, but if you feel that it is please provide more information.


[FRONTEND] Remove unnecessary replace in while op's after block

We've already updated the mapping between name and tensor before visiting each compound statement in the while op. As a result, any overwritten name gets up-to-date values updated in the while loop. And any unchanged livein names hold the original tensors.

@zahimoud is something up with the ptx reference check?
FileNotFoundError: [Errno 2] No such file or directory: 'reference'

seems like my latest PR works though, so maybe it was a rebasing issue kind of thing

seems like my latest PR works though, so maybe it was a rebasing issue kind of thing

Yea it could have been that the main branch has "integration-tests-nvidia" versus your branch has "integration-tests", I couldn't find the failing run to confirm, but if you see issues I'd be happy to take a look!


'HueBridge' object has no attribute 'sensor_manager'

Hi,
I am fairly new to HA. Im getting this error stated below. Anything I am missing?
My configuration looks like this:
hue:
bridges:
- host: 192.168.x.x
allow_unreachable: true
allow_hue_groups: true
remote:

platform: hueremote

Log Details (ERROR)
Wed Apr 08 2020 09:13:21 GMT+0200 (Central European Summer Time)
Error while setting up platform hueremote
Traceback (most recent call last):
File "/srv/homeassistant/lib/python3.6/site-packages/homeassistant/helpers/entity_platform.py", line 150, in _async_setup_platform
await asyncio.wait_for(asyncio.shield(task), SLOW_SETUP_MAX_WAIT)
File "/usr/lib/python3.6/asyncio/tasks.py", line 358, in wait_for
return fut.result()
File "/home/homeassistant/.homeassistant/custom_components/hueremote/remote.py", line 40, in async_setup_platform
config.get(CONF_SCAN_INTERVAL, DEFAULT_SCAN_INTERVAL),
File "/home/homeassistant/.homeassistant/custom_components/hueremote/data_manager.py", line 159, in async_add_platform_entities
async for is_new, model, dev_id, _ in self._iter_data(platform_models):
File "/home/homeassistant/.homeassistant/custom_components/hueremote/data_manager.py", line 56, in _iter_data
await bridge.sensor_manager.coordinator.async_request_refresh()
AttributeError: 'HueBridge' object has no attribute 'sensor_manager'

Did you copy the hueremote folder from:
https://github.com/robmarkcole/Hue-remotes-HASS/tree/master/custom_components
To your custom_components folder and then restart home assistant?
Also, the spacing in your pasted YAML isn't right and it looks like you have a bullet rather than a dash before platform: hueremote
Also, I don't think you need that hue code, just put:
discovery:
in your configuration.yaml file and HA will detect your hue bridge and lights, etc. and you can set it up with the gui.  You may need hass.io to do that, so I could be a little off here.
Once you do that, you can just add the following to your configuration.yaml:
remote:

platform: hueremote

Someone else can say this more elequently than I.

I used the HACS install process and the files are indeed in place i that folder.
I forgot to mention that i use the integrated hue integration with great success. That is for sensors, lights and groups.
Ill try adding the discovery: part and see if i get somewhere.

Did you update HA to the latest as well?  I just did this and it worked perfectly as I described.
The discovery part was what I was suggesting would find the integrated Hue stuff.  If that's already working then a reboot after HACS install of custom component and the remote: and platform in configuration.yaml is all that is needed.  Did you check in the Lovelace "unused entities" to see if found your remotes?

Ill have a try at upgrading and get back with info.

Upgraded to v0.108.1 and now it works like a charm.
Thanks for the help! :)


ProjectApi removeMember() throws GitLabApiException at success case

When I remove a member from a project with projectApi.removeMember(); function the user is removed, but I get GitLabApiException: No Content exception.
The GitLab API returns 204 - No Content when the deletion is success.
So change this:
public void removeMember(Integer projectId, Integer userId) throws GitLabApiException {
        delete(Response.Status.OK, null, "projects", projectId, "members", userId);
    }

to this
public void removeMember(Integer projectId, Integer userId) throws GitLabApiException {
        delete(Response.Status.NO_CONTENT, null, "projects", projectId, "members", userId);
    }

I think other delete() calls is bad too.

Same problem at GroupApi removeMember() @

Changed the expected HTTP status to NO_CONTENT (dependent on GitLab API version).  Have also made same change in all sub API's.  Fix is included in the new 4.2.3 release.


Update Chinese Localization

TW and CN are included, co-maintain by @auroursa @cirx1e

please review this PR

https://github.com/KuwaLee/bluesky-social-app/pull/9


why does it wrap paragraphs within blockquotes in quotes?

the following
> **Hint**: why is
> this paragraph in quotes
>
> * list in blockquote
>
> and another paragraph

yields

I wonder why the paragraphs in the blockquote are wrapped in quotes.

I think you can easily turn this behaviour off


Add bower support

Since angular-datetime is available on bower you should also make this available on bower

Actually angular-datetime dropped the bower support at v5.0.0, since npm v3 flattens the dependencies by default.


[BUG] [Android] Attribute subscription report data is always null

Reproduction steps
Subscribe to attributes which returns string data.
Wait for reported data.
Compare the data with the data posted by device.
Bug prevalence
always
GitHub hash of the SDK that was being used
Latest from master
Platform
android
Platform Version(s)
No response
Anything else?
We have custom clusters/attributes defined under endpoint 0 on the device side, and we are trying to read/write those attributes. when we subscribe for those attributes, i see the data is received at ReportDataMessage.cpp
ReportDataMessage =
{
	SubscriptionId = 0x204eff96,
	AttributeReportIBs =
	[
		AttributeReportIB =
		{
			AttributeDataIB =
			{
				DataVersion = 0x907aa9a1,
				AttributePathIB =
				{
					Endpoint = 0x0,
					Cluster = 0x1383fc01,
					Attribute = 0x13830102,
				}
				Data = "{"test":"test_value","abc":"def"}" (33 chars),
			},
		},
	],
	InteractionModelRevision = 1
}

While reporting at app layer, The data received as
Endpoint 0: {
        Cluster 0x1383fc01: {
                  Attribute 0x13830102: null
        }
}

The same thing works with iOS and is receiving data properly. Issue observed in android.

I see below error in log as well when there is a change in attribute value
OnMessageReceived failed, err = src/messaging/ExchangeMgr.cpp:305: CHIP Error 0x00000070: Unsolicited msg with originator bit clear

Issue seems to be at device end where the tlv data is not properly formatted due to that data is getting discarded.
Not an issue, Closing it.

hey @jagadeesh-ayla.
After adding your cluster, are there any changes to be made to the generated files after running the command? /scripts/tools/zap_regen_all.py
Thanks

Hi @amprazak no changes required, Our device team implemented custom clusters and attributes, and while writing value to the attribute, TLV data was not formatted properly which was causing this issue, However it was fixed.
Thanks


with require do I need gulp required on all tasks files?

all my require requireDir('path/dir') need this in their files:
var gulp = require('gulp');
Is there a way that  require('gulp') only has the need to set this in the gulpfile.js and not on every individual files in the path?...I feel like there should be a way not to have to add these to all the files that are added but have to in this case. It seems to make process delay.

There isn't any way today.
It's unlikely this is delaying your process. Node caches requires, so Gulp is only really getting required once under the hood.
You could confirm this by adding console.time and console.timeEnd calls before the requires.

I guess that makes sense ...maybe i just didn't want to add that repeated on every task pages, but if it has to be done than so be it

I hear you. =) The more I think about this issue btw, the more it feels like it'd be a great feature for Gulp to have (being able to automatically require a file in every task). Mocha has this (--require):
http://mochajs.org/#usage
So I encourage you to ask on a Gulp mailing list, etc. Good luck!


[1.18.1] Phantom can take damage while inside a solid block when invisible

Whenever you go invisible and go inside a block, you began taking damage in the block even if invisible

I'm still working on updating origins. The current release is mostly here as something to give people who are willing to play with major issues while I solve ~4000 compilation errors I got from updating upstream.
Also yes current Apoli is compilable, but 5s of play testing gave me some pretty bad results, so there's still quite a bit of work to solve the current issues, plus Origins isn't in line with upstream yet.

Fixed in 1.3.1


[WFCORE-323] Allow multistep op handling to defer resolution of the O…

…perationEntry until it's time to execute the step
https://issues.jboss.org/browse/WFCORE-323
I bumped the priority on this as it can be useful to tools like galleon by removing the need to segregate extension add ops associated with a feature from the related subsystem ops.
Just an experiment at this point. Certainly needs tests added.
The basic point here is to allow an extension=foo:add and a subsystem=foo:add op to both be in the same composite, without the latter failing because initially the MRR for the subsystem doesn't exist.
I kind of like this approach that I stumbled into because it doesn't change anything except in the specific case where the initial attempt to add the step fails due to a missing MRR.
The 2nd commit adds a bit of complexity just to guard against the corner case of someone removing an extension and then trying to re-add its subsystem resources in the same batch as the extension remove.
It works:
$ bin/jboss-cli.sh -c
[domain@localhost:9990  /] batch
[domain@localhost:9990  / #] /extension=org.wildfly.extension.io:add
[domain@localhost:9990  / #] /profile=default/subsystem=io:add
[domain@localhost:9990  / #] run-batch
The batch executed successfully
[domain@localhost:9990  /] batch
[domain@localhost:9990  / #] /profile=default/subsystem=io:remove
[domain@localhost:9990  / #] /extension=org.wildfly.extension.io:remove
[domain@localhost:9990  / #] run-batch
The batch executed successfully

Core - Full Integration Build 8020 outcome was UNKNOWN using a merge of f039fbcb2c900ce766ff2340f790c658f96fc6d4
Summary: Canceled (Error while applying patch; cannot find commit 4bc3f7c32a6d1a7a20afd9d87c982e6ec1213062 in the https://github.com/wildfly/wildfly-core.git repository, possible reason: refs/pull/3259/merge branch was updated and the commit selected for the ... Build time: 00:00:17

Core - Full Integration Build 8241 outcome was UNKNOWN using a merge of a225c567b02d07937254565e2b3c2343f5811a89
Summary: Canceled (Error while applying patch; cannot find commit 3879d756e8f129db274a72f2466b49dfcda8a5d5 in the https://github.com/wildfly/wildfly-core.git repository, possible reason: refs/pull/3259/merge branch was updated and the commit selected for the ... Build time: 00:00:34

Core - Full Integration Build 8584 outcome was FAILURE using a merge of 129b90ad89ecb5b2820c94bba62fd831207ffe5a
Summary: Error while applying patch Build time: 00:00:03

Core - Full Integration Build 8572 outcome was UNKNOWN using a merge of 129b90ad89ecb5b2820c94bba62fd831207ffe5a
Summary: Canceled (Error while applying patch; cannot find commit d8eba538850ee1745bbaa6191b63cd9f988a49ea in the https://github.com/wildfly/wildfly-core.git repository, possible reason: refs/pull/3259/merge branch was updated and the commit selected for the ... Build time: 25:53:40

Core - Full Integration Build 8652 outcome was UNKNOWN using a merge of 311a724c1a26e9a0e1636816df10e6ba7dfe5054
Summary: Canceled (Step 4/5) Build time: 00:02:41

@jmesnil  This should be good to go now. If this is WF 17, then Galleon can use it in WF 18.


Handling the 64 bit test case in a cleaner way

Rewrote test so it will compile on all 32 bit and 64 bit systems.
We now have the following distinct scenarios:

Test will pass on 64 bit systems with 64 bit longs
-> TEST().
Test should pass on 64 bit systems with 32 bit longs, but fails
due to a known implementation problem. Needs to be fixed.
-> IGNORE_TEST() for now.
Test cannot pass on 32 bit systems
-> IGNORE_TEST() always.

Should we then get the other test back that you deleted?

Why?
Would you then (assuming the 32 bit long problem was fixed) use the deleted one for 64/64 and the one in this pull request for 64/32?
E.g. I could then also flesh out the ignored test case that should pass. Using the new code there, it would compile, but fail if it wasn't ignored.
Hmm. Maybe not at all a bad idea.

We would then have:
TEST() // Original test case for pure 64 bit systems
IGNORE_TEST() // 32 bit long compatible test case
IGNORE_TEST() // Always empty for 32 bit systems

Should I do that?

Sorry, I'm slow. In this commit: https://github.com/cpputest/cpputest/commit/a4df3a62293d43bdf02c0039ed1c3aef16239ffe#diff-82d4bffd3899d43667ae495ad4b04a9a
You removed one test. Shouldn't we have that one back?

Yes, I think we should have it back.
But then, we can give pure 64 bit systems the old test back also (without the funky 32 bit max initialization constraint workaround).

P.S. Right now, I don't have a 64 bit Windows gcc environment ready for testing (we changed all back to 32 bit at work) and my Mac is 64bit (32bit Windows VM). To be frank, I find that combination detestable, so I don't use it normally (the only reason to use 64bit apps on 64 bit Win is if one of them needs that much memory all on its own :-)

Okay, I managed to test it -- sort of.

un-ignore test
compile with mingw 64 bit
hack away the pthread stuff
"fix up" Simplestring (see below) for Windows
Test passes.

SimpleString HexStringFrom(const void* value)
{
    return StringFromFormat("%llx", (long long)value);
}

So, this can be considered fully tested

32 bit Windows (my usual setup) - I?LP32
64 bit Windows with 32 bit longs (MinGW 64 bit) - LLP64 / IL32P64
Travis - LLP64 / I32LP64

Originally the test wasn't IGNOREd, but now it is. Why is this?

Could you maybe comment in the code? I am not sure I understand what exactly you are referring to here.
If you look at the new code in context (not the diff), the comments would make pretty clear what's intendend (or else, I failed miserably with this pull request :-)

Ah, now I get it. The diff is a bit confusing.
Before, the testcase was used for L64P64 (although the test is compatible with L32P64).
Now I am distingishing L64P64 with its own test case.
The old L32P64 test case is now used for L32P64 systems (Windows), and it needs to be ignored until SimpleString is fixed (one such fix would be using %llx and (long long), as detailed by the comment.
As I mentioned above, take a look at the new code in context (not the diff).

This way we make explicit that

One IGNORE_TEST() is out of necessity (no way this will ever pass on L32P32 systems)
The other IGNORE_TEST() is for code that needs fixing

Bunching these together like in my last pull request makes for less code and "fewer" conditional defines, but contradicts the principle of making explicit why we ignore certain tests, and what ultimately needs to be fixed.

But it wasn't IGNOREd before? So, why does it need to be ignored now?

The conditional define logic is different.
Before, L32P32 and L32P64 was bunched together (which it shouldn't, in my opinion) and totally IGNOREd.
So the not-IGNORED test was only run for L64P64 (now covered by the new test case).
Now, the not-IGNORED test is run on L32P64 systems, where it will compile but fail (until I twist your arm to use long long in SimpleString). Hence it now needs to be IGNOREd.......

Ok, I'll just merge it then :)

Thx :)
This is the test failing when built against MinGW-64:

and now it is ignored:


Readme link to bigdatagenomics/lime 404s

@devin-petersohn The link to Lime in the latest rev of README.md 404s (https://github.com/bigdatagenomics/lime).  Could your repo be migrated to the bigdatagenomics organization in a timely fashion, or should we update the readme to link to your repo?  Ping me for help, I've done it a few times already.

Migrated Lime to bigdatagenomics.


concurrency safety for interval aggregation

hi,@gocraft ,I've looked into the source code of gocraft/health,what surprises me is that the aggregation part is totally free of lock.what I'm wondering is how you guarantee the concurrency safety.
for example,the code of func ingest in interval_aggregation.go
func (a *TimerAggregation) ingest(nanos int64) {
	a.Count++
	a.NanosSum += nanos
	floatNano := float64(nanos)
	a.NanosSumSquares += (floatNano * floatNano)
	if a.Count == 1 || nanos < a.NanosMin {
		a.NanosMin = nanos
	}
	if a.Count == 1 || nanos > a.NanosMax {
		a.NanosMax = nanos
	}
}
```
while doing the plus operation,the value may be modified in other goroutines.the plus operation `+` is not atomic,the whole `ingest` may produce inconsistent for relevant fields or wrong result of computation.

in the `aggregator.go`
```
func (a *aggregator) getIntervalAggregation() *IntervalAggregation {
	intervalStart := now().Truncate(a.intervalDuration)

	n := len(a.intervalAggregations)
	if n > 0 && a.intervalAggregations[n-1].IntervalStart == intervalStart {
		return a.intervalAggregations[n-1]
	}

	return a.createIntervalAggregation(intervalStart)
}
```
the judge for existence if not atomic either,the *IntervalAggregation can be created for many times.

oops,sorry.I found the whole process is put  in a buffered channel,a single worker in a single goroutine ,so that's ok for doing so in the code.


INS-3076: added helper to get request from global context

- What I did

added new helper GetRequest()
refactored foundation a bit

- How I did it
- How to verify it
- Description for the changelog

reverted mock fix, will investigate a bit in INS-3086


Fix message collector and serialize

Removing RemoveAllListener, that function will stop any command because the command listener is removed after message collector end.
And add null safety on serialize when checking body message with specified key.

found a bug, on removeListener


Minimum version required for Hybrid-Joined

After hunting around including looking at this document I realised I need 1804 to use SSPR on HubridAADJ devices, can the Limitations section be updated, see https://techcommunity.microsoft.com/t5/Azure-Active-Directory-Identity/Reset-passwords-from-all-the-versions-of-Windows-important-to/ba-p/265978.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: c2015c6c-60c7-bb74-469c-e9320301d08a
Version Independent ID: 0ff19de6-c892-10ff-5fe8-f6a70abfa3f5
Content: Azure AD SSPR from the Windows 10 login screen
Content Source: articles/active-directory/authentication/tutorial-sspr-windows.md
Service: active-directory
Sub-service: authentication
GitHub Login: @MicrosoftGuyJFlo
Microsoft Alias: joflore

@frehnejc Thank you for pointing that out. The article does mention about windows 10 April 2018 update which is windows 10 v1803 update . Are you referring to that or in your case you were only able to use the feature after updating to 1804 version specifically ?

If you could point out the minimum version eg 1803 that would be great.

@frehnejc We have updated the same and it will be updated in the next 24-48 hours maximum as per next release cycle. We will close this issue now.
Thank you.