Sure. To be more precise, it's a "dangling modifier" [1]. The modifying clause "As a non-native English speaker" intends to refer to the narrator, who is using ChatGPT to improve their text. But the sentence as constructed, where this clause is followed by the subject "ChatGPT", might be read as implying that ChatGPT is a non-native English speaker. The original beginning "I am not a native English speaker..." was clearer.
It fixed some things (“ChatGPT have”, “It’s has”) but changed the meaning of the first sentence and introduced a misplaced modifier (“As a non-native English speaker, ChatGPT…”).
Hi, Mapbox developer here. We've gotten a few requests for offline for mapbox-gl-js[0], but haven't put a priority on it yet. We need to do some investigation to see if this is something that's feasible to build with Web APIs such as IndexedDB.
Absolutely. My preference for new modules is to use both newless and "this"-less Javascript. Newless via the technique outlined in this post (or encapsulated in a module: https://github.com/Mr0grog/newless), and this-less via the module pattern (see link in post).
This is the pattern followed by D3. It's easy to follow internally, gives you true private data and methods, and (IMHO) is a nicer interface for API consumers -- no `new`, `delete`, or `bind`'s necessary.
We're a team of 30 or so artists, developers, designers and strategists working on an open platform for maps. Our platform powers everything from apps like Foursquare, GitHub and Evernote to news stories on NPR and USAToday to simple maps on personal blogs and wedding websites. Much of our work is powered by open source and open data and we're often in touch with folks at OpenStreetMap, the US Census Bureau, USGS, and NASA.
Check out what we have been working on lately on our blog:
It's fully functional, and you can switch over to the live OpenStreetMap database by clicking 'dev' in the lower right. Loading and saving data happens via an XHR request to the OpenStreetMap API hosted on http://www.openstreetmap.org. The API supports CORS, making direct cross-origin connections possible.
* RubyGems did not validate SSL certificates (the dreaded OpenSSL::SSL::VERIFY_NONE problem).
* RubyGems allowed HTTPS-to-HTTP redirects. And in fact rubygems.org did redirect gem downloads from HTTPS to HTTP (also fixed).
Either of these mean that an attacker could MITM your `gem install` or `bundle install` and give you malicious gem contents. You'd be owned when you required the gem -- possibly sooner, in fact, because gem install itself provides mechanisms for arbitrary code execution.
It's also important to note that RubyGems does not default to HTTPS. I highly recommend using `source "https://rubygems.org` in your Gemfile and the following in your ~/.gemrc:
With everything Github has done to lower the barrier to contributing to an open source project, it's a shame that the legal climate around software (especially in patent-related areas) makes such things necessary.
I can definitely imagine cases where the time and effort required to get company approval to sign such an agreement would outweigh the benefits of submitting a change upstream; I've been in such a position myself.
I'm curious about the technical details of the CSRF bypass vulnerability. Anyone know what the "combinations of browser plugins and HTTP redirects" that lead to it are?
[1] https://en.wikipedia.org/wiki/Dangling_modifier