I have successfully created my LSP using Xtext and have integrated it with Theia. As for the archived repo, I was referring to the theia-ide/theia-sprotty-example: https://github.com/theia-ide/theia-sprotty-example
The directory structure of my project is almost the same as the one listed here: https://github.com/theia-ide/theia-xtext
But am still a bit confused on where to begin.
First, should I add a .diagram project to my lsp, and if so, which specific files should I add? I understand that the yang-lsp repo contains some files that are specific to yang, but not sure which files are essential for integrating Sprotty.
Related
I have been using STM32G474, but if I look into the HAL driver folder structure I cannot find the files for LL-Drivers. I want to use LL functions in my code.
Looking forward to your quick suggestions.
BRs,
Waled
Folder Structure
STM32G4 Hal and Low layer drivers, UM2570
I found the file in the official STM32CubeG4 repo on github.
Either you have an older version of the code on your local copy, or the file got deleted somehow. You should be all good by getting the current version of the whole repo.
I am tasked with setup a Mercurial version control system for our small team of developers (2-3 person). There was no version control system before, just shared folders and multi-copies. I don't have much experience in setting version control system except for personal projects, just happened to be the most experienced person in term of version control system in our team. The code repository is in a shared folder in centre server, the top leve directory is client name, one level down is project name for that client.
The problems is I haven't figure out how to deal with binary files in our code repository. From what I read, the binary files shouldn't be version tracked. But as the code repository is centralized on the server, shouldn't the binary in here as well? Otherwise for things like image file, and third-party dll files, the project wouldn't build or run properly when cloned from centre server. Also there is a nice feature for Mercurial web interface where you can download the whole source package as ZIP or BZ2 compressed file, without necessary binary files, the download project wouldn't run or compile.
I guess the solution is including everything for the version control system except the temporary files and the files for debug purpose, but other than that, most binary files should be included? Due to limitation of version control system, I don't think there is a way for them to track changes sets only for binary files, so I guess we have to deal with it for a version control system.
Edit: After more research about how to setup version-control repository, the more recommended way of using version-control is to "store everything which is created manually, and nothing else", quote from Eric Sink.
You want to version control anything that you can't generate from other stuff in version control. That would be your source files, and your instances of third-party libraries, tools, etc. that your package relies on.
The binaries built from your project are something else entirely, and should be treated as different sorts of artifacts. If you want an easy-to-test downloadable archive, adapt your build process to provide that as a target: it should build the code, and then compress the source and built binary into the desired single file.
Binary files that are related or required by the project must be included in version-control, they can be tracked. The only thing that version control can't do with binary files is compare and merge.
I am looking for a step-by-step Mercurial guide for iPhone projects. Please assume:
hg already installed
the audience is comfortable with command line operations
everything is on OS X
As a newbie, I am particular interested in:
what files should be excluded
how to exclude above files
guideline/suggestion of naming builds
any relevant experience to share with
Please do not discuss how hg is better/worse than any other SCS. This is a how-to question, not a why question.
Thanks!
A more general exclusion tip that applies to all source-control systems is that it's really useful to set up Xcode to use a shared build directory somewhere away from the source code. I prefer to use /Users/Shared/builds/ but it could go anywhere. The nice thing is that you don't need to bother excluding build products from hg, and it makes it convenient to exclude them from backups as well.
You can set this up in Xcode's preferences, under "building".
Files you should exclude are: .DS_Store build *.mode1v3 *.pbxuser. You can also always ignore stuff from other SCSs like .git and .svn. I also ignore .LSOverride which is in some of my projects since I have multiple installs of the developer tools (for SDK betas) and sometimes want to override the standard launch service behavior.
These files can be ignored by listing them in a .hgignore file in the root of the working directory. The .hgignore file must be created manually. It is typically put under version control, so that the settings will propagate to other repositories with push and pull [1].
I have created a web part using VSeWSS 1.3. It creates a wsp file and my web part gets installed, everything works great.
I would like to also create a folder in the LAYOUTS directory of the 12 hive and place a couple files in there. How do I go about doing this? I know that I can manually place the files there, but I would prefer to have it all done in one fell swoop when I uses stsadm to install my solution.
Is there a best practices guide out there for using VSeWSS 1.3 to do this? They changed a bunch of stuff with this new version and I want to make sure I don't mess anything up.
You can create a new folder structure in your webpart project, like:
Templates/Layouts/CustomFolder and put your files in the CustomFolder directory and include them in your project.
When you go to the WSP View in Visual Studio, you can see in the manifest.xml that your files are being included in the deployment.
I have done this successfully on multiple projects now.
In case anyone is wondering, the VSeWSS 1.3 user guide is incredibly helpful. It is installed to the same directory as the tool itself, default in C:\Program Files\Microsoft SharePoint Developer Tools 9.0\VSeWSS13.CHM
You can see a working example with screenshots Here
A simple step-by-step tutorial for the above, along with deploy/retract scripts is here at Add New Files To 12-Hive Through A SharePoint Solution. Just follow the steps and in a few minutes you'll be able to add whatever you want to the 12-Hive!
Our development uses lots of open-source code and I'm trying to figure out what the best way to manage these external dependencies.
Our current configuration:
we are developing for both linux and windows
We use svn for our own code
external dependencies (boost, log4cpp, etc) are not stored in svn. Instead I put them under ./extern (or c:\extern on windows). I don't want to put them in our repository because I will not be able to update them that way. Some of these are constantly being updated.
My questions
What to do if I need to modify external code?
Currently I have created a folder in my svn repository called extern_hacks and that is where I put the modified external code. I then link (or copy on windows) the files into the external directory structure. This solution is problematic since it is hard to keep track of copying the files, and very hard to update from svn when files are sitting in two repositories (mine for the modified files, and the original repository say sourceforge)
How to manage versions of external dependencies?
I'm interested to hear how others deal with these issues. Thanks.
I keep them in svn, and manage them as vendor branches. Keeping them loose externally makes it very hard to go back to a previous build, or fix bugs in a previous build (especially if the bug is from a change to the external dependency)
Keeping them in svn has saved me lots of headache, and also allows you to get a new workstation able to work on your codebase quickly.
I do not understand why you say
I don't want to put them in our repository because I will not be able to update them that way. Some of these are constantly being updated.
You really need to
include external dependencies in your source control and periodically update them and then tese, test, test.
Coordinate your build process with the updates for the external dependencies.
If your code depends upon something, then you really need to have control over when it gets updated/modified. Coding in a space where these dependencies can get updated at any time is too painful as you're no doubt finding out. I personally prefer option 1.
When I had to do something like this, I added the external source as external, and then applied a patch to it. The patch contains my modifications to the external source. So, I actually only version control my patches. Most of the times this works, if there are no "dramatic" changes in the external code.
Have you considered Maven? It's a build system that has excellent support for managing dependencies. For each project you can specify the required dependencies in an xml file as part of that project. The external libraries are held in a dependency repository (in our case Artifactory) this is separate from your version control system and can just be a network drive. It also allows managing different versions of projects.
I would be careful considering Maven because:
it is another repository in a system where you already have a repository with your current version control system;
it (Maven) is based on the only "common version control" every developer have, the file system (which means no metadata, or properties attached to the file, no proper history in term of who modified what and when)
Now when dealing with third-parties, you can consider having them in your version control system, but in a packaged way: that is in a very compact way, with sources and documentations zipped, in order to have the least possible number of files.
That way, you will manage the deployment of those (many) third-party libraries easily since the number of files to deploy is low.
Plus, having them under source control allows you to make a branch (say, a 'hack' branch), in which you will stored the packaged (or zipped) version of the hacked library.
What you can store in an external way is the un-zipped, complete set of files representing those libraries since there is no real development on them, or just a punctual hack: normally, your job is not to develop existing libraries, but to use them (even a bit modified) for implementing faster some features of your project.
If you need at some point to compare some hacked version with some official version, you will just pull out from svn the appropriate 'hacked' version number, unzip-it and compare-it with the official (and externally stored) version (with winmerge for instance)