Git Product home page Git Product logo

t1-cli's People

Contributors

eiriksm avatar evansimpson avatar jiahuang avatar johnnyman727 avatar jp1971 avatar kevinmehall avatar marie-x avatar natevw avatar nicholasspencer avatar olegas avatar ryanseys avatar shokai avatar tcr avatar xyziemba avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

t1-cli's Issues

tessel/npm init instead of mkdir node_modules

Currently, on the blinky doc page, it instructs the user to mkdir node_modules.

For the sake of consistency across node applications, I recommend that users instead be instructed to either npm init or tessel init. Node users are used to using npm init every time they're starting a new module or application, and starting a new tessel project should be no different.

If the major concern with npm init is that the questions that the init prompts ask are overwhelming to new users, a simple tessel init that creates the package.json for you would also suffice.

Race condition / segfault with __destroy hack for Windows re-enumeration

Reproducible occasionally on Rampart (Ubuntu 14.04 x64 where 4 Tessels are updated simultaneously)

Sometimes the process hangs after Complete, sometimes it segfaults with:

Program terminated with signal SIGSEGV, Segmentation fault.                     │·······················
#0  0x0000000001642230 in ?? ()                                                 │·······················
(gdb) bt                                                                        │·······················
#0  0x0000000001642230 in ?? ()                                                 │·······················
#1  0x00007f13fb625506 in handleCompletion(Transfer*) ()                        │·······················
   from /home/rampart/cli-new/node_modules/usb/build/Release/usb_bindings.node  │·······················
#2  0x00007f13fb626435 in UVQueue<Transfer*>::internal_callback(uv_async_s*, int│·······················
) ()                                                                            │·······················
   from /home/rampart/cli-new/node_modules/usb/build/Release/usb_bindings.node  │·······················
#3  0x0000000000463609 in ?? ()                                                 │·······················
#4  0x00000000004636f3 in ?? ()                                                 │·······················
#5  0x00000000004702bc in uv.io_poll ()                                         │·······················
#6  0x0000000000463f8c in uv_run ()                                             │·······················
#7  0x0000000000426e05 in node::Start(int, char**) ()                           │·······················
#8  0x00007f13fbd67ec5 in __libc_start_main (main=0x41c810 <main>, argc=4,      │·······················
    argv=0x7fff1b9fb618, init=<optimized out>, fini=<optimized out>,            │·······················
    rtld_fini=<optimized out>, stack

Has not been observed in any single-device case, but seems to be timing-related. Commenting out the __destroy calls prevents the crash.

Console.logs occasionally don't get output until script abortion

I'm not sure if this is a CLI or a runtime issue, but I'm seeing that in some cases, my console.log won't be output to the console until I abort a script.

Test Code is below. Connect a physical wire between gpio 2 and 3 on port bank B:

var tessel = require('tessel'),
    test = require('tape'),
    ppn = tessel.port['B'].digital[2],
    trig = tessel.port['B'].digital[3];

ppn.input();
trig.output().low();


test('simple rise event', function(t) {
  // Two tests
  t.plan(2);
  // Interval handle
  var interval;
  // Time we've risen
  var times = 0;
  // Watch for a rise
  ppn.watch('rise', function() {
    // console.log("Card removed", ppn.read());
    // Make sure that the read state is one after rising
    t.equal(1, ppn.read(), "high registered as high..");
    // If we've succeeded more than once
    if (time >= 1) {
      // Cancel the interval
      clearInterval(interval);
      // End this test
      t.end();
    }
    // Wait for this event to occur again
    else {
      time++;
    }
  });

  // Set the interval to toggle a few times
  interval = setInterval(function() {
    trig.toggle();
  }, 100);
});

LIBUSB_ERROR_OTHER occasionally

This has happened intermittently on master, retrying works correctly every time. Consistent cause is "long time after I last did a Tessel USB command"

TESSEL! Connected to TM-00-04-f000da30-00674f43-14982586.
INFO Using local file ./out/Release/tessel-firmware.bin
INFO Updating firmware... please wait. Tessel will reset itself after the update

/Users/tim/Code/technical/git/cli/node_modules/usb/usb.js:243
        this.streamTransfers[i].cancel()
                                ^
Error: LIBUSB_ERROR_OTHER
    at InEndpoint.Endpoint.stopStream (/Users/tim/Code/technical/git/cli/node_modules/usb/usb.js:243:27)
    at /Users/tim/Code/technical/git/cli/node_modules/usb/usb.js:158:8
    at Array.forEach (native)
    at Interface.release (/Users/tim/Code/technical/git/cli/node_modules/usb/usb.js:153:18)
    at Tessel.close (/Users/tim/Code/technical/git/cli/src/tessel_usb.js:187:13)
    at Device.<anonymous> (/Users/tim/Code/technical/git/cli/src/commands.js:164:10)
    at Transfer.<anonymous> (/Users/tim/Code/technical/git/cli/node_modules/usb/usb.js:95:15)
