I'm trying to start a purescript project that uses the purescript signal and drawing libraries. When I try to bower install with both of them as dependencies, bower's interactive prompt asks to resolve several dependency versions. I admittedly pick the versions somewhat arbitrarily since most of the issues are several layers of dependencies deep. Then when I pulp build a basic hello world piece of code that doesn't even use the dependencies, pulp gives around 40 errors depending on which versions I selected.
How do I resolve these dependency versions correctly? Sifting through forty errors and all of the dependencies for both projects doesn't seem feasible. Is there some non-arbitrary way of picking the versions that will resolve the conflicts? From the choices it gave me, it didn't seem like there was any clear resolution. Or are their dependencies too conflicting and you just can't use them together?
This may actually be more of an question about bower, but it may also be something about purescript and pulp that I am just unaware of. They both seem like libraries that should be able to work together, and I can't imagine that other people are having too much difficulty using two or more libraries in a single project.
Purescript 0.10 has breaking changes. If you have the latest compiler, it's likely that it's not compatible with some libraries. From what I see, signal lib is updated but the drawing is not. You can update the lib and use your own version. Or, send a PR, Phil and purescript community in general, is really fast on responding to pull requests.
Another temporary solution is to use the old compiler (0.9) and wait a couple months till everything is back to normal.
also see 0.10 migration guide.
Related
I have an old MVC application I need to make changes to. It would be nice to update all the recommended NuGet packages, but I know from experience that this can break a project.
In particular, I'm troubled by the following:
If one reads this a certain way, it appears that it's actually suggesting I upgrade to Twitter Bootstrap 5.1.2. I know for a fact that numerous breaking changes have been implemented since my current version.
I prefer not to have to rewrite the site. I thought Updates might have been a little smarter. Do I really need to know each package well enough to know if it would include breaking changes? Is there no way to specify compatible updates? Did Microsoft consider this aspect?
You do need to know each package well enough. Why? Because there's not a single way of doing versioning. Some packages, probably a lot of packages even, follow Semantic Versioning, but there's nothing to stop anyone from using any versioning they want (even if it doesn't make sense). There's nothing preventing you from going 3.0.1 to 15.14.13 with a change in an unimportant .txt file.
It's your responsibility to know what to update and when. Look at this Q&A to see how you can restrict the versions suggested: NuGet Limit max major version of a package
For the development/testing of our CFD code I like to frequently switch between Clang (for its strictness/warnings) and GCC (for performance), but this requires some of its dependencies (like e.g. NetCDF) to be compiled with the same compiler.
I know that Homebrew has the option to install multiple versions of software side-by-side and switch between them, but is it possible to do something similar using the same software version, but compiled with different compilers (by setting HOMEBREW_CC and HOMEBREW_CXX)?
Something like (wishful thinking, after somehow installing NetCDF with both Clang and GCC):
brew switch netcdf 4.3.3-gcc
brew switch netcdf 4.3.3-clang
I think this is possible only if you explicitly have different version numbers like in the example you used "4.3.3-gcc" and "4.3.3-clang".
If the version number is identical then there is no difference in the builds and brew can't differentiate them.
Also I wouldn't do this.
By compiling the same library multiple different ways you now start going into a dependency nightmare.
Dependency conflicts. Because even if you swap out "netcdf", how do you know you swapped out all it's dependencies too? If they are not compiled with the same compiler bad things can happen, for example conflicts can arise due to the differences in how calls are made or due to options enabled in one compiler for both the app and it's dependencies that weren't enabled in another build.
I don't recommend doing this, it's too much of a hassle.
But, if you really need two builds (such as for testing) then I would build them to isolated folder trees outside of your system path and do any testing against them there. Brew is not the best way to address this issue, as this is a non-standard use-case.
I recently get to know grails and start to using it, I know that grails is a great language and it is very helpful for rapid development, but I cant understand why grails dont have a good backward compatibility, I use grails 2.3.8 and grails 2.4 for my projects but many of sample codes in the internet are 2.2 or less, and it isn't time efficient to convert them to 2.3.8 or 2.4 because there are many changes from one version to another. And some times although I do any things right and every thing must work like it works with grails 2.1 or 2.2 but some things still remains.
Am I wrong? I skipped some things that make converting version so hard?
And above all this, what are the guaranties that projects I'm developing right now will be compatible with higher versions of grails that comes in the future?
Joshua Moore is right with his answer, but I do not see it as passimistic as he does.
The grails development team is brave enough to make changes which break with the past. I consider this as a great feature - Grails does not ride dead horses.
For me, most of the changes don't seem to bee too radical. Most of the time, I skip 2-3 version and then upgrade my apps to the current stable version in less than a day. This also helps me to get to know the new features.
If you don't know how to upgrade, the safest way is to use the grails upgrade command. Just increase you version number step by step and do an upgrade and re-run your test (yes, tests help you in your upgrade process :-). If tests fail, take a look at the great changelogs and the "What new in Grails x.y?" sections of the documentation.
Often it is also helpful to compare your old grails version app with a new and empty target version project with a good comparison tool like BeyondCompare. This way you easily spot changed configurations.
Hope that helps
Update: When you are new to "all those webconcepts" you should first decide on the platform you want to work on. If it is the java ecosystem, Grails is the best webframework on the market :-) Otherwise PHP, Rails, DJango etc. could also be a match.
So if you want to learn Grails (and with Grails all those webconcepts), I would suggest to start reading the Guide which will tell you how Grails works. If you need more examples, I can suggest the "The Definitive Guide to Grails 2" published by Apress. It covers basically the same content as the guide, but it does so by walking you through a process of building a sample application.
When it comes to the samples you find on the net... as soon as you get to know the framework better, you will probaply know ho to handle the examples - but there is no silver bullet...
Nothing guaranties that your projects will be compatible with future versions of Grails. In fact, from my own experience, they won't. Often things change, and sometimes radically too, as Grails matures into higher versions.
The same holds true of backwards compatibility as well.
All you need do is take a look at the introduction section of the Grails documentation to see how often things change significantly between versions. A lot of times these changes require significant refactoring of older projects to upgrade them. I still have several large projects running on the 1.3.x branch of Grails because we don't have the resources (time) to go through and upgrade them.
Often this upgrade process involves creating a new empty project then slowly moving the code from the old project into the new project, updating code to reflect newer means of doing the same thing and testing. It's not easy for projects where you have 100+ Domain classes, 1000+ GSPs, 50+ Services and several hundred thousand lines of tests.
My Delphi installation has been going downhill for the past few months. It seems though that every so often when I build a release it has strange errors in it which are resolved if I build, then compile, then build, compile, etc.
I've talked to another developer who thinks that this is a compiler error. This sort of degrading performance over time has happened on other computers to us too.
What does stack overflow think could be the problem.
What I've seen most is a case where multiple versions of the same units/dcus exist in different folders/paths, and depending on almost insignificant variations the compiler/linker uses a different path and picks different versions of the units to build the exe.
I would make a huge Spring clean-up, scrutinize the lib/search paths, remove all dcus and make sure there is no duplicate versions of any unit.
And, agreed, reinstalling Delphi could help start with a clean state.
I agree with #François about the DCUs, but also want to point out an observation: sometimes it matters what was built prior to what you're building. i.e. if you have several projects that contain source code that results in various .dcu/bpl files being created in a common directory, but the project that you're concerned with doesn't explicitly call for them to be rebuilt, then you're going to end up with whatever is there. If you clear the dcus/dcps prior to building, and then find that your project doesn't build, then you are missing a uses/requires clause somewhere. Every project shoudl be able to build on a "clean slate", and not rely on leftover binaries.
That's not much to go on, but it sounds like a classic case of "bit rot". Too many things interacting in too many ways for too much time under a poorly-designed OS, leading to strange forms of data corruption.
First thing I'd do is uninstall Delphi and reinstall. If that doesn't work, try reinstalling Windows. (If it's been around long enough for this to be happening, you're probably due for an OS reinstall anyway.) And if that doesn't work, contact Embarcadero tech support.
I've a portal project built in Rails 1.2.3. I've finished it at end of 2006.
The project are using the following plug-ins:
acts_as_attachment
acts_as_ferret
betternestedset
simple_http_auth
I know all plug-ins (or dependencies) was changed today, or doesn't exists anymore. The DHH says: Don't overestimate the power of versions. But I'm worrying about this.
If I update the rails version, all things will gonna fail. I can change my application to work with new rails version. I think I can read what's now deprecated and change it. But now I need to support all dependencies by myself or change it to other dependencies (Eg: acts_as_attachment to atachment_fu or paperclip). What to say about tomorrow?
My doubt isn't only about Rails, it's about using dependencies to increase productivity. In other projects I've used pure Python code, or even pure Ruby code, or pure Php code. Today I can run it in latest versions of "language/environment" without (or few) changes.
These projects haven't external dependencies, it's just the application code. Maybe using some web framework just as skeleton, but not external projects.
What do you think about this?
When you use someone else's code you pay with your independence for the ready-baked solution for a problem. So it's up to you to decide in each case what's more important to you - build your own stuff and lose time on it now (probably - a lot of time), or use someone else's projects and get the job done right now, but keep tied to them or pay with your time for upgrade/migration later on.
You've said the project worked for you for three years already - and I think it's great, if you need to bring it up to date - it's natural that you have to invest some time to do it, three years is a long timeframe in this area.