I'm using babel with gulp (.pipe($.babel())), and it seems to work for most things but is not working for Array.from.
It works fine when running babel-node:
$ ./node_modules/babel/bin/babel-node.js
> Array.from
[Function: from]
But when the following code is processed with gulp:
var foo = () => { console.log(Array.from) }
The transpiled source is:
var foo = function foo() {
console.log(Array.from);
};
And the console output when I execute foo is:
undefined
Ended up solving this myself while writing my question, but figured I'd finish and answer myself to help future searchers:
There are certain features of babel that require a polyfill loaded in the browser due to limitations of ES5. This is loaded automatically in babel-node or you can include with with babel-polyfill.
Some of the features requiring the polyfill:
Abstract References
Array destructuring
Async functions
Comprehensions
For of
Array.from
spread
Related
I do not understand how is one supposed to use multiple modules that each implement the same behaviour since i get this error at compile time:
Function is already imported from
In my case i have two modules implementing gen_event behaviour and i am trying to import them in a third module.
I get the error message whenever i am trying to compile this code:
-module(mgr).
-import(h1,[init/1]). // implements gen_event
-import(h2,[init/1]). // implements gen_event
You can't do that. Import is a simple trick to avoid to write the complete "definition" of a function. It does nothing but just says to the compiler : when you see init(P) in this module, replace with h1:init(P).
Thus it is not possible to import several function with the same name/arity.
For short names, I do not see any benefit to use import.
If you are using module:function with long names, and you want to shorten the lines in the code, it is possible to use macros instead, and there are no limitation (but also few chance that the function name are the same :o):
-define(Func1(Var1,...,VarN), module1:func(Var1,...,VarN)).
-define(Func2(Var1,...,VarN), module2:func(Var1,...,VarN)).
...
?Func1(A1,...,AN);
...
?Func2(B1,...,BN);
Edit
The next example illustrates how it works, first I create the module mod1 as follow:
-module (mod1).
-export ([test/1]).
test(P) ->
case P of
1 -> ok;
2 -> mod2:test()
end.
and I test it in the shell:
1> c(mod1).
{ok,mod1}
2> mod1:test(1).
ok
3> mod1:test(2).
** exception error: undefined function mod2:test/0
4> % this call failed because mod2 was not defined.
4> % lets define it and compile.
mod2 is created as:
-module (mod2).
-export ([test/0]).
test() ->
io:format("now it works~n").
continue in the shell:
4> c(mod2).
{ok,mod2}
5> mod1:test(1).
ok
6> mod1:test(2).
now it works
ok
7>
As you can see, it is not necessary to modify mod1, but only to create and compile mod2 (note that it would be the same if mod2 already exists but the function test/0 is not exported).
If you want to verify that your code is not using undefined function, you can use external tools. As I am using rebar3 to manage my projects, I use the command rebar3 xref to perform this check. Note that calling an undefined function is a simple warning, it is meaningful in the context of application upgrading. This verification is not bullet proof: it is done at build time, this does not guarantee that the modules yo need will be present, with the right version on a production system: it opens a lot more interesting questions about versioning, code loading...
In the CoffeeScript 1.9.0 ChangeLog, I read:
Changed strategy for the generation of internal compiler variable names. Note that this means that #example function parameters are no longer available as naked example variables within the function body.
I don't quite understand what this means for me as a user. Is this somehow an incompatible change? Can I safely upgrade to version 1.9.0?
It depends. Yes, this change is incompatible. If you had written tests, you could check if it affects you. Take this little piece of code:
example = "new"
obj = method: (#example) -> console.log(example)
obj.method "old"
In 1.8 this would print old. In the new version, this prints new.
In the older version, #example would be translated to example in the method parameters. So you're accessing obj.method's function parameter in the old version.
In the new version you're accessing the example variable of the outer scope. a.example still gets set to "old" in both cases.
Here you can see the difference in the generated JS code:
-// Generated by CoffeeScript 1.7.1
+// Generated by CoffeeScript 1.9.0
(function() {
var example, obj;
example = "new";
obj = {
- method: function(example) {
- this.example = example;
+ method: function(_at_example) {
+ this.example = _at_example;
return console.log(example);
}
};
obj.method("old");
}).call(this);
See Patrick J. S.’ answer for what the change means.
See How do I find cases of CoffeeScript 1.9.0 breaking change in my code? for how to know if you can upgrade safely, and what you need to do if not.
Transitioning from Play Framework 2.1 to 2.2 (Scala) I was restructuring some code and found some lines of code to totally freeze the SBT build until the process was killed due to java.util.concurrent.ExecutionException: java.lang.OutOfMemoryError: GC overhead limit exceeded. Also Eclipse (tried with Juno and Kepler but I doubt it has anything to do with this) froze and it didn't even load the workbench anymore.
So, here's the code. I would love to know what makes the compiler to freeze and not just give an error here.
def foo = Action { implicit request =>
someForm.bindFromRequest.fold(
formWithErrors => Ok,
form => Async { Future.successful(Ok) }
)
}
I solved the issue already, but I'm curious why this just freezes everything. I'm on a Mac running java (1.7.0_40).
Update: Also, I'm using Scala 2.10.2. A coworker of mine can compile this on his PC, but with deprecation warnings on Async.
There are certain expressions within Scala that when you ask the compiler to evaluate them, it will instantiate a TON of type instances trying to figure out the unified difference between two types. Most likely, the type you're returning is NOT what you expect.
I would explicitly annotate the result type:
def foo = Action { implicit request =>
someForm.bindFromRequest.fold[Result](
formWithErrors => Ok,
form => Async { Future.successful(Ok) }
)
}
This should help the type inferencer KNOW what the types are and only check to see if they match, rather than expand infinitely. Also, sounds like it may have been a scala compiler bug.
What is the difference between a scala script and scala application? Please provide an example
The book I am reading says that a script must always end in a result expression whereas the application ends in a definition. Unfortunately no clear example is shown.
Please help clarify this for me
I think that what the author means is that a regular scala file needs to define a class or an object in order to work/be useful, you can't use top-level expressions (because the entry-points to a compiled file are pre-defined). For example:
println("foo")
object Bar {
// Some code
}
The println statement is invalid in the top-level of a .scala file, because the only logical interpretation would be to run it at compile time, which doesn't really make sense.
Scala scripts in contrast can contain expressions on the top-level, because those are executed when the script is run, which makes sense again. If a Scala script file only contains definitions on the other hand, it would be useless as well, because the script wouldn't know what to do with the definitions. If you'd use the definitions in some way, however, that'd be okay again, e.g.:
object Foo {
def bar = "test"
}
println(Foo.bar)
The latter is valid as a scala script, because the last statement is an expression using the previous definition, but not a definition itself.
Comparison
Features of scripts:
Like applications, scripts get compiled before running. Actually, the compiler translates scripts to applications before compiling, as shown below.
No need to run the compiler yourself - scala does it for you when you run your script.
Feeling is very similar to script languages like bash, python, or ruby - you directly see the results of your edits, and get a very quick debug cycle.
You don't need to provide a main method, as the compiler will add one for you.
Scala scripts tend to be useful for smaller tasks that can be implemented in a single file.
Scala applications on the other hand, are much better suited when your projects start to grow more complex. They allow to split tasks into different files and namespaces, which is important for maintaining clarity.
Example
If you write the following script:
#!/usr/bin/env scala
println("foo")
Scala 2.11.1 compiler will pretend (source on github) you had written:
object Main {
def main(args: Array[String]): Unit =
new AnyRef {
println("foo")
}
}
Well, I always thought this is a Scala script:
$ cat script
#!/usr/bin/scala
!#
println("Hello, World!")
Running with simple:
$ ./script
An application on the other hand has to be compiled to .class and executed explicitly using java runtime.
I'm setting up a Cakefile that will compile and minify my CoffeeScript and minify my Vanilla libs.
I created different tasks for each case (whether it was a coffee file or not) but I want to combine them into one task.
The problem I'm having is calling a method from the task; I can call a method with no problem under some circumstances, but otherwise I receive
TypeError: undefined is not a function
The object I'm working on looks like
source =
libs: [
'lib/jquery-1.7.1.min.js'
'lib/backbone.js'
'lib/underscore.js'
]
coffees: [
'app/800cart.coffee'
'app/models/coffee/cart.coffee'
'app/models/coffee/contact.coffee'
]
And Im wanting to do this, and I get the error
task 'build', 'Concat, compile, and minify files', ->
for fileType, files of source
concatinate files
concatinate = (files) ->
console.log 'concatinating'
The part that I'm really confused by is if I call the method with a condition it runs fine
task 'build', 'Concat, compile, and minify files', ->
for fileType, files of source
concatinate files if fileType is 'coffees'
concatinate = (files) ->
console.log 'concatinating'
What am I doing wrong here?
The problem is that you're trying to call concatinate before you define concatinate with the line concatinate =. Just move up the declaration, or better yet, move it outside of the task definition.
You're probably used to JavaScript's function concatinate syntax, which automatically moves the function to the top of the scope. CoffeeScript compiles to the concatinate = function syntax instead, mainly because the function cocatinate syntax behaves inconsistently across different JS runtimes (particularly IE). So, CoffeeScript functions simply obey ordinary variable assignment rules.