make: *** [deploy] Error 8

tessel update file.bin vs. tessel update ./file.bin

In my opinion, these two commands should be identical:

tessel update tessel-firmware.bin
and
tessel update ./tessel-firmware.bin

In practice, they differ:

D:\VMShare>tessel update tessel-firmware.bin
TESSEL! Connected to TM-00-04-f0009a30-00544f45-466045c2.
INFO Checking for latest firmware...
INFO Tessel is already on the latest firmware build. You can force an update with "tessel update --force"

D:\VMShare>tessel update ./tessel-firmware.bin
TESSEL! Connected to TM-00-04-f0009a30-00544f45-466045c2.
INFO Using local file ./tessel-firmware.bin
INFO Updating firmware... please wait. Tessel will reset itself after the update
Waiting for bootloader....
Writing:   0%        0 /1224476
Writing:   0%     4096 /1224476
Writing:   1%     8192 /1224476
Writing:   1%    12288 /1224476
Writing:   1%    16384 /1224476
Writing:   2%    20480 /1224476
Writing:   2%    24576 /1224476
Writing:   2%    28672 /1224476
... *snip* ...
Writing: 100%  1224476 /1224476
Done!

where is hardware-resolve module

why is there a hardware-resolve npm module published and depended on, but no repository for it? where is that source code? I have a PR for it.

Does bundling include dev deps?

When I try to deploy code, it looks like it bundles up my cwd:

$ tessel run apps/blinky.js 
TESSEL! Connected to TM-00-04-f0009a30-00584f4b-56cc45c2.
INFO Bundling directory /Users/nick.heiner/public-projects/tessel-hacking (~25.20 MB)
INFO Deploying bundle (34.07 MB)...

However, the file size seems to include dev deps. (When I try this same command in a directory without the dev dependencies, the number is much smaller.)

Why push dev deps onto the tessel? The whole point of dev dependencies is that you don't actually need them to run the code. If I'm using grunt to lint my code, there's no need to bring all of grunt onto the tessel itself.

Would you accept a PR for this? Or is there some reason that this is necessary that I'm missing?

`tessel run` fails w/ Maximum call stack size exceeded but `tessel debug` works

when running time tessel run blinky.js (from the FRE) I get this:

$ time tessel run blinky.js
TESSEL! Connected to TM-00-04-f000da30-00554345-64842586.

RangeError: Maximum call stack size exceeded

real    0m33.449s
user    0m16.200s
sys 0m13.960s

strangely though tessel debug blinky.js works as expected:

$ time tessel debug blinky.js 
TESSEL! Connected to TM-00-04-f000da30-00554345-64842586.
Starting debug logs... saving to https://debug.tessel.io/logs/53bdb72b7a7aa10200c338e1
Running Blinky test... please wait...
INFO Bundling directory /Users/maxogden/src/js/tessel/scripts/blink (~600 bytes)
INFO Deploying bundle (6.00 KB)...

Tessel is reading 6144 bytes...
Populating filesystem...
Starting script: /_start.js
Initializing runtime...
Loading tessel library...
Running script...
Uptime since startup: 716.699968s
Blinked 0 times
Blinked 1 times
Blinked 2 times
Blinked 3 times
Blinked 4 times
Blinked 5 times
Blinked 6 times
^C
real    0m4.453s
user    0m0.417s
sys 0m0.104s

blinky.js:

// Import the interface to Tessel hardware
var tessel = require('tessel');

// Set the led pins as outputs with initial states
// Truthy initial state sets the pin high
// Falsy sets it low.
var led1 = tessel.led[0].output(1);
var led2 = tessel.led[1].output(0);

setInterval(function () {
    console.log("I'm blinking! (Press CTRL + C to stop)");
    // Toggle the led states
    led1.toggle();
    led2.toggle();
}, 100);

versions:

$ tessel version
INFO v0.3.8
$ tessel version --board
TESSEL! Connected to TM-00-04-f000da30-00554345-64842586.
INFO Serial #: TM-00-04-f000da30-00554345-64842586
INFO Wifi Version: 1.26
INFO Firmware Commit: 2d997e2
INFO Runtime Commit: ced4026
INFO Firmware Build: 0.1.6
$ node -v
v0.10.29
$ npm -v
1.4.16

streamTransfers[i].cancel() error.

OS X: Unplug Tessel. Plug in. Run tessel blink. Run tessel update or make arm-deploy:

