in 2016, the font format stack shown no longer makes sense.

The stack shown in https://github.com/dwighthouse/onfontready/blob/master/README.md#usage doesn't make sense anymore in mid-2016, with Microsoft having disavowed IE8 and below, and Safari and Android having great webfont support by now.
Long story short: http://stackoverflow.com/questions/36105194/are-eot-ttf-and-svg-still-necessary-in-the-font-face-declaration/36110385#36110385
Showing this stack should come with either an explicit warning that this is not modern CSS anymore (just WOFF and WOFF2 means your webfonts work on every currently-supported browser), or it should show a modern syntax with only woff/woff2 with a link to an ancient.css file that shows the format we needed three years ago =)
(although even then, SVG fonts were never useful, and we killed off the spec as soon as it turned out they were in fact a terrible idea, which is why most current browsers did support SVG at some point, but have removed SVG font support again. It's a revoked spec).

Thanks for the feedback. I will make this information available when I update the documentation with usage examples. Keep in mind that this library is designed to work even back to IE6 (for the lolz), so having obsolete font formats should come as no surprise. Nevertheless, SVG fonts may not be legitimate for any time period. I will look into it further.

To be clear, I plan to go into more depth with which font format specs to apply depending on which version of the library is used (modern vs legacy).

I'm not sure I see the value in making sure versions of IE are supported that Microsoft themselves no longer officially support. IE8 and below have been abandoned, much like how IE4 and 5 were abandoned, we just (finally) moved on to a new "minimum IE version". As of January 12th 2016, Microsoft disavowed IE8 and below, and only supports IE9 very specifically only on Vista SP2. IE9 on Windows 7, for instance, is not supported, so questions need to be asked why one would keep pretending these incredibly insecure browsers should still be catered for. Surely, we're not telling people who still use them that they're perfectly safe on the web - their operating systems and browsers are so full of holes they might as well publically post their personally identifiable information and financial details.

Yeah, I normally would agree with you. My forward looking projects are not directly supporting browsers IE9 and below. There are a couple of things to consider for such a generic library as onfontready though:
IE6/7/8 is still somewhere around 6% worldwide summed usage. IE9+ make up as much as 10% on some measures. While Microsoft may have disavowed these browsers, they are still in major use in some parts of the world. It is well outside of the scope of onfontready to tell users what browser they should be using. No doubt, anyone using those versions has probably been told exactly what browsers they should be using for over five years. The fact that they are still using them implies that they have no choice in the matter.
Effectively, the legacy version of onfontready exists to make the claim that "onfontready supports ALL browsers." To my knowledge it does. I know of no browser capable of custom fonts that won't also support the legacy version of my library. If I had the capacity to test IE4 and 5, I would. This part of the library is mostly a personal challenge. I didn't have to make it work in older browsers. I didn't have to make it this small either.

fair points.

Let's keep this issue open until I have a chance to re-evaluate the stacks and remove unnecessary font types when I add new documentation.
@Pomax I was wondering, could you supply me with a binary copy of your special font as a TTF file? In addition, can you provide some variation of it (a font containing only the the 'A' character, no spaces) in an EOT format as well so I can test older IEs? I'd convert it myself, but I know FontSquirrel will add a space automatically.

That's actually something you don't need me for, the browsr can already do that for you: open dev tools, go to the network tab, and simply open the ont's data-uri in a new tab. Now it's a download =)
As for variants at that small a size, we're talking non-trivial changes, which require more time that I have available for the forseeable future (I'm not doing any font work at the moment). If you want to convert any fonts or real testing, don't us fontsquirrel, it is literally terrible at this job. Use real tools like TTX and/or FontForge, or since the font is so small, literally just write the 30 or so bytes you need to turn a ttf/otf into an eot font manually, using a hex editor (which I'd probably recommend)

It looks like your Minimal Font Generator might just meet my needs. Thanks for that! I will give it a try.
I have decided to eliminate WOFF2 and SVG Font support in tests.

Only iOS 4.1 and lower support SVG fonts while not supporting other font formats. Global marketshare of these older iOS versions sits at 0%.
WOFF2 support was removed as redundant, since any browser that supports WOFF2 also supports WOFF.

This leaves EOT for old IE, TTF for older browsers in general, and WOFF for modern browsers.

Hm, are there any browsers that "supports TTF, does not support WOFF"? The only ones I can find are Firefox 3.5 and Chrome 4, neither of which are used anymore, Opera 10, which is also no longer used, Safari 5 and below, and IOS Safari 4.3 (both with really low usage); the only "real" browser I can think of for which ttf would be necessary is the Android webview engine, but its ttf support ever for Android 4.2 and 4.3 (it started supporting WOFF in 4.4) is super flaky.
I'd probably go with just WOFF and EOT, given how far back we need to go to find browsers that do TTF but not WOFF, but as an interesting idea: it is fairly easy to extract the original TTF from a WOFF in-browser by just slicing up the bytecode (provided the WOFF wasn't deflated of course) so that might be an interesting option.

Well, these are just for tests, mind you. My library doesn't need any fonts of its own to operate. Any reduction in font usage for the tests is just to reduce the weight of the test code.
It is as you say, Android tends to have a longer tail. And I would have limited it to just EOT and TTF, except that IE (including mobile IE) has some specific requirements about it being an "installable font", which I can't necessarily guarantee. I simply don't have the skills or time to hand-edit hex files or read font format specs. All I really want to do is guarantee some test cases using test fonts known to have this or that property. My goal is not to be a font format expert.

that's fair enough, having worked my way deep into the OpenType spec it's not a journey I recommend many people.

Your minimal font tool unfortunately didn't work out very well, because it generated a TTF that couldn't be converted into a EOT that worked in IE. I ultimately had to use a FontSquirrel exported font, that I then edited with fonttools to get a space-less font that could then be correctly converted to an IE-compatible EOT file.
I've added tests for this unusual case in my test suite.

Interesting... EOT is essentially just a wrapper around the original font, just like  WOFF-without-compression, so it might be that on ancient IE the TTF itself is overoptimised. Not sure if I'll ever get to it, but I've filed that as an issue on the repo. Thanks for the heads up.

It could be something to do with the "installable" feature of TTF. I couldn't convert one of my earlier FontSquirrel fonts correctly, but when I unchecked the "WebOnly" feature, it worked.

hm, pretty sure I generate the TTF with the installable bit set, but... let me check!

Well, I'm out of ideas. On IE6, the font simply didn't load (apparently lacking a valid font is a silent failure in IE6).

damn. I'll have to grab myself a modern.ie IE6 VM and investigate, probably won't have time for that until the weekend though.

Actually, there's one other idea. I had left the entry for space but defined it as .notdef, rather than removing its entry in the cmap tables (I think). Convert the TTF to TTX I made: https://github.com/dwighthouse/onfontready/blob/2.0-SpaceCharacter/tests/mainTests/custom_fonts/f_F1.ttf
On IE6, the font simply didn't load (apparently lacking a valid font is a silent failure in IE6). Incidentally, the tool I used to convert the TTF to EOT (and also WOFF), is here: https://everythingfonts.com/ttf-to-eot
Notably, I tried about 4 different font conversion services, and all but one produce byte-identical conversions of your minimal TTF to EOT, so maybe they were all using the same underlying library.

to be fair: the minimal font is spec-compliant, but not generic service compliant, so while it works in the browser, it will almost certainly fail conversion by online services. These services generally are much stricter about what a "legal" font is compared to what the spec actually says.

Makes sense. Kinda like how there are hundreds of JPEG decoders, but not one of them actually implements the entire JPEG spec. Too complex, not worth it.

yeah kind of, although also kind of in the opposite direction: the spec itself is actually really permissive in terms of what data you can omit and what data needs to be kept in, which in a bizar twist is actually more work to implement in a parser than to just say "well no NORMAL font would ever ... so let's just reject all fonts that do". It works, for the most part, until you hit that one, free, hand-crafted font that breaks your simplified model, or that $599 intricate Urdu font that gets the most out of OpenType =)

Changes made with 1.1.0 release!


HTTP filter manager: Support a "continue only the current filter" mode

Title: Support a way to continue encoding/decoding, but only for the current filter
Description:
In the ext_proc filter, the protocol first sends a "request_headers" message to the external processing server, waits for a response, and then decides what to do with the request body. It then may or may not send a separate message to handle the body, and so on for the response path and perhaps the trailers.
Here is one typical series of calls:

decodeHeaders() called
Dispatch async gRPC to server
Return StopAllIterationAndWatermark
Receive async gRPC reply
continueDecoding()
decodeData() called with end_stream = false -- return StopIterationAndBuffer
decodeData() called with end_stream = true
Dispatch async gRPC with body
Return StopIterationAndBuffer
Receive async gRPC reply
continueDecoding()
... Same thing on the response path ...

The problem is that at step 5 (continueDecoding) the headers are dispatched down the filter chain and can no longer be modified. What I'd like, instead, is that if the filter is configured to buffer the body that the headers will be retained until the response to the body gRPC (sent in step 8) is returned, and then everything continues. That way an external processor can modify the headers after inspecting and possibly modifying the body too.
I can almost make this happen by returning StopEncoding in step 3. But in that case, decodeData may be called before the async gRPC returns, and at that point we don't know for sure whether the server wants us to handle the body at all, or just stream it through. So if we do that, then we have to compromise on other important parts of the protocol.
In other words we get this:

decodeHeaders() called
Dispatch async gRPC to server
Return StopIteration
decodeData() called -- here we must assume that the server wants to process the body even if it doesn't. That may mean buffering things that we don't want to buffer, or forcing developers to pre-configure the processing mode for the filter rather than change it on the fly.
... after this we can probably make it work, but not without changing some important aspects of the protocol, or making the filter a lot more complicated...

What I'd rather do is replace step 5 -- the first continueDecoding -- with something like "continueLocalDecoding". This should result in my decodeData() callbacks being enabled, but should NOT result in sending the headers further down (or up) the filter chain until decodeData() returns a continue status or continueDecoding() is called properly. This is kind of like changing the "StopAllIterationAndWatermark" status into "StopIteration" status.
I THINK that this might be a simple change in filter_manager.cc to have some more options to "commonContinue". However, I'm not totally sure -- perhaps other things need to change too.
Relevant Links:
ext_proc users are asking about this:
https://github.com/envoyproxy/envoy/issues/15569

May be we can just enhance ext_proc to support mode like this and developers to pre-configure it:
decodeHeaders() called
Return Stop StopIteration.
decodeData() called with end_stream = false
return StopIterationAndBuffer
decodeData() called with end_stream = true
Dispatch async gRPC (headers) to server
Receive async gRPC (headers) reply
if need then dispatch async gRPC (body) to server and keep stop.
if no need then continueDecoding.
It should be an acceptable overhead to always cache the body when the headers need to be updated based on the results of the body GRPC reply.

Do we not already support this via the StopIteration return value? The current filter will block header iteration until continue is called, but will still receive data + trailers. It means that the ext_proc filter will need to manage receiving data etc. while there might be a pending ext_proc gRPC call, but I think this would give you the flexibility to do what you want here?
@alyssawilk might have thoughts here as well

