laarc

Friendly fellow. I've heard that the site's community felt like they were a part of a movement. Did they know the operators felt this way?

Analysis of the community in general seems interesting. I wonder if their forums were archived anywhere.

It seems like this might also be one of the best ways to learn R. This is a real-world scenario, and various libraries are brought to bear on the problem. It feels accessible to beginners like myself, and it poses a question that I'm sort of tempted to try chasing...

Anyone have any theories about why Wednesday 4-5pm appears to be the most common time for arrests?

A comment says "It's because that's the day and time when there are the most patrol officers out on the street." Is there a data source that might prove/disprove this?

Maybe a whoishiring-type weekly submission might be a better format? "Here's some interesting stuff you may not have seen."

This is a mindset the world could use more of. Best of luck.

The first thing to do is to check whether the company has any disclosure programs set up. This is somewhat rare, but companies are starting to pay regular bounties for this type of thing: https://hackerone.com/hacktivity

If there's no program in place, contact a pentester and ask how to proceed. There are a variety of pentesters available on Twitter who will absolutely jump at the chance, so if you're looking for a way to responsibly disclose a bug, that's one way to do it. If you're worried they might try to claim credit, well... Don't worry about that. No one's interested in tanking their own reputation by pulling a stunt like that. The discovery is much more valuable to you than to them.

What you should not do is continue to probe the vulnerability beyond what you initially discovered. E.g. if you got access to a server somehow, disconnect and seek a way to responsibly disclose the vuln. Don't try to see how deeply you can breach, and don't run commands to poke around at their data.

If you're a teenager, there are pretty much two options: Show the vuln to your friends, or try to disclose the vuln responsibly. Showing it off is usually a bad idea. They'll probably pressure you to show off, which makes disclosure a little more difficult. The cred you get won't matter long-term. But impressing your peers is a pretty powerful force to try to persuade against in an HN comment. Whatever you do, don't tell anyone but a pentester any specific steps to replicate your finding, else you'll be on the hook for whatever silly thing they do.

Your vuln may seem very important, and maybe it is. But you're also usually the first one to run across it. Even if it takes 17 months to resolve an issue, companies in the current social climate are almost all willing to work with you to get it done. This is where contacting a pentester can help, because they can contact the company on your behalf, or at least advise you about what to say when you contact them. Again, don't worry about them claiming credit; they have no interest in such things.

The article raises a few points I'll pass on addressing. I wanted to give a perspective on how to disclose a vuln that you stumble across.

Emphasis on "stumble across." The world is in a strange state right now where it's not really a good idea to go looking for flaws unless a company is actively asking you to seek them out, like Twitter.

Usually I try not to leave dupe comments, but in this case the story is off the front page and you might not see it otherwise:

I've been trying to find an emacs user to ask some (admittedly beginner-level) questions. I'm trying to get a certain obscure emacs plugin set up, but I occasionally run into some elisp problems that take a few hours to track down. So I was hoping to find someone to bug with questions.

I'll figure it out one way or another, but a peer would be nice. I was wondering if it would be ok to email you?

No worries either way. Have a great week!