➜  firmware git:(master) ✗ TESSEL_USB_DEBUG=4 make arm-deploy
AR=arm-none-eabi-ar AR_host=arm-none-eabi-ar AR_target=arm-none-eabi-ar CC=arm-none-eabi-gcc gyp  firmware.gyp --depth=. -f ninja-arm -D builtin_section=.text -D COLONY_STATE_CACHE=0 -D COLONY_PRELOAD_ON_INIT=0 -D enable_ssl=1 && ninja -C out/Release
ninja: Entering directory `out/Release'
ninja: no work to do.
arm-none-eabi-size out/Release/tessel-firmware.elf out/Release/tessel-boot.elf out/Release/tessel-otp.elf
   text    data     bss     dec     hex filename
1225564    5116   26716 1257396  132fb4 out/Release/tessel-firmware.elf
  30388    2736    3232   36356    8e04 out/Release/tessel-boot.elf
   5644   34764      36   40444    9dfc out/Release/tessel-otp.elf
tessel dfu-restore ./out/Release/tessel-firmware.bin
USB debug level 4
TESSEL? [timestamp] [threadID] facility level [function call] <message>
--------------------------------------------------------------------------------
[ 0.149117] [00000d07] libusb: debug [libusb_get_device_list]
[ 0.149150] [00000d07] libusb: debug [discovered_devs_append] need to increase capacity
[ 0.149212] [00000d07] libusb: debug [libusb_get_device_descriptor]
[ 0.149260] [00000d07] libusb: debug [libusb_get_device_descriptor]
[ 0.149279] [00000d07] libusb: debug [libusb_get_device_descriptor]
[ 0.149295] [00000d07] libusb: debug [libusb_get_device_descriptor]
[ 0.149312] [00000d07] libusb: debug [libusb_get_device_descriptor]
[ 0.149330] [00000d07] libusb: debug [libusb_get_device_descriptor]
[ 0.149347] [00000d07] libusb: debug [libusb_get_device_descriptor]
[ 0.149364] [00000d07] libusb: debug [libusb_get_device_descriptor]
[ 0.149379] [00000d07] libusb: debug [libusb_get_device_descriptor]
[ 0.149824] [00000d07] libusb: debug [libusb_open] open 26.4
[ 0.149957] [00000d07] libusb: debug [usbi_add_pollfd] add fd 25 events 1
[ 0.149970] [00000d07] libusb: debug [darwin_open] device open for access
[ 0.150004] [00004103] libusb: debug [handle_events] poll() returned 1
[ 0.150025] [00004103] libusb: debug [handle_events] caught a fish on the control pipe
[ 0.150043] [00004103] libusb: debug [libusb_get_next_timeout] no URBs, no timeout!
[ 0.150051] [00004103] libusb: debug [libusb_handle_events_timeout_completed] doing our own event handling
[ 0.150058] [00004103] libusb: debug [handle_events] poll() 3 fds with timeout in 60000ms
[ 0.151166] [0000170f] libusb: debug [darwin_async_io_callback] an async io operation has completed
[ 0.151198] [00004103] libusb: debug [handle_events] poll() returned 1
[ 0.151208] [00004103] libusb: debug [op_handle_events] checking fd 21 with revents = 0
[ 0.151214] [00004103] libusb: debug [op_handle_events] checking fd 23 with revents = 0
[ 0.151219] [00004103] libusb: debug [op_handle_events] checking fd 25 with revents = 1
[ 0.151249] [00004103] libusb: debug [darwin_handle_callback] handling control completion with kernel status 0
[ 0.151256] [00004103] libusb: debug [usbi_handle_transfer_completion] transfer 0x102200b20 has callback 0x100d86d3b
[ 0.151289] [00004103] libusb: debug [libusb_get_next_timeout] no URBs, no timeout!
[ 0.151296] [00004103] libusb: debug [libusb_handle_events_timeout_completed] doing our own event handling
[ 0.151301] [00004103] libusb: debug [handle_events] poll() 3 fds with timeout in 60000ms
[ 0.152182] [0000170f] libusb: debug [darwin_async_io_callback] an async io operation has completed
[ 0.152211] [00004103] libusb: debug [handle_events] poll() returned 1
[ 0.152225] [00004103] libusb: debug [op_handle_events] checking fd 21 with revents = 0
[ 0.152233] [00004103] libusb: debug [op_handle_events] checking fd 23 with revents = 0
[ 0.152240] [00004103] libusb: debug [op_handle_events] checking fd 25 with revents = 1
[ 0.152248] [00004103] libusb: debug [darwin_handle_callback] handling control completion with kernel status 0
[ 0.152256] [00004103] libusb: debug [usbi_handle_transfer_completion] transfer 0x1022012c0 has callback 0x100d86d3b
[ 0.152267] [00004103] libusb: debug [libusb_get_next_timeout] no URBs, no timeout!
[ 0.152272] [00004103] libusb: debug [libusb_handle_events_timeout_completed] doing our own event handling
[ 0.152278] [00004103] libusb: debug [handle_events] poll() 3 fds with timeout in 60000ms
[ 0.153375] [00000d07] libusb: debug [libusb_claim_interface] interface 0
[ 0.153886] [00000d07] libusb: debug [get_endpoints] building table of endpoints.
[ 0.153906] [00000d07] libusb: debug [get_endpoints] interface: 0 pipe 1: dir: 1 number: 1
[ 0.153918] [00000d07] libusb: debug [get_endpoints] interface: 0 pipe 2: dir: 1 number: 2
[ 0.153929] [00000d07] libusb: debug [get_endpoints] interface: 0 pipe 3: dir: 0 number: 2
[ 0.153978] [00000d07] libusb: debug [darwin_claim_interface] interface opened
[ 0.154441] [0000170f] libusb: debug [darwin_async_io_callback] an async io operation has completed
[ 0.154466] [00004103] libusb: debug [handle_events] poll() returned 1
[ 0.154478] [00004103] libusb: debug [op_handle_events] checking fd 21 with revents = 0
[ 0.154484] [00004103] libusb: debug [op_handle_events] checking fd 23 with revents = 0
[ 0.154489] [00004103] libusb: debug [op_handle_events] checking fd 25 with revents = 1
[ 0.154496] [00004103] libusb: debug [darwin_handle_callback] handling control completion with kernel status 0
[ 0.154502] [00004103] libusb: debug [usbi_handle_transfer_completion] transfer 0x102201a30 has callback 0x100d86d3b
[ 0.154512] [00004103] libusb: debug [libusb_get_next_timeout] no URBs, no timeout!
[ 0.154518] [00004103] libusb: debug [libusb_handle_events_timeout_completed] doing our own event handling
[ 0.154524] [00004103] libusb: debug [handle_events] poll() 3 fds with timeout in 60000ms
[ 0.154736] [00004903] libusb: debug [libusb_set_interface_alt_setting] interface 0 altsetting 1
[ 0.161614] [00004903] libusb: debug [get_endpoints] building table of endpoints.
[ 0.161645] [00004903] libusb: debug [get_endpoints] interface: 0 pipe 1: dir: 1 number: 1
[ 0.161653] [00004903] libusb: debug [get_endpoints] interface: 0 pipe 2: dir: 1 number: 2
[ 0.161660] [00004903] libusb: debug [get_endpoints] interface: 0 pipe 3: dir: 0 number: 2
[ 0.162348] [00000d07] libusb: debug [ep_to_pipeRef] converting ep address 0x81 to pipeRef and interface
[ 0.162362] [00000d07] libusb: debug [ep_to_pipeRef] pipe 1 on interface 0 matches
[ 0.162446] [00000d07] libusb: debug [ep_to_pipeRef] converting ep address 0x81 to pipeRef and interface
[ 0.162456] [00000d07] libusb: debug [ep_to_pipeRef] pipe 1 on interface 0 matches
[ 0.162499] [00000d07] libusb: debug [ep_to_pipeRef] converting ep address 0x81 to pipeRef and interface
[ 0.162507] [00000d07] libusb: debug [ep_to_pipeRef] pipe 1 on interface 0 matches
[ 0.162540] [00000d07] libusb: debug [ep_to_pipeRef] converting ep address 0x81 to pipeRef and interface
[ 0.162547] [00000d07] libusb: debug [ep_to_pipeRef] pipe 1 on interface 0 matches
[ 0.162792] [00000d07] libusb: debug [ep_to_pipeRef] converting ep address 0x82 to pipeRef and interface
[ 0.162802] [00000d07] libusb: debug [ep_to_pipeRef] pipe 2 on interface 0 matches
[ 0.162849] [00000d07] libusb: debug [ep_to_pipeRef] converting ep address 0x82 to pipeRef and interface
[ 0.162858] [00000d07] libusb: debug [ep_to_pipeRef] pipe 2 on interface 0 matches
TESSEL! Connected to TM-00-04-f000da30-0058434c-14682586.
INFO Using local file ./out/Release/tessel-firmware.bin
INFO Updating firmware... please wait. Tessel will reset itself after the update
[ 0.166506] [0000170f] libusb: debug [darwin_async_io_callback] an async io operation has completed
[ 0.166545] [00004103] libusb: debug [handle_events] poll() returned 1
[ 0.166571] [00004103] libusb: debug [op_handle_events] checking fd 21 with revents = 0
[ 0.166580] [00004103] libusb: debug [op_handle_events] checking fd 23 with revents = 0
[ 0.166583] [00004103] libusb: debug [op_handle_events] checking fd 25 with revents = 1
[ 0.166588] [00004103] libusb: debug [darwin_handle_callback] handling control completion with kernel status 0
[ 0.166591] [00004103] libusb: debug [usbi_handle_transfer_completion] transfer 0x100b284f0 has callback 0x100d86d3b
[ 0.166600] [00004103] libusb: debug [libusb_get_next_timeout] no URB with timeout or all handled by OS; no timeout!
[ 0.166604] [00004103] libusb: debug [libusb_handle_events_timeout_completed] doing our own event handling
[ 0.166607] [00004103] libusb: debug [handle_events] poll() 3 fds with timeout in 60000ms
USB TX:  0 42 <Buffer >
[ 0.167457] [00000d07] libusb: debug [ep_to_pipeRef] converting ep address 0x02 to pipeRef and interface
[ 0.167467] [00000d07] libusb: debug [ep_to_pipeRef] pipe 3 on interface 0 matches
[ 0.167624] [0000170f] libusb: debug [darwin_async_io_callback] an async io operation has completed
[ 0.167643] [0000170f] libusb: debug [darwin_async_io_callback] an async io operation has completed
[ 0.167650] [00004103] libusb: debug [handle_events] poll() returned 1
[ 0.167663] [00004103] libusb: debug [op_handle_events] checking fd 21 with revents = 0
[ 0.167681] [00004103] libusb: debug [op_handle_events] checking fd 23 with revents = 0
[ 0.167688] [00004103] libusb: debug [op_handle_events] checking fd 25 with revents = 1
[ 0.167693] [00004103] libusb: debug [darwin_handle_callback] handling bulk completion with kernel status 0
[ 0.167696] [00004103] libusb: debug [usbi_handle_transfer_completion] transfer 0x100b277f0 has callback 0x100d86d3b
[ 0.167703] [00004103] libusb: debug [libusb_get_next_timeout] no URB with timeout or all handled by OS; no timeout!
[ 0.167707] [00004103] libusb: debug [libusb_handle_events_timeout_completed] doing our own event handling
[ 0.167710] [00004103] libusb: debug [handle_events] poll() 3 fds with timeout in 60000ms
[ 0.167745] [00000d07] libusb: debug [libusb_cancel_transfer]
[ 0.167726] [00004103] libusb: debug [handle_events] poll() returned 1
[ 0.167759] [00000d07] libusb: debug [ep_to_pipeRef] converting ep address 0x81 to pipeRef and interface
[ 0.167761] [0000170f] libusb: debug [darwin_async_io_callback] an async io operation has completed
[ 0.167772] [00004103] libusb: debug [op_handle_events] checking fd 21 with revents = 0
[ 0.167783] [00000d07] libusb: debug [ep_to_pipeRef] pipe 1 on interface 0 matches
[ 0.167803] [00004103] libusb: debug [op_handle_events] checking fd 23 with revents = 0
[ 0.167811] [00000d07] libusb: warning [darwin_abort_transfers] aborting all transactions on interface 0 pipe 1
[ 0.167821] [00004103] libusb: debug [op_handle_events] checking fd 25 with revents = 1
[ 0.167839] [00004103] libusb: debug [darwin_handle_callback] handling bulk completion with kernel status -536870163
[ 0.167847] [00004103] libusb: warning [darwin_transfer_status] transfer error: device not responding (value = 0xe00002ed)
[ 0.167853] [00004103] libusb: debug [usbi_handle_transfer_completion] transfer 0x100e00590 has callback 0x100d86d3b
[ 0.167862] [0000170f] libusb: debug [darwin_async_io_callback] an async io operation has completed
[ 0.167866] [00000d07] libusb: debug [darwin_abort_transfers] calling clear pipe stall to clear the data toggle bit
[ 0.167927] [00004103] libusb: debug [libusb_get_next_timeout] no URB with timeout or all handled by OS; no timeout!
[ 0.167947] [0000170f] libusb: debug [darwin_async_io_callback] an async io operation has completed
[ 0.167960] [00004103] libusb: debug [libusb_handle_events_timeout_completed] doing our own event handling
[ 0.167975] [0000170f] libusb: debug [darwin_async_io_callback] an async io operation has completed
[ 0.167979] [00004103] libusb: debug [handle_events] poll() 3 fds with timeout in 60000ms
[ 0.167994] [00004103] libusb: debug [handle_events] poll() returned 1
[ 0.167999] [00004103] libusb: debug [op_handle_events] checking fd 21 with revents = 0
[ 0.168005] [00004103] libusb: debug [op_handle_events] checking fd 23 with revents = 0
[ 0.168010] [00004103] libusb: debug [op_handle_events] checking fd 25 with revents = 1
[ 0.168090] [00004103] libusb: debug [darwin_handle_callback] handling bulk completion with kernel status -536870163
[ 0.168097] [00004103] libusb: warning [darwin_transfer_status] transfer error: device not responding (value = 0xe00002ed)
[ 0.168103] [00004103] libusb: debug [usbi_handle_transfer_completion] transfer 0x100e00830 has callback 0x100d86d3b
[ 0.168111] [00004103] libusb: debug [libusb_get_next_timeout] no URB with timeout or all handled by OS; no timeout!
[ 0.168117] [00004103] libusb: debug [libusb_handle_events_timeout_completed] doing our own event handling
[ 0.168123] [00004103] libusb: debug [handle_events] poll() 3 fds with timeout in 60000ms
[ 0.168136] [00004103] libusb: debug [handle_events] poll() returned 1
[ 0.168142] [00004103] libusb: debug [op_handle_events] checking fd 21 with revents = 0
[ 0.168148] [00004103] libusb: debug [op_handle_events] checking fd 23 with revents = 0
[ 0.168153] [00004103] libusb: debug [op_handle_events] checking fd 25 with revents = 1
[ 0.168250] [00004103] libusb: debug [darwin_handle_callback] handling bulk completion with kernel status -536870165
[ 0.168258] [00004103] libusb: debug [usbi_handle_transfer_completion] transfer 0x100e001b0 has callback 0x100d86d3b
[ 0.168267] [00004103] libusb: debug [libusb_get_next_timeout] no URB with timeout or all handled by OS; no timeout!
[ 0.168272] [00004103] libusb: debug [libusb_handle_events_timeout_completed] doing our own event handling
[ 0.168278] [00004103] libusb: debug [handle_events] poll() 3 fds with timeout in 60000ms
[ 0.168289] [00004103] libusb: debug [handle_events] poll() returned 1
[ 0.168295] [00004103] libusb: debug [op_handle_events] checking fd 21 with revents = 0
[ 0.168300] [00004103] libusb: debug [op_handle_events] checking fd 23 with revents = 0
[ 0.168305] [00004103] libusb: debug [op_handle_events] checking fd 25 with revents = 1
[ 0.168311] [00004103] libusb: debug [darwin_handle_callback] handling bulk completion with kernel status -536870165
[ 0.168404] [00004103] libusb: debug [usbi_handle_transfer_completion] transfer 0x100e002d0 has callback 0x100d86d3b
[ 0.168415] [00004103] libusb: debug [libusb_get_next_timeout] no URB with timeout or all handled by OS; no timeout!
[ 0.168421] [00004103] libusb: debug [libusb_handle_events_timeout_completed] doing our own event handling
[ 0.168426] [00004103] libusb: debug [handle_events] poll() 3 fds with timeout in 60000ms
[ 0.168438] [00004103] libusb: debug [handle_events] poll() returned 1
[ 0.168444] [00004103] libusb: debug [op_handle_events] checking fd 21 with revents = 0
[ 0.168449] [00004103] libusb: debug [op_handle_events] checking fd 23 with revents = 0
[ 0.168454] [00004103] libusb: debug [op_handle_events] checking fd 25 with revents = 1
[ 0.168460] [00004103] libusb: debug [darwin_handle_callback] handling bulk completion with kernel status -536870165
[ 0.168466] [00004103] libusb: debug [usbi_handle_transfer_completion] transfer 0x100e003f0 has callback 0x100d86d3b
[ 0.168560] [00004103] libusb: debug [libusb_get_next_timeout] no URB with timeout or all handled by OS; no timeout!
[ 0.168568] [00004103] libusb: debug [libusb_handle_events_timeout_completed] doing our own event handling
[ 0.168574] [00004103] libusb: debug [handle_events] poll() 3 fds with timeout in 60000ms
[ 0.169314] [00000d07] libusb: error [libusb_cancel_transfer] cancel transfer failed error -99

/Users/tim/Code/technical/git/cli/node_modules/usb/usb.js:243
        this.streamTransfers[i].cancel()
                                ^
Error: LIBUSB_ERROR_OTHER
    at InEndpoint.Endpoint.stopStream (/Users/tim/Code/technical/git/cli/node_modules/usb/usb.js:243:27)
    at /Users/tim/Code/technical/git/cli/node_modules/usb/usb.js:158:8
    at Array.forEach (native)
    at Interface.release (/Users/tim/Code/technical/git/cli/node_modules/usb/usb.js:153:18)
    at Tessel.close (/Users/tim/Code/technical/git/cli/src/tessel_usb.js:195:13)
    at Device.<anonymous> (/Users/tim/Code/technical/git/cli/src/commands.js:164:10)
    at Transfer.<anonymous> (/Users/tim/Code/technical/git/cli/node_modules/usb/usb.js:95:15)
make: *** [deploy] Error 8
$

Tessel is now in DFU mode and blinking.

requiring up multiple subdirectories fails (with underscores?)

Test case, have a folder set up like this:

app/
  index.js
  util.js
  sub_dir1/
    subdir_2/
      test.js

In util.js:

var util = function(){}

util.go = function(){
    console.log("util called");
}

module.exports = util;

In test.js

var util = require('../../util');

util.go();

index.js

var test = require('./sub_dir1/sub_dir2/test')

Running on Tessel throws:

>> tessel run index.js
TESSEL! Connected to TM-00-04-f000da30-005d4344-60782586.
INFO Bundling directory /Users/jialiya/projects/technical/test/mongo (~192 bytes)
INFO Deploying bundle (7.50 KB)...
INFO Running script...
Error: Could not find module "/app/sub_dir1/sub_/../util/index.js"
stack traceback:
    /app/sub_dir1/sub_dir2/test.js:3: in function 'res'
    /app/index.js:1: in function 'res'
    /_start.js:4: in function 'res'
    [T]: src/colony/lua/cli.lua:34: in function <[T]: src/colony/lua/cli.lua:33>```

