I have one Fay file which is the heart of my program, however I need some helpers for my logic, for instance a method to replace substrings. From what I understand, if I need such methods which are offered by many Haskell libraries from Hackage directly, I can't use those Haskell libraries, but I must copy-paste the code in my project. So it's what I did, I copy-pasted a "replace" function together with other helpers from the MissingH library in a new file in my project: Utils.hs.
That Utils.hs compiles without problems with Fay. Also I import it in my main Fay file and I get a JS file for the main project file without problems. However at runtime I get the following error:
ReferenceError: Utils$$36$ is not defined
I don't think that Fay will include the code from the helper file in my main JS file, so I'm including both JS files in the loading HTML. And to make even more sure that when I load the main file, that the utils file is loaded, I load it like that:
$.getScript("Utils.js", function(){
$.getScript("FayConfig.js");
});
But despite this I still get the error. I tried compiling the Utils.hs with "--library" but it didn't help.
So my question is, which setup do I need to achieve that the generated JS will find the helper functions that I put in another HS file, knowing that at compile-time, Fay (apparently) finds them without problems? Is there an example of such a setup online? Most of the Fay uses that I found have all the code in a single HS file, though they often use external Fay code from cabal, as with fay-jquery. In my case, setting up a cabal project just for these simple helpers would be overkill.
Which version of Fay are you using (fay --version)? It seems like you are using a version older than
0.16 where forgetting import Prelude wouldn't give any warnings, see this closed ticket. So upgrade fay and/or add import Prelude.
We're also considering renaming operators in the produced output to make error messages like these easier to understand.
You do not need to invoke fay several times, fay outputs all dependencies into the same js file. So there's no difference from using a cabal package in that regard.
Hope this helps, otherwise please give me a way to reproduce this.
Related
I just put some of my code from a/b.dart to a/b1.dart file and now I started getting lot of errors on importing.
Is there any command or any other fix to import all a/b1.dart file in these files instead of manually opening each file and importing one by one.
I understand that a function or a property can be defined in more than two files and Dart can't make the right choice but if a function or property is defined in just one place, I think there must be some way to import it except searching for a/b.dart and replacing it with a/b.dart + a/b1.dart and then optimizing all imports.
As much as I am aware, Plugins/Extensions for your specific IDE (for dart) can be found that will help you with this problem.
I would recommend using dartdev tools - dartfix
I've already Google'd for an answer, since this is a common problem, but all the replies point in using alternatives instead of explaining why this doesn't work, so I'm asking here.
I put this code in my Atom's init.coffee script:
beautify = require('js-beautify').html
But Atom fails with Failed to load init.coffee and Cannot find module 'js-beautify'. Curiously enough, this works on a package and this works if I type the exact same code on Atom's console.
Of course, I could write a package for this, in fact there are a couple available, this is just an example because I want to learn how to require modules from init.coffee for future tweaks.
Thanks a lot!
When you require() from init.coffee, Atom looks for those modules in its own path. An example of where you might want to do that is if you had oni = require('oniguruma') to get access to regular expression functions.
In order to get to js-beautify, you have to specify its complete path. So far, only explicitly declaring the entire absolute path has worked for me:
beaut = require 'C:\\Users\\<username>\\.atom\\packages\\atom-beautify\\node_modules\\js-beautify'
console.log beaut
In practice, the most reliable way to use a module like this is to globally install it so that you can link to your global NPM folder. Linking to a module inside a package will break if the package is ever uninstalled.
I am using play framework v2.3. The problem I am facing is that any change in html and refreshing browser causes recompilation of the complete code. Can I avoid this?
Twirl templates are compiled, as stated by the docs:
Templates are compiled as standard Scala functions, following a simple naming convention. If you create a views/Application/index.scala.html template file, it will generate a views.html.Application.index class that has an apply() method.
There is no way to disable this behavior because it works this way by design. My suggestion here is use ~ (tilde) before SBT commands so things will happen as you save the file, per instance:
sbt ~run
This will recompile the changed file (and possible others), every time you change and save it. Also, sbt has some options that can possibly help you here: withNameHashing.
See sbt docs to understand how it works. To enable it, add the following line to your build.sbt file:
incOptions := incOptions.value.withNameHashing(nameHashing = true)
Today I cleared my .ivy cache and cleaned my project output targets. Since then I have been getting really strange behaviour when running tests with SBT or editing in the Scala IDE.
Given the following:
package com.abc.rest
import com.abc.utility.IdTLabel
I will get the following error:
object utility is not a member of package com.abc.rest.com.abc
Notice that com.abc is repeated twice, so it appears that the compiler uses the context of the current package when doing the import (maybe it's supposed to do this, but I never noticed it before).
Also, if I try to access classes in package com.abc from anywhere inside com.abc.rest (even using the full path) the compiler will complain that the type can not be found.
It appears that the errors only occur when I try to include files from parent packages. What I do find strange is that my code used to work. It only started happening after I cleaned up my project and my ivy cache, so maybe a later version of the compiler is more strict than the previous one.
I would love some ideas on what I can be doing wrong, or how I can go about troubleshooting this.
Update:
By first importing the parent classes and then defining the current package, the problem goes away:
import com.abc.utility.IdTLabel
import com.abs._
package com.abc.rest {
// Define classes belonging to com.abc.rest here
}
So this works, but I would still love to know why on earth the other way around worked, and then stopped working, and how on earth I can fix it. I had a good look, and could find no packages, objects or traits by the name of com anywhere inside the parent package.
Update relating to Worksheets:
Scala worksheets belonging to the same package share the same scope, which sounds obvious, but wasn't. Worksheets are not sand-boxed - they can see the project, and the project can see them. So all the 'test' object, traits, and classes you create inside the worksheet files, also becomes visible in the rest of the project.
I have so many worksheets that I did not even try to see where the problem came in. I simply moved them all to their own package, and like magic, the problem went away.
So, lesson learned for the day: If you create stuff inside worksheets, it's visible from outside the worksheet.
Anyway, this new found knowledge will come in handy, meaning anything 'interesting' can be build, monitored and tweaked inside the worksheet, while the rest of the project can actually use it. Quite cool actually.
It's still interesting to think how a sbt clean and cleaned up ivy cache managed to highlight the problem that was hidden before, but hey, that's another story....
(At the request of JacobusR, I'm making a proper answer out of my earlier comments).
This can happen if you have defined some class/trait/object inside package com.abc.rest.com. As soon as package com.abc.rest.com exists, and given that you are in package com.abc.rest, com would designate com.abc.rest.com as opposed to _root_.com. Fastest (but non-conclusive) way to check, without even scanning the source files, is to look for any .class files in the "com/abc/rest/com" sub-folder.
In particular you would get this behaviour if any of your files has duplicate package definitions (as in package com.abc.rest; package com.abc.rest; ...). If you have this duplicate package clause somewhere in the same file where you get the error, you wouldn't even see anything fishy with the .class files, as the failure at compiling the file would prevent the generation of .class files for any class definition inside the file.
The final bit of useful information is that as you found out the scala Worksheets are not sandboxed, and what you define in the worksheets affects your project's code (rather than only having the project's code affecting the worksheet). So a duplicate package clause in a worksheet could very well cause the error you got.
If package names conflict, there might be a custom error message for that. See if specifying the full path resolves the issue by starting from __root__. Ex. import __root__.com.foo.bar._
i'm looking for a way to import an existing xpo-export via command-line into ax2009 aot and afterwards compile just this imported xpo. google tells me how to compile the whole aot by commandline, which takes quite long.
so is there a way to import an xpo ( shared project ) and compile just these objects?
what possibilities are available, if the objects which should be imported are version-controlled by ax and are checked-in?
hoping for an easy way to automate optionally check-out, import, avoid overwrite?-questions, compile and run ;)
thanks in advance!
You can make you own startup command:
Make a new class and extend SysStartupCmd
Change the construct method of SysStartupCmd to call you class.
Do whatever you need, this includes parsing the parm variable.
Also you will have to deal with version control by calling checkin/checkout in your code, handling compile errors etc.
There are no easy way, this is complicated stuff.
Over the last two years I have introduced and refined a command line process for deploying XPOs to AX 4.0 with great success. The class SysAutoRun is key as mentioned above. The following is a brief explanation of the resulting process:
Developers export AX objects from the AOT to a corresponding folder(layer) i.e. CUS, VAR, etc... for the most part the file name is the default file name set by AX.
Developers commit using SVN in this scenario. This would have to be evaluted to meet your needs.
Console application for the build process reads all file names from each directory(layer) and creates corresponding AX project definition files.
Console application reads all file names from each directory (again) and creates an import definition file for each corresponding layer(folder). The project definition created above is also instructed to be imported after all other objects are loaded and finally compiled. The import definition contains some specialized elements that are recognized by the SysAutoRun.execCommand(XmlNode _command) method.
A call is made to ax32.exe "config.axc" -StartupCmd=AUTORUN_ImportDefinitionMentionedAbove.xml -lazyclassloading -lazytableloading -nocompileonimport -internal=noModalBoxes
AX parses this import definition file invoking customizations as instructed. Logging is added to the process for outputting compilation results to an XML log file. Finally step 3's project definition file is compiled.
Console application validates the outputted XML log and handles appropriately.
Step 5-7 is repeated for each (folder)layer.
I understand this is very vague. The intent of this post is to get feedback on interest before I invest more time on describing the process. The import definition file is probably of most interest as it is responsible for loading the objects in the right order, synchronizing the ORM, compiling, repeating, etc...
Thanks M#