The problem I have now is that I don't necessarily know what to do with the body chunks that come in to the filter until the reply comes back from the "request headers" message, and I don't want to just buffer the body in case it's too large for the current buffer size.
I was hoping for an easy way out, by returning StopAllIterationAndWatermark from the headers callback, and then adding some way to only partially "continue" encoding or decoding by changing the filter state so that it now behaves as if I just called StopIteration.
I'll keep working out how ext_proc might work without this. But I also tried experimenting with changes to FilterManager and it's not as easy as I had hoped!

The whole "store-and-forward" flow doesn't really work for request/responses with unbounded sizes, so I'd highly discourage it unless you have to transcode body in a non-streaming way (e.g. resize image), but even then you usually don't need to block headers.
Also, unless I'm missing something obvious, returning StopIterationAndBuffer means that ext_proc is flaky and doesn't work in a "real world", since request/response are terminated with 413/500 once they reach the buffer limit, which Envoy recommends to set to 32 KiB at the edge.

ext_proc is deliberately designed to give the server control over what callbacks and data it gets. Receiving a buffered body is one of the options that the server can choose. It's not the only option the we designed (although right now it's the only one implemented) and it's not the default -- by default ext_proc doesn't do anything with the bodies at all and doesn't buffer them.
In a lot of use cases when it's required to transform an HTTP body, it's often the case that buffering is the only choice -- there are very few data transformation technologies that operate on streaming data. I think it's important that ext_proc offer this option, but only as an option.

Hi, thanks for working on this :)
@PiotrSikora I'm curious about your comment. We have a use-case where we want to transform the body of the request, however since we are changing the body of the request we are required to change a field in the header (a crc32 hash of the body). Would there be any way to approach this besides buffering the body + headers?
Would you also discourage doing it this way in lua, which does support buffering the whole body and headers?
@gbrail We are also trying to decide between using the ext_proc filter and using lua, which does support the above. Is there any indication on how long this enhancement would take? Thanks!

I have a PR in flight that lets ext_proc process headers along with buffered bodies by using the existing callback structure, so I'm going to close this issue.
Here's the PR:
https://github.com/envoyproxy/envoy/pull/15935
it seems to be working OK so I suspect that it'll be ready in the next few days.

@dragonbone81 for something like checksum, the better approach woud be to send it in HTTP trailers, after the body, assuming that the client supports them.

@PiotrSikora Trailers would be a good solution I think, but I don't think any of the envoy filters like lua, wasm or ext_proc support them right now.
However do you think it would be a huge gain by using them? We'd still need to completely buffer the body in the proxy in order to read and modify it.
So is getHeaders->sendHeaders->getBody/modifyBody/sendBody->sendTrailers faster than
getHeaders->getBody/modifyBody/sendBody/sendHeaders
Forgive if my understanding of this is extremely rudimentary.

@PiotrSikora Trailers would be a good solution I think, but I don't think any of the envoy filters like wasm or ext_proc support them right now (except lua).

Proxy-Wasm supports trailers, but you're right, it looks that ext_proc doesn't support them yet.

However do you think it would be a huge gain by using them? We'd still need to completely buffer the body in the proxy in order to read and modify it. In the ext_proc filter we could buffer the body inside the grpc server, but it would still need to be buffered. And in the lua case it just buffered inside envoy.
So is getHeaders->sendHeaders->getBody/modifyBody/sendBody->sendTrailers faster than
getHeaders->getBody/modifyBody/sendBody/sendHeaders
Forgive if my understanding of this is extremely rudimentary.

That really depends on what kind of transformations are you doing. A lot of things can be done in a streaming fashing (e.g. (de)compression, chunk-by-chunk transcoding, HTML rewriting, etc.), in which case you don't need to buffer the complete body, and you could calculate the checksum in a streaming fashion as well.
But if for you need to buffer the complete body (e.g. you're doing on-the-fly image optimzation), then it won't matter much.

Awesome thank you for the help and insights!


Parallax effect added to website

Related Issue
Fixes #324
Description
Added a Parallax effect to the homepage of the website
Type of PR

[ ] Bug fix
[x] Feature enhancement
[ ] Documentation update
[ ] Other (specify): _______________

Screenshots / videos (if applicable)
https://github.com/Suchitra-Sahoo/AgriLearnNetwork/assets/138088550/09ed7d7a-019b-45c7-9bd7-29ca9f768e94
Checklist:

[x] I have performed a self-review of my code
[x] I have read and followed the Contribution Guidelines.
[x] I have tested the changes thoroughly before submitting this pull request.
[x] I have provided relevant issue numbers, screenshots, and videos after making the changes.
[ ] I have commented my code, particularly in hard-to-understand areas.

Additional context:
[Include any additional information or context that might be helpful for reviewers.]

@Suchitra-Sahoo Mam I've reopened the PR by solving the navbar issue, as you said me to. Kindly review and merge the PR.
Thank you!


[py2.py3] add function to coerce strings to six.binary_type

This patch is required to run python-autopxd on python3, as well as to python2.7 when a header file contains some non-ascii character.
python-autopxd already requires six, however the new ensure_binary function is currently only in the six git repository and hasn't been released to PyPI yet, therefore I temporarily copied it here.
The source comes from: https://github.com/benjaminp/six/pull/204
It's a trivial function (every py2.py3 project has its own way to do the same thing).
Fixes #12
Supersedes #3

(sorry for the typos, pressed the button too early ;)

I'm using UTF-8 as default encoding, which is also the one implied by the line
https://github.com/tarruda/python-autopxd/blob/b75f8711b3a870d9739846e91ee1f22df4df8578/autopxd/__init__.py#L319\
in 2018 I think it's ok to assume that text files will be encoded in utf-8. If we really care, we could add an --encoding command line option.

@gabrieldemarmiesse thanks, but why did you have to fork? Is the upstream project unmaintained?
@tarruda maybe you could add @gabrieldemarmiesse as a collaborator if you don't have time to maintain this any more, so he could give you a hand?

It seems there are quite a few unresolved issues in this repo. That's why I assumed it wasn't maintained. But I have the time to maintain it if I am a colaborator. I would then drop the fork.


Fix typo

declaritive -> declarative

This seems like a small (but important) contribution, so no Contribution License Agreement is required at this point. We will now review your pull request.
Thanks,
Microsoft Pull Request Bot

@jekstrom : Thanks for your contribution to the Azure documentation! The author, @Heathl17, has been notified to review your proposed change.

Good catch!  Thanks, James!
#Sign-off


lib: posix: Make sure the name string NULL termination is within the bounds

Make sure the name string NULL termination is within the bounds of the char array.
CID: 186491
Fixes Issue #8280
Signed-off-by: Subramanian Meenakshi Sundaram<EMAIL_ADDRESS>

Codecov Report

Merging #8285 into master will decrease coverage by <.01%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master    #8285      +/-   ##
==========================================
- Coverage   64.54%   64.53%   -0.01%
==========================================
  Files         420      420
  Lines       40117    40117
  Branches     6762     6762
==========================================
- Hits        25892    25891       -1
  Misses      11108    11108
- Partials     3117     3118       +1

Impacted Files
Coverage Δ

lib/posix/fs.c
48.29% <100%> (ø)
:arrow_up:

boards/posix/native_posix/timer_model.c
98.21% <0%> (-1.79%)
:arrow_down:

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 e8d0e72...b747b1f. Read the comment docs.


Deleted files on desktop

Issue Type: Bug
I have no clue how this happened but some how I saw a bunch of my files on my desktop on vs code... as desktop git? I didn't know what was going on... saw i discarded everything which was about 5000 files..... then now I lost a lot of files on my desktop some how?
 How did you see this? Did you discard all your changes?


Updating tools

@kwatkins If you take this change you'll have to update a few things. Let me know what you think?

Should be fine.


Fix build on Linux

Moving one DPF include after X11/Xresource.h fixes the issue.

Just tried compiling a fresh clone of 9538417 and it works, go figure.

External UI is not part of the default build though, so this error is not caught by default now.


Spelling OCD

Apologies I can't help myself.

We honestly love these contributions! If you see any more typos, please send us more PRs like this one


Balloon toolbar appears in a wrong place when editor is inside div with overflow:auto

Hi!
Sorry for raising so many issues, but I'm currently implementing the editor in the app and finding out many new things. I've found out, that when I use editor inside a div that has scrollbars (constant height with set overflow to auto), position of toolbar is calculated wrong and appears way too high. I've created a reproduction environment on codesandbox: https://codesandbox.io/s/suneditor-scrolled-down-toolbar-yumjh
Also, screeenshot:

Cheers!

Hi, @tswistak
Thank you so much.
I'll fix the bug and apply it to the next version.


video-viewer strange cpu usage

I'm on Jetson Nano 4GB (JetPack 4.5) and testing the scripts provided as examples with docker. On executing the video-viewer, I encountered the following strange results:
Test 1
video-viewer --input-codec=h265<EMAIL_ADDRESS>cpu usage: ~107%
Test 2
video-viewer --input-codec=h265 --input-height=1080 --input-width=1920<EMAIL_ADDRESS>cpu usage: ~23%
My camera resolution is 1920x1080 and streams 25 fps. Why there is such a difference on cpu utilization just by adding the input-width and input-height parameters? Both commands give the desired output (i'm able to see the image from the camera on my screen).

Hi @pbouzon-iter, specifying --input-width and --input-height will use the hardware rescaler to change the resolution.  Are you sure it isn't running at a different resolution without --input-height=1080 --input-width=1920

Hi @dusty-nv, i'm pretty sure it's running with the expected resolution. That's what i see on the terminal when running the video-viewer without specifying the --input-width and --input-height.

@dusty-nv i've made a mistake on checking the cpu usage when setting the --input-width and --input-height parameters, now i'm having both ways with ~107% cpu usage.
Thank's for your reply and sorry for taking your time.


[Add-ins] Remove all Add-ins docs from this doc set.

The Outlook add-ins docs are being moved into the Office Add-ins doc set (stored in the OfficeDev/office-js-docs-pr repo). Redirects are being added (as part of this PR) for all articles that are being removed.

Docs Build status updates of commit cb8ce8f:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

.openpublishing.redirection.json
:white_check_mark:Succeeded

docs/actionable-messages/invoke-add-in.md
:white_check_mark:Succeeded

docs/actionable-messages/message-card-reference.md
:white_check_mark:Succeeded

docs/add-ins/activation-rules.md
:white_check_mark:Succeeded

docs/add-ins/add-and-remove-attachments-to-an-item-in-a-compose-form.md
:white_check_mark:Succeeded

docs/add-ins/add-in-commands-for-outlook.md
:white_check_mark:Succeeded

docs/add-ins/add-in-requirements.md
:white_check_mark:Succeeded

docs/add-ins/add-mobile-support.md
:white_check_mark:Succeeded

docs/add-ins/addin-tutorial.md
:white_check_mark:Succeeded

docs/add-ins/apis.md
:white_check_mark:Succeeded

docs/add-ins/authenticate-a-user-with-an-identity-token.md
:white_check_mark:Succeeded

docs/add-ins/authenticate-a-user-with-an-sso-token.md
:white_check_mark:Succeeded

docs/add-ins/authentication.md
:white_check_mark:Succeeded

docs/add-ins/categories.md
:white_check_mark:Succeeded

docs/add-ins/compare-outlook-add-in-support-in-outlook-for-mac.md
:white_check_mark:Succeeded

docs/add-ins/compose-scenario.md
:white_check_mark:Succeeded

docs/add-ins/contextual-outlook-add-ins.md
:white_check_mark:Succeeded

docs/add-ins/delegate-access.md
:white_check_mark:Succeeded

docs/add-ins/extension-module-outlook-add-ins.md
:white_check_mark:Succeeded

docs/add-ins/extract-entity-strings-from-an-item.md
:white_check_mark:Succeeded

docs/add-ins/get-and-set-item-data-in-a-compose-form.md
:white_check_mark:Succeeded

docs/add-ins/get-and-set-recurrence.md
:white_check_mark:Succeeded

docs/add-ins/get-attachments-of-an-outlook-item.md
:white_check_mark:Succeeded

docs/add-ins/get-or-set-the-location-of-an-appointment.md
:white_check_mark:Succeeded

docs/add-ins/get-or-set-the-subject.md
:white_check_mark:Succeeded

docs/add-ins/get-or-set-the-time-of-an-appointment.md
:white_check_mark:Succeeded

docs/add-ins/get-set-or-add-recipients.md
:white_check_mark:Succeeded

docs/add-ins/images/add-in-permission-tiers.png
:white_check_mark:Succeeded

docs/add-ins/images/addin-tutorial/add-in-buttons-in-owa.png
:white_check_mark:Succeeded

docs/add-ins/images/addin-tutorial/add-in-buttons-in-windows.png
:white_check_mark:Succeeded

docs/add-ins/images/addin-tutorial/addin-prompt-configure.png
:white_check_mark:Succeeded

docs/add-ins/images/addin-tutorial/addin-settings.png
:white_check_mark:Succeeded

docs/add-ins/images/addin-tutorial/addin-taskpane.png
:white_check_mark:Succeeded

docs/add-ins/images/addin-tutorial/button-and-pane.png
:white_check_mark:Succeeded

docs/add-ins/images/addin-tutorial/yeoman-prompts-2.png
:white_check_mark:Succeeded

docs/add-ins/images/bing-maps-add-in.jpg
:white_check_mark:Succeeded

docs/add-ins/images/block-on-send-body.png
:white_check_mark:Succeeded

docs/add-ins/images/block-on-send-subject-cc-inforbar.png
:white_check_mark:Succeeded

docs/add-ins/images/commands-collapsed.png
:white_check_mark:Succeeded

docs/add-ins/images/commands-menu-button-1.png
:white_check_mark:Succeeded

docs/add-ins/images/commands-normal.png
:white_check_mark:Succeeded

docs/add-ins/images/commands-overflow-menu-expand-web.png
:white_check_mark:Succeeded

docs/add-ins/images/commands-overflow-menu-web.png
:white_check_mark:Succeeded

docs/add-ins/images/commands-task-pane-button-1.png
:white_check_mark:Succeeded

docs/add-ins/images/commands-uiless-button-1.png
:white_check_mark:Succeeded

docs/add-ins/images/compose-form-commands.png
:white_check_mark:Succeeded

docs/add-ins/images/contextual-window.png
:white_check_mark:Succeeded

docs/add-ins/images/outlook-detected-entity-card.png
:white_check_mark:Succeeded

docs/add-ins/images/outlook-detected-entity-highlight.png
:white_check_mark:Succeeded

docs/add-ins/images/outlook-mobile-addin-interaction-android.gif
:white_check_mark:Succeeded

This comment lists only the first 50 files in the pull request.
For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

@ElizabethSamuel-MSFT here's the PR that removes all of the Outlook add-ins docs from outlook-dev-docs. Please review when you have time. Thanks!


RHEL 7.6: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found

Prerequisites

[X] Put an X between the brackets on this line if you have done all of the following:

Reproduced the problem in Safe Mode: https://flight-manual.atom.io/hacking-atom/sections/debugging/#using-safe-mode
Followed all applicable steps in the debugging guide: https://flight-manual.atom.io/hacking-atom/sections/debugging/
Checked the FAQs on the message board for common solutions: https://discuss.atom.io/c/faq
Checked that your issue isn't already filed: https://github.com/issues?utf8=✓&q=is%3Aissue+user%3Aatom
Checked that there is not already an Atom package that provides the described functionality: https://atom.io/packages

Description
Under RHEL 7.6, with libstdc++.x64 version 4.8.5-36.el7, when running atom nothing is appearing. Looking at ~/.atom/nohup.out:
A JavaScript error occurred in the main process
Uncaught Exception:
Error: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by /usr/share/atom/resources/app.asar.unpacked/node_modules/nslog/build/Release/nslog.node)
    at process.module.(anonymous function) [as dlopen] (ELECTRON_ASAR.js:166:20)
    at Object.Module._extensions..node (module.js:671:18)
    at Object.module.(anonymous function) [as .node] (ELECTRON_ASAR.js:180:18)
    at Module.load (module.js:561:32)
    at tryModuleLoad (module.js:504:12)
    at Function.Module._load (module.js:496:3)
    at Module.require (module.js:586:17)
    at require (internal/module.js:11:18)
    at Object.<anonymous> (/usr/share/atom/resources/app.asar/node_modules/nslog/lib/nslog.js:5:11)
    at Object.<anonymous> (/usr/share/atom/resources/app.asar/node_modules/nslog/lib/nslog.js:15:4)

Looking at available GLIBCXX_*:
$ strings /lib64/libstdc++.so.6 | grep GLIBCXX
GLIBCXX_3.4
GLIBCXX_3.4.1
GLIBCXX_3.4.2
GLIBCXX_3.4.3
GLIBCXX_3.4.4
GLIBCXX_3.4.5
GLIBCXX_3.4.6
GLIBCXX_3.4.7
GLIBCXX_3.4.8
GLIBCXX_3.4.9
GLIBCXX_3.4.10
GLIBCXX_3.4.11
GLIBCXX_3.4.12
GLIBCXX_3.4.13
GLIBCXX_3.4.14
GLIBCXX_3.4.15
GLIBCXX_3.4.16
GLIBCXX_3.4.17
GLIBCXX_3.4.18
GLIBCXX_3.4.19
GLIBCXX_DEBUG_MESSAGE_LENGTH

GLIBCXX_3.4.21 is not available.
Steps to Reproduce

Upgrade / install atom-1.35.0 from RPM package repository.
Run atom.

Expected behavior: Atom window appearing.
Actual behavior: Nothing is appearing
Reproduces how often: 100%
Versions
RHEL 7.6 with atom-1.35.0-0.1 installed from official RPM repository.

UPDATES
Did a test with new version 1.35.1 and works again perfectly ! I think this issue can be closed ?

Every number has to stay the same due to a an old memories on simpler devices using simpler technology

Did a test with new version 1.35.1 and works again perfectly ! I think this issue can be closed ?

I don't have a RHEL to test with so if things are working for you we can close this out :+1:  I did poke around a bit though and it seemed like this was an issue with RHEL?  ref: https://access.redhat.com/discussions/3405861


os/fsnotify: add new package

Issue for creating standard fsnotify package (current exp/inotify)

Just in case someone lands here from the search there's also another library with API similar to os/signal - https://github.com/rjeczalik/notify.

Well ! It's a good new because only two libraries work but each has specific running (recursive or not…). Make a « official » lib is good to unify the golang environment. +1

At this point I don't know if it makes sense to have os/fsnotify in the standard library. Maybe an x/fsnotify package to benefit from Gerrit, the cross-platform builders, and the CLA process. That would also make it  more official, but without have a compatibility promise.
Whether that's based on the current revision of fsnotify or @rjeczalik's library, I'm not sure. I've been meaning to take a closer look at notify.

At this point, and in light of burnout among the core team, I think this issue can be safely closed. Please correct me if I'm wrong.

With internal/ packages, tools like guru, godoc, and even the go command can technically make use of fsnotify or @rjeczalik's notify without needing a public API in standard library or x/.
Fsnotify will remain under a BSD license (3-clause or 2-clause), but perhaps there is a caveat with the CLA situation if it is a non-Google project?
In time, we will hopefully have a way to ensure that (foundational) libraries like fsnotify and grpc-go run everywhere that Go does. #17312

If anyone reading this has the bandwidth and interest in file system notifications, you are certainly welcome to contribute as much or little as you like over at https://github.com/fsnotify. Thanks.

Closing this, as requested.


Release 1.0

cherry-pick #372 for v0.27.x

Codecov Report

Merging #380 (4a89e09) into release-1.0 (a3e27bc) will decrease coverage by 0.36%.
The diff coverage is n/a.

@@               Coverage Diff               @@
##           release-1.0     #380      +/-   ##
===============================================
- Coverage        80.57%   80.20%   -0.37%
===============================================
  Files               20       20
  Lines              767      763       -4
===============================================
- Hits               618      612       -6
- Misses             135      137       +2
  Partials            14       14

Impacted Files
Coverage Δ

pkg/vsphere/adapter.go
62.59% <0.00%> (-1.53%)
:arrow_down:

plugins/vsphere/pkg/command/flags.go
100.00% <0.00%> (ø)

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 a3e27bc...4a89e09. Read the comment docs.


Default start command doesn't support graceful shutdown

By default, when you build a node app the start command is going to be npm start.
https://github.com/paketo-buildpacks/npm/blob/master/npm/build.go#L112
This results in a process tree for a running app that looks like this:
Dr-No:node-signals dmikusa$ docker exec -it afc ps auxf
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
vcap        31  0.0  0.1  34404  2760 pts/1    Rs+  13:22   0:00 ps auxf
vcap         1  0.0  0.0   1052     4 pts/0    Ss   13:21   0:00 /sbin/docker-in
vcap         6  1.2  2.3<PHONE_NUMBER>6 pts/0    Sl+  13:21   0:00 npm
vcap        23  0.0  0.0   4632   784 pts/0    S+   13:21   0:00  \_ sh -c node
vcap        24  0.2  1.6<PHONE_NUMBER>0 pts/0    Sl+  13:21   0:00      \_ node ap

You have npm, which starts sh which starts node. Unfortunately, npm doesn't relay SIGTERM to it's child processes and wait for them to stop, so if you issue docker stop on this container it stops immediately and an shutdown hooks registered with process.on() do not fire.
You can test this with the attached sample app.

pack build node-signals
docker run -it node-signals
Then in another terminal run docker stop on the container

You'll see that it exits immediately and you don't see the messages on exit.
If you add --init and -e TINI_KILL_PROCESS_GROUP=1 to the docker run argument, it gets a little better. Sometimes you can see the message logged that the SIGTERM was caught, but it doesn't wait for the full shutdown.
It appears that npm doesn't relay the SIGTERM. It does relay SIGINT, which you can confirm by repeating the test above and using docker kill -s SIGINT. That doesn't help a log though because the default behavior on Kubernetes and Cloud Foundry is to send a SIGTERM followed by a SIGKILL after a certain timeout period.
Having graceful shutdown work out of the box is important. It's expected by developers so, while you can just override the start command with node app.js and get graceful shutdown working, I don't believe that's an OK solution. It should Just Work™.
Any solution that supports graceful shutdown by default would be acceptable. One possibility, would be to pull the start command out of package.json and copy that as the start command. This would a.) fix graceful shutdown and b.) remove npm and an extraneous shell from the list of running processes. Both wins, IMHO.
It appears that npm start isn't doing much, just setting up PATH and running the command so that seems feasible for the buildpack to handle that instead.
node-signals.tar.gz

