Installing gulp-imagemin on Windows creates well over 10,000 files - gulp

I have installed gulp-imagemin on my Windows 7 laptop using
npm install --save-dev gulp-imagemin
and after a lengthy process ended up with a folder with well over 10,000 files and some very deep folder structures. Has anyone else seen this? Is it likely to be correct or would I be right in suspecting an issue?

Yes it is correct. I've installed it too on my Windows machine and I saw the same thing as you describe here.
The reason it has over 10,000 files and an even more lengthier directory structure is the nature of node modules.
Each and every node module is self containing and has a sub directory node_modules with all it's dependencies. Those dependencies have dependencies as well, resulting in a very deep directory structure.
When I try to remove gulp-imagemin, Windows is even complaining that the directory structure is too large and that it cannot remove certain files. This is because of the MAX_PATH length of 260 characters; see msdn.microsoft.com.
Nevertheless I really, really like this node module and I'm using it in every front end project I work on. Sometimes it takes 2 tries to install it, but I think it's definitely worth it.
On GitHub I have a starter application for working with single page applications; skeletonSPA in which I use it too.

Related

Re-using Caffe files after building it

I succesfully builded Caffe on Windows 10 by following https://github.com/BVLC/caffe/tree/windows.
Then, after copying C:\Projects\caffe\python\caffe folder to my Python site_packages folder, I can use "import caffe" in Python.
My question is that if I want to use Caffe on other computers without building Caffe from the beginning, do I just need to copy the files in C:\Projects\caffe\python\caffe folder to the other computers' site_packages folder?
Actually, I am not familiar with 'build' and 'compile' and I don't know what 'build' is doing during the Caffe installation.
You can do the copy provided that the destination computer uses the same support libraries (for software linkage to your Python and Caffe) and has bit-compatible hardware (to support the binary code).
I do this regularly, within a controlled cluster. All the nodes have the same OS configuration. I build on one node, and then copy the entire directory to the same place on the other nodes. Then I run multi-node applications on the result.
If you switch to a different core processor, or a different OS implementation, your attempts to use the result will likely crash. I've tried that one, too. :-)

Can't get JRuby to work on AIX machine

