I've created a tiny project [0] to reproduce an error in a controlled environment. The facts, I'm using jenkins to build my project, a big one, I'd like to make some parallel builds. Let me make it graphically
[MyBasicPackage] -----> [MyPackageTester] ------> [MyBasicApp]
.
.
+-----> [...]
+-----> [...]
this is the organization I've made on [0], I have a class TMyUnit (MyBasicPackage) registered on spring container to be tested. I build it and generate its .dcu, .bpl, and so on.
The second stage I build my MyPackageTester that requires MyBasicPackage. Finally I build the app that requires MyPackageTester. So far so good.
When I try to build my MyBasicPackage on, say PC-00, get the artifacts and try to build the the MyPackageTester on PC-06 (same arch, same OS, same IDE, same spring4d version), and a nice error arise:
Unit TMyUnit was compiled with a different version of Spring.Container.Registration
so, I update my spring4d on both machines (PC-00 and PC-06) and build them. Run... and same error arise.
check the library path options (C:\Program Files (x86)\Embarcadero\Studio\14.0\Componentes\spring4d\Library\DelphiXE6\Win32\Debug), delete dcu files and build them once again on both machines, same error.
copy dcu files from PC-00 to PC-06 to avoid any kind of system configuration and the same error arise.
Probably I'm trying to do something that's not possible so far. I've googled a couple of days without luck.
Any ideas?
Please feel free to fork or pull request the example ;)
Regards
[0] https://github.com/graguirre/DelphiDepencyExample
In your case you need to build with the Spring.Core runtime package. Not only will that prevent this error but your code will actually work.
If you do not then all modules will hold their own version of the GlobalContainer instance you are using and nothing will work.
Maybe one solution is put all your libraries in a centralized repository and pull them to compile your projects. It should resolve the different version error.
Related
I'm trying to figure out how to properly setup an ejabberd project that allows for easy compilation of custom beam files- so far, we've been using an existing project that is cumbersome to manage, and uses erlide as the IDE.
I would like to set up the project in a way that I can use a more helpful IDE like vscode, and somehow streamline the compiling and copying of the beam files and updating the module on the server.
Writing code in Elixir is fine as well- I just want the project to be set up in a way that is dev friendly.
Apologies if the question is too broad, but I'm not exactly sure how else to best phrase it. If you feel like I'm missing something in my current flow, please let me know, as I've basically inherited this project. If there are any clarifications required, let me know as well.
Thanks.
easy compilation of custom beam files
somehow streamline the compiling and copying of the beam files and updating the module on the server.
If the task is about compiling and loading additional modules, a running ejabberd node can compile, load and start additional modules in runtime, see
https://docs.ejabberd.im/developer/extending-ejabberd/modules/#ejabberd-contrib
Usually the modules come from
https://github.com/processone/ejabberd-contrib
but you can tell ejabberd to download other modules from other git repositories, or you can copy modules source code and tell ejabberd to install them. And those modules can be written in Erlang or Elixir. Full example: https://docs.ejabberd.im/developer/extending-ejabberd/elixir/#elixir-module-in-ejabberd-contrib
Basically:
you write the module in your development machine, test it...
when happy with the source code, copy mod_whatever.erl to the production machine, $HOME/.ejabberd-modules/sources/mod_whatever as explained in the example mentioned earlier
run ejabberdctl module_install mod_whatever
In step 2, instead of copying the source code yourself, you can have a git repository just for your module, tell ejabberd the module's git URL, similarly to https://github.com/processone/ejabberd-contrib/tree/master/extra
BTW, for step 3, starting in ejabberd 22.10, there's a page in ejabberd webadmin to install and uninstall those modules (copying the files requires manual administration of course).
I would like to set up the project in a way that I can use a more helpful IDE like vscode
What a coincidence, these days I'm playing with VSCode variants (VSCode, VSCodium, Coder's code-server and Github Codespaces) and how to develop ejabberd using them. This is useful for step 1 that I mentioned earlier (write module and test it). If you are interested in ejabberd + VSCode, tell me.
I have looked at many other posts related to this issue and have tried each solution. None have worked in my case, including copying over the makevars from Rcpp. Anyhow, when building on Travis I get the following error
undefined symbol: dpotrf_’
The interesting note is that the package installs fine on windows, macOS, and linux.
here is my repo R package
I can reproduce the failure on a very standard Debian testing system (which I use for the extensive reverse dependency checks on Rcpp and RcppArmadillo).
After installing packages bain and BFpack (I had the rest) I attempted to build the tar.gz from your pristine just-checked-out sources. And I get:
*** installing help indices
*** copying figures
** building package indices
** testing if installed package can be loaded from temporary location
Error: package or namespace load failed for ‘BGGM’ in dyn.load(file, DLLpath = DLLpath, ...):
unable to load shared object '/tmp/Rinst106c6ed5251a/00LOCK-BGGM/00new/BGGM/libs/BGGM.so':
/tmp/Rinst106c6ed5251a/00LOCK-BGGM/00new/BGGM/libs/BGGM.so: undefined symbol: dpotrf_
Error: loading failed
Execution halted
ERROR: loading failed
* removing ‘/tmp/Rinst106c6ed5251a/BGGM’
-----------------------------------
ERROR: package installation failed
This appears to be a moderately complex and large enough package so please pardon me for not diving in and debugging. I would suggest you simplify with smaller mock packages to see what may be wrong. (dpotrf is a fairly standard LAPACK routine so something somewhere calls it. Maybe you call it explicitly. Maybe you did a Fortran-to-C mapping wrong. Maybe you have something wrong in how you interface with RcppArmadillo. Hard to tell...)
Edit: You committed compiled code and a Windows library. "Don't do that." When Travis builds it also starts from a git checkout as I did. That may be the difference.
Edit 2: It wasn't, but your R code mixes .Call() with generated entry points (ie via RcppExports.cpp and RcppExports.R). I have seen that blow up for other people. That may be something to look into.
Disclaimer: I work with D_Williams, but I figured out the problem, and others may find it useful.
A functioning configure.ac was present, and a Makevars.in is present.
The problem is that the configure file was not yet generated. This is an autotools/autoconf setup. To resolve it, I ran autoconf in the package directory, which generated the configure file. That configure file is then executed when R builds the package. The configure file modifies the Makevars.in and creates Makevars. That Makevars file ultimately defines where to find libraries, includes, compilers, compiler options, etc.
If you do not generate the configure file from configure.ac using autoconf, then there is no configure file to be executed, and no Makevars to define the needed options at compile time. Therefore, the compiler is not fully configured, and it will fail.
TLDR: If you have an configure.ac, you must run autoconf on it, and commit that configure file to your repo. R needs to execute it to have a functioning Makevars.
So, I am working on an embedded project for a cortex m7 microcontroller (ATSAME70Q21). The code is written in Atmel Studio 7, but I want to build it in a Debian environment through Docker (gcc docker image is Debian-buster based if I'm not mistaken) so that I can work in a Continuous Integration workflow.
At the moment I am trying to manually construct a Makefile, based on the generated makefile by the IDE, but that seems like the wrong way to handle this problem. Maybe I am too tunnel-visioned to notice different solutions. So I would like some help from folks who maybe have struggled with this problem before.
Thanks in advance.
I solved this problem the following way by mimicking the output of Atmelstudio into a CMakeLists file.
First I analyzed the generated makefile from the debug build to discover what files were built, what compiler flags were used and what programs were called.
Then I compared the generated makefile from the release build with the debug build to discover the differences.
With this information, I made a CMake file. For now, I GLOB_RECURSE all my source files, but I could crawl the Atmelstudio *.cproj file to find out what files are required.
This might not be the ideal answer, but it solves my problem.
We want to have the same VSCode settings for the whole crew of developers. Also it would be fine to have a oneline command to tear VSCode down and restart it from scratch with predefined settings and plugins so that you do not have to worry about trying out plugins and getting beck to the known state. Kind of Config-as-Code for VSCode.
I already found:
https://code.visualstudio.com/docs/editor/extension-gallery#_command-line-extension-management
https://github.com/microsoft/vscode-dev-containers
https://marketplace.visualstudio.com/items?itemName=Shan.code-settings-sync&ssr=false#qna
https://github.com/gantsign/ansible-role-visual-studio-code-extensions
https://code.visualstudio.com/docs/remote/containers
https://github.com/gantsign/ansible-role-visual-studio-code
But non of these provides a good solution to me
We are using Mac and Windows machines and develop most of the time locally (not remotely in the cloud or the like).
I imagine like having a script like
.... projectname up
or
.... projectname reset
(or
.... projectname down)
to receive/reset the configured settings and newest plugins that have been configured for the project.
Have any ideas or use a similar solution already?
After doing a lot of research, playing with Docker, Ansible and so on... it seems that although I excluded it at first the plugin Settings Sync Plugin from Shan Khan is the way to go. It has round about 1 million installs!
Only dependency - you need a GitHub account to host your configs. That is what held me back at first - but it should be not that much of a problem to get one for everyone in the team and connect it to like a company-github-account.
Copy the files settings.json and keybindings.json to your target machine(s) to copy the settings. You can find those files here:
Win: ~\AppData\Roaming\Code\User
Mac: ~/Library/Application Support/Code/User/
Linux: ~/.config/Code/User
You can copy extentions from ~/.vscode/extensions or C:\Users\username\.vscode\extensions from linux/mac or windows respectively.
FalcoGer's answer should explain how to copy the files in a way VS Code will pick them up. If you only need to copy the config files once, this solution would be fine.
If you need to "sync" these config files on a regular basis, I would advise to create a Git repository where all config files will be stored.
When cloning the repo to local machines, you can symlink the files to the config destinations (see FalcoGer's anwser). Then when you need to "sync", you only have to run git pull and restart VS Code to apply the changes.
For your other script-related question, you could create a CLI for this. Python would be the most friendly way to do this. You can find an example here.
I'm trying to clean start karaf on Windows using clean option.
It does delete data directory with bundles cache but it copy new bundles into data directory from system directory not local maven repository. But system directory has stale jars in comparison to local maven repository which cause karaf to start with stale bundles.
Is this a 'feature' of clean option? Am I missing something? How could I start Karaf with latest code from maven repo not dealing with file system?
You can't as the system directory is per default the one to use.
The clean does mean to clear up bundles in a awkward state and is only rarely used. Sometimes this happens if you start and stop the karaf container very close to each other then bundle might be in an incomplete state and since those bundle state is kept only a clean will help. Another way of cleaning is to delete the data folder.
So what you look like to be intending is to update certain bundles that are installed from the systems folder. For that you need to install the never version cause Karaf nows which versions are in the systems folder, those bundles are defined in the framework feature which is the basic feature to be used by Karaf itself.
If you have your own bundles in the system folder there is no way of updating those as those are regarded to be bootfeatures. In case you want to update those you'll need to make sure those features aren't boot features anymore and after that just do install the never versions of your bundles and uninstall the older ones. This can be done with the command shell.
One side note, it's usually best to ask those questions on the users mailinglist of Karaf, you get more people to answer your questions there.