I have a few questions I was hoping to ask an emacs user, and it sounds like your situation was almost identical to mine. Is there an email address I can reach you at? (If not, that's fine! Thank you anyway.)

"So-and-so is coming to speak at my university, but there was a bomb threat."

"What?"

"Yeah, it's pretty crazy. I think her talk is going to go on anyway, though."

"Can't the FBI do something?"

"Not really."

Apparently stuff like this happens a lot. It wasn't till then that it sunk in how pervasive the problem is. The bomb threat was apparently due to the speaker's public remarks about gamergate.

I don't know. Bad situation all around.

  brew install rlwrap
  brew install sdl2
  brew install sbcl
  wget https://beta.quicklisp.org/quicklisp.lisp
  shasum -a 256 quicklisp.lisp  # c.f. https://www.quicklisp.org/beta/
  sbcl

  (load "quicklisp.lisp")
  (quicklisp-quickstart:install)
  (ql:add-to-init-file)

  (exit)

  cd ~/quicklisp/local-projects/
  git clone https://github.com/afainer/cleven.git
  cd cleven
  rlwrap sbcl

  (ql:quickload "sdl2")
  (ql:quickload "cleven")
  (load "sandbox.lisp")
  (in-package #:sandbox)
  (run-sandbox)

  debugger invoked on a SIMPLE-ERROR in thread
  #<THREAD "Render thread" RUNNING {1006D70EF3}>:
    Shader compilation failed.  The info log is:
  ERROR: 0:24: '' :  version '330' is not supported

Unfortunately I'll have to stop here, since I'm a bit pressed for time. This project is way cool, so I'll look into it more later. If you have any ideas how to debug it further, please let me know here or by email.

Those steps might work for other people on OS X, though. There's probably some kind of driver issue on my end. (Ah, the life of gamedev...)

Edit: Created issue https://github.com/afainer/cleven/issues/1

The result would be the inverse: a living body controlled by a program.

The fact that cryogenics destroys your cells seems like an insurmountable obstacle. Freezing causes expansion. There's nothing of value to salvage after that.

I wonder if they could experiment with ways of overcoming this?

I've been using vim for a decade and I'm trying to switch to emacs. Retaining muscle memory is only possible if I keep using the bindings I learn. Remembering all of them is difficult, and using a subset will lead to suboptimal results.

Some kind of app that quizzes me seemed like a good path to learning emacs, since after 100 hours I would end up much more effective. Then I realized maybe an app like that might be helpful for anyone investing 100 hours into a variety of things.

What I mean is, there is a large body of existing code that I'd like to run alongside Terra. But if the choice is Terra xor LuaJIT, this becomes difficult.

I'll have more time to look into your work later, but I wanted to say (a) very cool! Keep it up! (b) check out Lumen (https://github.com/sctb/lumen). It compiles into Lua, and can be powered by LuaJIT. The benchmark performance is off the charts, on par with LuaJIT itself, because it compiles to code that mimics the way you'd write in Lua without any of the hassle.

My current plan is to add support for running Lumen via luvit, which provides many libraries for LuaJIT, some of them useful for gamedev. If you're interested in some kind of a collaboration, shoot me an email or something. But regardless, best wishes and good luck!

By the way, thanks for making this available under a permissive license. It's not always an easy decision, but the gamedev industry in particular will be improved by choices like this.

I left a rather critical comment, but I wanted to say that the piece has many good points. I was wondering if you could provide examples of ideas you're trying to aim for.

This excludes most ideas that can affect the world.

Is not being worked on by anyone else (i.e. no direct competitors).

Dropbox had about a dozen when they started. Viaweb had none, but quickly had a dozen. Maybe the author means the latter is a good situation to be in?

The first mover has a major advantage. [...] Is a natural monopoly that can be defended.

Without funding, you won't be able to exploit these advantages. But they seem some of the most important to aim for, if possible. E.g. Uber and Ebay.

Solves an interesting and/or important problem that will make your mother proud.

Most parents are shocked by what their children work on which later turn out to be great ideas. There are an even larger list of parents who were right, though.

The author makes some good points. I'm misunderstanding the point of this list, I think. Aiming for all of these seems to exclude two kinds of ideas: those that can affect the world, and those that can get you rich. But aiming for a subset of them depending on your goals seems more promising.

Creating a new model seems more valuable than specific areas of research.

As far as specific projects go: big discoveries are almost never centrally planned. It might be important to set up the environment to let small ideas grow from acorns into oak trees.

A research team needs to be able to pivot like a startup, and current systems don't really allow for that.

1. Make it as effortless as possible to copy any code from any repo into a subfolder of your own repo. The subfolders should automatically pull in any new changes by default, and can be pinned to a specific commit hash / branch.

2. Come up with a way to do "structured monkeypatching." Sometimes you run across a bug in someone's library but don't have the time to fork it, fix the bug, submit a PR, and change your project to use the fork. This is also hard when you have many repos that depend on whatever library you're fixing. Now you can just `monki clone` the troublesome library, then describe to monki how to fix the bug.

(There's a sneaky third motive: I've been working on a new dialect of Arc, and I'm trying to hone the language by building real applications in it as quickly as possible. Then I fix whatever pain points pop up.)

Here's an example of #2: https://github.com/laarc/monki/blob/master/lumen/monki.l ... Monki is powered by Lumen, but it extends Lumen with additional syntax like """python raw strings""", without forking it.

I don't know if these scenarios are common for many other people, or if anyone would find this useful.

No no, if anyone failed, it was me! Don't worry about it. If I'd done a better job showing people, or if I'd given them something to play with, then words would've been unnecessary. We're all in it together. Part of the challenge is making everyone feel like they can do great things.

Is a "gut feeling" enough?

Counter-intuitively, it seems like the answer is yes, for two reasons: (a) It prevents me from fooling myself. If I say "Look how beautiful this design is," people will push back if most disagree. (b) If young people don't want to build cool stuff with Lisp, then that's alarming to someone who intends to grow Lisp, as I do. And young people turn out to be the most likely to vocalize a negative gut reaction.

The trick is to be aware when (a) happens, but to brush it off if you're right and the world is wrong. It's as hard as it sounds.

I usually run the language past some friends and tell them to be as cynical as possible, then think of ways their critique is justified. The discoveries from that process have been so cool. For example, the outermost parens of a Lisp expression are unnecessary:

  (def even (x)
    (is (mod x 2) 0))

  def even (x)
    (is (mod x 2) 0)

Whether it's a good idea to formally drop them is a different question, but now I know to check. It'd break all existing Lisp auto-indent plugins. But that could be worthwhile; it depends.

User testing has been pretty great.

Wart is freaking cool! Thanks for showing that. Whoaaa, you use tangle/weave! How do you like it / what do you think about literate programming? I was batting around the idea of writing code that way, but it seemed like tangle might not be the best solution. But I love your 000prefix naming scheme; I instinctively do that for branches. After reading through a few files starting at https://github.com/akkartik/wart/blob/master/literate/000org... it became pretty clear how wart worked, pretty quickly. I'm mainly wary of the "compile" step that using Tangle implies; do you find it slows you down much? Would you choose to do it that way if starting fresh?

What would a language ecosystem be like without any backwards-compatibility guarantees, super easy to change and fork promiscuously?

It's fun to find someone has been mulling over the same problems!

I was considering taking Laarc in a similar direction:

  (import "akkartik/foo")

It would also rewrite its own source code to look like:

  (import "akkartik/bar" "f1d2d2f924e986ac86fdf7b36c94bcdf32beec15")

So it's static linking, basically. It's a guarantee that "This source code will always work, the same way (+ 1 2) will always yield 3. You could copy-paste this source code into a gist, and whoever ran it would end up running the same program."

That removes dependency hell / worrying about versions entirely. But it's not the right solution, and I've been searching for a better one. What do you think?

The problem is that it throws away the ability for the code to pull updates from library maintainers. If the import is "pinned" at commit f1d2d2f9, then you push a security-related patch to akkartik/bar, most existing code will stay vulnerable forever, because most code is never maintained after being written.

I was thinking of following that model, but using the convention that libraries are expected to use git tags in order to indicate major.minor.patch, and (import "akkartik/bar" "f1d2d2f924e986ac86fdf7b36c94bcdf32beec15") will bump itself to the next commit if it's tagged as an increment of the patch version.

What kind of things have surprised you about Wart during development? Any unexpected pitfalls or interesting discoveries along the way? Thanks again for pointing it out!

By the way, were there any ambiguities with indentation-as-parens? I haven't thought about it rigorously, so I was just wondering if there are any corner cases to watch out for when I add it.

Sure. That's easy in Lumen: https://github.com/sctb/lumen/commit/6410c8cc2de66d1976515bd...

Is it possible to use this technique to introduce, say, infix arithmetic operators?

Yep! I wrote a macro to swap any instance of `x with the previous expression. Meaning, it allows you to write:

  (foo `= (x `+ y))

  (= foo (+ x y))

But more generally, it's easy to write a macro to do whatever you want. If you really want infix expressions all of the time, I could imagine writing a macro which matches the pattern (... + ... + ...) and replaces it with (+ ... ... ...)

That's made-up notation, but the idea is just "look for some set of symbols, like + or /, which occur within a list in between all of the other elements, and then move the symbol to the front of the list."

The power is available to you, but whether you choose to use it is a separate question. Prefix notation tends to be a win for everything except math. And even for math, it's usually a matter of code formatting. Rather than

  (- (* 2 (/ (+ x y) (+ a b c))) 1)

  (- (* 2
        (/ (+ x y)
           (+ a b c)))
     1)

  (let u (+ x y)
    (/= u (+ a b c))
    (*= u 2)
    (-- u))

  let u (+ x y)
    /= u (+ a b c)
    *= u 2
    -- u

- Arc embraces macros.

- You can redefine anything. (assign + -) (+ 3 4) evaluates to -1. Not only are you an equal partner to the language, but the language is short enough to carry in your head.

- Green threads. Here's a snippet from Laarc which does hot code reloading:

  (thread
    (on-err autoerr (fn ()
                      (while autoload*
                        (sleep 0.25)
                        (autoreload)))))

But green threads make it so easy to do that in parallel. I never once had to worry about synchronization issues in the case of the autoreloader.

- There's no FFI for Arc. However, I'm in the process of porting Arc from Racket to Lumen, which has a very interesting FFI thanks to LuaJIT: https://github.com/sctb/motor/blob/master/motor.l

It's literally "copy-paste these C declarations. Now you can call those C functions." It quite simply rocks.

If you're interested in Arc, consider Lumen as well. https://github.com/sctb/lumen

It has many similarities to Arc, like a powerful macro system, and has some interesting distinctions, like keyword arguments and the FFI facilities.

It turns out that if you use arc for something critical, the language itself won't break. The programs written in Arc might contain bugs, but as far as I can tell, the underlying infrastructure is solid.

This is going to sound like bullshit, but a couple years ago I wrote a site in Arc and left it running by mistake. It was set up to push hourly backups to Tarnsap, and the site was doing useful things, but I never ended up needing it.

Turns out the site continued running for 1.4 years by accident. There weren't any scripts to restart the server on a reboot -- it simply ran for that long. Presumably it halted because Amazon rebooted the micro instance or the account ran out of money. When I checked the logs in Tarsnap, I was pretty amazed to find that it had served 37k requests, almost all of which were automated fuzzers. I hadn't launched the site; it just happened to be using an obscure URL. The site had a bit of dynamic functionality, so it wasn't merely a static site. But I hadn't written it cleverly or carefully. Arc is what carried the site for those 16 months, not me.

As for the community: correct, but I intend to change that. If the growth exponent flips from negative to positive, it won't be small for very long. In the meantime, though, they're some of the nicest and most helpful people ever, so feel free to post whenever you get stuck, or shoot me a message.

Here's an example in concrete terms of the power of this technique: https://github.com/laarc/monki/blob/master/sudoarc.l

That's a file which adds many of Arc's constructs to Lumen: printing (pr, prn), list building (accum), structure (w/uniq, aif, awhen), etc.

To put it another way: At the top of the file, the language available to you is Lumen. But at the bottom of the file, the language available to you resembles Arc. (It doesn't redefine anything from Lumen, though, so it's not a destructive change.)

That must sound pretty dubious. It probably sounds like it's useful only for lone-wolf programmers rather than a team. If you give people the power to reshape the language, wouldn't it wreak havoc in a team setting?

The answer turns out to be no, and it's surprising enough to write an essay about. Having macros available to your team ends up making your team more powerful, not less. It's simply a technique to generate patterns of code.

When coupled with a good debugger, there's no mystery when things break. When an error happens, you get a debug breakpoint right where the error occurred. It makes no difference whether the error occurs during a macro expansion or during a function call, because macros are simply functions that answer "What should happen next?"

It's like having a function that takes code as input and returns code as output, which is then executed. Except in Javascript, you'd have to do that by representing code as strings, which get passed to eval. In Lisp, code is a list. Meaning you can walk through it and see "This is an if statement. This is a function call." Etc.

It's true that there are ways to abuse macros which make them difficult to understand or debug. But this is rare. The most common case is a short, simple transformation like d0m showed: "here is a pattern; please generate it."

Imagine a language whose startup time was faster than python / ruby / node, yet could be bent into whatever shape you wanted, thanks to macros. If you install luajit and run `make; make test`:

  $ time make test
  js:
   525 passed, 0 failed
  lua:
   525 passed, 0 failed

  real	0m0.153s
  user	0m0.119s
  sys	0m0.033s

I should start by clarifying that I'm not associated with Arc in any way. Everything that I show should be thought of as an eager derivative, at best. But for several months a colleague and I have been working on a derivative, which we've been calling laarc, which incorporates a few additions that make it a bit easier to write programs with. Here's a debugger similar to pdb.set_trace(), for example: http://i.imgur.com/WWKa4kw.png Except when it breaks, it shows a list of the values of all the local variables. It's really useful for stepping through macro expansions and understanding them, because there's no longer any mystery when something breaks. Laarc isn't anywhere near ready yet, so it's too early to know whether it'll be useful generally, but the goal is to discover a way to make programming feel like a Tesla.

So, what are the benefits? Well, here's an example of a real-world program. It's all pimply and has a few hacks in it, but on the other hand, you can get a gist of how it might look: https://github.com/laarc/monki/blob/master/main.l

Note that this was made two days ago, and I've been working very fast. So it's pretty rough. The program (monki) is essentially "cp for git", and while it works, it's not quite finished. Monki is Yet Another alternative to git subtrees / submodules; think of it like "cp for git". `monki clone voltagex/foo foo` would create a clone of that repo into the subdir "foo". But that subdir can be within one of your existing repositories.

Here's the scenario it's useful for: https://github.com/tlbtlbtlb/startuptools

This requires an installation of tlbcore (https://github.com/tlbtlbtlb/tlbcore) symlinked to this directory.

With monki, you'd just type `monki clone tlbtlbtlb/tlbcore tlbcore` from within a clone of startuptools, and then you'd commit the result. Monki takes care of pulling updates, so that whenever tlbcore changes, startuptools would also get the new stuff. But you can `monki clone` a specific commit instead, if you want to pin to a "known working" version.

Anyway, that monki business was the result of trying to answer "What's a simple way where I can share code between all my repositories, pull in updates as I make them, and not have to worry too much?" And it was a good chance to exercise... Lumen!

Confused yet? Ok, so Arc runs on Racket. So did Laarc. Then we had the good fortune to hear about Lumen: https://github.com/sctb/lumen

It's a Lisp that compiles to either Javascript or Lua. It literally exhibits the same behavior whether you're running via luajit, node, or the browser. Since LuaJIT's FFI is awesome, that makes it incredibly easy to interface with existing C libraries using Lumen. Just look how beautiful his postgres bindings are! https://github.com/sctb/motor/blob/master/pq.l

That should catch anyone's attention -- the FFI is literally "copy paste some C declarations and you're done."

I want to take that further. In Lumen, it's already possible to interface with node libraries or with lua libraries as-needed. What if we extend it to work with python and go libs as easily as it works with C? You might end up with a language that could do any given task very easily, because you'd simply use whatever library happens to be convenient regardless of whether it's a C lib, a node package, or a Ruby gem.

So why have I been yakking about Lumen? Because it seems like it offers a bunch of interesting benefits as a runtime. I've been porting Laarc from Racket to it, slowly. It's extremely early, but here's an early version of the compiler: https://github.com/laarc/lumen-arc/blob/master/arc.l ... It's essentially ac.scm. I wanted to make it match as closely as possible, both because ac.scm is a good answer to "What's a good way to write a lisp compiler in a lisp language?" and because it's dangerous to assume you can write from scratch something that a smart team has been thinking about and working on for 13 years.

Sooo... That's a whirlwind tour of stuff that's not even ready to tour. On the plus side, the plan is to get an in-browser repl running soon (arc can already run in the browser, so it's a matter of coaxing CodeMirror into submission). There's a server running Lumen over at http://arc.lol:9999 which does absolutely nothing useful yet. The plan is to get a REPL up and to dub it "Arc dot tiefighter" since "lol" obviously looks like a tie fighter.

Here are some unfinished notes about what the diffs mean: https://gist.github.com/laarc/a07799e89940dc7c31c9 It's interesting how short the diffs are vs how many features and fixes they deliver.