I looked everywhere and I can't find any help on how to get JRuby to work on AIX. I tried unpacking the binary package, tried using the jruby-complete.jar but I stumble on the same problems.
All errors seem to occur because JRuby is looking in the wrong directories for lib files.
For instance, I set my GEM_PATH=/home/dev999/install_tmp/gem and then I try to require activerecord-jdbc-adapter, which is installed under ./gem/gems/activerecord-jdbc-adapter-1.3.12, but for some reason JRuby keeps looking for the gem under ./gem/gems/activemodel-4.1.8/lib as shown below.
dev-host:/home/dev999/install_tmp$ jruby -e "require 'activerecord-jdbc-adapter'"
Errno::ENOENT: ENOENT - /home/dev999/install_tmp/gem/gems/activemodel-4.1.8/lib/activerecord-jdbc-adapter
file? at org/jruby/RubyFileTest.java:131
contains_requirable_file? at /usr/local/jruby-1.7.16.1/lib/ruby/shared/rubygems/basic_specification.rb:46
any? at org/jruby/RubyEnumerable.java:1473
contains_requirable_file? at /usr/local/jruby-1.7.16.1/lib/ruby/shared/rubygems/basic_specification.rb:46
any? at org/jruby/RubyEnumerable.java:1473
contains_requirable_file? at /usr/local/jruby-1.7.16.1/lib/ruby/shared/rubygems/basic_specification.rb:44
find_inactive_by_path at /usr/local/jruby-1.7.16.1/lib/ruby/shared/rubygems/specification.rb:898
find at org/jruby/RubyEnumerable.java:592
find_inactive_by_path at /usr/local/jruby-1.7.16.1/lib/ruby/shared/rubygems/specification.rb:897
try_activate at /usr/local/jruby-1.7.16.1/lib/ruby/shared/rubygems.rb:183
require at /usr/local/jruby-1.7.16.1/lib/ruby/shared/rubygems/core_ext/kernel_require.rb:132
(root) at -e:1
Any insights on what may be causing this are greatly appreciated.
EDIT: The server is an AIX 64 bits; we tried Java 1.6 and 1.7 both 64 and 32 bits (IBM custom build for AIX) but we ended up sticking with 1.7 64 bits in the final solution, although the version doesn't seem to affect the issues found in the Ruby 1.7.9 installation, but since we couldn't get JRuby 1.7.16 to work, I can't be sure if the Java builds we used could have played part in the problem.
OK, so the server admin and I spent two days trying to figure these things out and I can finally summarize the solution we ended up with to get JRuby working on AIX_64.
1 . First and most important of all, I had to install JRuby 1.7.9 since the 1.7.16 stable version from the main download page in jruby.org has many (seemingly AIX specific) bugs that we could not figure out; for instance, the wrong gem path resolution shown in my original question. Version 1.7.9 sorts out most of the issues automatically;
2) For some weird reason that I'm still unable to figure out, jirb won't work with the jline-2.11.jar lib that comes with the downloaded JRuby package. At some point I got it to work but then I could not retrace my steps so I gave up. To sort this issue out I downloaded jline-1.0.jar and replaced the jline jar located under <jruby_path>/lib/ruby/shared/readline/jline-2.11.jar; please note that even if we are replacing this with jline-1.0, the jar file name must still be the same i.e. jline-2.11.jar otherwise jirb will complain about a missing lib;
3) Some common steps: add jruby/bin to $PATH; make sure which java shows the correct Java version you want to use; set $JAVA_HOME;
4) (Optional, but very useful) in order to avoid having to grant my user write access to the /usr/<jruby>/<gem_paths> directories but still allow me to install gems without having to ask the admin I added export GEM_PATH=~/.gem to my .profile, then mkdir ~/.gem. To install gems to my home directory I do jgem install <gem_name> -i $GEM_PATH.
Hopefully this helps other users struggling with the same problems.
My main suggestion is to join the jruby mailing list and ask there. I've used jruby just once and managed to get it working. Here is a bit of magic that I don't really understand that I have at the top of one of the first files I require:
# We need the db2j.jar loaded
require 'db2j.jar'
# Some feaking magic Java needs
Java::JavaClass.for_name 'com.ibm.db2j.jdbc.DB2jDriver'
# The connection string is jdbc:db2j:the/path/to/the/file where the
# file is actually a directory.
CloudscapeDriver = 'jdbc:db2j'
You can see the email thread here: http://comments.gmane.org/gmane.comp.lang.jruby.user/17856
good luck

How to properly update Monogame with a Github PR

