CoffeeScript compiler errors suppressed under Node 0.5.10-pre - coffeescript

When my script fails to parse for any reason, I get a stack trace from the compiler, with no insight at all into where in my script the problem lies:
mpurvis#citadel:~/coffee$ coffee -c Test.coffee
/usr/local/lib/node_modules/coffee-script/lib/command.js:15
return process.binding('stdio').writeError(line + '\n');
^
Error: No such module
at /usr/local/lib/node_modules/coffee-script/lib/command.js:15:20
at /usr/local/lib/node_modules/coffee-script/lib/command.js:167:7
at /usr/local/lib/node_modules/coffee-script/lib/command.js:115:26
at [object Object].<anonymous> (fs.js:108:5)
at [object Object].emit (events.js:64:17)
at afterRead (fs.js:1074:12)
at Object.wrapper [as oncomplete] (fs.js:246:17)
For now, it's just a toy script to try the system out, so I can usually just experiment until it works again, but that would be impossible in a file of any size. Is there some trick I'm not seeing to get the line where the error occurred?
Thanks!

the latest version from node isn't full compatible with cs..the node_stdio module ws removed...a simple way for fix it is open /usr/local/lib/node_modules/coffee-script/lib/command.js and change the line 15
process.binding('stdio').writeError(line + '\n')
for
process.stderr.write(line + '\n')
always you can get more help from github issues section
https://github.com/jashkenas/coffee-script/commit/c77f7737a5d94a05a999109810ea7634f540e1e2
good luck and happy coding

This doesn't look like a syntax issue. The error is coming from command.js, which is what defines the coffee command-line utility. If it were a compiler error, it would be from coffee-script.js.
So why is the process.binding('stdio') bit in command.js failing? There are two possibilities I can think of:
You're using a weird shell (or a weirdly configured one) that doesn't play nice with Node's version of stdio. This seems unlikely, but it's possible...
You're using a version of Node.js that CoffeeScript isn't currently compatible with. What do you get when you do node -v? Your safest bet is the latest 0.4.x, since those are stable releases (0.5.x is experimental).

This question is from awhile back.
Node 0.6.x throws a similar error with CoffeeScript 1.1.x; upgrading to 1.3.x does the trick.

Likely 2 different coffee-scripts on your system. check which coffee, than track down the older one and ice it. I had one from an install last summer (v1.1), it's all cleared up now.

Related

Undefined method [] for nil when trying to run cap deploy:restart

I have a Rails 5.2 app, and with cap 3.4.1 we are suddenly getting this weird error:
[b35efe76] Phusion Passenger(R) 6.0.8
DEBUG [b35efe76] Finished in 0.305 seconds with exit status 0 (successful).
(Backtrace restricted to imported tasks)
cap aborted!
SSHKit::Runner::ExecuteError: Exception while executing as deploy#host.com: undefined method `[]' for nil:NilClass
Trying to narrow it down, it happens when attempting to restart, because this is the line that fails:
cap production deploy:restart
The question is, how do I go about finding what file is trying to call [] on a nil value on? Running cap with --trace is of no value because it just gives me internal errors - nothing in my code. Basically, how do I find out what is nil?
One more clue, currently, I have a bunch of servers, if I run the cap restart command on server A, it restarts fine, on server B, it throws this error, so I'm guessing there's an environment variable on server A but not B, but the error is just so opaque I don't know where to begin.
Thanks for any help,
kevin
A wild guess: I had a similar problem and I could solve it by upgrading capistrano-passenger to >= 0.2.1
Looks like the version change of passenger from 6.0.7 to 6.0.8 has introduces a problem. I see you are also on 6.0.8, so it might affect you, too!
Link to the capistrano-passenger issue

OpenModelica IBPSA example error spatialDistribution

I'm quite new to Modelica and I'm trying to understand some basic examples. I'm looking at the example IBPSA.Fluid.FixedResistances.Examples.PlugFlowPipe and checking this model gives me the following error
Number of classes to check: 2
Checking: model IBPSA.Fluid.FixedResistances.Examples.PlugFlowPipe... 0.2350000000001273 seconds -> FAILED!
Error String:
Error Buffer:
Warning: Requested package Modelica of version 3.2.2, but this package was already loaded with version 3.2.3. You might experience problems if these versions are incompatible.
[C:/Program Files/OpenModelica1.14.0-64bit/lib/omlibrary/IBPSA 3.0.0/Fluid/FixedResistances/BaseClasses/PlugFlowTransportDelay.mo:49:3-55:44:writable] Error: Function argument initialValues={time + pip.cor.timDel.t_in_start, time + pip.cor.timDel.t_out_start} in call to spatialDistribution has variability continuous which is not a parameter expression.
#[-], 0.2350000000001273, IBPSA.Fluid.FixedResistances.Examples.PlugFlowPipe
-------------------------------------------------------------------------
Checking skipped: package IBPSA.Fluid.FixedResistances.Examples.PlugFlowPipe.Medium...
[2] 11:48:12 Scripting Notification
Number of classes checked / failed: 2/1
It seems that the module pip.cor.timDel uses the function spatialDistributuon. My guess is that there is something wrong with pip.cor.timDel.t_in_start or pip.cor.timDel.t_out_start? It would be greatly appreciated if someone could help me with this.
P.S. I'm using OMEdit v1.14.0 on windows 10 with Modelica library v3.2.3
OpenModelica does not support the function spatialDistribution yet, i opened a ticket on Trac where you can follow for the current development status.