More conversation/backstory here -> https://paketobuildpacks.slack.com/archives/CU8RVQZ1R/p1590704049052600

Thanks for reporting the issue with details. We have a plan in the pipeline to split the current npm cnb into 3 cnbs - one that provides the npm executable on the PATH, one that installs the dependencies, one that provides the start command. So it looks like if the start-cmd cnb is smart enough to parse the package.json and and construct a command that calls node directly with appropriate arguments, this issue would go away. We should be able to factor this issue in when we are working on the cnb refactor, which should be soon.
cc @dwillist @thitch97 @kvedurmu

Closing this. This is now resolved in the latest version of the Node.js buildpack. Yarn/NPM start commands both support graceful shutdown, but this was implemented without the use of Tini. See https://github.com/paketo-buildpacks/yarn-start/blob/main/rfcs/0002-reimplement-start-command.md and https://github.com/paketo-buildpacks/npm-start/blob/main/rfcs/0002-reimplement-start-command.md for the issues we discovered with Tini.


REST-api not working

Service gives response code 200 but no content
Tested also here:
http://api.annif.org/doc/#!/Automatic32subject32indexing/post_autoindex

Server has run out of disk space. Fixing...
We've started a new implementation at https://github.com/NatLibFi/Annif . It will take a while to reach the level of functionality in this prototype though. Eventually the new implementation will supersede this one. You may want to follow development.

Should be working now.

Works, thanks!
BTW: We have Annif now in our Master's thesis online publishing form so that users can choose keywords by themselves (planned to run in production in December). Do you think that this rest api is more or less permanent during development?

