Should I be using toPromise in rxjs6? What does it do? - deprecated

I'm having a little trouble reading the rxjs documentation.
As far as I can see, this is the official documentation: https://rxjs-dev.firebaseapp.com/api
In the Observable documenation page under methods it has listed lift() and subscribe(), though later down the page, under examples, there are forEach(), pipe(), and toPromise().
None of those have usage notes - just argument specifiers.
Looking at this page: https://www.learnrxjs.io/operators/utility/topromise.html
We're told:
:warning: toPromise has been deprecated! (RxJS 5.5+)
How I am I meant to be reading this? toPromise was deprecated in 5.5x and continues to be deprecated?

TLDR; I think the documentation is incorrect.
toPromise is not deprecated.
Apparently there was some issue when toPromise was moved to operators and then removed in 5.5 beta.
toPromise was only available in rxjs/operators during a beta of 5.5. It was removed because it doesn't make any sense, it's not an operator, it's a method of subscription that results in a promise.
See GH issue
Also there is no deprecation notice in the sources and none in the migration guide. Rxjs team is pretty reliable about deprecation warnings.
I think the documentation at https://www.learnrxjs.io/operators/utility/topromise.html is either wrong or it's referring to toPromise as operator - which has been removed.

Related

QSerialPortInfo isValid() and isBusy()

QSerialPortInfo class has const methods isValid() (deprecated since 5.2) and isBusy() (deprecated since 5.6). They both seem to work but QT documentation does not provide with info whether they should be replaced with isNull() or state of QSerialPortInfo object should be checked some other way.
Can anyone please tell me actual way to check serial port availability?
I am using the same function call and it appears to work, so I was wondering why the function is obsolete. Turns out, the function opens the port in question, see bug report here. This side effect seems to be the reason why it was marked obsolete and deprecated.
If that side effect is okay with you (and the reported "other issues" by the maintainer in the bug report), then that appears to be an okay way to get done what you're asking for.
With reference to the documentation, both isValid() and isBusy() are obsolete and not recommended to be used in new code.
Quote from documentation (emphasis mine):
They are provided to keep old source code working. We strongly advise against using them in new code.
The See also section points to isNull() method so it should be used.
See commit.

Is it safe to upgrade Meteor's Underscore to 1.7.0?

This is coming from this topic:
Best way to take out keys with invalid (NaN, blank, etc) values from an object?
I couldn't get the commenter's underscore method to work because Meteor only uses Underscore 1.0.0, and certain functions don't work like Underscore 1.7.0 does.
From the Meteor Docs:
We have slightly modified the way Underscore differentiates between objects and arrays in collection functions. The original Underscore logic is to treat any object with a numeric length property as an array (which helps it work properly on NodeLists). In Meteor's version of Underscore, objects with a numeric length property are treated as objects if they have no prototype (specifically, if x.constructor === Object.
So it appears that Meteor has changed Underscore a tad.
Has anyone here forced Meteor to use Underscore 1.7.0 in their app and gotten any weirdness?
If you look at the history of the underscorejs package in the meteor repository, you'll see that they actually changed the underscorejs library instead of monkeypatching it. (here and here)
So I would strongly recommend against upgrading the underscorejs version.
If you really really must upgrade, I suggest trying to apply the commits of the meteor version to the latest version. Luckily the package does contain tests for the fixes the meteor team did. So start with upgrading the underscorejs file and then running the tests if they all pass you're probably good to go.

Why doesn't this template code from the Discover Metor book work?

Working my way through the Discover Meteor book. The code form chapters on creating postItem templates that include a link to specific posts just doesn't 'work' (no errors, but no result either).
See linked gists for code I'm using [1]. There are no errors in the console. I've also read up about changes introduced in Meteor 0.8 with Blaze and I suspect that this is causing the problem, however, the documentation seems to suggest template helper usage in my case is the same[2] and I can see from looking at various meteor created scripts such as router.js that older templating systems are at least attempted to be supported [3].
Why doesn't this code work? And is there a way to make only slight changes to get it working rather than moving over to iron-router and potentially departing too far from the edition of Discover Meteor that I'm using?
[1] client/views/posts/post_item.html: https://gist.github.com/Trindaz/11139437; client/helpers/router.js: https://gist.github.com/Trindaz/11139409;
[2] http://meteorpedia.com/read/Blaze_Notes#Template Helpers [Note: space before 'Helpers' in this link breaks it] This appears to be more about block helpers than the way I'm using helpers, but seems to be the extent of any discussion on helper usage so I assumed everything else remained unchanged.
[3] https://github.com/tmeasday/meteor-router/blob/master/lib/router_client.js#L88
I found the answer almost immediately after writing this up, leaving question up for future googlers.
The problem seems to be caused by UI.body member assignments at https://github.com/tmeasday/meteor-router/blob/v0.6.1/lib/router_client.js#L89-L90. This breaks changes introduced in Meteor 0.8.0-rc3 https://groups.google.com/forum/#!msg/meteor-talk/oatU1zzcaeQ/54ay-pPlRrwJ.
From the release: "Templates no longer automatically access the helpers of ancestors [11]. If you were declaring helpers with UI.body.helpers you need to switch to UI.registerHelper instead."
This may all be redundant now as work has moved to iron-router.

how do I fix "/app/scripts/[foo].coffee is using deprecated documentation syntax" in hubot?

checking the heroku logs for my bot is showing messages like:
/app/scripts/tigger.coffee is using deprecated documentation syntax
but I can't seem to find what the undeprecated documentation syntax should be ...
It's normally due to the TomDoc at the top of the files. There's a good example for a correct one here

Sqlite bindings for OCaml

I have been looking for SQLite bindings for OCaml. I stumbled upon ocaml-sqlite3 which looks good and current, but there is no documentation whatsoever about how to use it.
There is some very old documentation (API reference only) of an obsolete ocaml-sqlite binding that was discontinued in 2004. But it really doesn't look current and probably is already quite different from the updated version I found (listed in the above link).
I was just wondering if anybody has some documentation, examples or clue at all of how these libraries work. I could go through the code, but I'd like to keep that option as the last resource.
Howdy. The ocaml-sqlite3 library you mentioned does, in fact, have documention; you just have to build it with make doc. It's included in the comments in the .mli file as well; you can have a look here: http://hg.ocaml.info/release/ocaml-sqlite3/file/b28bff3ff215/sqlite3.mli . I realize it's basically just an API reference, but it looks fairly comprehensive.
In addition to phooji's answer, please note that the API follows closely the C sqlite library. Thus, any Sqlite book should help you to use the OCaml binding. And you are correct about which version to use; the one here: http://www.ocaml.info/home/ocaml_sources.html.

Resources