HN user

jvilk

310 karma

PhD from the University of Massachusetts; currently at Stripe.

https://jvilk.com/

Posts3
Comments86
View on HN

Yeah, I had the same experience in my area. It's so strange to see so many people (online, and locally) strongly assert that Costco has the cheapest price on many goods. It's a strangely pervasive notion. We thought that we must be missing something!

Sure, some specific items are always cheap -- like the rotisserie chicken. But outside of those few things, you really have to look for actual savings, and that's true even of baby products which so many in our area seem to get at Costco. In many cases, we would be buying something in bulk for more money than at Winco or Kroger.

Shopping there is also rather disorienting... many times an item we bought one week would be gone the next. Or items would unpredictably shift locations.

As some commenters have identified, there may be specific items you want that are in fact cheaper at Costco. And I only have personal experience from my area, which is not a big city and has cheaper local grocery prices than a more urban area. My main point is: if you've been shopping at Costco assuming you are getting a good deal, you might want to double check against other stores!

What do you mean? Nearly every native English speaker who works with Coq pronounces it "cock" (from experience at POPL, PLDI, and other PL conferences).

Personally, I'm very happy that they are changing the name.

I'd bet that anyone with a PhD could have made more money with a masters degree and a switch to industry.

This is common knowledge for those pursuing CS PhDs. You don't do it for the money. If you only care about money, a master's degree is what you want.

You can capture a heap snapshot in most browsers now using development tools. However, even a blank webpage (about:blank) has tens of thousands of objects allocated for the default JavaScript/DOM APIs. It's challenging to manually grok a JavaScript heap.

I recently wrote an automatic memory leak detector and debugger, which makes this a lot easier (imo) [0]. You write a short input script that drives the UI in some loop, it looks for growing things (objects, arrays, event listener lists, DOM node lists...), and then collects stack traces to find the code that grew them. While it won't find all of the leaks, I was able to eliminate an average of 94% of the live heap growth I observed in 5 web applications (which found new memory leaks in Google Analytics, AngularJS, Google Maps, etc).

More information about the technique can be found in a PLDI paper (which I presented last week :D ), which I tried to write clearly so that it is accessible to a technical audience (i.e., non-academics) [1].

[0] http://bleak-detector.org/

[1] https://dl.acm.org/citation.cfm?doid=3192366.3192376 (shouldn't be paywalled, but if it is, it's also available at [0])

Well, this is useful! I recently built BLeak [0], an automatic memory leak debugger for the client-side of web apps, which consumes heap snapshots during the automatic leak debugging process.

I had to work around the DOM limitations of V8 heap snapshots by building a JavaScript 'mirror' of DOM state that I could examine in the snapshots [1]. Perhaps I'll be able to strip out that logic and rely on the improved snapshots!

[0] http://plasma-umass.org/BLeak/

[1] Discussed in Section 5.3.2 of the preprint of our PLDI 2018 paper: https://github.com/plasma-umass/BLeak/raw/master/paper.pdf

There are meal recipe subscription services that do exactly that. I've been a subscriber to CookSmarts for a few years now, and love it!

https://www.cooksmarts.com/weekly-meal-plan-service/

I pay a low monthly fee for four recipes a week and have access to the archives if I don't like some of the recipes. I like to jokingly call it 'Netflix for meal recipes'. Each recipe has a vegetarian, paleo, and gluten free variant, and it creates a shopping list for your week. You can get a free trial if you want to see what it's like.

Recipes specify what you can prepare ahead of time (so you could do most of your prep for the week in one go), and contain embedded videos showing how to do some of the prep steps if you are inexperienced.

I will note that I simplify some of the meals. For example, some recipes contain salads and specify how to make a particular salad dressing from scratch, but I opt to use prepackaged salad dressing to save time. Other recipes specify expensive items, like capers, that I skip.

I also have lost weight eating these recipes in the portions specified, which has been quite nice.

(Note: I'm not affiliated in any way with CookSmarts; I'm just a super happy customer!)

During undergrad, I wrote up all applicable college assignments using LaTeX for ~3 years. I recommend it if you want the ability to skillfully typeset math or if you plan to attend graduate school.

Pros:

- Transcribing from paper often revealed problems with my solutions

- Easy to modify / improve solutions once typeset

- Easier for me and the graders to read (I have bad handwriting)

Cons:

- Steep learning curve (first assignment took me many hours to complete, but provided the template for future assignments)

- Painful to edit sequences of equations if you are explicitly showing your work

I wrote a library and command line tool that generates TypeScript types for JSON objects from samples. It can also generate "proxy" objects that typecheck JSON objects at runtime, so you can code against JSON services without fear!

The use cases include:

* (Types) Generating quick-and-dirty TypeScript types for a web service or other JSON service you are coding against using response samples in its documentation.

* (Proxies) Ensuring that your code fails reliably when a service returns a JSON object with data that you do not expect. (Otherwise, your code may chug on with an undefined value and fail in a weird place!)

The generated proxies are also useful for non-TypeScript code when compiled to plain ole JavaScript.

To generate types from samples, I adapted the technique used in the F# Data library, which is described in the following paper:

https://dl.acm.org/citation.cfm?id=2908115

Let me know what you think! In addition to the linked demo, the code is on GitHub:

https://github.com/jvilk/maketypes

And there's an NPM package that contains a command line tool:

https://www.npmjs.com/package/maketypes

To better explain from my previous comment, the use case is that you can take a Java program and run it in the browser with no modifications. So, if you have a legacy program or library and rewriting it would be a large undertaking, you can run it in DoppioJVM.

Thanks, rektide! Streams support haven't been added since a) there hasn't appeared to be great demand from folks using the library, and b) I haven't needed it for any project at all.

