vicapow

Is there a lot more work to be done?

that SVG wow how?!

thanks for hosting us on the pod!

Hope you like it :D I'm here if you have questions, too

I'm not against typst. I think it's integration would be a lot easier and more straightforward I just don't know if it's really that popular yet in academia.

Yes, but there's a really large number of users who don't want to have to setup vscode, git, texlive, latex workshop, just to collaborate on a paper. You shouldn't have to become a full stack software engineer to be able to write a research paper in LaTeX.

Users have full control over whether their data is used to help improve our models

I could see it seeming likely that because the UI is quite minimalist, but the AI capabilities are very extensive, imo, if you really play with it.

You're right that something like Cursor can work if you're familiar with all the requisite tooling (git, installing cursor, installing latex workshop, knowing how it all works) that most researchers don't want to and really shouldn't have to figure out how to work for their specific workflows.

The deeper I got, the more I realized really supporting the entire LaTeX toolchain in WASM would mean simulating an entire linux distribution :( We wanted to support Beamer, LuaLaTeX, mobile (wasn't working with WASM because of resource limits), etc.

Just a suggestion: The github permissions your comment login thing requests is a bit too aggressive.

> This application will be able to read and write all public repository data.

We have a few different ideas but hoping to get signal from the folks here on what people would like to see.

Some sort term ideas:

* Auto-categorization. We're seeing most people just have "starred" places, and that's really it, so having some way to suggest a better breakdown of places should locations.

* Adding the ability to sort results by various criteria (distance, recently viewed, rating, alphabetical)

Some longer term ideas:

* Making the experience more social, but more like "iMessage" social not "Facebook" social, if that makes sense.

Once you start importing your saved places, it may take a bit of time for them to show up but once they’re there, you can add notes, add to lists, search through your saved places by note, category, list, visited / not-visited or star rating.

I built this for my fiancée who wanted these features but I’m looking for feedback on how intuitive it is for others as well to see if there are any other features folks would like to see.

Thank you for checking out the App

If you use Google Saved Places a lot but feel it’s lacking some features I’d love to connect with you.

If you’d also like to try out an alternative, here’s the TestFlight download link for an app I’m working on before it gets released to the App Store

Some features: * Import your saved / starred places from Google * Search your place notes * Filter by list to find places you’ve saved again. * Search by your personal star rating or if you’ve visited the location. * [Your future feature request here]

for giving it a try

I like it. It means if someone breaks into the car they can’t get into the glove box. Also, with a Tesla, the car is never off so you don’t need to turn the car on again to get access to it.

How about a summary of the paper?

How can null be implicitly cast to a string? I wasn't able to reproduce with: https://flow.org/try/#0PTAEAEDMBsHsHcBQiDGsB2BnALqAhgFyg4BOA...

Flow has built in support for the Language Server Protocol. tsserver doesn't even support LSP. I agree ts has better IDE support but that's in part because they don't use LSP. odd they expect others to follow it when they don't.

Apologies, lxe. I can tell you're frustrated. If the the Flow upgrade process has been burdensome to others, I'd really like to know. I've always thought we've done a good job of updating internally on the platform team and that it hasn't been a concern for end users. We did run into some pain points in changing configuration options around the unnecessary optional-chaining lint rules but that wasn't related to updating the Flow version. I think you may be conflating those.

I’m not sure I agree. I’ve found updating Flow in a rather large monorepo a relatively straightforward process. The changes are usually rather small because the team releases every two weeks. They also manage the update internally within their company’s monorepo so they’ll usually find out about these types of unexpected behavior changes before the community does.

That said, we do rely on automated error excludes (similar to eslint-ignore-next-line) for things that cannot be fixed with codemods. Those errors were always there it’s just now you know about them. Better to stem the bleeding by updating the type checker to the latest version.

There is not a 1-1 metric for "coverage" across these two systems. For exmaple, TS believes this code is "covered" but Flow knows it's not safe:

type A = { readonly prop: number }; type B = { prop: number };

function func(f: B) { f.prop = 20; return f; }

const a: A = { prop: 10 }; func(a); // no error?

yep! see https://github.com/vicapow/explained-visually

Likely has to do with the increase in the number of pixels on your desktop display. Even worse if you're using a high resolution external display.

Hello, HN. Co-author, here. Surprised to see this pop up again!

You can find the source code here: https://github.com/vicapow/explained-visually

Wish I had the free time to work on these more.

I'm sucker for self descriptive "boring" names like "create-react-app"

Also, sweet project!!

Find the source code for this and other explanations at: https://github.com/vicapow/explained-visually/tree/master/cl...

They've also never built a car before

I've worked both at a large company (Facebook) that used the mono repo approach as well as a large company that uses the per project repo approach (Uber) and I have to say I'm personally a VERY big fan of the project based repo approach but every company is different. So is every team. If you're a small company with primarily one service and primarily in one programming language, the mono-repo way seems to be the best approach. On the other hand, if you're a company that has embraced a service oriented architecture, the per project repo approach is likely the way to go. Especially if your company is OK with services being written in a variety of different languages and so long as it is as easy to use open source code as it is to use third party code written within your org. It also goes a long way in supporting local (ie., laptop) development. Otherwise, the entire codebase would be too big to fit in RAM.

Disclaimer, these opinions do not necessarily represent the opinions of my employer.

Also, if you're in SF and are interested in learning more about d3.js, one of the primary libraries that we used to build EV, we'll be teaching a 1 day workshop May 2nd geared towards people comfortable with data but haven't gotten deep into web programming. We'll also be using "explorable explanation" style techniques along the way.

Have a look at our preliminary workshop demos for an example: https://vicapow.github.io/d3-1-day-workshop/

I promise the demos will get more advanced and start incorporating data before the workshop :)

You can apply to the workshop here: https://docs.google.com/forms/d/1VgBUu7znZVllkVw2d6TISzsTjGD...

The application process is to ensure everyone's at about the same level. If you're accepted, the ticket is $99 and includes food and refreshments.

I think it's important to remember that, for at least EV, these explanations aren't intended to stand on their own. There's a lot of good resources online already for learning this stuff. The problem, as we see it, is one of motivation and curiosity. If we can help people intuit what's happening and why it's important, we think this will help motivate people to want to get more into the details on their own.

Pull request? :)

PCA minimizes the error along the PC axis. Here's a nice article that goes into more detail: http://www.r-bloggers.com/principal-component-analysis-pca-v...