Heey,
I got a little problem. The current Monogame 3.2 build available hasn't got a working template for Windows Phone 8. This will result into a black screen and a non working app. So I went onto their git hub and found the issue https://github.com/mono/MonoGame/pull/2089 and someone who fixed it and posted a Pull request.
The problem now is I have close to zero experience with building my own version or editing project template files. I got some common knowledge and started to delve into this all and already tried copying the template files to my visual studio files and building projects and throwing around the new .DLL but it all doesn't want to work properly. I started to work with the older template but I need the new version due to proper support for landscape in windows phone 8 that we need to utilize for our game.
Now is my question if someone knows the right/proper way to do this. A short summing up from what to copy where will do.
Thanks in advance.
Okay it took me some time but I figured out what to copy,build,set and run.
You download the .Zip or make a pull with your Github into an empty folder and when finished extract it.
In the map open the MonoGame.Framework or MonoGame.Framework.”your
target platform” which will startup visual studio.
Build the solution/project (don’t forget to build in ARM, x86 and
x64 if enabled and needed) and navigate to “Extracted
folder”/MonoGame.Framework/bin/”your targeted platform” at the same
time open a new explorer and navigate to your MonoGame installation
by default C:\Program Files (x86)\MonoGame\v3.0
Navigate in your extracted folder to your targeted platform and
build and copy the MonoGame.Framework.dll to the opposing C:\Program
Files (x86)\MonoGame\v3.0\Assemblies\”targeted platform”\”build”
Rebuild your Project/Solution
Gratz you now updated your MonoGame :)
This could fix your problem but it’s possible that you still get an error when initializing your app on your phone or emulator DXGI related.
If this occurs then follow these steps. The problem lies probably by your SharpDX.WP8.dll how to fix this? In my case download and install the newest SharpDX http://sharpdx.org/download/ you could also look further how to only download the SharpDX.WP8.dll & .winmd!
Navigate to your SharpDX install (by default C:\Program Files
(x86)\SharpDX) navigate further to
Bin\DirectX11_1-“platform”-“build”\ and copy the SharpDX.WP8.dll and
.winmd to C:\Program Files
(x86)\MonoGame\v3.0\Assemblies\WindowsPhone\”build”
Rebuild your Project/Solution (if this still doesn't work you may
need to manually add the references again to SharpDX.WP8.winmd for
both builds)
So if it’s alright this should fix most issues but there is one left. Between MonoGame 3.0.x and 3.2 the project template of a windows phone game has changed but this didn't went well in the code. So we’re now going to update the project template of our Visual Studio.
Go back to your extracted Monogame map and head into the folder
“ProjectTemplates”\”your visual studio version”\WindowsPhone
Select all files and create a .Zip (could be done by the integrated
windows option “Send To”) make sure when you open the .Zip you will
immediately see all the files and they aren't nested into a folder
inside the .Zip
Navigate to C:\Users\”your PC name”\Documents\Visual Studio
201X\Templates\ProjectTemplates\Visual C#\MonoGame and copy your
just created .Zip and overwrite the existing file.
You may have to follow these steps if you use different version of Visual Studio because of the lack of support for XNA inside VS2013.
Now you should've fixed any possible problem. If your project still gives errors try to recreate a new one (this would now use the new updated template you just copy pasted and would work) If this still doesn't work than please post what goes wrong but this all should do! These instructions should also work for all other platforms (at least which you could build of course)
Pretty easy to do pull it in to your own version.
Follow these steps:
Fork the Monogame repository
Clone your version to your local machine
Find the repository of the fixed code.
In a command prompt, move to your MonoGame folder, and pull the changes in using this line on your machine. (the branch is most likely master)
git pull http://github.com/other/repo branch_name
Once you have the pull request pulled into your local branch, just build it using Visual Studio.
You can also follow these steps if you think you'll be doing this often.
https://help.github.com/articles/syncing-a-fork
For some reason MrME, I couldn't get your solution to work because of some missing SharpDX reference which REFUSED to be added manually. While your solution may be valid I would like to present an alternative if you have the patience to transfer the code to a Monogame 3.2 project and are still getting the black screen:
Set the DrawingSurface to a DrawingSurfaceBackgroundGrid in the GamePage.xaml. Full details are found in the commented explanation at the bottom of the GamePage.xaml file.
Source: https://github.com/mono/MonoGame/issues/2081

Can't get Lazarus to do.....anything?

So I thought I would install Lazarus/Free pascal -latest version from the sourceforge website.
Downloaded the win32 version and install on my XP machine couple of nights ago.
Problem is, it can't seem to find any of its own files.
From the first and every subsequent run it comes up with an error which says it can't find its system.ppu file relating to win32.
I just ignore that error and it seems to still run.
I tried to make a simple calculator application and it couldn't even seem to find the system files or files in the project directory. After battling these problems and setting every single path I could find in all the setups to every directory I could find it eventually compiled and run the program - once, not been able to make it do it again.
I also tried to make a user component library following the instructions on the web and that won't work either because, you guessed it, it can't the files. This time it gives an error saying it can't find a Ttreeview component, despite not even using that component in the library.
Being able to follow search paths is pretty fundamental stuff that they don't seem to have mastered.
Anybody managed to get a working system going, or any tips to sort these problems out?
Did you install in the default directory c:\lazarus? I thought there was an issue with installing to another directory, especially if the path contains spaces.
Nine times out of ten, its the old config of an earlier Lazarus attempt, that still lingers somewhere in the "local app" part of the profile.
If nothing else helps uninstall Lazarus, download Lazarus CodeTyphon edition, and run install as admin.

binary files in wix install package

I can't figure it out: do the files which are referenced in the Binary element of .wxs file get copied to the target machine, or are they resources of the install package?
They are definitely the resources of the install package. This means that they don't get installed to your application folder, but Windows Installer is supposed to extract it internally to some temporary location to address the functionality in it. And it is supposed to clean after itself. But this is definitely not visible to the end users of your installation.
At least, this is how I understand it.