Error requiring Express

When you try to require Express, you'll get the following issue:

Error: Could not find module "/app/node_modules/express/node_modules/type-is/node_modules/mime-types/lib.js"
stack traceback:
    ...p/node_modules/express/node_modules/type-is/index.js:2: in function 'res'
    /app/node_modules/express/lib/request.js:6: in function 'res'
    ...
    /app/music-client.js:14: in function 'res'
    /_start.js:4: in function 'res'
    [T]: runtime:1: in main chunk

The problem is that the mime-types package.json specifies that the entrypoint is a folder instead of a file:

...
"main": "lib",
...

Our CLI tries to find lib.js instead of lib/index.js

Bad output of `tessel wifi -l` command?

When I run the following command

 tessel wifi -l

I get output resembling:

INFO Requesting wifi status...
Currently visible networks (17):
xxxxxx (51/127)
yyyyxxx (32/127)
zzzyxxx (37/1227)
...

i.e. the shorter(?) network names have portions of other, longer, network names included in their output.

It seems like there's a buffer erasing or null character placement that's being handled incorrectly somewhere?

Further update: when I ran the command again, the output appeared correct.

But then when I ran it again it output some console logs (I assume this TODO is the reason), then got stuck in a loop listing network names.

Then when I plugged in the device and tried again it seemed okay.

