sigill

Funny to see this. I once considered x86 emulation plus emulation of a number of Linux system calls in JS as a way to get Go programs running in the browser. In contrast to the submission, this would have allowed umodified programs yo be run, even written in another language than Go.

Great idea! I have always felt that the Wireshark Lua bindings are not ready-to-use enough. They feel like the ugly stepchild of Wireshark.

In the last dissector I wrote, which was about 1000 lines of Lua, I built a very limited structure definition parser, not completely unlike wssdl. I did it to cut down on the repetitive code needed parse the structures: Typically I parse every field twice: Once to add it to the dissection tree and once to get its value as a Lua-held variable.

I'll definitely be using wssdl in my next dissector!

As other comments tell you, software breakpoints are used with flash parts such as the AVRs. You can write flash from they outside.

Yes. And these software breakpoints are written into flash. This is why they're very slow - and why they wear down your flash.

The situation is kinda OK when you don't often change breakpoints and your CPU has an instruction register writable by the debug probe via JTAG/SWD/etc. Upon stepping or continuing from a breakpoint, the debugger will write the actual instruction at the breakpoint into the instruction register and tell the CPU "run again, but don't load the instruction from memory as I have already loaded it into your instruction register.".

Another option is to emulate the effects of the instruction in the debugger and write the results back into registers/RAM/I/O. This is not always possible.

If you don't have the options above, your flash will wear down quickly, as stepping away or continuing from a breakpoint entails writing the actual instruction back, stepping, then writing the breakpoint again.

ACID sure is a way to deal with data change faster than once a day. Once you stop passing paper slips and order forms through your company, you can get accurate, up to date information at a human timescale, i.e. on the order of seconds.

Of course when you want stuff to happen at a faster-than-human timescale - or when you just want lots of stuff to happen - an ACID model might not be the right fit.

> As for "local scope" I meant "at a single business entity".

Understood.

> This is quite arguable. Before the Computer Era, all businesses, including the whole financial sector did just fine without ACID.

Can you elaborate a bit? I believe that in the pre-ACID world, business processes were much slower, not online processes like today. When you're only really changing data once a day, backups and manual intervention are acceptable options.

> Still, ACID is used only at a local scope.

What do you mean by "local scope"?

Do you propose having another syntax for getting the zero-length slice just past the last element? The [2:] syntax giving you {} is a pretty natural progression from [0:] giving you {0, 1} and [1:] giving you {1} in your example.

The submission links to a blog post on how the data was retrieved: http://255.wf/2016-09-18-mass-analyzing-a-chunk-of-the-inter...

> For this little experiment, I’ve setup a single KVM instance, running a single 2GHz vCore with 2GIB of RAM and 10GiB of HDD space. This is sufficient. Probing for ftp access is an extremely CPU-intensive task. You are going to hit bottlenecks in this order: > > CPU > Memory > a whole lot of nothing > network > > While the rescan was running, only about 1 to 2kpps were exchanged, while the CPU was pinned at 100%.

So this means his setup spent about 1-2 million clock cycles per probe. That's a lot!

I suppose this is because he runs the probe script once per IP address? I suspect that an implementation which would stay in-process would be at least an order of magnitued faster.

> Customization is what distinguishes platforms from applications.

What does this even mean?

Unix history certainly has aspects of the "grandfather's axe". Few users of unixoid systems today are running original 70ies Unix code.

But Unix is not just code. The concepts introduced by Unix - or at least the flavor given to certain concepts - lives on to this day. Basically all of the userspace-kernel interface, the system calls, are still there and work in largely the same way. These concepts and interfaces are parts of the axe too and they haven't been replaced.

Thank you. I was thinking of scale as a measure of order of magnitude and then it didn't make sense.

The article makes a number of good points. The first three points in the "Learning" section resonated very well with me.

Then there's stuff I just don't understand. For example:

> Multiple scales. Move between scales freely. Maybe this is a design problem, not a testing problem. Maybe it is a people problem, not a technology problem [cheating, this is always true].

What does he mean by scales?

Sorry, I haven't been dogmatic about listing all the puns.

Where is your dog now?

> But after decades of dogged effort, he and his fellow scientists are still arguing about the answers.

> Other canine genetics experts think that Larson’s barking up the wrong tree.

> Of all the problems that scientists struggle with, why has the origin of dogs been such a bitch to solve?

It seems like the author was in some sort of pun writing competition.

> Not only is it [linearly written code with async/await] easier to read (as the chaining example was), but now the error handling behavior is the exact same as regular synchronous JavaScript code.

Then why not write code synchronously in the first place?

I understand that async/await looks attractive in languages with an event loop model, such as Javascript, or with expensive threads, such as C#.

I see two main justifications for async/await in these languages: 1. Linear code. 2. More performant code.

It's easier to follow a linear flow of code than it is to follow entangled callbacks and state machines.

Async/await is also sometimes perceived to help with performance. This is an observation that is typically made in languages with few, heavy threads, such as C#. As async/await code "doesn't block", expensive thread resources are mostly free to execute concurrent async/await code.

It seems to me that async/await provides very little apart from making code flow over callbacks look like regular, synchronous, structured, procedural code.

It introduces new concepts: Now there are two types of function calls: vanilla "blocking" function calls and the new async function calls. The difference is that one "blocks" or "takes a long time" whereas the other does not.

Some APIs are only available in one flavor. How do I adapt between the two conventions in code that is required to deal with both API types?

C# and the .NET framework mostly choose to completely double API surface - for example you now have a System.IO.Stream with both vanilla and async/await Read()/Write() etc. methods. You can only hope that they're implemented in a consistent fashion. (they're not)

Given all these conceptual and practical disadvantages I don't understand how async/await becomes such a praised thing.

I'm in favor of coroutines/green threads/goroutines (depending on whether you learned programming in the 1970ies, 1990ies or 2010ies ;)) with a scheduler that multiplexes I/O to the appropriate OS concepts for concurrency. With this approach you get the benefits of structured, procedural programming without the mental and practical disadvantages of async/await.