We will notify you before any major changes. But eventually this REST API will probably go away (since it's really a prototype, not something we expect to maintain in the long term), replaced by the new implementation that has a similar REST API but with more functionality. It has an analyze method which does the same as this API.
You may have to adjust the API endpoint URL and some parameters in your application code. I expect that both APIs will be available in parallel for a while.

Ok, good to know.


Swagger UI documentation - what is a nodegroup?

The comments describing each method in the REST API are inconsistent - some refer to a "nodegroup id" and some refer to a "nodegroup json" without explanation. Some just refer to a "nodegroup", which is ambiguous.

Doing file searching in https://github.com/ge-high-assurance/RACK/wiki/REST-API-Swagger-Demo I'm not sure I know which references you're pointing at.

I'm actually referring to the page in Swagger that describes the NodeGroupExecution service, which can be accessed as
http://rack.server.com:12058/swagger-ui.html#/node-group-execution-rest-controller


Update material-top-tab-navigator.md

READ ME PLEASE!
TL;DR: Make sure to add your changes to versioned docs
Thanks for opening a PR!
The docs cover several versions of react-navigation, and in some cases there are several files (for version 1, version 2 and etc.) that all describe a single page of the docs (eg. "Getting Started").
Please make sure that the edit you're making in docs/file-you-edited.md is also included in the file for the correct version, eg. /versioned_docs/version-3.x/file-you-edited.md for version 3. If such file doesn't exist, please create it. :+1:

Sorry its my first time PR into this repo not sure If I've done it right but essentially I've copied this line 3 times now and each time I've got a syntax error in my project so thought id rather change it your side this time!


Add CLI support for user bind mounts.

With this, the user bind mounts can be specified via the -B command line flag.
Also moves the user bind mount code out of sexec.c.

Thanks, merged!


Problem with epochs

Hey. Today I tried to install lib32-sdl2_mixer, which has lib32-smpeg2 as a dependency.
lib32-smpeg2 needs the 64-bit smpeg2 to compile, but smpeg2, unlike lib32-smpeg2 uses an epoch, so in the lib32-smpeg2 PKGBUILD you'll find:
depends=("${pkgname#*-}=1:$pkgver")

However, upon trying to install lib32-sdl2_mixer I got an error, saying something along the lines of smpeg=1 not found (I lost the output when my terminal crashed for some reason, and I'm not willing to got through the installation again, I'm glad I got it installed), but it definitely wanted to find smpeg version 1.
I initially thought that it was the PKGBUILD's fault, but I tried manually building the package and and had no problems whatsoever.

Indeed, thanks for the report. Seems that is a regression when I did some cleanup in 2c28bec0af4b4ed3f52286d3d1f4d4acae7bdf1e. This is now fixed in 81afd122adfb3e6fbf1bc926ca7732bec0ca22bf. Available in pacaur-git.


#3779: Benchmarking for mistral TT model

This Branch contains test_perf_accuracy_mistral file for mistral model.
Which does benchmarking of TT model using Hellaswag dataset.

Here is the passing CI Links
[post-commit] Run all post-commit workflows Link
Scheduled slow dispatch frequent build and run Link


Add Dynatrace as APM integration

Created dynatrace-metrics doc
Updated _index.md
Left some TODOs where I was not sure how to do it

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.Ekrem Sekerci seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.

Thanks @MarkvanMents . Looks good and ready to go out. I'll let you know once we release the integration (probably next Thursday) so we can get this out as well.


[ML-9890] Add tests for all primitive types

df: DataFrame
rows=df.collect()
Tensor (in Dataset)
Evaluated tensor dtype
Evaluated tensor element type

BooleanType
bool
bool
np.bool_
bool_

ByteType
int
int8
np.int8
int8

ShortType
int
int16
np.int16
int16

IntegerType
int
int32
np.int32
int32

LongType
int
int64
np.int64
int64

FloatType
float
float32
np.float32
float32

DoubleType
float
float64
np.float64
float64

StringType
str
string
np.object_
bytes

BinaryType
bytearray
string
np.object_
bytes

What changes are proposed in this PR?
Add tests for primitive types that petastorm supports. Added ByteType, StringType and BinaryType.
Why these changes are needed?
These tests make it clear which column type is mapped to what types in the tensor.

Codecov Report

Merging #5 into master will increase coverage by 0.03%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master       #5      +/-   ##
==========================================
+ Coverage   85.56%   85.59%   +0.03%
==========================================
  Files          80       80
  Lines        4233     4235       +2
  Branches      668      668
==========================================
+ Hits         3622     3625       +3
  Misses        503      503
+ Partials      108      107       -1

Impacted Files
Coverage Δ

petastorm/spark/spark_dataset_converter.py
100% <100%> (+2.32%)
:arrow_up:

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 08eb10c...5ba9762. Read the comment docs.


[SUP-498] Pause cloud compute from clusters page

For Reviewers
I'm experimenting with something new in hopes of easing PR reviewing (feedback welcome) where the PR can be viewed in three separate diff's as listed below.

Functional changes
Mostly refactoring/non-functional changes
IntelliJ reformatter changes
PR Feedback #1 to
i. improve responsiveness of the page after clicking Pause
ii. fix a pre-existing case where a cell would be displayed as blank upon clicking Delete for a disk while it's in Deleting status
iii. make minor non-functional  improvements

Ticket
https://broadworkbench.atlassian.net/browse/SUP-498
Screenshots
Dev

PR Branch

Tooltip message when buttons are disabled:

Highlights

Name the last column on the tables on Cloud Environments page as Actions and Action.
Add Pause button alongside Delete button on the Cloud Environments table.
Label Pause and Delete buttons.
Display disabled buttons in a lighter shade of grey for higher contrast with enabled buttons.
Do some refactoring along the way to reduce code duplications.

Testing

Locally deployed the changes and ran against dev backends.

I tested a little bit, a few comments:

I feel like pause from the Cloud Environments page suffers from the "immediate feedback" problem. When I click pause nothing happens initially -- only after the page auto-refreshes ~10 seconds later do I see the status change to "Stopping". It feels like it'd be nicer to have the change reflected on the page immediately after click.

When a runtime or Galaxy is paused, I see a greyed-out Pause button. Should there be a Resume button instead?

I see a browser console warning when clicking pause:

Warning: Can't perform a React state update on an unmounted component. This is a no-op, but it indicates a memory leak in your application. To fix, cancel all subscriptions and asynchronous tasks in a useEffect cleanup function.
    at ComputeModalBase (http://localhost:3000/static/js/1.chunk.js:3510:25)

Thanks for the testing @rtitle.

I feel like pause from the Cloud Environments page suffers from the "immediate feedback" problem. When I click pause nothing happens initially -- only after the page auto-refreshes ~10 seconds later do I see the status change to "Stopping". It feels like it'd be nicer to have the change reflected on the page immediately after click.

I agree. This exists in dev too but I'll see if I can improve it opportunistically.

When a runtime or Galaxy is paused, I see a greyed-out Pause button. Should there be a Resume button instead?

No, this ticket was scoped to only having the pause functionality. I agree though that it'd be nice to add a resume functionality at which time it'd make sense to have the button label and icons toggle between pause and resume.

I see a browser console warning when clicking pause
TL;DR: It's been a known situation and doesn't indicate a problem in our case. We have a wrapper around API calls that allows for setting a flag before and after making the API call. The one that's made after the API call triggers this warning because it happens after the component is unmounted. Since the flag we're updating isn't dependent on the component being mounted, it doesn't cause any issues for us.

I feel like pause from the Cloud Environments page suffers from the "immediate feedback" problem. When I click pause nothing happens initially -- only after the page auto-refreshes ~10 seconds later do I see the status change to "Stopping". It feels like it'd be nicer to have the change reflected on the page immediately after click.

@rtitle This issue should be resolved now. Upon clicking Pause, the UI will display the usual spinner while it gets a response from Leo. Upon receiving the response, the spinner will disappear and the tables will have updated values/button states.


write models/predict_model.py and test_predict_model

idea:
Class Predict:
       __init__(hydra_config, path_to_chph):
               self.tokenizer = ..
               self.model = .. load(ckph)
       predict(string):
               tokenized = self.tokenizer(string)
               preds = self.model(tokenized)

use this class then in cloud function local / anywhere else.

@still we have no tests.

works


Intermediate stop border point information in trip leg

Addition of border point in the trip response, to indicate which intermediate stop is the border between two or more countries.

4.0.0 version looks good.

We can add changes to 3.4.1. It has not been released yet. Do not bump patch version yet, please.

Thank you @jspetrak for the review. PR updated


Client-Side and Server-Side validation for Enterprise store Publisher

This feature is to provide a framework of client and server side validations of CRUD forms.

Closing the PR, since changes are conflicting with the latest changes. Please fix the conflicts and reopen the PR, if you need to add this change


Carousel show item view incorrect region.

###Question.
(Write your answer here.)
I'm using your Carousel in my application, which is developing in react native language.
Installation & usage is easy of this carousel.
My carousel open after select an particular item from flat list.
Sometimes it how wrong origin of the view in carousel.
Please look at following screenshots.

Please let me know, if anybody faced this issue.

Please provide a Snack example in which the issue can be reproduced.

Closing as no further feedback has been provided.


CSharp Client Generator - Not returning result nor throwing exception for non-success HTTP status codes if IsPlainText = true

Hi,
I'm having an issue trying generate a C# client out of an OpenAPI spec which contains plain/text responses.
Specifically, I have this error telling me that not all code paths return a value if the operations have non-success HTTP status codes as you can see below:

I think that the problem happens here:
https://github.com/RicoSuter/NSwag/blob/1c836ee3cc766ce25f3170618a5d12e5e96fde61/src/NSwag.CodeGeneration.CSharp/Templates/Client.Class.ProcessResponse.liquid#L15
Basically we will need to add an else block to deal with that non-success HTTP codes and throw an exception properly.
Does that make sense? If it does I can fix this and raise a PR.
Thanks!

As a work-around, I have to downgrade the nuget package "NSwag.ApiDescription.Client" to version "13.6.2".
This is an issue with the nuget package "NSwag.ApiDescription.Client" version "13.7.0" and higher.

So it's currently producing code which does not compile?

So it's currently producing code which does not compile?

@RicoSuter, exactly.

And just a regular
return result_;

would be enough?

Either that, or throw an exception as we are doing for the "response to object deserialization case":

I think this should fix it:
https://github.com/RicoSuter/NSwag/pull/3530
What do you think?

Super thx for checking.
Is this fix urgent for you? For now you could also use the new template file and replace it via the replacement directory option...

@RicoSuter no urgency at all, actually I did exactly that as a workaround :) I'll remove my template once the new version is released.
Thanks!

Hi.
I tried to use the updated template file Client.Class.ProcessResponse.liquid but I get the following compiler error:
error CS0103: The name 'objectResponse_' does not exist in the current context

I'm using the NSwag.ApiDescription.Client nuget package version 13.11.3.
    <OpenApiReference Include="ApiClient.json" CodeGenerator="NSwagCSharp" Namespace="MyNamespace.ApiClient" ClassName="ApiClient" Options="/ClientBaseClass:ApiClientBase /UseHttpRequestMessageCreationMethod:true /TemplateDirectory:template">
      <SourceUri>http://localhost/MyWebApplication/docs/v1/swagger.json</SourceUri>
      <OutputPath>..\ApiClient.cs</OutputPath>
    </OpenApiReference>

Any ideas?
Thank you.


Updated Typo

Checklist:

[x] I have read freeCodeCamp's contribution guidelines.
[x] My pull request has a descriptive title (not a vague title like Update index.md)
[x] My pull request targets the main branch of freeCodeCamp.
[x] I have tested these changes either locally on my machine, or GitPod.

Closes #48498

As a new contributor, we encourage you to read our contributing guidelines.
We expect our contributors to be aware of the process specific to this project. Following the guidelines religiously earns you the respect of fellow maintainers and saves everyone time.
Some examples of this are:

Do not edit files directly through GitHub – while you can, it's not a good idea.
Make sure you follow the PR checklist and not just tick things off; otherwise, we won't take you seriously.
Use the correct way to link issues in the description of the PR by updating the XXXXXX. Do not just add issue numbers everywhere and anywhere you feel like.
Keep mentions and review requests to a minimum. We understand you are excited about contributing, and our maintainers will get back to you as soon as they get a chance.
Do not work directly off your main branch - create a new branch for the changes you are working on.

We appreciate you taking the time to help us, and we hope to see more contributions from you.
Happy Contributing.

Hey there,
This issue has been resolved by #48517. Please note that we typically accept the first pull request which comprehensively resolves an issue and follows our contributing guidelines.
Thanks again! 😊

If you have any questions, feel free to ask questions on the "Contributors" category on our forum or the contributors chat room.


CODE

Hello, I am very interested in your research. Could you provide the code based on the HPT model? Thank you.

How can the NYT dataset be accessed for free?


Error - TagsInput & Custom Component [Cannot read property 'transformer' of undefined - components.js:177]

Hi,
At first, have found the tcomb* to be a high quality of library and nicely written and organized too - Thanks!.
Am trying to achieve a custom component or factory, simple ones as provided in guide or one of the issues - unable to get it working.

tcomb-form v0.9.0?
react v0.14.3?

Error is
components.js:177 Uncaught TypeError: Cannot read property 'transformer' of undefined

from chrome debugger this is where it fails and options is undefined
Component.prototype.getTransformer = function getTransformer() {
    return this.props.options.transformer || this.constructor.transformer;
  };

I tried both the examples provided in Guide and one another issue #280
example code in guide is:
import TagsInput from 'react-tagsinput';

class TagsComponent extends t.form.Component { // extend the base class

  getTemplate() {
    return (locals) => {
      return (
        <TagsInput value={locals.value} onChange={locals.onChange} />
      );
    };
  }

}

export default TagsComponent;

Assuming that the transformer was required to be provided within the custom / extended component thus included the same as below from #280 but still error remains same:
const template = t.form.Form.templates.textbox.clone({
  // override just the textbox rendering...
  renderTextbox: (locals) => <TagsInput value={locals.value} onChange={(tags) => locals.onChange(tags)} />
})

class TagsComponent extends t.form.Component {

  static transformer = {
    format: (value) => value || [],
    parse: (value) => value
  };

  getTemplate() {
    return template
  }

}

export default TagsComponent;

And the usage is as below (not sure if it could be different way to use)? - please help/hint on what could be wrong in this scenario - very important to crack a sample custom component / factory to move ahead.
Have also tried to attach a transformer in options which is passed to <Form options={options}/> - still no luck.
TCombSample = React.createClass({

onClick: function () {
    var value = this.refs.form.getValue();
    // getValue returns null if validation failed
    if (value) {
      console.log(value);
    }
  },
render: function() {

	var Person = t.struct({
	  name: t.Str,
	  surname: t.Str,
	  tags: t.list(t.String)
	});

	var options = {
	  fields: {
	    tags: {
	      factory: TagsComponent
	    }
	  }
	};

  return (
				<div>
				<Form ref="form" type={Person} options={options} />
				<button onClick={this.onClick}>Click me</button>
				</div>

			)
	}
});

export default TCombSample

Thanks!

Please close this issue.
It looks to be the order issue while trying things in a compact manner from a single file.
Thanks.


Add support for subqueries

SELECT, INSERT, UPDATE, and DELETE statements.

Select Statement (excluding where clause) - https://github.com/mjovanc/njord/pull/135

Insert subquery: https://github.com/mjovanc/njord/pull/146


URL name not updated if file reselected on new publish

If you select a file, the URL is auto populated. If you reselect a file in the same process, it won't update after the new one.

This is now fixed.


Fix rounding

There was still the issue with 2 digits in the DateTable for tempTargets
also another place in TT state model

No. It is rounded  in a closure higher up already. Thus this PR serves no purpose

@Jon-b-m try to put in 8.1mmol/L as temp target and when switch to mg/dL.

It will also be saved with one decimal im mg/dL.
This commit fixes this and also that the data table displays converted TT with 2 decimals.

I tested current code. It converts fine already mmol/L <-> mg/dl. Your code is outdated. You need to sync updates.

I did the screens just now with current dev.
But I guess you worked on the TT thing and fixed with that. Did you fix the History Table too?


Use CUB by default

/test mini

Will you do docs in separate PR or in this PR?
We will need to add test variant for CUPY_ACCELERATOR="" case.

@kmaehashi Updated. PTAL!

We will need to add test variant for CUPY_ACCELERATOR="" case.

Did it in: https://github.com/cupy/cupy/pull/6580

Could you fix doctest failure? https://ci.preferred.jp/r/job/97008

Add that this difference does not apply when CUB is enabled (CuPy v11+)
https://docs.cupy.dev/en/latest/user_guide/difference.html#nan-not-a-number-handling
Use env:CUPY_ACCELERATORS: "" instead of env:CUPY_ACCELERATORS: null so that doctests run with CUB disabled: https://github.com/cupy/cupy/blob/42718a96a1de4c9d1007624add585eda7239350f/.pfnci/matrix.yaml#L339-L362

/test full

Ah wait, this is not done yet 😅

Add that this difference does not apply when CUB is enabled (CuPy v11+)
https://docs.cupy.dev/en/latest/user_guide/difference.html#nan-not-a-number-handling

/test full


Streamline token chaincode params initialization

Current approach
The Fabric chaincode needs the fabric --init-required functionality: when deploying, before any other transaction, one party has to call the init function which then stores the public params on the ledger.
This is not the most ergonomic feature, because:

Low support by tooling (notably Fabric Smart Client - but also the Fabric Ansible Scripts barely support it)
It forces a deployment model that mixes infrastructure with application, especially if you use chaincode as a service (back and forth between fabric and configuration of the application)
Not so lenient for mistakes (have to deploy a new version of the chaincode, with a new chaincode id, update config, etc, which requires Fabric knowledge).

From the Fabric docs:

Note that in most scenarios it is recommended to embed initialization logic into chaincode rather than use the chaincode lifecycle mechanism described above. Chaincode functions often perform checks against existing state, and initialization state can be implemented like any other chaincode state and be checked in subsequent chaincode function calls. Handling initialization state within chaincode logic rather than with the chaincode lifecycle mechanism has the benefit that you are not limited to a single initialization function, rather you are in full control of initialization logic and can call your own functions that initialize state from an application consistent with how all other application functions are called.

The flow of the init function is as follows:
Init -> ReadParamsFromFile -> if empty use builtInParams -> write to ledger

And when doing a transaction:

Invoke
GetValidator
cc.Initialize
Get params from memory. If not in memory: ReadParamsFromFile -> if empty use builtInParams
Validate
Store actions
AddPublicParamsDependency - adding a Read for the params on the ledger without using them.

As far as I can tell this means that if an endorser changes their public params file and restarts the chaincode, transactions will fail because they're the only one reading it from the file.
Proposal

Allow initializing token chaincode with a normal invoke instead of --init-required. It doesn't change the trust assumptions because init has the same endorsement policy as normal functions.
Let cc.Initialize get the params from the ledger, to enforce unity across endorsers and FSC nodes (makes it easier to reason about / debug). Log a warning if they don't match with the file (alternatively we could do that as part of AddPublicParamsDependency if the performance cost is low).
Allow the new init function to be called more than once, to update the params without deploying a new chaincode. It's easier to coordinate because endorsers can change the params file as part of normal operations instead of going through the install/endorse/commit/init ritual for new chaincode. There can be zero downtime if we let cc.Initialize use the ledger truth until we explicitly update it. Does it change the trust assumptions? From lifecycle endorsement policy (new chaincode version required), officially we go to the chaincode endorsement policy (writing a key) for updating params. But technically this is already the case: if a quorum signs a rwset with new params (bypassing the chaincode logic), that's the new committed reality for the network - also in the current setup.

If you agree with the proposal I can make a PR.

Hi @arner , thanks for reporting this issue.
I have a question: Who should be able to perform the update? Should the chaincode enforce some access control on the creator of the proposal?

As far as I understand, we currently don't have that. Even though we require Init, and don't have a function for updates, we can't stop a quorum of endorsers from crafting a rwset offline, signing it and getting it committed. In my view, if that possibility is there, any hurdle in the chaincode is just cosmetic. In my proposal there is already a conscious decision by the endorsers to do the update, because they each have to manually update the parameters in their chaincode before someone invokes the update transaction (similar to the current way but easier). Contrary to, for instance, approving a transfer, which is done automatically by the chaincode and has no human oversight.
If we want to enforce access control on who initiates the invoke, maybe an option could be key-level endorsement: that can be set to be stricter than the normal endorsement policy. Whether to use it and how to configure it would be different per use case though.

so, the endorsement policy is the trust assumption that covers also against a subset of malicious endorsers that come together and try to update the namespace without an actual request from a user. So, it must set properly to avoid also this.
In this sense, we don't have the issue you point to.
I agree anyway that the process is not the simplest. Unfortunately, it would not be efficient to retrieve for each request the state from the ledger. We must cache it in some way.
So, to summarize, I find it risky to allow anyone to submit new public parameters. The honest endorsers would have no way to check if they must accept these params or not.
But what if we say that the issuer can update the public params? Would this be fine? We can ask the token-sdk to check such a signature. Wdyt?

so, the endorsement policy is the trust assumption that covers also against a subset of malicious endorsers that come together and try to update the namespace without an actual request from a user. So, it must set properly to avoid also this.
In this sense, we don't have the issue you point to.

Agree. It means that (currently/by default) the rules are the same to update any key on the ledger. So a subset of malicious endorsers could arbitrarily reassign ownership of tokens, or change the issuer in the public parameters. I guess this is ok because both are pretty catastrophic, so we'd ensure a strong policy anyway.

I agree anyway that the process is not the simplest. Unfortunately, it would not be efficient to retrieve for each request the state from the ledger. We must cache it in some way.

This is fine. For the caching, the main thing I propose is to change the function behind initOnce (https://github.com/hyperledger-labs/fabric-token-sdk/blob/2e556dd0f1dd48252e6874753e33e5be7947eae1/token/services/network/fabric/tcc/tcc.go#L163) to retrieve it from the ledger instead of the file (but keep the cache feature!). I saw you're already reading the params from the ledger in AddPublicParamsDependency, so I thought maybe a comparison could make sense as a sanity check for the config (because these things are hard to debug). But we can forget about this part for now, it's not so important.

So, to summarize, I find it risky to allow anyone to submit new public parameters. The honest endorsers would have no way to check if they must accept these params or not.

I don't mean that the invoke would allow the user to submit the parameters as argument of the invoke. That would indeed be a bad idea. It would have a few steps:

There is offline agreement to update the parameters.
Each endorser manually updates the file that the chaincode reads in here: https://github.com/hyperledger-labs/fabric-token-sdk/blob/2e556dd0f1dd48252e6874753e33e5be7947eae1/token/services/network/fabric/tcc/tcc.go#L143 to the new parameters. This is the essential part: human oversight, but not one-sided because it's not in use yet.
Someone (doesn't matter who) invokes the 'init' or 'update' function.
The invocation causes the file to be written to the ledger. Because a quorum of endorsers has the same read/writeset (because they each used their new file), the transaction succeeds and is committed.
Hopefully the network is well organized and everybody has updated the params. In that case, all is well. Otherwise, endorsers who haven't updated their params will not be able to endorse new transactions. We could add a time-to-live to the in-memory cache so that they'll automatically recover within a reasonable timeframe by reading it from the ledger. Still, this is a very rare and specific case, and client applications should ideally already have some cleverness about switching endorsers...

But what if we say that the issuer can update the public params? Would this be fine? We can ask the token-sdk to check such a signature. Wdyt?

Do you mean the client application? When would it check it? If it only sees it after the new params have been committed, it could get a bit messy with differing points of view (what does it do if it rejects the new params?).
Issuer as authority makes sense, but maybe it's better to enforce it at the ledger level? Then we get back to either relying on the normal endorser quorum (which often includes the issuer organization as mandatory anyway) or key-based endorsement (I don't really like the added complexity - maybe someone might need it for specific cases but then they can just write the code for it ;) ).

Let me make sure I understand. The proposal is: The administrator of each chaincode, update locally the public parameters and maybe a flag telling the chaincode that as soon as an Init command is received, it must be accepted and the flag reset.
When this happens, anyone can submit the Init command maybe with the hash of the public params to activate and the switch happens. Something like this? Did I understand your proposal correctly?

Yeah, except that I even don't think the flag and hash are necessary, they know to which params they update the file, right? Do we need an explicit vote or is the changing of the file your vote? However, now that you put it that way, we may not want the moment  that the switch happens to be so free to choose for anyone...


Various Windows tweaks

Addresses @fdopen's patch referred to in #146. Three changes accepted:

Sys.remove replaced with Sys.force_remove which will attempt to remove the "read-only" attribute on Windows files
ocaml variable now includes the .exe extension on Windows
Context.Temp.destroy silently fails if it can't delete the file (as the at_exit routine does)

I have not merged the change to bash escaping for two reasons: firstly, this is better solved in the long-term using the cygvoke mechanism I've written for opam (but this needs to be spun into a library) and until a full solution is there, I think it better to keep discouraging the use of bash in actions anyway.
@diml - please could you give this a quick once-over?

Looks good to me

Cool - I'll let the CI run, then merge


Crash when adding object to realm

How frequently does the bug occur?
Sometimes
Description
Realm seems to crash for some users when adding new objects to realm
I have seen similar issues since 10.22.0, but this is also happening since the 10.24.0 upgrade.
Stacktrace & log output
Crashed: com.apple.main-thread
SIGABRT ABORT 0x00000001b8563964

shell
Crashed: com.apple.main-thread
0  libsystem_kernel.dylib         0x28414 __pthread_kill + 8
1  libsystem_pthread.dylib        0x2b40 pthread_kill + 272
2  libsystem_c.dylib              0x76b74 abort + 104
3  MyApp                       0x6806d8 std::__1::basic_stringstream<char, std::__1::char_traits<char>, std::__1::allocator<char> >::basic_stringstream() + 821 (sstream:821)
4  MyApp                       0x6808dc realm::util::terminate_internal(std::__1::basic_stringstream<char, std::__1::char_traits<char>, std::__1::allocator<char> >&) + 123 (terminate.cpp:123)
5  MyApp                       0x680a14 realm::util::terminate(char const*, char const*, long, std::initializer_list<realm::util::Printable>&&) + 140 (terminate.cpp:140)
6  MyApp                       0x358284 realm::BPlusTree<double>::get_uncached(unsigned long) const + 371 (bplustree.hpp:371)
7  MyApp                       0x4b60f0 realm::Node::calc_item_count(unsigned long, unsigned long) const + 61 (node.cpp:61)
8  MyApp                       0x4b6144 realm::Node::alloc(unsigned long, unsigned long) + 76 (node.cpp:76)
9  MyApp                       0x42e52c realm::Array::alloc(unsigned long, unsigned long) + 207 (array.hpp:207)
10 MyApp                       0x42e9e8 realm::Array::insert(unsigned long, long long) + 447 (array.cpp:447)
11 MyApp                       0x44124c realm::ArrayTimestamp::insert(unsigned long, realm::Timestamp) + 70 (array_timestamp.cpp:70)
12 MyApp                       0x44d860 void realm::Cluster::do_insert_row<realm::ArrayTimestamp>(unsigned long, realm::ColKey, realm::Mixed, bool) + 28 (array_timestamp.hpp:28)
13 MyApp                       0x44c9dc realm::util::FunctionRef<bool (realm::ColKey)>::FunctionRef<realm::Cluster::insert_row(unsigned long, realm::ObjKey, std::__1::vector<realm::FieldValue, std::__1::allocator<realm::FieldValue> > const&)::$_1&>(realm::Cluster::insert_row(unsigned long, realm::ObjKey, std::__1::vector<realm::FieldValue, std::__1::allocator<realm::FieldValue> > const&)::$_1&)::'lambda'(void*, realm::ColKey)::__invoke(void*, realm::ColKey) + 378 (cluster.cpp:378)
14 MyApp                       0x6551dc realm::TableClusterTree::for_each_and_every_column(realm::util::FunctionRef<bool (realm::ColKey)>) const + 119 (function_ref.hpp:119)
15 MyApp                       0x4482e4 realm::Cluster::insert_row(unsigned long, realm::ObjKey, std::__1::vector<realm::FieldValue, std::__1::allocator<realm::FieldValue> > const&) + 409 (cluster.cpp:409)
16 MyApp                       0x449f38 realm::Cluster::insert(realm::ObjKey, std::__1::vector<realm::FieldValue, std::__1::allocator<realm::FieldValue> > const&, realm::ClusterNode::State&) + 672 (cluster.cpp:672)
17 MyApp                       0x456d24 realm::ClusterTree::insert_fast(realm::ObjKey, std::__1::vector<realm::FieldValue, std::__1::allocator<realm::FieldValue> > const&, realm::ClusterNode::State&) + 882 (cluster_tree.cpp:882)
18 MyApp                       0x456ec0 realm::ClusterTree::insert(realm::ObjKey, std::__1::vector<realm::FieldValue, std::__1::allocator<realm::FieldValue> > const&) + 906 (cluster_tree.cpp:906)
19 MyApp                       0x654f7c realm::TableClusterTree::insert(realm::ObjKey, std::__1::vector<realm::FieldValue, std::__1::allocator<realm::FieldValue> > const&) + 47 (table_cluster_tree.cpp:47)
20 MyApp                       0x64adf8 realm::Table::create_object_with_primary_key(realm::Mixed const&, std::__1::vector<realm::FieldValue, std::__1::allocator<realm::FieldValue> >&&, bool*) + 3010 (table.cpp:3010)
21 MyApp                       0x2f3de8 realm::Table::create_object_with_primary_key(realm::Mixed const&, bool*) + 463 (vector:463)
22 MyApp                       0x2e924c realm::Object realm::Object::create<objc_object* __strong, RLMAccessorContext>(RLMAccessorContext&, std::__1::shared_ptr<realm::Realm> const&, realm::ObjectSchema const&, objc_object* __strong, realm::CreatePolicy, realm::ObjKey, realm::Obj*) + 298 (object_accessor.hpp:298)
23 MyApp                       0x2e8c70 RLMAccessorContext::createObject(objc_object*, realm::CreatePolicy, bool, realm::ObjKey) + 1093 (RLMAccessor.mm:1093)
24 MyApp                       0x330774 RLMAddObjectToRealm + 139 (RLMObjectStore.mm:139)
25 MyApp                       0x75150 thunk for @callee_guaranteed () -> (@error @owned Error) +<PHONE_NUMBER> (<compiler-generated>:4343763280)
26 MyApp                       0x24c788 partial apply for thunk for @callee_guaranteed () -> (@error @owned Error) +<PHONE_NUMBER> (<compiler-generated>:4345694088)
27 MyApp                       0x24d6b4 thunk for @callee_guaranteed () -> (@error @owned Error)partial apply +<PHONE_NUMBER>
28 MyApp                       0x75a0a4 Realm.write<A>(withoutNotifying:_:) + 255 (Realm.swift:255)

Can you reproduce the bug?
Not yet
Reproduction Steps
No response
Version
10.24.0
What SDK flavour are you using?
Local Database only
Are you using encryption?
No, not using encryption
Platform OS and version(s)
iOS 15
Build environment
Xcode version: 13.2.1
Dependency manager and version: SPM

Hi @sipersso Do you have any code which may help to reproduce the issue?

It only happens very infrequently in production and I have not been able to reproduce it locally I am afraid :/

I noticed that the actual crash was missing from firebase so I added that: Not sure if it helps:
Crashed: com.apple.main-thread
SIGABRT ABORT 0x00000001b8563964.

Hi @sipersso

Do you know what the size of the Realm file is when the crash occurs?
Do you have any analytics for how long the app is running before a crash happens?
Are you keeping references of Realm objects/results/realms alive anywhere in your app?

1: I don't know the size of the realm file, but this is maybe something that I could add tracking for in a future update.
2: I don't. But I can see that there are repetitive crashes. The affected have crashes within minutes of each other.
3: I don't have any global realm instances if that is what you are talking about. I wrap all calls to realm in background threads in autoreleasepools.
I did see another realm thread in crashlytics if that helps in Realm notification listener.
external_commit_helper.cpp - Line 221
realm::_impl::ExternalCommitHelper::listen() + 221
tuple - Line 181
void* std::__1::__thread_proxy<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_deletestd::__1::__thread_struct >, realm::_impl::ExternalCommitHelper::ExternalCommitHelper(realm::_impl::RealmCoordinator&)::$_0> >(void*) + 181

@sipersso could you show us how you wrap the calls the background threads in autorelease pools?

Realms are not supported on concurrent queues, which is what global() is. You should create a serial queue to use a Realm on a non main thread. e.g.
        let queue = DispatchQueue(label: "my-queue")
        queue.async {
            let realm = try! Realm(configuration: .defaultConfiguration, queue: queue)
        }

Would you be able to remove the usage of Realms with concurrent queues and see if that solves the issue?

Realms are not supported on concurrent queues, which is what global() is. You should create a serial queue to use a Realm on a non main thread. e.g.
        let queue = DispatchQueue(label: "my-queue")
        queue.async {
            let realm = try! Realm(configuration: .defaultConfiguration, queue: queue)
        }

Would you be able to remove the usage of Realms with concurrent queues and see if that solves the issue?

Yes, I can definitely remove the use of global(). I'll try this out. Thanks!

By the way @leemaguire maybe this is something that should be made a little more clear in the documentation? I just read https://docs.mongodb.com/realm/sdk/swift/advanced-guides/threading/ and there is no mention there that you should avoid concurrent queues and DispatchQueue.global() and when searching on GitHub I see that you have written the same response to many open issues. Maybe something to add to the documentation?

@leemaguire FIY... I have changed all background operations to use serial queues as per your recommendation. But the issue still persists.
The write operation in this case is performed on the main thread. Could that have anything to do with it? I am in the process of switching to writing on background threads, but not done with that yet. I am not using sync, only local realms for now.

@sipersso once you read / write from the realm on the queue that it is bound to things should be fine. Do you have any additional crash logs and any new code snippets you could share with us?

I think all of the issues here are caused by corrupted realms. The corruption seems to have happened for 10.22.0, but I don't see many new instances of these after upgrading. However, if there is corrupt data in the realm, upgrading won't help. You have to delete and reinstall the app (and thus risk loosing data, since I haven't been able to migrate to MongoDb Realm yet). Realm doesn't offer any API for detecting corruption in local files so all I can do is to wait for the user to reach out after getting multiple repeated crashes :/
I have an open support case: 00900582 and have shared more info there.

@anlaital are you using sync? or just locally? To be fair, I think the crashes for me has been limited to t a few people on the 10.22.0 update. But I haven't seen many crashes for other users after that. The app does have quite a lot of volume with 100k+ active users.
If you got repeated crashes even before the 10.22.0 update, maybe there is something wrong with your Realm usage? Tens of thousands of crashes per day sounds a lot though. Sorry you have to go through this.
@anlaital do you see the same stack trace as I do?

We are not using sync at all.
Realm storage engine has always been somewhat volatile, but with the most recent updates it's just gone to a whole new level of pain. I don't think there is anything we are doing wrong, it's just that our data volumes are large as is our user base and our models are fairly complex and see heavy usage throughout the application.
Here's a stack trace where simply deleting an object from the Realm causes constant crashes:
Crashed: com.apple.main-thread
0  libsystem_kernel.dylib         0x69e8 __pthread_kill + 8
1  libsystem_pthread.dylib        0x10824 pthread_kill + 208
2  libsystem_c.dylib              0x1f0b4 abort + 120
3  Realm                          0x2cb940 realm::util::terminate(char const*, char const*, long) + 10
4  Realm                          0x2cbc40 realm::util::terminate_internal(std::__1::basic_stringstream<char, std::__1::char_traits<char>, std::__1::allocator<char> >&) + 328
5  Realm                          0x2cbdb8 realm::util::terminate(char const*, char const*, long, std::initializer_list<realm::util::Printable>&&) + 328
6  Realm                          0x159368 realm::ArrayBacklink::remove(unsigned long, realm::ObjKey) + 460
7  Realm                          0x20049c realm::Obj::remove_one_backlink(realm::ColKey, realm::ObjKey) + 312
8  Realm                          0x1721f0 realm::Cluster::remove_backlinks(realm::ObjKey, realm::ColKey, std::__1::vector<realm::ObjKey, std::__1::allocator<realm::ObjKey> > const&, realm::CascadeState&) const + 356
9  Realm                          0x177f94 realm::Cluster::do_erase_key(unsigned long, realm::ColKey, realm::CascadeState&) + 284
10 Realm                          0x177150 realm::util::FunctionRef<bool (realm::ColKey)>::FunctionRef<realm::Cluster::erase(realm::ObjKey, realm::CascadeState&)::$_3&>(realm::Cluster::erase(realm::ObjKey, realm::CascadeState&)::$_3&)::'lambda'(void*, realm::ColKey)::__invoke(void*, realm::ColKey) + 2164
11 Realm                          0x2a1e5c realm::TableClusterTree::for_each_and_every_column(realm::util::FunctionRef<bool (realm::ColKey)>) const + 84
12 Realm                          0x171430 realm::Cluster::erase(realm::ObjKey, realm::CascadeState&) + 160
13 Realm                          0x17f69c realm::ClusterNodeInner::erase(realm::ObjKey, realm::CascadeState&)::$_3::operator()(realm::ClusterNode*, realm::ClusterNodeInner::ChildInfo&) const + 68
14 Realm                          0x17b3d4 realm::ClusterNodeInner::erase(realm::ObjKey, realm::CascadeState&) + 240
15 Realm                          0x17e238 realm::ClusterTree::erase(realm::ObjKey, realm::CascadeState&) + 128
16 Realm                          0x2962ac realm::Table::remove_object(realm::ObjKey) + 268
17 Realm                          0x1f8fa8 realm::Obj::remove() + 44
18 Realm                          0x5a89c RLMDeleteObjectFromRealm + 190 (RLMObjectStore.mm:190)

Here's one where simply adding an object to Realm causes it to blow up constantly:
Crashed: com.apple.main-thread
0  libsystem_kernel.dylib         0x7b78 __pthread_kill + 8
1  libsystem_pthread.dylib        0x73bc pthread_kill + 268
2  libsystem_c.dylib              0x2051c abort + 168
3  Realm                          0x2cb940 realm::util::terminate(char const*, char const*, long) + 10
4  Realm                          0x2cbc40 realm::util::terminate_internal(std::__1::basic_stringstream<char, std::__1::char_traits<char>, std::__1::allocator<char> >&) + 328
5  Realm                          0x2cbdb8 realm::util::terminate(char const*, char const*, long, std::initializer_list<realm::util::Printable>&&) + 328
6  Realm                          0x5b858 void realm::util::terminate_with_info<char const&, unsigned long&>(char const*, int, char const*, char const*, char const&, unsigned long&) + 51 (terminate.hpp:51)
7  Realm                          0x175008 realm::util::FunctionRef<bool (realm::ColKey)>::FunctionRef<realm::Cluster::move(unsigned long, realm::ClusterNode*, long long)::$_2&>(realm::Cluster::move(unsigned long, realm::ClusterNode*, long long)::$_2&)::'lambda'(void*, realm::ColKey)::__invoke(void*, realm::ColKey) + 322
8  Realm                          0x173cac void realm::Cluster::do_insert_row<realm::BasicArrayNull<double> >(unsigned long, realm::ColKey, realm::Mixed, bool) + 208
9  Realm                          0x173494 realm::util::FunctionRef<bool (realm::ColKey)>::FunctionRef<realm::Cluster::insert_row(unsigned long, realm::ObjKey, std::__1::vector<realm::FieldValue, std::__1::allocator<realm::FieldValue> > const&)::$_1&>(realm::Cluster::insert_row(unsigned long, realm::ObjKey, std::__1::vector<realm::FieldValue, std::__1::allocator<realm::FieldValue> > const&)::$_1&)::'lambda'(void*, realm::ColKey)::__invoke(void*, realm::ColKey) + 612
10 Realm                          0x2a1e5c realm::TableClusterTree::for_each_and_every_column(realm::util::FunctionRef<bool (realm::ColKey)>) const + 84
11 Realm                          0x16ef20 realm::Cluster::insert_row(unsigned long, realm::ObjKey, std::__1::vector<realm::FieldValue, std::__1::allocator<realm::FieldValue> > const&) + 212
12 Realm                          0x170f4c realm::Cluster::insert(realm::ObjKey, std::__1::vector<realm::FieldValue, std::__1::allocator<realm::FieldValue> > const&, realm::ClusterNode::State&) + 240
13 Realm                          0x17f308 realm::ClusterNodeInner::insert(realm::ObjKey, std::__1::vector<realm::FieldValue, std::__1::allocator<realm::FieldValue> > const&, realm::ClusterNode::State&)::$_1::operator()(realm::ClusterNode*, realm::ClusterNodeInner::ChildInfo&) const + 72
14 Realm                          0x17a3f0 realm::ClusterNodeInner::insert(realm::ObjKey, std::__1::vector<realm::FieldValue, std::__1::allocator<realm::FieldValue> > const&, realm::ClusterNode::State&) + 248
15 Realm                          0x17f308 realm::ClusterNodeInner::insert(realm::ObjKey, std::__1::vector<realm::FieldValue, std::__1::allocator<realm::FieldValue> > const&, realm::ClusterNode::State&)::$_1::operator()(realm::ClusterNode*, realm::ClusterNodeInner::ChildInfo&) const + 72
16 Realm                          0x17a4a4 realm::ClusterNodeInner::insert(realm::ObjKey, std::__1::vector<realm::FieldValue, std::__1::allocator<realm::FieldValue> > const&, realm::ClusterNode::State&) + 428
17 Realm                          0x17dcb0 realm::ClusterTree::insert_fast(realm::ObjKey, std::__1::vector<realm::FieldValue, std::__1::allocator<realm::FieldValue> > const&, realm::ClusterNode::State&) + 48
18 Realm                          0x17df90 realm::ClusterTree::insert(realm::ObjKey, std::__1::vector<realm::FieldValue, std::__1::allocator<realm::FieldValue> > const&) + 164
19 Realm                          0x2a1990 realm::TableClusterTree::insert(realm::ObjKey, std::__1::vector<realm::FieldValue, std::__1::allocator<realm::FieldValue> > const&) + 52
20 Realm                          0xc51c realm::Object realm::Object::create<objc_object* __strong, RLMAccessorContext>(RLMAccessorContext&, std::__1::shared_ptr<realm::Realm> const&, realm::ObjectSchema const&, objc_object* __strong, realm::CreatePolicy, realm::ObjKey, realm::Obj*) + 322 (object_accessor.hpp:322)
21 Realm                          0xbbe4 RLMAccessorContext::createObject(objc_object*, realm::CreatePolicy, bool, realm::ObjKey) + 1093 (RLMAccessor.mm:1093)
22 Realm                          0x5a2f4 RLMAddObjectToRealm + 139 (RLMObjectStore.mm:139)
23 RealmSwift                     0x69774 Realm.add<A>(_:update:) + 284 (<compiler-generated>:284)

HI @anlaital which version of Realm are you using at the moment?

@dianaafanador3 we are using Realm v10.24.1 on iOS, which is the platform experiencing these crashes. Android has no crashes whatsoever and they are using an older Java Realm version v10.5.1.

We added some fixes for some data corruption crashes on large files on <IP_ADDRESS>, I would recommend to update to our latest version 10.25.2, and if you are still experiencing these issues we can try to reproduce it on our side.

Updating won't help correct the realms that already have corruption though. There is also no API for detecting corruption. If there is corrupt data, realm will just crash because of an assertion and there is nothing you can do about it except for deleting the realm.
In my case I was able to get a hold of one user that had the problem and extract a realm file. Using Realm.writeCopy didn't work since it would also crash. But using FileManager I was able to give him a special build that didn't use any realm apis, extract the file and remove the corrupted entries manually using Realm Studio.
The user won't be able to use the corrupted realm, so delete and reinstall (with possible data loss) seems to be the only option here.

Is there any way to detect corruption? I am struggling with the error logs coming up without being able to reproduce it.

@shimastripe I don't think you won't be able to reproduce this. The transaction causing corrupted data could have happened anywhere. I am seeing fewer issues now than I did in the 10.22.0 update, but I still have customers reaching out every week with realms that are corrupted :/ I don't know if that is because they were using the 10.22.0 update and then waited to reach out or if this is still an issue.
I was in contact with support and since Realm is using hard asserts when bad data is discovered I can not provide the user with an error dialog informing them that there is a problem with their data. The ticket was basically closed as a won't fix as the app probably won't function anyway with corrupt data in there and the assertion would be justified. But it does lead to a bad user experience. All I can do is wait for the negative reviews and angry customers to reach out :(

Still getting crashes here. It is rare but it happens. And for those that have the issue, it happens repetitively. Here is a new stack trace
3  MyApp                       0x6ce598 realm::util::terminate(char const*, char const*, long, std::initializer_list<realm::util::Printable>&&) + 147 (terminate.cpp:147)
4  MyApp                       0x6ce8d8 realm::util::terminate_internal(std::__1::basic_stringstream<char, std::__1::char_traits<char>, std::__1::allocator<char> >&) + 142 (terminate.cpp:142)
5  MyApp                       0x6cea54 realm::util::terminate_with_info(char const*, char const*, long, char const*, std::initializer_list<realm::util::Printable>&&) + 163 (terminate.cpp:163)
6  MyApp                       0x49dc34 realm::GroupWriter::FreeList::merge_adjacent_entries_in_freelist() + 637 (group_writer.cpp:637)
7  MyApp                       0x4a82fc realm::StringIndex::do_insert(realm::ObjKey, int, unsigned long, realm::StringData, realm::Mixed const&) + 861 (index_string.cpp:861)
8  MyApp                       0x4a7ea0 realm::StringIndex::do_insert(realm::ObjKey, int, unsigned long, realm::StringData, realm::Mixed const&) + 799 (index_string.cpp:799)
9  MyApp                       0x4a7720 realm::StringIndex::TreeInsert(realm::ObjKey, int, unsigned long, realm::StringData, realm::Mixed const&) + 743 (index_string.cpp:743)
10 MyApp                       0x68a084 void realm::StringIndex::insert<realm::StringData>(realm::ObjKey, realm::StringData) + 415 (index_string.hpp:415)
11 MyApp                       0x68a6c8 realm::Table::update_indexes(realm::ObjKey, realm::FieldValues const&) + 824 (table.cpp:824)
12 MyApp                       0x47f0c8 realm::ClusterTree::insert(realm::ObjKey, realm::FieldValues const&) + 104 (cluster_tree.hpp:104)
13 MyApp                       0x69d894 realm::TableClusterTree::insert(realm::ObjKey, realm::FieldValues const&) + 47 (table_cluster_tree.cpp:47)
14 MyApp                       0x6935cc realm::Table::create_object_with_primary_key(realm::Mixed const&, realm::FieldValues&&, realm::Table::UpdateMode, bool*) + 3083 (table.cpp:3083)
15 MyApp                       0x30fb14 realm::Table::create_object_with_primary_key(realm::Mixed const&, bool*) + 485 (vector:485)
16 MyApp                       0x305040 realm::Object realm::Object::create<objc_object* __strong, RLMAccessorContext>(RLMAccessorContext&, std::__1::shared_ptr<realm::Realm> const&, realm::ObjectSchema const&, objc_object* __strong, realm::CreatePolicy, realm::ObjKey, realm::Obj*) + 306 (object_accessor.hpp:306)
17 MyApp                       0x304a14 RLMAccessorContext::createObject(objc_object*, realm::CreatePolicy, bool, realm::ObjKey) + 1102 (RLMAccessor.mm:1102)
18 MyApp                       0x35512c RLMCreateObjectInRealmWithValue + 133 (RLMObjectStore.mm:133)
19 MyApp                       0x80c5b0 Realm.create<A>(_:value:update:) + 611 (Realm.swift:611)

Hello,
I'm getting these crashes pretty often
private let queue = DispatchQueue(label: "StoragePerformerQueue", qos: .userInteractive)

func add(_ objects: [Object]) {
      guard let db = self.db else {
          Logger.log(.debug, logItem: "Realm writing error: DB is nil")
          return
      }
      queue.async {
          do {
              try db.write {
                  objects.forEach {
                      db.add($0)
                  }
              }
          } catch let error {
              Logger.log(.debug, logItem: "Realm writing error: \(error)")
          }
      }
}

Sometimes it crashes and indicates at line db.add($0)
but can it be related to situation when object with same id exists already?


frontend: optimize request transfer

Previously, the code didn't account for the fact that it takes a certain amount of time from the moment
a user initiates a transfer request until he actually submits it via his wallet provider.
The transfer object was fetching & storing the target chain block at the moment of triggering a "createRequest" transaction call instead of after successful submission of the transaction call.

Can we be sure that we do not miss the fill event if we do this change?
Specifically I'm wondering whether we fetch the target chain block after the transaction was successfully submitted to the source chain. If that's the case I believe we have a race condition between fetching the start block and actually the request already being filled.

I'm not sure if I would like to do this change now. Calling the contract function does a signer.sendTransaction(txRequest) and there are some old reports that sometimes metamask returns the hash immediately and sometimes it waits. (seems to be fixed in recent releases, but I would more time to test)
https://github.com/ethers-io/ethers.js/issues/372
Also, we always need to do getLogs for the old blocks. Whether we do 1 call that fetches only 20 blocks, or one call that fetches 500 - doesn't really matter I think.

@fredo true, with this change we are actually opening the possibility for such cases, therefore, i am closing this.


UWP DatagramSocket does not receive data until after data is sent on the socket.

See: https://stackoverflow.com/a/39767527 and https://stackoverflow.com/a/39768462
You can also use https://github.com/Microsoft/Windows-universal-samples/tree/master/Samples/DatagramSocket to demonstrate this issue. Use scenario 5 to listen for multicast traffic and observe nothing is received until after hitting the send button.
Visual Studio 2017 15.6.2
.NET Framework 4.7.02558
Windows 10 Anniversary Edition (10.0: Build 14393)

This repo is no longer actively monitored. Closing up old issues that have not had activity in while. If this is still an issue, please reach out to us at<EMAIL_ADDRESS>For all other issues, please open a new issue in an appropriate repo listed in microsoft/dotnet#1275

This repo is no longer actively monitored. Closing up old issues that have not had activity in while. If this is still an issue, please reach out to us at<EMAIL_ADDRESS>For all other issues, please open a new issue in an appropriate repo listed in microsoft/dotnet#1275


PHP 8 Support

Description
I added PHP 8 to be allowed by the required PHP version is composer.json. I also upgraded PHPUnit to v9 since none of the older versions work on PHP 8.
Motivation and context
PHP 7.2 is EOL, PHP 7.3 will be EOL in December. PHP 8 was released 4 months ago.
How has this been tested?
No code changes were required, just adding PHP 8 to the allowed PHP versions. I am currently using my branch in production and connections to Backblaze B2 are stable in PHP 8.
composer test output is also all passing.
Screenshots (if appropriate)
Types of changes
What types of changes does your code introduce? Put an x in all the boxes that apply:

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:
Go over all the following points, and put an x in all the boxes that apply.
Please, please, please, don't send your pull request until all of the boxes are ticked.

[x] I have read the CONTRIBUTING document.
[x] My pull request addresses exactly one patch/feature.
[x] I have created a branch for this patch/feature.
[x] Each individual commit in the pull request is meaningful.
[x] I have added tests to cover my changes.
[x] All new and existing tests passed.
[x] If my change requires a change to the documentation, I have updated it accordingly.
[x] My code follows the code style of this project.

If you're unsure about any of these, don't hesitate to ask. We're here to help!

I can't seem to get Scrutinizer to upgrade the version of phpcs it is using. Is that something you have to do?

Could you merge, either this or #31, and tag a new release please? Thanks!