I have a main coffee file and a mix of other coffee and livescript files.
# main.coffee
require 'LiveScript'
one = require './one.coffee'
two = require './two.ls'
console.log one.fun(), two.fun()
# one.coffee
module.exports.fun = -> 1
# two.ls
module.exports.fun = -> 2
I can run
coffee main.coffee
But trying to run
browserify -t coffeeify main.coffee
Gives an error:
module.exports.fun = -> 2
^
ParseError: Unexpected token >
The only workaround I see is to compile ls files to js first. Is there a simpler, direct way to mix ls and coffee files?
require 'LiveScript' is only sufficient for Node.js. Browserify does not support require.extensions, and is trying to parse the LiveScript as JavaScript.
You need a transform for LiveScript as well, for example Liveify.
You might try Webpack. With proper loaders, e.g. livescript-loader, coffee-loader and others, you can compose your program with different js flavors.
Related
Windows 7 x64, Erlang-OTP 17.
I wrote simple module like this:
-module (somequery).
-export ([fbquery/2]).
fbquery(P1,P2) ->
inets:start(),
ssl:start(),
token = "78a8shd67tyajsndweiu03hr83h19j",
Encoded = {"Authorization","Basic " ++ base64:encode_to_string(lists:append([token,":",""]))},
ContentType = "application/xml",
Headers = [Encoded, {"Content-Type",ContentType}],
Options = [{body_format,binary}],
{ok, File}=file:read_file(P1),
Res = httpc:request(post, {"https://datapi.com/api/xml4-8", Headers, ContentType, File}, [], Options),
file:write_file(P2, io_lib:fwrite("~p.\n", [Res])).
This code working in interactive mode (werl.exe), and compiling into beam.
The question is how use *.erl or compiled *.beam module now? How import it and run fbquery/2 method?
First of, you need to add the directory containing your beam with the argument -pa Dir1 Dir2 .... It will add the directory to the erlang path and you will be able to type somequery:fbquery(Arg1,Arg2) in your shell.
Then, you can use the argument -s module function [args..] to launch erl with the specified function.
You can read about it in the erlang documentation for erl.
SharpDevelop compiles fine, but trying to compile through booc doesn't work.
Boo Compiler version 0.9.4.9 (CLR 2.0.50727.8000)
Program.boo(4,8): BCE0021: Namespace 'Microsoft.Xna.Framework' not found, maybe
you forgot to add an assembly reference?
booc -resource:"C:\test\" Program.boo , the command used in Windows cmd tool.
Thank you. Alisa.
Sharpdevelop most likely already references the libraries to the compiler for you. What that means is, when you manually invoke the booc command line compiler, you will have to tell the compiler where exactly the MonoGame library is. I haven't been able to check myself yet, but I did have a quick look at the command lines and the Boo source code, and I think you have to do the following:
-lib:C:/Path/To/MonoGame/Libraries
This will tell the compiler where to look for additional libraries.
The next thing you should then do is add the libraries you want, eg:
-r:Microsoft.Xna.Framework.dll,Microsoft.Xna.Framework.Game.dll
Add these two additional compiler options to your command line and I think it should work.
I haven't compiled this myself really, because I found it rather tedious. Instead, I decided to create my own build script in Boo itself in order to compile my Boo programs. That way I still had to add the library path and reference the libraries, as in the following snippet:
def CompileEngine() as bool:
"""Compiles the engine and puts it in ./lib/SpectralEngine.dll"""
compiler = BooCompiler()
compiler.Parameters.Pipeline = CompileToFile()
compiler.Parameters.OutputType = CompilerOutputType.Library
compiler.Parameters.Ducky = true
compiler.Parameters.LibPaths.Add("./lib")
compiler.Parameters.OutputAssembly = "./lib/SpectralEngine.dll"
# Add libraries.
compiler.Parameters.References.Add(compiler.Parameters.LoadAssembly("OpenTK.dll"))
compiler.Parameters.References.Add(compiler.Parameters.LoadAssembly("NAudio.dll"))
compiler.Parameters.References.Add(compiler.Parameters.LoadAssembly("Boo.Lang.dll"))
compiler.Parameters.References.Add(compiler.Parameters.LoadAssembly("Boo.Lang.Parser.dll"))
compiler.Parameters.References.Add(compiler.Parameters.LoadAssembly("Boo.Lang.Compiler.dll"))
# Take all boo files from the Engine source directory.
files = (Directory.GetFiles(Directory.GetCurrentDirectory() + """/src/Engine""", "*.boo", SearchOption.AllDirectories)
.Where({file as string | return not file.Contains("Gwen")})) # Filter out old GWEN files.
for file in files:
print "Adding file: " + file
compiler.Parameters.Input.Add(FileInput(file))
print "Compiling to ./lib/SpectralEngine.dll"
context = compiler.Run()
if context.GeneratedAssembly is null:
print "Failed to compile:\n" + join(e for e in context.Errors, "\n")
return false
else:
return true
I've put two of these build scripts at here and here. It's perhaps a bit overkill for you, though.
I'm doing VPATH builds with automake. I'm now also using generated source, with SWIG. I've got rules in Makefile.am like:
dist_noinst_DATA = whatever.swig
whatever.cpp: whatever.swig
swig -c++ -php $^
Then the file gets used later:
myprogram_SOURCES = ... whatever.cpp
It works fine when $builddir == $srcdir. But when doing VPATH builds (e.g. mkdir build; cd build; ../configure; make), I get error messages about missing whatever.cpp.
Should generated source files go to $builddir or $srcdir? (I reckon probably $builddir.)
How should dependencies and rules be specified to put generated files in the right place?
Simple answer
You should assume that $srcdir is a read-only, so you must not write anything there.
So, your generated source-code will end up in $(builddir).
By default, autotool-generated Makefiles will only look for source-files in $srcdir, so you have to tell it to check $builddir as well. Adding the following to your Makefile.am should help:
VPATH = $(srcdir) $(builddir)
After that you might end up with a no rule to make target ... error, which you should be able to fix by updating your source-generating rule as in:
$(builddir)/whatever.cpp: whatever.swig
# ...
A better solution
You might notice that in your current setup, the release tarball (as created by make dist) will contain the whatever.cpp file as part of your sources, since you added this file to the myprogram_SOURCES.
If you don't want this (e.g. because it might mean that the build-process will really take the pregenerated file rather than generating it again), you might want to use something like the following.
It uses a wrapper source-file (whatever_includer.cpp) that simply includes the generated file, and it uses -I$(builddir) to then find the generated file.
Makefile.am:
dist_noinst_DATA = whatever.swig
whatever.cpp: whatever.swig
swig -c++ -php $^
whatever_includer.cpp: whatever.cpp
myprogram_SOURCES = ... whatever_includer.cpp
myprogram_CPPFLAGS = ... -I$(builddir)
clean-local::
rm -f $(builddir)/whatever.cpp
whatever_includer.cpp:
#include "whatever.cpp"
Usually, you want to keep $srcdir readonly, so that if for instance the source is distributed unpacked on a CDROM, you can still run /.../configure from some other part of the file-system.
However if you are using SWIG to generate source code for a wrapper library, you probably want to distribute that SWIG-generated code as well so that your users do not need to install SWIG to compile your code. Then you have indeed a choice: you can decide that the SWIG-generated code should end in $builddir (it's OK: make dist will collect it there and include it in the tarball), or you could decide to output SWIG-generated code in $srcdir since it is really a source from the point of view of the distributed package. An advantage of keeping it in $srcdir is that when make distcheck attempts to build your package from a read-only source directory, it will fail on any attempt to call SWIG to regenerate the wrapper source. If you have your wrapper source in $builddir, you might not notice you have some broken rule that cause SWIG to be run on the user's host; by generating in $srcdir you ensure that SWIG is not needed by your users.
So my preference is to output SWIG wrapper sources in $srcdir. My setup for Python wrappers looks as follows:
EXTRA_DIST = spot.i
python_PYTHON = $(srcdir)/spot.py # _PYTHON is distributed by default
pyexec_LTLIBRARIES = _spot.la
MAINTAINERCLEANFILES = $(srcdir)/spot_wrap.cxx $(srcdir)/spot.py
_spot_la_SOURCES = $(srcdir)/spot_wrap.cxx $(srcdir)/spot_wrap.h
_spot_la_LDFLAGS = -avoid-version -module
_spot_la_LIBADD = $(top_builddir)/src/libspot.la
$(srcdir)/spot_wrap.cxx: $(srcdir)/spot.i
$(SWIG) -c++ -python -I$(srcdir) -I$(top_srcdir)/src $(srcdir)/spot.i
# Handle the multi-file output of SWIG.
$(srcdir)/spot.py: $(srcdir)/spot.i
$(MAKE) $(AM_MAKEFLAGS) spot_wrap.cxx
Note that I use $(srcdir) for all targets, because of limitations of the VPATH feature on various flavors of make. My setup to deal with the multiple files output by SWIG could be improved, but as these rules are not run by users and it has never caused me any problem, I do not bother.
I want to be able to debug minified compressed javascript code on my production site. Our site uses django compressor to create minified and compressed js files. I read recently about chrome being able to use source maps to help debug such javascript. However I don't know how/if possible to tell the django compressor to create source maps when compressing the js files
I don't have a good answer regarding outputting separate source map files, however I was able to get inline working.
Prior to adding source maps my settings.py file used the following precompilers
COMPRESS_PRECOMPILERS = (
('text/coffeescript', 'coffee --compile --stdio'),
('text/less', 'lessc {infile} {outfile}'),
('text/x-sass', 'sass {infile} {outfile}'),
('text/x-scss', 'sass --scss {infile} {outfile}'),
('text/stylus', 'stylus < {infile} > {outfile}'),
)
After a quick
$ lessc --help
You find out you can put the less and map files in to the output css file. So my new text/less precompiler entry looks like
('text/less', 'lessc --source-map-less-inline --source-map-map-inline {infile} {outfile}'),
Hope this helps.
Edit: Forgot to add, lessc >= 1.5.0 required for this, to upgrade use
$ [sudo] npm update -g less
While I couldn't get this to work with django-compressor (though it should be possible, I think I just had issues getting the app set up correctly), I was able to get it working with django-assets.
You'll need to add the appropriate command-line argument to the less filter source code as follows:
diff --git a/src/webassets/filter/less.py b/src/webassets/filter/less.py
index eb40658..a75f191 100644
--- a/src/webassets/filter/less.py
+++ b/src/webassets/filter/less.py
## -80,4 +80,4 ## class Less(ExternalTool):
def input(self, in_, out, source_path, **kw):
# Set working directory to the source file so that includes are found
with working_directory(filename=source_path):
- self.subprocess([self.less or 'lessc', '-'], out, in_)
+ self.subprocess([self.less or 'lessc', '--line-numbers=mediaquery', '-'], out, in_)
Aside from that tiny addition:
make sure you've got the node -- not the ruby gem -- less compiler (>=1.3.2 IIRC) available in your path.
turn on the sass source-maps option buried away in chrome's web inspector config pages. (yes, 'sass' not less: less tweaked their debug-info format to match sass's since since sass had already implemented a chrome-compatible mapping and their formats weren't that different to begin with anyway...)
Not out of the box but you can extend a custom filter:
from compressor.filters import CompilerFilter
class UglifyJSFilter(CompilerFilter):
command = "uglifyjs -c -m " /
"--source-map-root={relroot}/ " /
"--source-map-url={name}.map.js" /
"--source-map={relpath}/{name}.map.js -o {output}"
Is there any way to define CoffeeScript compilation order in sub-directories?
Please consider the following example:
Files:
src/App.coffee
src/view/B.coffee
src/view/a/A.coffee
Where class A extends B.
coffee --join js/app.js --compile src/view/ src/App.coffee
This throws an error in the browser:
Uncaught TypeError: Cannot read property 'prototype' of undefined
If I rename folder a to z, the error is gone and everything works fine.
src/view/z/A.coffee
I would expect the compiler to read all .coffee files from src/view/ before it goes into src/view/ sub-directories. Again, is there any way to do that?
Edit:
PC Windows 7,
CoffeeScript version 1.3.3
The only solution I think is to create the compile order manually within a build script.
You would create an ordered collection with filenames, where as the loop iterates and concatenates a new big string, which can be compiled as one file.
Create a Cakefile with following content, check Syntax first. And run with cake build. That should work, cake comes with CoffeeScript.
fs = require 'fs'
{exec} = require 'child_process'
viewsDir = "src/view"
coffeeFiles = [
'B'
'A'
]
task 'build'
# loops through coffeeFiles.
for file, index in coffeeFiles then do (file, index) ->
fs.readFile "#{viewsDir}/#{file}", 'utf8', (err, content) ->
appCoffee[index] = content
compile() if --remaining is 0
compile = ->
fs.writeFile 'js/app.coffee', appCoffee.join('\n\n'), 'utf8', (err) ->
throw err if err
exec 'coffee --compile js/app.coffee', (err, stdout, stderr) ->
throw err if err
console.log stdout + stderr
# you can skip deleting the app.coffee file
fs.unlink 'js/app.coffee', (err) ->
throw err if err
console.log 'Created app.coffe, compiled to app.js and removes app.coffee'
# maybe additional taks
# invoke 'test'
Documented also in Wiki of Coffeescript https://github.com/jashkenas/coffee-script/wiki/[HowTo]-Compiling-and-Setting-Up-Build-Tools
Before first loop you could also make it loop through different directories. And just list filenames in coffeeFiles to be processed before the others not in listed and the rest could be added to list with fs.readDir().
We created a simple module to solve a similar problem:
https://github.com/Vizir/rehab
Just put #_require [filename].coffee on your file and you're done.
We are using it in productions with complex dependency graphs.