Google Ortools - trouble with routing example

I am having an odd issue with Google Ortools vehicle routing example, found here:
https://developers.google.com/optimization/routing/tsp/vehicle_routing
Using Windows 10, and Python 3.6...
When executing the full program code provided in the link above, the program freezes up and exits. Command line provides the following:
WARNING: Logging before InitGoogleLogging() is written to STDERR
F0502 21:33:22.115679 7972 search.cc:2658] Check failed: step > 0 (0 vs. 0)
*** Check failure stack trace: ***
I have honed the code causing the freeze down to this line of code:
assignment = routing.SolveWithParameters(search_parameters)
I am certain I have the library properly installed because other examples of the program have run successfully. I attempted to use Visual Studio, and even went so far as to disable my second GPU.
I am wondering if anyone has encountered this issue and possibly knows how to fix. Thank You.
Issue was solved as follows:
Original model on google's website creates the following variable:
search_parameters = pywrapcp.DefaultRoutingSearchParameters()
I had changed to:
search_parameters = pywrapcp.RoutingModel.DefaultModelParameters()
But the required change should be:
search_parameters = pywrapcp.RoutingModel.DefaultSearchParameters()

Allegro Webactions not serving on SBCL. Methods to debug or possible solutions?

I am trying to get Portable Allegro Serve and Webactions up and running on SBCL. I have so far managed to make paserve properly serve pages. But webactions chunks out with the following warning in the console:
1-aserve-worker: 05/27/09 - 21:28:43 - processing clp file "/home/user/pages/index.html" got error The value NIL
is not of type
FUNCTION.
1-aserve-worker: 05/27/09 - 21:28:43 - while processing command "GET /testing/index.html HTTP/1.0"
got error The slot NET.ASERVE::OBJECTS is unbound in the object #<NET.ASERVE:CLP-ENTITY {C1C8201}>.
Any ideas as to why this is happening? Alternatively any ideas on how I could break into this to examine/investigate what is going on?
Versions of software: SBCL 1.0.28 running on debian 2.6.26, PAServe 1.2.47.
It seems the acl-compat library which comes with asdf-install is different from the acl-compat library that comes with paserve.
I never resolved the above problem, but using a different acl-compat layer made the problem disappear.

GTK applications fail to start - xfs restart needed Options

Sorry, not really programming question, but I am not sure where else I could find some help.
After a recent update (Xorg was updated among other things), GTK apps stopped running in my kde4. I have a Debian unstable, updated around 22 April. When I try to run them I get the following error:
ga#grzes:~$ iceweasel
The program 'firefox-bin' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadName (named color or font does not exist)'.
(Details: serial 888 error_code 15 request_code 45 minor_code 0)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the --sync command line
option to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)
ga#grzes:~$ gimp The program 'gimp' received an X Window
System error.
This probably reflects a bug in the program.
The error was 'BadName (named color or font does not exist)'.
(Details: serial 6955 error_code 15 request_code 45 minor_code 0)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the --sync command line
option to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)
(script-fu:4643): LibGimpBase-WARNING **: script-fu: gimp_wire_read():
error
I have to restart the font server manually to have it fixed:
ga#grzes:~$ su
Password:
grzes:/home/ga# /etc/init.d/xfs restart
Stopping X font server: xfs.
Setting up X font server socket directory /tmp/.font-unix...done.
Starting X font server: xfs.
Any ideas what could be wrong? Is it a configuration issue? My system has been updated for the last 7 years, so I can have some old settings.
Debian unstable is very... unstable now, since a release was made a short time ago. Major changes and packages migrations are happening. Xorg (and all X related stuff) being one of the critical packages in that process. My advice is to perform a new update/upgrade in order to catch a new version that may resolve this problem.
It's very frequent that after an update some thing will get broken in inexplicable ways, simply because the developers are uploading new, and not much tested, version of the applications
I finally figured this out: seems like xfs is not compatible with the other components currently and luckily removing it form the system completely solves the problem.