Develop Reference

Get real architecture of M1 Mac regardless of Rosetta

I need to retrieve the real architecture of a Mac regardless of if the process is running through Rosetta or not.
Right now in Node.js, process.arch returns x64 and in shell, uname -m returns x86_64.

Thanks to #Ouroborus, this note describes how to figure out if your app is translated.
If it's translated:
$ sysctl sysctl.proc_translated
sysctl.proc_translated: 1
If not:
$ sysctl sysctl.proc_translated
sysctl.proc_translated: 0
On non-ARM Macs:
$ sysctl sysctl.proc_translated
sysctl: unknown oid 'sysctl.proc_translated'

As #Elmo's answer indicates, the command line sysctl -n sysctl.proc_translated or the native equivalent sysctlbyname() call will indicate whether you are running under Rosetta.
Two other sysctl values are relevant. On M1 hardware without Rosetta, these values are returned:
hw.cputype: 16777228
hw.cpufamily: 458787763
hw.cputype is 0x0100000C (CPU_TYPE_ARM64) and hw.cpufamily is 0x1b588bb3 (CPUFAMILY_ARM_FIRESTORM_ICESTORM).
However, when executed under Rosetta, the low-level machine code which collects CPUID takes precendence and following two values are returned, both via sysctlbyname() and the command line:
hw.cputype: 7
hw.cpufamily: 1463508716
These correspond to 0x7 (CPU_TYPE_X86) and 0x573b5eec (INTEL_WESTMERE).
It appears Rosetta reports an x86-compatible Westmere chip under Rosetta, but this choice seems consistent everywhere I've seen. This "virtual architecture" may be useful information for some programs.
Another possibility presents itself in the IO Registry. While the default IOService plane collects data in real-time, the IODeviceTree plane is stored at boot, and includes these entries in the tree (command line ioreg -p IODeviceTree or ioreg -c IOPlatformDevice):
cpu0#0 <class IOPlatformDevice, id 0x10000010f, registered, matched, active, busy 0 (180 ms), retain 8>
| | | {
...
| | | "compatible" = <"apple,icestorm","ARM,v8">
(for CPUs 0-3)
and
cpu4#100 <class IOPlatformDevice, id 0x100000113, registered, matched, active, busy 0 (186 ms), retain 8>
| | | {
...
| | | "compatible" = <"apple,firestorm","ARM,v8">
(for CPUs 4-7)
This clearly indicates the ARMv8 Firestorm + Icestorm M1 chip.
The same approach should work for the M1 Pro and M1 Max.

How to view the assembly code generated from my JavaScript (in Chrome)?

is it somehow possible, to view the final machine code (x86 instruction) that a browser generates from my Javascript? E.g.
--- Raw source ---
function add(a, b){
return a + b;
}
...
--- Code ---
source_position = 0
kind = FUNCTION
Instructions (size = 456)
0x36953100 0 8b4c2404 mov ecx,[esp+0x4]
0x36953104 4 81f991806049 cmp ecx,0x49608091 ;; object: 0x49608091 <undefined>
0x3695310a 10 750a jnz 22 (0x36953116)
0x3695310c 12 8b4e13 mov ecx,[esi+0x13]
0x3695310f 15 8b4917 mov ecx,[ecx+0x17]
0x36953112 18 894c2404 mov [esp+0x4],ecx
0x36953116 22 55 push ebp
Thanks!

Your script doesn't transform to machine code directly. JavaScript runs on virtual machine V8 (it's true for chrome and classic nodejs) and you can get VM byte code using:
node --print-bytecode script.js
Then V8 executes and optimizes the byte code and calls external C libraries and OS API (system calls) or WEB API. Final machine code may vary even with the same javascript code (for example before and after optimization).
You can also start Chrome from the command line with
--js-flags="--print-bytecode"
UPD:
As #PeterCordes noticed nodejs allow to see Turbofan generated machine code using
node --print-opt-code script.js
Chrome:
--js-flags="--print-opt-code"
Also you can use HTML visualizer like https://github.com/v8/v8/tree/master/tools/turbolizer

Can't control BeagleBone Green's LEDs on Debian 8.6

I'm trying to use usr LEDs on BeagleBone Green Wireless on Debian 8.6 (default image from http://beagleboard.org/green with kernel 4.4.26-ti-r59) for my own debug purposes, but some script make it impossible. It is caused most likely by a JS script (after uninstalling nodejs leds stopped beating, but JS is crucial for me).
I've already tried to switch mode of led blink to none:
# cd /sys/class/leds/beaglebone\:green\:usr0
# echo none > trigger
# cat trigger
[none] rc-feedback kbd-scrollock ...
and to control brightness:
# echo 0 > brightness
# cat brightness
0
# echo 255 > brightness
# cat brightness
0
# cat brightness
1
As you can see - value of brightness is simply being overwritten by another program (script) running in loop. Does anyone have an idea which script may cause this situation?

PhantomJS performance

My question is, what is the most efficient configuration for PhantomJS tests.
Currently I have 1 instance of PhantomJS running and every instance can have 2 tabs opened (dev env).
Is it better to have more instance of phantomjs or opened tabs, and if tabs, what is the upper limit of PhantomJS.
CPU:
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 58
model name : Intel(R) Core(TM) i5-3210M CPU # 2.50GHz
stepping : 9
microcode : 0x19
cpu MHz : 2494.316
cache size : 3072 KB
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx rdtscp lm constant_tsc up rep_good nopl xtopology nonstop_tsc pni pclmulqdq monitor ssse3 cx16 sse4_1 sse4_2 popcnt aes xsave avx rdrand hypervisor lahf_lm
bogomips : 4988.63
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
Memory:
total used free shared buffers cached
Mem: 2515896 1155828 1360068 0 171648 622668
More information:
I would like to handle multiple tests at once with as less memory as possible. Now I am running two pages per phantom instance, and already I am having issues with network requests. I have a timeout of 20s and if a specific network request is not finished in that time, test fails.
Test is successful if I only run one page in one PhantomJS instance, but that is not optimal, because we will be running more then 1000 tests, and I would like to arrange tests in multiple pages across multiple phantomjs instances.
Example:
10 phantomjs instances
every phantomjs instance can run 30 pages
Now why when running multiple pages in one instance, does the network request lag so much?

Node.js, Cygwin and Socket.io walk into a bar... Node.js throws ENOBUFS and everyone dies

I'm hoping someone here can help me out, I'm not having much luck figuring this out myself. I'm running node.js version 0.3.1 on Cygwin. I'm using Connect and Socket.io. I seem to be having some random problems with DNS or something, I haven't quite figured it out. The end result is that I the server is running fine, but when a browser attempts to connect to it the initial HTTP Request works, Socket.io connects, and then the server dies (output below).
I don't think it has anything to do with the HTTP request because the server gets a lot data posted to it, and it was receiving requests and responding up until my connection that killed it. I've googled around and the closest thing I've found is DNS being set improperly. It's a network program meant to run only on an internal network, so I've set the nameserver x.x.x.x in my /etc/resolv.conf to the internal DNS. I've also added nameserver 8.8.8.8 in addition. I'm not sure what else to check, but would be grateful of any help.
In node.exe.stackdump
Exception: STATUS_ACCESS_VIOLATION at eip=610C51B9
eax=00000000 ebx=00000001 ecx=00000000 edx=00000308 esi=00000000 edi=010FCCB0
ebp=010FCAEC esp=010FCAC4 program=\\?\E:\cygwin\usr\local\bin\node.exe, pid 3296, thread unknown (0xBEC)
cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B
Stack trace:
Frame Function Args
010FCAEC 610C51B9 (00000000, 00000000, 00000000, 00000000)
010FCBFC 610C5B55 (00000000, 00000000, 00000000, 00000000)
010FCCBC 610C693A (FFFFFFFF, FFFFFFFF, 750334F3, FFFFFFFE)
010FCD0C 61027CB2 (00000002, F4B994D5, 010FCE64, 00000002)
010FCD98 76306B59 (00000002, 010FCDD4, 763069A4, 00000002)
End of stack trace
Node Output:
node.js:50
throw e; // process.nextTick error, or 'error' event on first tick
^
Error: ENOBUFS, No buffer space available
at doConnect (net.js:642:19)
at net.js:803:9
at dns.js:166:30
at IOWatcher.callback (dns.js:48:15)
EDIT
I'm hitting an LDAP server using http.createClient immediately after a client connects to get information, and that seems to be where the problem is that is causing ENOBUFS. I've edited the source to include && errno != ENOBUFS which now prevents the server from dying, however now the LDAP request isn't working. I'm not sure what the problem is that would cause that though. As I mentioned this is an internal only application, so I set the DNS servers in /etc/resolv.conf to the DNS servers that are being applied to the host machine. Not sure if this is part of the issue?
EDIT 2
Here's some output from gdb --args ./node_g --debug ../myscript.js. I'm not sure if this is related to ENOBUFS, however, as it seems to be disconnecting immediately after connection with Socket.io
[New thread 672.0x100]
Error: dll starting at 0x76e30000 not found.
Error: dll starting at 0x76250000 not found.
Error: dll starting at 0x76e30000 not found.
Error: dll starting at 0x76f50000 not found.
[New thread 672.0xc90]
[New thread 672.0x448]
debugger listening on port 5858
[New thread 672.0xbf4]
14 Jan 18:48:57 - socket.io ready - accepting connections
[New thread 672.0xed4]
[New thread 672.0xd68]
[New thread 672.0x1244]
[New thread 672.0xf14]
14 Jan 18:49:02 - Initializing client with transport "websocket"
assertion "b[1] == 0" failed: file "../src/node.cc", line 933, function: ssize_t
node::DecodeWrite(char*, size_t, v8::Handle<v8::Value>, node::encoding)
Program received signal SIGABRT, Aborted.
0x7724f861 in ntdll!RtlUpdateClonedSRWLock ()
from /cygdrive/c/Windows/system32/ntdll.dll
(gdb) backtrace
#0 0x7724f861 in ntdll!RtlUpdateClonedSRWLock ()
from /cygdrive/c/Windows/system32/ntdll.dll
#1 0x7724f861 in ntdll!RtlUpdateClonedSRWLock ()
from /cygdrive/c/Windows/system32/ntdll.dll
#2 0x75030816 in WaitForSingleObjectEx ()
from /cygdrive/c/Windows/syswow64/KernelBase.dll
#3 0x0000035c in ?? ()
#4 0x00000000 in ?? ()
(gdb)

OK, I digged around a bit, and after your second edit I found this bug on the issue list.
I doesn't state whether this was encountered under cygwin or not, but the error that it is hitting leads down to this piece of code:
uint16_t * twobytebuf = new uint16_t[buflen];
str->Write(twobytebuf, 0, buflen, String::HINT_MANY_WRITES_EXPECTED);
for (size_t i = 0; i < buflen; i++) {
unsigned char *b = reinterpret_cast<unsigned char*>(&twobytebuf[i]);
assert(b[1] == 0); // this assertion fails
buf[i] = b[0];
}
From what I can read (with my rusted C) it will convert it will create a new uin16 array and write the contents of the V8 string in their, then it will ensure that casting did not write any values outside the range of 0 - 255, and that's exactly what fails here.
I couldn't find anything regarding whether this is a V8 issue or not.
Since the code was added in this commit, the only thing I can suggest here is to try pulling the tree from a commit before the code was added. Since all versions after that have the crashing code.
If that works, I would recommend you to file another bug report on the issue Node.js issue list, although I made do this later this day.

Very hard to answer this one but +1 for the subject line.
Node.js comes with a test suite along with the main build, have you run that? I had built node successfully but because I'd omitted OpenSSL my web socket tests were failing. Install/rebuild fixed it. The test projects helped me diagnose the issue.
suggest doing "make test" as http://nodejs.org/#download describes.