Feel free to leave comments on the issue if you or others would like to use BrowserFS but have been dissuaded because it lacks streams. I'm interested in your use cases. If your files are relatively small, then basic stream support can be bolted on with 100% preloaded files. If they are larger, then it would require a larger effort to bolt on incremental file loading into each backend to support streams.

Here's the only thing I could easily find via Google [0]:

"The basic design right now is that we draw every pixel of every frame, but there's a lot of overdraw when things overlap. This shows up in the moiré demo where there's a lot of overlap. Also we don't have enough information to do subpixel antialiasing. gw had a great idea to solve both of these problems. The prototype he built uses a ray tracer to trace through all of the objects and draw each pixel only once. That should lead to new features like subpixel AA and also more consistent performance."

More context would be appreciated, though!

[0] https://github.com/servo/servo/wiki/Meeting-2016-03-07

It would require a complete rewrite; I commented previously [0] describing how WebAssembly seems inappropriate for Doppio, and also discussed similar thoughts about SharedArrayBuffer [1]. Also, the main source of slowness is due to the fact that Doppio uses a JVM interpreter and does not JIT; it could be much faster than it currently is with additional engineering.

[0] https://news.ycombinator.com/item?id=11656373

[1] https://news.ycombinator.com/item?id=11655922

Yes; the paper mentions CodeMoo.com, which the University of Illinois created independently of us to teach basic programming skills to kids [0]. The file system component is readily used by the Internet Archive for their MS-DOS collection [1]. A number of other instructors approached me regarding using Doppio for in-browser IDEs, but Doppio is somewhat cumbersome to integrate into webpages, and never had the time to dramatically improve its documentation and ease-of-use. I believe that is a more fundamental barrier to using Doppio than its performance, especially since you can run Doppio in a WebWorker to avoid some of the responsiveness issues.

Also, note that Doppio is an interpreter, so there is significant interpreter overhead. Using a JIT compilation approach would improve performance, and a contributor is currently working on a basic implementation. I honestly believe that it could become significantly faster with additional work, but as a single person with other projects, I lack the resources to do this work myself.

[0] http://www.codemoo.com/

[1] http://ascii.textfiles.com/archives/4924

It's better if you are writing new code for the web and want to use a different language, but Doppio is better if you need compatibility with existing JVM code. The goals are different.

ISC is the default license for NPM modules when you `npm init`, so I am not sure if that's their actual license.

Doppio itself is under the MIT license.

The Doppio authors (me) are completely uninvolved; this is an independent effort! This project makes it a bit easier to integrate Doppio and use it out-of-the-box.

I suspect the assertion failure is caused by some of their modifications to Doppio's start up code to pause and extend the main thread's runtime.

Yes, there is a good reason: Security exploits!

Fortunately, Doppio requires no plugins, and is written in 100% JavaScript. Crisis averted!

Also, more languages than just Java run on the JVM; Doppio can run Scala, Clojure, and other JVM languages.

And Scala devs don't need to learn Scala.js; Doppio runs Clojure and Scala. :)

(Joking; both of those projects are pretty great, and have different goals from Doppio.)

(Also, Scala in Doppio is... uh... quite slow. As you may imagine, if you are familiar with Scala's compilation process.)

Interesting! A cursory glance at the source code looks like they are doing some form of stack splitting at synchronization points, denoted by method annotations. Note that they reimplement the class library and eschew compatibility with traditional Java programs, so I'm not completely sure how general purpose their threads are. I tried finding some writeup about them, but I suspect the code is the documentation. :)

I haven't checked in with this project since we last talked a few years ago, so it's nice to see notable progress! Thanks for the pointer.

Oh, nice! I'll take a look at that when I next get the chance. I assumed that Closure's Long library, which is based on GWT's Long implementation, would be well-optimized, and never looked into an alternative.

Thanks! I hope Doppio can become useful to many more people. :)

There is a proposal for value types [0] that Niko Matsakis [1] and Brendan Eich [2] talked about a couple of years back and could be used to implement 64-bit numbers in JS, but I'm still waiting for an implementation or a more complete proposal. Looks like it might be dead in the water, as the proposal hasn't been edited in quite some time, but I do not have my finger on the pulse of browser standards so I could be wrong.

[0] http://wiki.ecmascript.org/doku.php?id=strawman:value_object...

[1] http://smallcultfollowing.com/babysteps/blog/2014/04/01/valu...

[2] http://www.slideshare.net/BrendanEich/value-objects

Well, if we represented objects with a blob of bytes, we would have to implement our own garbage collector and manage our own heap, as object references would just be a pointer that points into an array somewhere.

For interop with JavaScript, there's a usability difference between a JavaScript object and a blob of bytes, although that could be overcome with an object "mirror" that proxies operations appropriately.

Our approach was to leverage the existing GC and language features that browsers already have.

One of Doppio's explicit goals was to leverage existing resources in the browser to bring conventional programming languages to the web on top of JavaScript. Using WebAssembly would prevent Doppio from using the browser's garbage collector; we would have to write our own. It would also prevent Doppio from mapping JVM objects onto JavaScript objects.

The WebAssembly standard is constantly evolving, and now contains some ambiguous statements regarding the ability to take advantage of the browser's GC [0]. Considering WebAssembly's current focus on C/C++ code, I do not believe this will come to fruition anytime soon. If it does, I do not see how it would noticeably improve Doppio's current performance, which is bottlenecked primarily by its interpreter. A contributor is working on a JIT right now to make execution faster [1].

Hope that clarifies!

[0] https://github.com/WebAssembly/design/blob/master/GC.md

[1] https://github.com/plasma-umass/doppio/pull/443