All of which makes this a less than useful bug report: "tessel wifi -l command sometimes flakey?"

Tessel wifi command doesn't report success

In the event that I attempt to connect to a network, and it is successful, my CLI doesn't actually print out the success. It just continues printing dots. If I cancel the command and run tessel wifi -l, it will show that I am connected.

tessel erase behavior

Originally posted in private Beta repo.

"tessel erase --force" could be "tessel erase --dfu"

To me, this command belongs in the range of "--dfu" commands, the user must know what DFU is to use it, and it's more descriptive than "--force", which I find confusing (since it doesn't force anything unless you're in dfu mode). It also aligns with "tessel update --dfu" well.

path craziness in a place called "hardware-resolve/index.js"

tessel commands fail in magical ways if my folder has no node_modules folder. This is a silly condition. Currently, this hardware-resolve thing starts searching my entire hard drive because of a path traversal bug. The default should just be to run the commands I give it instead of trying to be clever.

process.sendfile incorrect error message

Originally posted in runtime.

The CLI prints out a confusing error message if process.sendfile is called from a Tessel script and the CLI tries to save the file in a directory that doesn't exist.

This block needs to be more specific about errors that it catches.

[Feature Request] Support CoffeeScript

Originally posted in private Beta repo.

Copying Tim's rationale:

Rationale: I'd rather precompile code than have people attempt to run the Coffee compiler on their Tessel.

To remove that temptation, we compile .coffee files AOT. I believe the require() bindings used for Coffee and other languages are explicit so we can play nice with how they're supposed to integrate in uncommon setups.

However, I don't want to install coffeescript if I don't have to. A forward-facing compiler option would be nice. If this were Git, I'd imagine like

$ tessel set config preprocess.coffee "coffee-script"
Or

$ tessel preprocess coffee "coffee-script"
And then some way to notify the user this is what they meant. Of course, coffee-script versions might be different for each module; a smarter preprocessor would look for those modules and run their built-in compiler. It's wacky, but we can't ignore coffeescript being part of the ecosystem.

This is an easy feature to add, but a hard one to make sense of.

check prepack size for 0 bytes

The default pack size that shows up includes the default run code that gets put into the file. If someone pushes a blank file, they still see a size of 4kb. We need to check the size of the files someone is trying to push before we add on the start code and throw up an error if its 0 bytes.

Throw warning if bindings.gyp found

We should add a check on the bundling process to see if any node modules contain a bindings.gyp file. If they do, it's likely that the module won't work on Tessel because we don't support binary addons yet.

This could save a lot of headache in figuring out why something isn't working.

Bad error if Tessel in use

Running tiny router application, tried to simultaneously run tessel wifi -l

Got this error:

~  tessel wifi -l
TESSEL? ERR! { [Error: LIBUSB_ERROR_ACCESS] errno: -3 }

A more helpful error would be "Tessel is currently in use. Make sure there are no programs currently running on Tessel and try again."

CLI can't find shared package dependency

The CLI is not accepting a package dependency which exists higher up in the node_modules directory structure.

cylon, cylon-gpio and cylon-tessel all have node-namespace as a dependency.

NPM installs node-namespace in the cylon-tessel node_modules and shares that dependency between cylon and cylon-gpio. The CLI however will not accept this shared node-namespace dependency and is expecting to find it in the node_modules directory of each cylon and cylon-gpio.

cylon, cylon-gpio and cylon-tessel all have this setting in their package.json

"hardware": {
  "*": true,
   "./": true
},

so the cli should pick up everything.

Here's the output of my tessel push as well as my npm ls

$ tessel push index.js 
TESSEL! Connected to /dev/ttyACM0.          

fs.js:654
  return binding.readdir(pathModule._makeLong(path));
                 ^
Error: ENOENT, no such file or directory '/home/adrian/development/hybridgroup/cylon/cylon-tessel-example/node_modules/cylon-tessel/node_modules/cylon/node_modules/node-namespace'
    at Object.fs.readdirSync (fs.js:654:18)
    at Object.readdirRecursiveSync (/home/adrian/development/tessel/cli/node_modules/effess/effess.js:19:18)
    at list (/home/adrian/development/tessel/cli/node_modules/hardware-resolve/index.js:68:10)
    at /home/adrian/development/tessel/cli/node_modules/hardware-resolve/index.js:112:26
    at Array.forEach (native)
    at list (/home/adrian/development/tessel/cli/node_modules/hardware-resolve/index.js:111:27)
    at /home/adrian/development/tessel/cli/node_modules/hardware-resolve/index.js:112:26
    at Array.forEach (native)
    at list (/home/adrian/development/tessel/cli/node_modules/hardware-resolve/index.js:111:27)
    at /home/adrian/development/tessel/cli/node_modules/hardware-resolve/index.js:112:26
$ npm ls
[email protected] /home/adrian/development/hybridgroup/cylon/cylon-tessel-example
└─┬ [email protected] (git://github.com/hybridgroup/cylon-tessel.git#a745935fff563015a7858094bebcdbf88c949e92)
  ├─┬ [email protected]
  │ ├── [email protected]
  │ ├── [email protected]
  │ ├── [email protected]
  │ ├─┬ [email protected]
  │ │ ├── [email protected]
  │ │ ├── [email protected]
  │ │ ├─┬ [email protected]
  │ │ │ ├── [email protected]
  │ │ │ ├─┬ [email protected]
  │ │ │ │ └── [email protected]
  │ │ │ ├─┬ [email protected]
  │ │ │ │ ├── [email protected]
  │ │ │ │ ├── [email protected]
  │ │ │ │ ├─┬ [email protected]
  │ │ │ │ │ ├─┬ [email protected]
  │ │ │ │ │ │ ├── [email protected]
  │ │ │ │ │ │ └── [email protected]
  │ │ │ │ │ └── [email protected]
  │ │ │ │ ├── [email protected]
  │ │ │ │ ├── [email protected]
  │ │ │ │ ├── [email protected]
  │ │ │ │ ├── [email protected]
  │ │ │ │ └── [email protected]
  │ │ │ ├── [email protected]
  │ │ │ ├── [email protected]
  │ │ │ ├── [email protected]
  │ │ │ ├── [email protected]
  │ │ │ ├── [email protected]
  │ │ │ ├── [email protected]
  │ │ │ ├── [email protected]
  │ │ │ ├── [email protected]
  │ │ │ └─┬ [email protected]
  │ │ │   └── [email protected]
  │ │ ├─┬ [email protected]
  │ │ │ ├── [email protected]
  │ │ │ ├── [email protected]
  │ │ │ ├── [email protected]
  │ │ │ └─┬ [email protected]
  │ │ │   ├─┬ [email protected]
  │ │ │   │ └── [email protected]
  │ │ │   ├── [email protected]
  │ │ │   ├─┬ [email protected]
  │ │ │   │ ├── [email protected]
  │ │ │   │ ├── [email protected]
  │ │ │   │ ├── [email protected]
  │ │ │   │ └── [email protected]
  │ │ │   └── [email protected]
  │ │ └── [email protected]
  │ ├─┬ [email protected]
  │ │ ├── [email protected]
  │ │ └─┬ [email protected]
  │ │   ├── [email protected]
  │ │   └── [email protected]
  │ ├── [email protected]
  │ └── [email protected]
  ├── [email protected]
  └── [email protected]

`tessel push` tries to package the parent directory if there is no `node_modules` directory

This probably manifests itself as a variety of problems, including

Error: ENOENT, no such file or directory '/usr/local/Cellar/automake/1.14/share/automake-1.14/INSTALL'
    at Object.fs.lstatSync (fs.js:684:18)
    at Object.exports.copyDirSyncRecursive (/home/km/tm/cli/wrench.js:278:38)
    at Object.exports.copyDirSyncRecursive (/home/km/tm/cli/wrench.js:268:21)
    at Object.exports.copyDirSyncRecursive (/home/km/tm/cli/wrench.js:268:21)
    at Object.exports.copyDirSyncRecursive (/home/km/tm/cli/wrench.js:281:25)
    at Object.exports.copyDirSyncRecursive (/home/km/tm/cli/wrench.js:268:21)
    at Object.exports.copyDirSyncRecursive (/home/km/tm/cli/wrench.js:268:21)
    at /home/km/tm/cli/index.js:114:12
    at /home/km/tm/cli/node_modules/temp/lib/temp.js:133:7
    at Object.oncomplete (fs.js:107:15)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.