I have problems compiling SASS on my Windows Environnement.
The website/files is on a mapped network drive, which causes horrible delay in compilation (more than 100 secs)
I use Grunt to compile the SASS files. I was using grunt-contrib-sass but recently switched to grunt-sass which uses libsass (c++) instead of Ruby/Gem
Even after switching from grunt-contrib-sass to grunt-sass, the compilation is slow.
I tried to compile directly with sass --watch src:dest but it's still slow.
I also tried several GUI (Koala, Scout, Prepos) but it's still slow.
I think the main issue is because I'm compiling files on the network drive.
Any ideas that could help speed it up? Maybe I should get a Mac...
If it makes you feel any better, I had the same problem on a Mac at a previous job. I think your best bet would be to actually compile on your local machine then use an automated tool to copy the new compiled file over to the appropriate place on the network drive. Since you're already using Grunt, grunt-multisync may provide a good workflow for you.
Related
I do have a strange behavior with a flutter package I am building. It uses FFI to integrate a custom-made c++ library.
When I run flutter run -d windows --release the code starts and I do have the window with the code running.
However, when I go to the directory where the executable is stored and I run it, the program starts but the library is not loaded. I do see also that when I run flutter test, it complains that it cannot load the library. I have checked that the dll's needed are there using dependenciesGUI.exe and it seems that everything is fine, at least on my side. I do see however that within kernel32.dll I am missing ext-ms-win-oobe-query-l1-1-0.dll.
I am using Visual Studio 2022 with the x64 configuration.
Any idea on what could be the issue? For me it is VERY puzzling to be able to run the software through flutter but not with the executable directly.
Thanks!
Yours,
Pi-r
EDIT:
I compared my package with a fresh package built with flutter. With a fresh package, the behavior is the one expected: I can have the program run normally or with flutter run.
I compared the libraries of the clean package with the ones linked in my package. They are the same (with the same missing dlls which do not seem to pose an issue).
I also checked that the exported functions I needed where present -> It is the case.
The only difference I can see is that using flutter run adds a series of libraries to the path. Has I am a Linux person, I do not know of a tool that could be used to detect what is the missing library. I am open to write a separated c++ code that would load the library if it could help me identify what is the issue... ANY tips/tricks would be greatly appreciated :)
I finally found the issue I had and it is related to a different behavior under Linux and under Windows (as you will guess, I am a Linux person).
When compiled under Linux, I can force the compiler to link multiple libraries relatively to my main library. I discovered that this is not the case under Windows. Either the dlls are in the executable folder or in the Path.
For the sake of code clarity, my package uses two different libraries. Library A, which is compiled from flutter with the ffi package, called library B. First the second library was in the asset folder and with the relative linking of Linux, it was working perfectly. But it did not work under Windows until I explicitly copied the two in the same directory of the executable.
The solution was then to ensure that both libraries are copied correctly in the directory of the flutter executable. This can be done easily if you add the dependent libraries to the bundle variable in the CMakeLists.txt of the package.
However, this doesn't work when you do the testing (flutter test). As the bundle mechanism seems to be not propagated to the test function. Therefore here, the only solution is to copy the dependent libraries to the root directory of the source code :vomiting_face:
I must point out that this is only the case under Windows, for Linux, it works out of the box...
My goal is to connect the open-source CBC solver with Pyomo in Spyder. I am working on a Windows 10 machine and it is not an option for me to use the NEOS server due to company policy.
I have downloaded the binaries from Bintray (https://bintray.com/coin-or/download/Cbc#files) that include a cbc.exe file. However when trying to run it, several errors come up stating that I am missing files (among other libbz2-1.dll and zlib1.dll). I do not know much about linux or software development but after a lot of time on google I understand that these are used for unpacking data among other things. I found all files except zlib1.dll in a developer chat on the same subject and zlib1.dll I found on another page. However when running I now get the error: “The application was unable to start correctly (0xc000007b).
I have also tried downloading MSYS2 MinGW and followed instructions from CBC. I don’t know if I require this or if it is only for developers.
Can anyone tell me what to do? I suspect other people than myself want to use CBC in Pyomo as an alternative to GLPK.
If you already have the .exe file, make sure it is in your current working folder (set as the working directory in Spyder, simply opening your file is not enough) and call it using the SolveFactory function:
opt = SolverFactory("cbc.exe")
results = opt.solve(model)
It works for me.
You will find some general information here where i outlined some approaches.
While this was targeted at Clp, it also applies to Cbc.
It's a bit strange as i observed too, that some libs are not statically linked (zlib) while it's certainly doable. But as mentioned in the thread, this should not be the case anymore (see the restriction about which files are fully statically linked) and therefore your observation is strange (and you did not say, which file you downloaded).
So i would trying one of the following (in this order):
Try again with your source, but stick to the master-versions (see first link) as the maintainer only guaranteed fully-static builds for those!
Use the builds from AMPL
(tested and works for me; generally recommended in terms of quality/stability of builds)
Use the builds from coin-or/pulp, another modelling-tool for python
(tested and works for me)
Compile from source using mingw64
(Use any build and provide some external dll of zlib and co -> hard to debug)
Of course i completely ignored other potential issues:
license-stuff (what's part of those builds)
not sure if a company can afford to use binaries not build themself in regards to legal stuff
version-compatibility with python
does every version of Cbc work
cbc version + configuration
modern version
compiled with multi-threading
...
I recently got upgraded from Go 1.8.4 to 1.9 without knowing it. Compilation speed wasn't affect (not noticed at least). But I had problem with tools like guru, so I uninstalled 1.9 and re-installed 1.8.4. Afterwards, go run foo.go becomes pretty slow. I'm suspecting that the older version of the compiler cannot use cache from 1.9 and had to recompile everything from scratch - I have no prove.
Is my suspicion correct? If so, is there a way I can reset the compiler cache?
Delete the folder $GOPATH\pkg. That is the package cache folder.
If you run the compiler with the -v flag it will list all the packages being compiled. If it keeps compiling the same packages that you have not changed then you know it is not using the cache.
In the past I have found that when compiling code with run/build the compiler does not cache packages, but it does cache them when using install.
I'm currently using Haxe, specifically haxeflixel for development. One thing that really bugs me is the build/compile time. I'm not even compiling to c++ target but decided to compile to neko vm as I thought it maybe faster. However; the compile time to neko debug (or release) is about 4 or 5 seconds. Having to wait this long every time I want to see a result makes it dreadfull :).
I even tried to debug with -v command and the parts that take the most time are:
Running command: BUILD
- Copying library file:
C:\HaxeToolkit\haxe\lib\lime/2,9,1/legacy/ndll/Windows/lime-legacy.ndll -> export/windows/neko/
bin/lime-legacy.ndll
- Running command: haxe export/windows/neko/haxe/release.hxml
From the above excerpt it seems like everything is behaving normally, which worries me because I do not want normal to be this slow.
Now 4 or 5 seconds might not seem a lot to some people but with the Golang, javascript , java and other super faster compiled languages out there - i'm spoiled.
Is there another target I can compile to that I dont know about which would be faster than neko vm compilation? Is there anything I can do to increase compile speed or further debug the cause of the compile slowness?
You can consider using the compilation server:
From a terminal, run haxe --wait 6000
In your hxml, add --connect 6000
This will make your build use the compilation server, which caches unchanged modules and compiles only changed modules. This will speed up your build.
Had a similar concern with running a large number of unit tests very quickly. Ended up building to JS and running the tests in node.
Pair that with gulp to build the code and process resources things can end up running pretty quick.
Codekit offers the ability to split static HTML files into designated partials using the include function and .kit files. More info: http://incident57.com/codekit/kit.php
The question is.. Using this file type works great for users that have CodeKit. But makes it so that anyone making HTML changes also needs a CodeKit license.
Is there anyway to compile these .kit partials without or outside of Codekit?
Even when the question is one year old:
For Windows User and Mac(CodeKit alternative App):
http://alphapixels.com/prepros/
For Linux, Mac and Windows (CLI):
Grunt:
https://www.npmjs.org/package/grunt-codekit
Gulp:
https://www.npmjs.com/package/gulp-codekit
I've spoken with Bryan (creator of CodeKit) and as of now there is no other way of compiling outside of CodeKit. There is also no server-side compiler (like with LESS) that can compile. So my advice would be to make no project rely on Kit unless you are sure it is going to someone who has CodeKit.