happi / thebeambook Goto Github PK

I am stucked with the Inspecting message handling example:

4> P = spawn(fun() -> receive stop -> ok end end).
<0.63.0>
5> P ! start.
start
6> hipe_bifs:show_pcb(P).

It is supposed to show the message queue of a process like this:

...
408 | msg.first | 0x00007fd40962d880 | |
416 | msg.last | 0x00007fd40962d880 | |
424 | msg.save | 0x00007fd40962d880 | |
432 | msg.len | 0x0000000000000001 | |
696 | msg_inq.first | 0x0000000000000000 | |
704 | msg_inq.last | 0x00007fd40a306238 | |
712 | msg_inq.len | 0x0000000000000000 | |
616 | mbuf | 0x0000000000000000 | |
640 | mbuf_sz | 0x0000000000000000 | |
...

All I see is :

P: 0x00007fd9ef6400b0

Offset| Name | Value | *Value |
72 | htop | 0x00007fd9ec1bb020 | |
96 | hend | 0x00007fd9ec1bb2d8 | |
88 | heap | 0x00007fd9ec1bab90 | |
104 | heap_sz | 0x00000000000000e9 | |
80 | stop | 0x00007fd9ec1bb290 | |
592 | gen_gcs | 0x0000000000000000 | |
594 | max_gen_gcs | 0x000000000000ffff | |
552 | high_water | 0x00007fd9ec1bab90 | |
560 | old_hend | 0x0000000000000000 | |
568 | old_htop | 0x0000000000000000 | |
576 | old_head | 0x0000000000000000 | |
112 | min_heap_.. | 0x00000000000000e9 | |
328 | rcount | 0x0000000000000000 | |
0 | id | 0x0000021000000423 | |
336 | reds | 0x000000000000001a | |
16 | tracer | 0xfffffffffffffffb | |
24 | trace_fla.. | 0x0000000000000000 | |
344 | group_lea.. | 0x0000019800000333 | |
352 | flags | 0x0000000000002004 | |
360 | fvalue | 0x000000000000640b | |
368 | freason | 0x000000000000000a | |
320 | fcalls | 0x00000000000007c9 | |
384 | next | 0x00007fd9ef6444b0 | |
48 | reg | 0x0000000000000000 | |
56 | nlinks | 0x0000000000000000 | |
616 | mbuf | 0x0000000000000000 | |
640 | mbuf_sz | 0x0000000000000000 | |
464 | dictionary | 0x0000000000000000 | |
472 | seq..clock | 0x0000000000000000 | |
480 | seq..astcnt | 0x0000000000000000 | |
488 | seq..token | 0xfffffffffffffffb | |
496 | intial[0] | 0x000000000000320b | |
504 | intial[1] | 0x0000000000000c8b | |
512 | intial[2] | 0x0000000000000002 | |
520 | current | 0x0000000000000000 | 0xffffffffffffffff |
296 | cp | 0x0000000000000000 | 0xffffffffffffffff |
304 | i | 0x00007fd9ed8294c8 | 0x000000000043f0bb |
312 | catches | 0x0000000000000000 | |
224 | arity | 0x0000000000000000 | |
232 | arg_reg | 0x00007fd9ef6401a8 | 0x000000000000320b |
240 | max_arg_reg | 0x0000000000000006 | |
248 | def..reg[0] | 0x000000000000320b | |
256 | def..reg[1] | 0x0000000000000c8b | |
264 | def..reg[2] | 0x00007fd9ec1bab91 | |
272 | def..reg[3] | 0x0000000000000000 | |
280 | def..reg[4] | 0x0000000000000000 | |
288 | def..reg[5] | 0x00000000000007d0 | |
136 | nsp | 0x0000000000000000 | |
144 | nstack | 0x0000000000000000 | |
152 | nstend | 0x0000000000000000 | |
160 | ncallee | 0x0000000000000000 | |
56 | ncsp | 0x0000000000000000 | |
64 | narity | 0x0000000000000000 | |

true

What am I missing?

The chunk named Atom is mandatory

This is no longer true, either the Atom or AtU8 chunk need to be present.

Haven't looked through all code, but there are a few HTML entities here and there:

https://github.com/happi/theBeamBook/search?utf8=✓&q=%26gt%3B&type=

https://github.com/happi/theBeamBook/search?utf8=✓&q=%26lt%3B&type=

https://github.com/happi/theBeamBook/search?utf8=✓&q=%26amp%3B&type=

As I am working now on a very similar topic (writing a beam-like writer/loader and implementing my own VM loop), I will be updating this chapter on the way, and a PR will follow.

https://github.com/kvakvs/theBeamBook/tree/ap-beam_instr-work

This book is ridiculously good. I have only read a few bits of it so far and have learned a lot already.

Please continue being awesome! 👏 👍 💯 🥇 😀

So it avoids unnecessary Travis failures.

call Arity Label
Does a call to the function of arity Arity in the same module at label Label. First count down the reductions and if needed do a context switch. Current code address before the call is saved into CP.

The before the call should be after the call.

Source code ref.

In source for the above screenshots list:appends and list_to_atom are surrounded by +, but it's not doing anything in the rendered ASCII doc on https://happi.github.io/theBeamBook/#_preface as shown in the screenshot. Maybe try switch to backticks?

In PCB section, there is a mention to the file show.erl to show the tag type, but I don't see the file. Is it supposed to be added ?

As an example, see: https://happi.github.io/theBeamBook/#_redbug

In "The Erlang Type System" section, the 2nd paragraph below the "Erlang Type Lattice diagram" (diagram is Figure 18 in the web version on your website), it says:

Both (1 < 1.0) and (1.0 < 1) are false, and (1 =< 1.0 and 1 >= 1.0) and (1 =/= 1.0).

I believe it should instead say:

Both (1 < 1.0) and (1.0 < 1) are false, while (1 =< 1.0), (1 >= 1.0) and (1 =/= 1.0) are true.

Compact term encoding is used by BEAM assembler to encode literal terms and special values (like register targets) inside the 'Code' section.

Here's my explanation with some code examples
http://beam-wisdoms.clau.se/en/latest/indepth-beam-file.html#beam-compact-term-encoding
I'll be happy to have parts of it taken/reworded/copy-pasted etc how you see fit.

None of mentioned URLs in section 1.4 works:

• http://erlangonxen.org : I found this discussion which claims the whole idea is abandoned, but the code still lives on github, although it is updated 6 years ago for the last time.
• http://www.erjang.org : It seems the project is not maintained anymore (website is unreachable), because the last JDK version used is 7 and the repo is updated in 2016 for the last time.

In the Scheduling: Non-preemptive, Reduction Counting section I think there is a minor mistake in the wording of the sixth paragraph, but I'm not 100% sure.

It reads:

Each function call is counted as a reduction, and BEAM does a test upon entry to each function if the process has used up all its reductions.

Should this instead be (changes in bold):

Each function call is counted as a reduction, and BEAM does a test upon entry to each function [to check] if the process has used up all its reductions.

It currently reads as if BEAM only performs the test if the process has already used up its reductions, but from surrounding context it seems like BEAM should be performing the test to determine if reductions are used up or not.

I'm not an expert (yet!) so this could just be my lack of understanding of how the BEAM works rather than an issue with the wording.

In the information box in section 6.2.14 if all the tag values are shifted down by one then:

and literal is 2#1010111

should read

and literal is 2#1000111

Hi guys, I wonder whether this project have plans for other languages? I could translate it to Chinese if it's ok ;)

Probably some links are broken, but images are not appearing:

URL in the book is: https://happi.github.io/images/observer_system.png

Not to clutter the root dir.

I haven't checked the whole of the book yet, but at least from the BEAM section I can see:

I'd happily replace it all over by the * symbol but I'm not sure what consequences it'll have for the PDF rendering.

Hi,

it would be useful to have a pdf available to download that represents the current release version.

Currently we could create version tag 0.1.0 and deliver the pdf. This way we avoid to make everyone to build the project, install the dependencies and "fight" against the troubles that can arise when building.

For example rebar3 project make the binary version available in each release, what is really cool.

Erik, I was waiting to buy your book before it was canceled. Thank you very much for make it available now as open source.

(see you at EUC2017 )
Cheers

Pedro

On type_system.asciidoc there's the following sentence:

These aspects of the Erlang type system, strongly statically typed
with an order on the types puts some constraints on the implementation
of the language.

Given what is previously written in the chapter saying that Erlang is strongly statically typed confuses me. Is it really correct?

In the chapter 1.3.2 you example some OTP behaviours, one of them gen_ftp:

The fifth layer, OTP, supplies the Erlang standard libraries. OTP originally stood for "Open Telecom Platform" and was a number of Erlang libraries supplying building blocks (such as supervisor, gen_server and gen_ftp)

