randyzwitch

Interesting project. Does the Terran side require GPUs to run or can it run CPU-only?

The selling model sounds strangely like the car buying model. Pre-COVID, even the suggestion that the total price of a car be listed on the car was viewed as idealistic nonsense. Only until a pandemic broke out, did car dealers admit "you're right, we could always sell you a car online"

Looks like a lot of great content and updates/announcements came out of JuliaCon last week

From that article, it shows an entire thread of people talking about how a typo lead to a stupid joke

https://twitter.com/NikkitaFTW/status/1009862568129781760

A humorous analogy based on something funny that a co-worker did seems like a joke to me. I'm not claiming I invented it, just saying that it doesn't stem from confusion.

I wouldn't say it's about confusion, it's just a very online joke.

In the two DevReal roles I've had, there is some aspect of marketing and customer support, but not really "sales". For me, it's been a hybrid engineering and product role, where talking to the users helps surface bugs as well as ideas for new features.

So much less "technical sales" than "developer whose role includes public interaction"

Thanks for sharing! I re-posted it here on the Streamlit forum as well, hopefully you'll get more feedback there as well:

https://discuss.streamlit.io/t/dynamically-rendering-latex-i...

Wearing 3 layers of clothes and still getting stung. I can't even imagine trying to stay calm, even with the thought of protective clothing

I see you've both commented here and on GitHub, so I'll make my last comment here and then we can address the specifics on your ticket (I didn't realize I referred you to your own GitHub issue).

As I mentioned, there is a pull request already created for this issue; our head of engineering/founder says its being held up by a lack of tests before merging. This problem isn't a slider issue, but a race condition in our session state manager.

Regardless, one month is a pretty trivial amount of time as far as open-source projects go, as well as in the history of Streamlit (project became public Oct 2019). Like all projects, we try and address things in the order of severity, and as far as this issue goes, it's a pretty isolated one, not an indication that the library is unreliable or somehow reflects that our engineers can't design at an early-90s level of engineering.

Thanks for clarifying. Since HN isn't the right place for a detailed discussion, I would invite you to comment on that issue and try to help us work through it.

As one of our engineers mentions in the linked issue, this bug is hard to trigger (as is the nature of many bugs), and she is working on a solution[1]. This issue has also been reported here[2], with the solution of adding time.sleep(1) inside the loop usually resolving that problem.

[1] https://github.com/streamlit/streamlit/pull/1494 [2] https://discuss.streamlit.io/t/displaying-images-from-opencv...

(Note: I'm Head of Developer Relations at Streamlit)

Out of curiosity, which features are you looking for in a "proper" front-end? Flexibility?

Thanks for sharing! If you're looking for feedback, you might try posting on the Streamlit forum.

OP

Definitely agree with you both. I chose Dash because I knew Python, but JavaScript is just something that never seems to click with me. They definitely make it easy for the pandas-using, wants-one-screen-and-a-few-dropdowns type of person to get started.

Yes, that's my point. It's too simplistic to say "well, the data fits in RAM", you have to add parallelism to make the workload tolerable. In the past, some people have done that using MapReduce or Spark, GNU parallel or just writing parallel code in their favorite language. But RAM by itself isn't the only limiting factor to whether a problem is solvable in a reasonable amount of time.

No, but I frequently see people implying that you can do your data science in Python and R as long as you can fit the data in RAM. As you mention, it's not RAM that's the limiting factor for larger data volumes, it's finding tools that exploit parallelism.

While pithy, the implication that you are going to process 12 TB of data in RAM using mostly single-threaded tools doesn't reflect reality.

Yes, that was generally my point. Even if available code already took advantage of multiple cores, my experience has shown that currently these chips bring out some latent assumptions on what hardware the code will be running on (whether that's OOM or UX or whatever)

I have the 3970X and use it with Ubuntu. It's fun to have a lot of cores, but in the beginning it's highlighted some areas where open-source programs aren't assuming you're going to use that many cores (similar to what they talk about for Windows). So you see OOM errors with make, see program crashes from defaults being too low (such as creating too many Postgres connections), things like that.

Not taking away from those developers, just sharing my experience. When you do get something that works really well (the newest version of Julia makes it easy to write multithreaded code), it's hilarious running htop and seeing 64 threads of green running.

This article is a great example of how a series of small decisions can mean the difference between wild success and modest success (or even failure)

Collaborator here: these visualizations required 4 NVIDIA P40 GPUs (96GB GPU RAM) for full interactivity using a pre-release version of OmniSci 5.0

OmniSciDB is useful when you need really high-performance from a relational database. Think <100ms query times over billions of records. This level of performance is useful for streaming use cases, operations, repeated drilling into subsets of data, etc.. Note that OmniSciDB refers to the open-source relational database portion of our product.

Using any of the OmniSci open-source charting libraries is useful when you want to do something using only OmniSciDB (i.e. not wanting to purchase Enterprise Edition), or when you want to create a custom visualization that isn't provided by OmniSci Immerse (our commercial visualization tool). Some of the work referenced in the blog post was in partnership with the creators of the Vega.js library as research into high-frame rate and large data interactivity in browser visualization

This is a really comprehensive tutorial, one of better uses of Jupyter Notebooks

How is this fewer than 32,000 steps? Doesn't the act of running this gem on every file to clean it count as a step?

There are 10's of thousands of CS majors every year, and probably hundreds of thousands of people who think being a data scientist would be "fun". No company is going to weed through that pile to find the literal "best" candidate, because acquiring that information is expensive.

Like any other job hunt, it all comes down to networking with people you hope to work with. Blindly learning techniques won't get you anywhere if you don't have anyone who will vouch for you/introduce you to other people

This is a good point. There are lots of interesting possibilities with Observable, especially using the OmniSciDB open-source project for analyses that people intentionally do want to share

Could you be more specific? Does which part scale?

It's certainly possible, I guess the bigger question is whether people would be comfortable having a database do an automatic data transfer into a public tool. In the case of this Jupyter integration, it's a Docker image that's running next to the OmniSci database, so it's all within the same network

This is an interesting comparison I wouldn't have thought of. But yes, PartiQL does have a similar feel to this announcement, though without GPU-acceleration, the processing speed might be several orders of magnitude slower