I did not have this problem 2 days ago, now it happens without me doing anything. I have my site.less file which includes bootstrap.less, and it takes 25s to load all the less files which is very annoying when developing
less: parsed http://localhost/css/dev/public.less successfully.
less: saving http://localhost/css/dev/public.less to cache.
less: css for http://localhost/css/dev/public.less generated in 26446ms
less: css generated in 26453ms
I was using Chrome and Firefox and both browsers have the same problem. I am not sure what is it.
So, to be clear, it looks like everything is local. but what isn't clear is what you're doing with the LESS and CSS. It's taking a while for the CSS to compile into LESS, but what are you using to compile? less.js?
So I'm assuming you're directly editing the LESS files and your goal is to have the LESS compile into CSS on the fly, and then you will use the CSS for production... right?
If my assumptions above were correct, don't use less.js during development the way you would if you were compiling LESS to CSS in the browser.
Use one of the solutions in this post: https://webmasters.stackexchange.com/questions/25289/is-there-a-way-to-compile-less-files-to-css-so-that-every-browser-doesnt-have
I figure out that I have changed the database (Redis) from localhost to a remote database. When I change it back to localhost, everything works as it is supposed to be. I am not sure how database connection can have anything to deal with less files.
Related
Within the last few updates to Aurelia I've noticed increasingly bad load times. I'm not talking about bundling load times, but dev load times on localhost. The Aurelia motto was that it would get out of your way and only be there if you needed it. With a ~10 second load time for my page, that's not getting out of my way. Simply making style changes to my site is a tediously slow process now.
I checked the skeleton navigation sample app to make sure this wasn't related specifically to my "custom" version and I got the same load times. 107 requests and an average of 9.5 seconds to load the page. How is this acceptable for even a dev environment?
Is there a way to bundle just the Aurelia code so it's "out of my way"? Again, this has only happened within the last few releases of Aurelia. I don't know which one specifically because it felt like such a gradual increase and only now am I noticing these long load times.
Edit
I did take note that these long load times started shortly after I updated Chrome and FireFox. I'm not sure if it's actually related, but I noticed big slowdowns after the update, specifically in Chrome (I use Chrome for the majority of my dev work).
For reference, here's the log. It seems there are two culprits taking up the majority of the time.
Everything evens out after that.
The results:
I am at my wits end. I've written a xul app and it runs fine if I open the .xul in firefox directly. But xulrunner doesn't cooperate at all. I can run my xul fine by using the -chrome flag for firefox and giving it an absolute path, but -app doesn't work on firefox either. I have all the files required (application.ini, chrome.manifest both in root and /chrome/ and tried with either missing as well) and their format has been checked and re-checked.
I was prepared to paste all my files here and link the code, but I've tried everything, including a boilerplate project from http://www.mozdev.org/projects/wizard/ (from the application wizard) which reacts the same way as my own project.
xulrunner returns no error message, nothing - it just stays there in the task manager, no cpu load, not loading anything to memory, inert.
I've tried other projects (https://github.com/matthewkastor/XULRunner-Examples - the periodic table works at least) but I can't get a single solid lead on why some projects run properly, while others just have xulrunner waiting and doing nothing. It also seems this is a rare problem because most people can at least run the boilerplate fine, even if their own projects don't initially run.
I don't think it's necessary to post my code at the moment since it behaves the same way as the boilerplate. Can anyone tell me possible reasons why xulrunner won't work with the boilerplate but will with the example project?
I'm running v25 on win xp sp2 and I have been searching and reading all day, so I'm pretty sure I've read everything related - thanks in advance; I hope 5 days of work won't be wasted :(
edit:
SOLUTION: I messed up and didn't notice that prefs.js was missing or empty. Even if you have no preferences in your app, prefs.js is needed to set up the environment and tell firefox or xulrunner where the xul file to start from is. Without this pointer it has no idea. Yes, the MDN article does state this and what it contains is accurate, this was a big mistake on my part, as it seems I subconsciously (or not?) ignored the prefs.js file because I had no need for preferences in my app.
tl;dr if your apps don't work but the example files do, check your prefs.js even if you don't use preferences.
Posting this to close this question, since it doesn't need further answering.
The fault was with me - the app required a valid prefs.js file which I hadn't created because I was under the impression it wasn't required unless you intended to have preferences in your app. The MDN (at least at the time) specified this.
I started to migrate a Ruby on Rails/Backbone.js app to production today and got a large number of new problems. One was the following CSS line:
#crops input[type=text, class=crop_selector] {
width:140px;
}
This was OK in development, but in production it isn't. On top of that, many of my images no longer appeared in the browser and I'm seeing no background colors. Could someone explain to me
1) what is wrong with the CSS?
2) what is so different about production? (perhaps point me to docs where I could read up on the differences)
EDIT on 1/24/13: someone helped me with the CSS error, so that is no longer a question. I still need to understand exactly what is different about production, when the switch is made. It is not just environment variables.
I'm trying to get DOH testing working for my company's upcoming platform, but I can't figure out the right combination of paths. Our file structure looks like this:
/dojo15
/release
/dojo
/dojo
dojo.js
dojoExt.js
/dojo
dojo.js
/util
/doh
/js
mainLib.js
/tests
base.js
This was created by our contractors, so unfortunately there are some things I have to figure out as I'm going along.
The "release" directory is what is used on our pages.
The "util" directory doesn't exist in our release directory. (I'd like to avoid having to make a copy of it there.)
I'm not entirely sure what they did with dojoExt.js there, but it seems to be required. I was able to make a simple "hello world" sort of test, but once I did dojo.require(js.mainLib), I got an error that dojo.behavior.add is not a method. So it seems to be they made a stripped-down dojo.js and put other required code in dojoExt.js.
My guess is that DOH is using the dojo in dojo15/dojo, but I need to include dojo15/release/dojo/dojo/dojoExt.js. I've tried every combination of dojoUrl, testModule, registerModulePath I can think of...also saw "boot" and "path" from other SE questions, even though I can't see in runner.html where they would even be used, but I tried throwing them in to see if they'd magically help anyway.
At the moment I don't really have the option to move code around, so I'm hoping to work this out with files where they currently are.
Did you try the bits I suggested over at a related question? We use the bits I detailed there to pull together a completely custom layout of dojo + util. Take a look at both boot and dojoUrl. I think it's runner.js that does most of the cunning stuff, rather than runner.html.
Is the problem that you can't arrange for dojoExt.js to get loaded? How does your other code arrange for it to get loaded? Is tests/base.js your test module?
Using the dojo toolkit, what is the proper way of locally testing code that will be executed as cross-domain, without making the actual build?
As it appears, there are three possible options (each, with their own drawbacks):
Using local (non xd) XMLHttpRequest dojo.require
This option does not really test the xd behavior, since it dojo.require[s] the js synchronously via XHR.
djConfig.debugAtAllCosts = true;
Although this option does load the required code asynchronously (via the 'script' tag), it also pulls the code in via XHR, parses the dojo.require[s] inside that, and pulls them in. This (using the loader_debug), again, is not what the loader_xd is doing. More info on this topic in a different question.
Creating a cross-domain build
This approach requires a build, which is not possible in the environment which I'm running the code in (We're using our own on-the-fly build process, which includes only the js that is necessary for a particular page. This process is not suitable for development).
Thus, my question: is there a way to use the loader_xd, which does not require an xd build (which adds the xd prefix / suffix to every file)?
The 2nd way (using the debugAtAllCosts) also makes me question the motivation for pre-parsing the dojo.require[s]. If the loader_xd will not (or rather can not) pre-parse, why is the method that was created for testing/debugging doing so?
peller has described the situation. If you wanted to just generate .xd.js file for your modules, you could look at util/buildscripts/jslib/buildUtilXd.js and its buildUtilXd.xdgen() function.
It would take a bit of work to make your own script, but you could look at util/buildscripts/build.js for pointers.
I am hoping in the future for Dojo (maybe Dojo 2.x timeframe) we can switch to a loader that just uses script tags with a module format that has a function wrapper around the module, something that is coded by the developer. This would allow the same module format to work in the local and xd cases.
I don't think there's any way to do XD loading without building and deploying it. Your analysis of the various options seems about right.
debugAtAllCosts is there specifically to solve a debugging problem, where most browsers, until recently, could not do anything intelligent with code brought in through eval. Still today, Firefox will report exception in the console as appearing at the eval site (bootstrap.js) with a line number offset from the eval, rather than from the actual eval buffer, and normally that eval buffer is anonymous. Firebug was the first debugger to jump through some hoops to enhance the debugging experience and permitted special metadata that Dojo's loader injects between the XHR and the eval to determine a filepath to the source. Webkit/Safari have recently implemented this also. I believe debugAtAllCosts pre-dates the XD loader.