May be you means gen_tcp?

The Revision History section in the book is becoming larger and larger and I see very little point in maintaining a complete history of the book inside the produced PDF, now that the project is open source. I would personally remove and add a THANKS section, instead (ideally automated by running the git log, extracting the contributors and u-sorting them. Opinions?

When I reading message passing chapter.

I found newer OTP had made some changes, such as ErlMessageInQueue has been renamed to ErlMessageInQueue since this pr erlang/otp@a67e91e.

And some strategy has changed I think.

Do you mind If I do some update about those changes?

I mean rewrite the message passing chapter based on OTP 23?

Hi, the images like followings are missing in chapter 3:
fig-observer_system, images/observer_applications.png, images/observer_processes.png, images/observer_code_server.png

(If it's ok to add images of observers on Mac, I can add them).

First of all, thanks a lot for your great work! 🙂 👍

In the last paragraph of section 7.2 BEAM code listings, right above section 7.3 Calls (pdf page 96) it reads:

Then the instruction {move,{atom,beamexample1},{x,0}} moves the module name atom to the first argument register x1

Doesn't {x,0} mean that it moves it to x0?

It would be great to get some basic CI pipeline in place, so that only Pull Requests which would not break compilation could be merged. The pipeline could also be used to ensure that the generated PDF and HTML are stored as artifacts, so that readers would not need to build their own.

And ensure that things such as which Asciidoc dialect to use are included.

Provide a Docker image including all dependencies required to build the book, to avoid users and contributors having to install dependencies (well, apart from Docker).

There is a description below. In my understanding timer wheel exists per scheduler after around 18. Is it the case ?

The timing wheel is a global resource and there might be contention for the write lock to the timing wheel if you have many processes inserting timers into the wheel

As stated here, it may be helpful to explicitly state somewhere in the book which version it targets.
Then readers can guess about the contents of the book even after the implementation is changed later. Since sometimes there are major changes that affect the contents of this book.

The file genop.tab which is used to generate the appendix with beam instruction documentation should be pulled in as a dependency from Erlang/OTP.

Preferably without pulling in the whole Erlang repo.

In section 3.6.2, it refers to

embed file= "code/msg.erl"

But the file does not exist.

In the memory chapter it looks as below:

I was thinking of making turning the chapter on the debugger into a broader chapter on "Finding and Fixing Bugs"

The top level idea is:

• Finding and Fixing Bugs
  ** In a long running 24/7 system there will always be bugs,
  or at east unwanted features. In this chapter we will look
  at different ways to find and fix bugs, without disrupting
  the running service.
  ** You want to read this chapter to learn about different ways to test code and
  about the tools and frameworks that are available for testing.
  This chapter will also cover some common sources of bugs and problems
  in the system, such as deadlocks, message overflow, and memory
  problems, and how to identify and fix them.
  ** You will learn about the "let it crash" principle and how to
  best use it in your system. You will also learn how exceptions
  works and how to design your system with supervisor trees.
  You will learn how to use the debugger to debug your program
  and how to use GDB to debug the runtime system.
  You will learn how to read crash dumps, you will learn
  why you often don't get crash dumps and what to do about it.
  You will learn how the Erlang debugger works.
  You will learn how redbug can make debugging easier and
  somewhat safer to run on a live system.
  You will learn a little bit about how to use gdb
  to debug on the ERTS level.
  You will also learn a little about dtrace and systemtap.
  And maybe, perhaps, you will pick up some debugging philosophy.
  ** You will be able to test your system in a systematic way,
  and you will be able to test individual components of your system.
  You will be able to identify some common mistakes and problems.
  You will be able to use the debugger.

Suggested outline:

Testing

Eunit

Common Test

Mocking

The Usual Suspects

Deadlocks

Mailboxes

Binaries

Let it Crash

Exceptions

Supervisors

The Debugger

The Erlang debugger dbg

redbug

starting, stopping

choosing what to debug

setting limits.

Crash Dumps

Debugging the Runtime

gdb

gdb macros

systemtap and dtrace

Is it a typo ?

The content is concatenated to the table at the end of Appendix A.

I started the translation work in my fork https://github.com/hitdavid/theBeamBook
and suffer some error in Chinese charset display in pdf build using asciidoc.

I'll keep my focus on the content first, and maybe solve asciidoc config problem at last.

Please keep on write the book till complete, It's a GREAT work, thank you contributors.