jfirebaugh

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.

[1] https://en.wikipedia.org/wiki/Dangling_modifier

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.

[0]: https://github.com/mapbox/mapbox-gl-js

ndk-gdb / ndk-gdb.py seem to be broken in this release:

https://github.com/android-ndk/ndk/issues/2 https://github.com/android-ndk/ndk/issues/3

(author here)

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.

This looks like a bug. I filed a ticket and we'll take a look. Thanks for the details!

https://github.com/mapbox/mapbox-gl-js/issues/652

MapBox - San Francisco and Washington DC

MapBox is looking for developers and designers, an Operations Manager, and a Business Development Lead.

http://www.mapbox.com/jobs/

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:

http://www.mapbox.com/blog/

A query like "one-way streets and stop-lights within my area" is perfect for the Overpass API: http://wiki.openstreetmap.org/wiki/Overpass_API

The best UI for Overpass is http://overpass-turbo.eu/

iD developer here. I did a series of posts on the architecture of iD that folks here might find interesting:

http://www.mapbox.com/osmdev/2013/02/26/id-architecture-part... http://www.mapbox.com/osmdev/2013/02/27/id-architecture-part... http://www.mapbox.com/osmdev/2013/02/28/id-architecture-part...

As far as I've been able to find, Hal Abelson's last statement was on May 13, when he wrote that the report would be released "this summer".

http://tech.mit.edu/V133/N26/swartz/2.html

This is indeed much delayed from his initial statement on January 22 that he hoped the report would be ready "in a few weeks."

http://tech.mit.edu/V132/N63/abelson.html

It's disappointing that it's taken this long.

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.

Please comment on the gist with any additional libraries (public and patched vulnerabilities only please). I'll keep it updated.

I'm keeping track of a list of vulnerable gems here: https://gist.github.com/4532291

RubyGems 1.8.23 is also out with the same fix.

Two security issues were fixed:

* 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:

    :sources:
      - https://rubygems.org

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.

As of 1.9.3-p125, clang is officially supported by MRI.

If ruby-build refuses to compile with clang, you should open an issue. I've done so for rvm: https://github.com/wayneeseguin/rvm/issues/763

I just released a port of Slim with embedded CoffeeScript: https://github.com/jfirebaugh/skim

If you prefer HAML, check out https://github.com/9elements/haml-coffee

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?

http://groups.google.com/group/rubyonrails-security/browse_t...