Hacker Newsnew | past | comments | ask | show | jobs | submit | kernyan's commentslogin

I had an exercise bike that came with a heart-rate band monitor, but it only pairs with the stationary bike. I wanted to use it for running to show heart rate zones. So I wrote an android app that pairs with the band, gets reading and make some nicer display. I had no idea how to write flutter, or talk to bluetooth devices, but github and chatGPT helped a lot.

https://github.com/kernyan/HeartRateBandHacking


> Interestingly enough AWN had this DNS dashboard saved with a filter specifically looking at Facebook traffic. It's unclear why they would be particularly interested in who was going to Facebook.

One likely non-malicious explanation is that the telco is offering some plan with data caps based on social media such as instagram, facebook, etc. Searching around, I found the offering below for unlimited data on 9 social media apps http://www.ais.co.th/one-2-call/simcard/en/super_social.html...

I'm guessing one way the telco implements the selective cap is by tracking user's DNS, and is probably interested to know traffic to facebook


These two books might be useful,

1) https://www.oreilly.com/library/view/electronic-design-autom... 2) https://www.crcpress.com/Electronic-Design-Automation-for-IC...

On the first book, see chapter 10 - 12 (on floorplanning, placement, and routing). End of chapter 11 points you to some literature survey as well. But the book itself is somewhat dated (published in 2009)

I haven't read the second book but it's much more recent (published in 2018), it also has chapters on placement, and routing.


>I think we need a ridiculously fast interpreter so that we can skip machine code generation and linking. To me, this should be the default way of running unittest blocks for faster feedback, with programmers only compiling their code for runtime performance and/or to ship binaries to final users. This would also enable a REPL.

I am most excited about this, where a language supports two modes 1) interpreter for development, and 2) compilation for performance. Never thought about this, but reading this, it makes perfect sense on large projects


I'm a fan of Go's "go run". For example, you can do:

  go run main.go
or:

  go run ./cmd/server
When invoked this way, Go compiles your code behind the scenes, but you don't have to create a binary.

This means Go lends itself pretty well to ad-hoc scripting or writing small script-like tools.

Unfortunately, Go doesn't support shebang lines, but with gorun [1] you can:

    #!/usr/bin/env gorun

    package main

    func main() {
      println("Hello world!")
    }
[1] https://github.com/erning/gorun


D's default package manager already allows you to write code like this which 1. runs the code like a script 2. downloads dependencies if they are required.

    #!/usr/bin/env dub
    /+ dub.sdl:
        name "allthepythons"
        dependency "d-glob" version="~>0.3.0"
    +/

    import std.stdio : stdout;
    import glob : glob;
    
    void main () {
        foreach (entry ; glob("/usr/local/bin/python*")) {
            stdout.writefln("%s", entry);
        }
    }


Dub's documentation should use some love...


D already works like this.

Scala (Ammonite) works like this.

The author isn't complaining about keystrokes; he wants the compile + run process to be faster. Using an interpreter instead of a compiler would make it faster.


Java has the same now (since Java 9 I think).


So you're saying it's as simple as:

java build ./app/ ./app

That's impressive if true as last I worked with Java it was a mess


Not quite. You can run `java Foo.java` and it will compile and execute the class file (and remove it when done).


D compilers do work as a shebang already.


I actually use this for all of my complicated build scripts and just use make to glue them together. For instance I have a stack name from computer,branch,sha,username that I calculate so I have a different stack per thing I'm working on. I tried getting that to work with awk fu but doesn't work the same on every platform, so instead "go run cmd/get_stack_name/main.go" instead. Fast and like it.


OCaml works like that


Haskell too.


Add Flutter to the bunch - having a fast interpreter is especially pleasing when the result is an instant visual change the app running on an emulated android phone.


Java can do this via AOT or partially also JIT compilation.

For AOT there is this JEP: https://openjdk.java.net/jeps/295 and a different project: the GraalVM


Java could do this always, as it's a compiled language (the important thing here is interactivity vs. compilation, not JVM vs. native).

So I'd say that Java can do "this" since recently (JDK 9 in 2017) via JShell (I wouldn't count BeanShell or Groovy), i.e. it always had the compiler part but added the interpreter.

Although its usage is still quite rare, whereas the blog post would suggest a different pattern.


As addendum, Java has had support for AOT since around 2000, the only caveat is that it has been a feature only available on third party commercial JDKs.

GCJ improved very slowly and around 2009 lost most of its developers with the release of OpenJDK.


JIT runtimes try to give you both.

It starts interpreted, but if you run for very long, it runs compiled.

But that costs memory and startup time.


Most JIT runtimes also can't produce a standalone binary


Pretty much all JITs have tools for standalone binaries.

People usually don't do it because JITs are heavy so they'd prefer to share them.


https://github.com/s-matyukevich/raspberry-pi-os

Matyukevich page on GitHub has lessons with accompanying code to develop a Linux OS for raspberry Pi. The author goes into kernel, processor initialization, interrupt handling, scheduler, implementing syscall, and virtual memory.

I like his approach for these reasons 1. Minimal workable code, 2. Points you to entry function in linux repo 3. Line commentary of those entry function

Note that it's also a somewhat short read as he focuses on the practical implementations instead of the theory.

I myself was hoping that the author continue developing the chapters on file system, drivers, and networking but seemed to have been on hiatus.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: