I am using the following library to connect via USB to an external device:
https://github.com/node-serialport/node-serialport
I set up the following sample project to narrow down where the issue might be:
https://github.com/nyoung697/node-serial-test
This code works on my Mac. The device I am connecting to accepts an ascii command and the carriage return to terminate that command.
In the example project, I am passing in 'V\r' and am expecting the version of the device to be returned. When I run this code on my Mac, I get the expected response.
However, when I run it on my Windows 10 machine, I do not get any response at all. Neither the port.on('data') or port.on('error') events are hit.
I tested downgrading the serialport library to version 4.0.7 and it does work.
Does anyone have any ideas what might have changed between 4 => 6?
P.S. I edited this question, as I originally thought it had something to do with Electron, however after doing this simple test with only node.js, I believe I have narrowed it down to this version of the library on Windows.
Okay... I just figured this out.
All I needed to do was add the property 'rtscts' to the openOptions object I pass in to the constructor and set it to true.
const SERIAL_PORT_SETTINGS = {
baudRate: 115200,
rtscts: true
};
let port = new SerialPort(devicePath, SERIAL_PORT_SETTINGS);
I figured this out by digging around in the release notes. I noticed that from v5.x.x to 6.0.0 the breaking changes included making this value default to false.
windows: We previously hard coded to have RTS on for windows at all times it now default to off.
Related
I'm running a long running custom nodejs script and would like to be notified when the script is completed.
How do I make nodejs trigger the "System Bell"?
Output the BELL character (Unicode 0007) to the standard output.
console.log('\u0007');
Update 2023
Solution above doesn't work anymore, but writing directly to stdout still works (tested on Node.js v14.20):
process.stdout.write('\u0007');
References
ASCII/ISO 8859 (Latin-1) Table
Unicode Characters: 00000 to 000FF
The Open Group Base Specifications Issue 7: Portable Character Set
Programming with Unicode Documentation (unicodebook.pdf)
How a bullet turns into a beep – The Old New Thing
Unicode 10.0.0 Final Names List
The console.log('\u0007') didn't work for me running VSCode on windows 10.
The following code did work:
import { exec } from 'child_process'
exec(`rundll32 user32.dll,MessageBeep`)
I know this question is tagged unix, but I found it from Google so here is a Windows PowerShell solution.
The current answer works fine in Windows, but I wanted something a bit more unique than the standard Windows tone so this worked better for my needs:
const { exec } = require('child_process');
// Single beep
exec("[console]::beep(1000, 500)", {'shell':'powershell.exe'});
// Multiple beeps
exec("1..3 | %{ [console]::beep(1000, 500) }", {'shell':'powershell.exe'});
I am trying to port an old GTK webkit code written in python2 to webkit2 and python3 (Ubuntu has removed old webkit v1). The js code changes the title of the html, and python detected it to close it. However, it is not working in webkit2.
In the old code, there is the line
self.webview.connect('title-changed', title_changed) #title_changed is a python function, which will do something
which shows TypeError: <WebKit2.WebView object at 0x7f14b687ecd0 (WebKitWebView at 0x557297cdb7c0)>: unknown signal name: title-changed.
How to port this code to webkit2?
According to https://webkitgtk.org/reference/webkit2gtk/stable/WebKitWebView.html there is webkit_web_view_get_title (), but is there any way to detect change of title?
Since title is a property, it automatically comes with a notify signal you can connect to. Use notify::title.
Use the following code, for example
self.webview.connect('notify::title', title_changed)
I have a very strange problem with the constructor of AptPkg::Cache object in the precise package of libapt-pkg-perl (v. 0.1.25).
The perl script is designed to download a debian package for three different architectures (i386, armel, armhf). For each architecture I do the following:
Configure AptPkg::Config '$_config' with the right parameters and package-lists for the desired architecture.
Create the cache object with AptPkg::Cache->new .
Call the method AptPkg::Cache->policy to create the AptPkg::Policy object.
Call the method AptPkg::Policy->candidate("program-name") .
Download the package for the selected architecture.
This works very well with Ubuntu Lucid, but with Ubuntu Precise I can only download the package for the first architecture defined. For the other two architectures there will be no installation candidate (method AptPkg::Policy->candidate("Package-Name") doesn't return an object).
I tried to build a workaround and I found one solution how the script works for all three architectures, without problems, in precise:
If I create the cache object (with AptPkg::Cache->new) twice in a row it works and the script downloads the debian package for all three architectures:
my $cache = AptPkg::Cache->new;
$cache = AptPkg::Cache->new;
I'm sure that the problem has something to do with the method AptPkg::Cache->new because I checked everything else, what could cause the problem, twice. All config-variables are set correctly and I even get a different Hash for AptPkg::Cache->new for each architecture, but it seems that I am overlooking something important.
I'm not very familiar with perl, so I am asking you guys if someone can explain why the script works with the workaround but not without it. Further it looks quite strange if you have the same line of code twice in your script.
Maybe you hit this bug - https://bugs.launchpad.net/ubuntu/+source/libapt-pkg-perl/+bug/994509
There is a script there to test if you're affected. If it's something else consider submitting a bug report.
edit: Just saw this is 11 months old :/
When I debug my Node application, my ObjectId's are represented by Unicode gibberish like ObjectID {id: RýÕ/H} instead of the actual readable ID. Here's a screenshot. Does anyone know what's causing this?
I am using WebStorm 7.0.1 on Crunchbang Waldorf x64.
UPDATE: After checking in node-inspector, I get the same results: http://i.imgur.com/8dxOGhd.png
The only time I can see my ObjectId's properly is if I check them in Robomongo (a MongoDB GUI) or if I log them to the console from within the Node app.
Unfortunately, it's just the way WebStorm currently works. You can do a quick evaluate using object.toString() when debugging if you need it. Instead of WebStorm showing something friendly, it's showing the binary representation of the ObjectID.
I had the same problem while doing a Node.js and MongoDB exercise from this book: https://leanpub.com/nodecraftsman. The code I'm talking about is on page 83, line 12.
I was running and testing everything through the command line.
What I discovered was that one line of the code (line #12) contained console.dir(documents). I changed it to console.log(documents), and it gave me back an id I expected -- something like 54e95c6f322fd679214d3a18 rather than the gibberish of, for example, Té\o2/Öy!M:\u0015
MDN describes console.dir() as "nonstandard," so perhaps there was something odd going on. More info: https://developer.mozilla.org/en-US/docs/Web/API/Console/dir
This is a bug in WebStorm. They are tracking the issue here:
https://youtrack.jetbrains.com/issue/WEB-9945
OK, so i have a SmartGWT web application, where i have some reports running in list grids.
I export to excel using the Smartgwt built-in export as per the examples using the listgrid.exportclientdata();
Here's the issue:
-When running locally, all works fine and i can open the XLSX file and see all data.
-When running from the server, the columns containing data become hidden! If i manually do the "unhide" thing from within Excel, i can see the columns...
My local environment is Mac OSX, Mountain Lion(also tried earlier), running Sun's Java.
The prod server is Debian running OpenJDK.
Not sure if that would have something to do with it, and i am at a loss as to how i go about solving it... Running my webapp on Tomcat6 in both environments.
For others, searching the stackoverflow void for answers to riddles in the dark:
This was caused by certain fonts not being available in OpenJDK, without any errors being logged anywhere...
I switched to Sun's JDK on my Debian as well, and the Excel files now open and display properly.
This an also happen when facing this POI Bug that seems to be related to a Java Bug.
If it's the case changing the Font to something other than Calibri or using jre above 7u21 should fix the issue.
You can also mitigitate the issue and avoid the columns from being totally collapsed by using a code like this
sheet.autoSizeColumn(x);
if (sheet.getColumnWidth(x) == 0) {
// autosize failed use MIN_WIDTH
sheet.setColumnWidth(x, MIN_WIDTH);
}