If you're updating JSON by hand, you're doing it wrong. No exceptions.
I don't understand. How does one maintain a file like package.json or any
other config file?
On Mon, Jan 13, 2014 at 10:07 PM, Alex Kocharin a...@kocharin.ru wrote:
JSON scripts are for GUIs so they can be updated by
Hi Jerry,
were you able to find a solution to this problem?
i'm having exactly the same thing (same slow buffers, same sizes).
i've discovered that when i run the nodejs directly and not from behind a
proxy, the problem is reduced (but its still there).
furthermore - i can't reproduce this
Don't feed the troll. He goes on a tirade every time anyone mentions json.
Pretty soon you just tune him out.
--
Brian Lalor
bla...@bravo5.org
On Jan 14, 2014, at 3:37 AM, Mark Hahn m...@reevuit.com wrote:
If you're updating JSON by hand, you're doing it wrong. No exceptions.
I don't
On Tuesday, January 14, 2014 7:13:54 AM UTC-5, Alex Kocharin wrote:
It was an experiment a year ago, but right now I can't even imagine how I
would use package.json without an ability to comment anything. :)
If you're commenting your package.json, you're doing it wrong. No
exceptions.
--
14.01.2014, 17:46, "mscdex" msc...@gmail.com:On Tuesday, January 14, 2014 7:13:54 AM UTC-5, Alex Kocharin wrote:It was an experiment a year ago, but right now I can't even imagine how I would use package.json without an ability to comment anything. :)If you're commenting your package.json, you're
I saw this few months ago, and I had one question how many times do you
change your package.json manually? I use:
- npm i module —save (or —save-dev)
-
npm remove module —save
-
npm version patch/minor/major
And things like that which does not only change the package but do the
I'm heavily using `npm version`, but prefer to edit manually anything else. It's mainly because I don't like to pin down dependencies, and make open semver ranges like '=1.2.3'. That's where comments in package.json come in, when some dependency version is known to be buggy, package.json is the
I'm running a series at http://learnallthenodes.com. It's 9 episodes so
far, and the 10th will be out this coming Monday.
I go from raw Node, if you will, to Express. This week's episode was about
doing view templates with Jade.
Hopefully it can be of use to you.
On Sunday, January 12, 2014
I like the simplicity of JSON, I endured years of XML and XSLT :)
The reason for the JSON format, which is actually any of JSON, CSON, YAML,
is for the project script to survive round trips between the drag 'n drop
GUI and editing the script manually. Functions are supported through simple
You won't get the problem is you use either streamline.js or fibers. A
try/catch in your request handler will catch all exceptions that may be
thrown by the current request (and only those exceptions). Streamline will
also give you a TLS (thread local storage) equivalent: useful if you need
to
check out Koa http://koajs.com/ you won't get separate stacks like you do
with node-fibers but similar otherwise (built with generators)
On Tuesday, 14 January 2014 12:28:52 UTC-8, Gregg Caines wrote:
Hey all... I'm wondering if anyone can point me to the current
best-practice for isolating
+1 for Fibers
On Wednesday, 15 January 2014 00:28:52 UTC+4, Gregg Caines wrote:
Hey all... I'm wondering if anyone can point me to the current
best-practice for isolating requests in a web app. In general I'm trying
to solve the problem of keeping the server running despite bad code in a
I've heard that generators helps to catch errors but didn't seen any good
explanation how to do that, if anyone knows such an article please post
link here
On Wednesday, 15 January 2014 07:48:38 UTC+4, Alexey Petrushin wrote:
+1 for Fibers
On Wednesday, 15 January 2014 00:28:52 UTC+4, Gregg
Well even though all the responses so far would require some pretty
non-standard solutions (and therefore major changes to our current app), I
really do appreciate them. We have logging, metrics and alerts on server
restarts, so we know about and fix restarts as fast as possible I believe,
As I see it, there are a few paths open to you that don't require you to do
a total rewrite using a different framework:
1. This is pretty much the exact problem that domains were designed to
solve. It's up to you to decide whether you want to recover from errors or
to shut down the process
So, you have a couple of formats to write a config, but if user wants to use UI, it will be converted to JSON removing all formatting, right? Just checking, I got that kind of a problem several times with different applications, when you can't automatically update config and preserve formatting
You can use this module: https://github.com/CrabDude/trycatch It won't require any major changes to the app. I think this is exactly what are you looking for. As for better general solution, I'd second @tj on that, generators are a nice idea. I didn't try koa, but looks promising. Also, this
I've heard that generators helps to catch errors but didn't seen any good
explanation how to do that, if anyone knows such an article please post
link here
With the galaxy library, you just use try/catch to handle errors with
generators. The model is the same as async/await in other
For example type in node console:
while(true) console.log('waiting please');
How stop it? CTRL-C not work. CTRL-BREAK close console (and all my work is
lost).
I want ability to break a script execution in any time and get the stack
trace for point were a break happened.
--
--
Job Board:
Short of using gdb or mdb (or Visual Studio's debugger), there's no way to
interrupt a tight loop in the Node REPL. For normal, asynchronous code on a
Unixy system (including OS X) that may not be returning you back to a
prompt, you can run kill -USR1 node pid to turn on the V8 debugger in
the
20 matches
Mail list logo
