A recent Cygwin upgrade left me ripping my hair out, because none of my npm or grunt commands would work. They spat out the error
Unknown system errno 203
In your Cygwin
~/.bash_profile file (create it and
chmod 755 .bash_profile if it doesn’t exist):
This did the trick for me. Special thanks to this github comment.
This will be short but sweet. When deploying some new servers today, I ran into a problem where no matter what, sudo bitched about syntax errors in my sudoers file. I tried a bunch of different options/whitespace tweaks/etc and nothing worked.
deploy ALL= NOPASSWD: monit restart my-app
Looks fine right? Nope.
Use absolute paths
This fixed it:
deploy ALL= NOPASSWD: /usr/bin/monit restart my-app
Everyone in the world’s advice is to “just use visudo” but I couldn’t find any info on what was actually causing the syntax error. Hopefully this helps a few lost souls.
The Composer.js MVC framework has just released version 1.0! Note that this is a near drop-in replacement for Composer v0.1.x.
There are some exciting changes in this release:
- Composer no longer requires Mootools… jQuery can be used as a DOM backend instead. In fact, it really only needs the selector libraries from Moo/jQuery (Slick/Sizzle) and can use those directly. This means you can now use Composer in jQuery applications.
- Controllers now have awareness of more common patterns than before. For instance, controllers can now keep track of sub-controllers as well as automatically manage bindings to other objects. This frees you up to focus on building your app instead of hand-writing boilerplate cleanup code (or worse, having rogue objects and events making your app buggy).
- The ever-popular RelationalModel and FilterCollection are now included by default, fully documented, and considered stable.
- New class structures in the framework expose useful objects, such as Composer.Class which gives you a class structure to build on, or Composer.Event which can be used as a standalone event bus in your app.
- There’s now a full test suite so people who want to hack away on Composer (including us Lyon Bros) can do so without worrying about breaking things.
- We updated the doc site to be much better organized!
Try as we might, we couldn’t let some things stay the same and keep a clear conscience. Mainly, the problems we found were in the Router object. It no longer handles hashbang (
#!) fallback…it relies completely on History.js to handle this instead. It also fixes a handful of places where non-idiomatic code was used (see below).
Sorry for any inconvenience this causes. However, since the rest of the framework is backwards compatible, you should be able to just use the old Composer.Router object with the new framework without any problems if you don’t wish to convert your app.
Check out the new Composer.js, and please open an issue if you run into any problems. Thanks!
- The Lyon Bros.
I recently embarked on a project to rebuild the main functionality of Turtl in common lisp. This requires embedding lisp (using ECL) into node-webkit (or soon, Firefox, as node-webkit is probably getting dumped).
So I wrote up some quick bindings for nanomsg in lisp and wired everything up. So far, it works really well. I can’t tell if it’s faster than my previous messaging layer, but one really nice thing about it is that it uses file descriptors which can be easily monitored by an event loop (such as cl-async), making polling and strange thread < –> thread event loop locking schemes a thing of the past (although cl-async handles all this fairly well).
This simplified a lot of the Turtl code, and although right now it’s only using the nanomsg “pair” layout type, it could be easily expanded in the future to allows different pieces of the app to communicate. In other words, it’s a lot more future-proof than the old messaging system and probably a lot more resilient (dedicated messaging library authored by 0MQ mastermind beats hand-rolled, hard-coded simple messaging built by non-C expert).
Lately I’ve been neck-deep in embedding. Currently, I’m building a portable (hopefully) version of Turtl‘s core features in ECL.
Problem is, when embedding turtl-core into Node-webkit or Firefox, any output that ECL writes to
C operation (write) signaled an error. C library explanation: Bad file descriptor.
Well it turns out Windows doesn’t let you write to
STDOUT unless a console is available, and even if using msys, it doesn’t create a console for GUI apps. So here’s a tool (in lisp, of course) that will let you convert an executable between GUI and console.
Seems to work great. Special thanks to death.
It can be nice to access your FF extension’s variables/functions from the browser console (
ctrl+shift+j) if you need some insight into its state.
It took me a while to figure this out, so I’m sharing it. Somewhere in your extension, do:
var chromewin = win_util.getMostRecentBrowserWindow();
chromewin.my_extension_state = ...;
Now in the browser console, you can access whatever variables you set in the global variable
my_extension_state. In my case, I used it to assign a function that lets me evaluate code in the addon’s background page. This lets me gain insight into the background page’s variables and state straight from the browser console.
Note! This is a security hole. Only enable this when debugging your extension/addon. Disable it when you release it.
Note that this may or may not work on your device. If you’re running into an app that works in a real browser but on in your Android’s stock browser, do this:
- Navigate to your app in the browser.
- In the same tab go to
- Reload (it may reload for you).
This will show you errors that even
window.onerror doesn’t catch, which should help you narrow down your problem(s).
Source: This stackoverflow answer.
As you all know, I’m building a Turtl, a browser extension for client-side encrypted note/file storage.
Well once in a while the I need to debug the release version. There are docs scattered around detailing how to do this, but as usual with this type of thing you really need to do some digging.
By default, Firefox’s Browser Console only logs error events. You can change this to log any and all
console.log() calls from your addon (and any other addon) by doing this:
- Go to about:config
- Search for the key extensions.sdk.console.logLevel
- If it exists, set it to “info”, otherwise add a new string with the key extensions.sdk.console.logLevel and the value “info”
Boom, all your addon’s log calls now show up in the browser console.
I use curl to test out my HTTP libraries all the time. Recently, I ran into an issue where when uploading a file (25mb) from curl in the command line to my common lisp app server, only about half the data showed up (12.5mb). I was doing this:
curl -H 'Authorization: ...' -H 'Transfer-Encoding: chunked' --data-binary @/media/large_vid.mov
Naturally, I assumed the issue was with my libraries. It could be the cl-async library dropping packets, it could be the HTTP parser having issues, and it could be the app server itself. I mean, it has to be one of those. Curl has been around for ages, and there’s no way it would just drop data. So I spent days tearing my hair out.
Finally, I ran curl with the
--trace and looked at the data. It provides a hex dump of everything it sends. It’s not formatted perfectly, but with vim’s block select and a few handy macros, I was able to get the length of the data being sent: 12.5mb. That’s right, curl was defying me. There was no error in my code at all.
I did a search online for curl not sending the full file data when using
--data-binary. Nothing. So I looked over my options and found
-T which looks surprisingly similar to
--data-binary with the
@ modifier. I tried:
curl -H 'Authorization: ...' -H 'Transfer-Encoding: chunked' -T /media/large_vid.mov
All 25mb came through (every byte accounted for).
If you’re uploading files, use
-T /path/to/file instead of
--data-binary @/path/to/file. Note that
-d/-D were also “broken.”
Hi FORKS. Tuesday I announced my new app, Turtl for Chrome (and soon Firefox). Turtl is a private Evernote alternative. It uses AES-256bit encryption to obscure your notes/bookmarks before leaving the browser. What this means is that even if your data is intercepted on the way to the server or if the server itself is compromised, your data remains private.
Even with all of Turtl’s privacy, it’s still easy to share boards with friends and colleagues: idea boards, todo lists, youtube playlists, etc. With Turtl, only you and the people you share with can see your data. Not even the guys running the servers can see it…it’s just gibberish without the key that you hold.
One more thing: Turtl’s server and clients are open-source under the GPLv3 license, meaning anyone can review the code or use it for themselves. This means that Turtl can never be secretly compromised by the prying hands of hackers or government gag orders. The world sees everything we do.
So check out Turtl and start keeping track of your life’s data. If you want to keep up to date, follow Turtl on Twitter.