|
Not only is this not the right forum, it's not the right site. If you are looking for someone to write code for you, try rentacoder.
This space for rent
|
|
|
|
|
When you get stuck on a specific part of the code then come back and ask and we'll gladly help you through it; but no, no one is going to write all this code for you.
There are two kinds of people in the world: those who can extrapolate from incomplete data.
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
Hello all,
I have just moved from Windows environment to Linux, and have been asked to update a project - still learning but tips would be helpful!
I have a directory structure:
RootMakefile.mk
.
.--\GUI1 (Folder)
. |
--dataprep(Folder)
. ---makefile1.mk
--config(Folder)
.--\GUI2 (Folder)
. |
--dataprep(Folder)
....makefile2.mk
--config(Folder)
.
.---\GUI(n) (Folder)
|
--dataprep(Folder)
....makefile(n).mk
--config(Folder)
makefile1.mk...makefile(n).mk are similar with just the variables within changing the paths, and the task is to move all makefiles to the root so they don't need to updated each time a new GUI is added to the project.
I changed the root makefile as following:
GUI_PATH := $(wildcard GUI*/)
TARGET_FILE := GuiDetails.rb
ACTIVE_GUIS := $(filter %, $(wildcard SMA*/$(TARGET_FILE)))
GUIS_OF_INTEREST := $(filter %, $(dir $(ACTIVE_GUIS)))
DATAPREP_FOLDER := dataprep
CONFIG_FOLDER := config
DATAPREP_PATHS := $(foreach GUIS_OF_INTEREST,$(GUIS_OF_INTEREST), $(GUIS_OF_INTEREST)$(DATAPREP_FOLDER))
CONFIG_PATHS := $(foreach GUIS_OF_INTEREST,$(GUIS_OF_INTEREST), $(GUIS_OF_INTEREST)$(CONFIG_FOLDER))
Now I seem to have all the folders that containing the Target file and so the makefile(1)...makefile(n), tried this to make sure:
test:
$(warning The following paths have guis $(GUIS_OF_INTEREST))
$(warning The following gui paths have dataprep $(foreach GUIS_OF_INTEREST, $(GUIS_OF_INTEREST), $(GUIS_OF_INTEREST)$(DATAPREP_FOLDER)))
$(warning The following gui paths have config $(foreach GUIS_OF_INTEREST, $(GUIS_OF_INTEREST), $(GUIS_OF_INTEREST)$(CONFIG_FOLDER)))
Is there a way now to move the makefiles within the folders to the root, and change the path variables dynamically so the guis can be generated for all different folders from a single makefile?
examples are:
(Within .\GUI1):
$(call DEF_RULES,GUI1,nodll)
$(call INCL,dataprep)
(Within .\GUI1\dataprep\):
GUI1_ALL:=$(call CANONICAL_PATH,$(GUI1_CONFIG)/GUI1_generated.txt)
GUI1_GWM:=$(call CANONICAL_PATH,$(GUI1_CONFIG)/gwm.xml)
GUI1_SSH:=$(call CANONICAL_PATH,$(GUI1_CONFIG)/ssh.xml)
GUI1_SSH_SUB:=$(call CANONICAL_PATH,$(GUI1_CONFIG)/ssh_sub.xml)
GUI1_SSH_APPROACH:=$(call CANONICAL_PATH,$(GUI1_CONFIG)/ssh_approach.xml)
This would be helpful as new GUIs are added and all the variables in the nested makefile don't have to updated with the new GUI path. The number of GUIs will increase as the project progresses.
Thanks in advance! I know this might sound really novice, but this is the first time I have had to use makefile and really would appreciate the help!
|
|
|
|
|
|
Thanks! It was not my intention, the original post was sent to the spam folder:
Your message 'Make a general makefile at root to search subdirectories and pick the path variables' has been marked as potentially being spam and is currently in the moderation queue pending approval.
That's why I reposted it.
|
|
|
|
|
It hadn't "gone to the spam folder" - it was in a queue to be reviewed. I think it was me that actually cleared it to be posted. Just be patient ... we're all volunteers here. Don't take it personally by the way ... we have been hit very hard with spam in the past and the filters are still learning... which is why there is always a human asked to check 
|
|
|
|
|
Thanks CHill60! Appreciate the effort! 
Will keep in mind to wait before reposting!
|
|
|
|
|
We used TFS 2015 in our company. There were many branches in our project and we made separate build definition for every branch. So, we had quite a large number of build definitions. It was not good and we made one build definition for several branches. We could specify which branch to work with when starting a build.
For downloading source files we used "DownloadFiles" activity from:
clr-namespace:Microsoft.TeamFoundation.Build.Workflow.Activities;assembly=Microsoft.TeamFoundation.Build.Workflow
It worked fine. Until we moved to TFS 2017.
Downloading files began taking twice as much time from that moment. If it had taken 10 minutes before it began to take 20 minutes then.
Build definitions which continue to use "TfsBuild" activity work fine and quickly. Although "DownloadFiles" and "TfsBuild" have the same internal logic for downloading files. Only "DownloadFiles" activity works slowly. Nothing changed in build definitions. Only TFS version.
Any ideas what can be the reason of downloading files running slowly?
Thanks.
|
|
|
|
|
Hi! Sorry for a simple question but I know nothing and have to create a table that I will put on my site in wordpress. I don't want a simple table like from excel. is there any good tool? I read somewhere that coding is needed but I know nothing about coding. thank you for your help.
|
|
|
|
|
You haven't explained what you want, if not a table like that from Excel.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
|
I don't want a "simple table like from Excel" ... ?
You can "style" Excel sheets / tables any way you want. There are also "thousands" of templates available.
You can then "save as" HTML.
That is "simple"; beyond that, you can have Excel generate tabs; navigation; etc.
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
We need more info. Do you mean a table in a database that will store information? Or do you mean a table of information printed out on a web page?
If you mean the latter, then yes, WordPress has tools to add images, tables, fields, etc. It is where you create your pages. I don't have access so I can't walk you through it but it should be pretty easy to find.
There are two kinds of people in the world: those who can extrapolate from incomplete data.
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
I thinks that unity containers should check child containers instead of the parent container.
That way, during registration after the manager registers global modules, it can pass a child container to every module to register it's services.
Then resolution can then be done using the parent container after it's wrapped in an IServiceLocator.
What do you think?
The only way of discovering the limits of the possible is to venture a little way past them into the impossible.
|
|
|
|
|
Why would you be wrapping the parent container in a service locator? You're providing IoC and then subverting it by using service location.
This space for rent
|
|
|
|
|
'Cause in resolution you don't want modules changing other modules services.
The only way of discovering the limits of the possible is to venture a little way past them into the impossible.
|
|
|
|
|
I wasn't talking about the child container part - I got that. It was the use of the service locator I was questioning.
This space for rent
|
|
|
|
|
IServiceLocator does not have a RegisterService(). So all modules will be able to use the services registered on the parent container (and child containers) without being able to block the configuration of child containers by adding services to the parent.
The only way of discovering the limits of the possible is to venture a little way past them into the impossible.
|
|
|
|
|
Nope, sorry - that didn't make much sense to me. Could you put a practical example here highlighting what you're trying to solve. BTW - don't forget - just because you have registered a child container in your module, this doesn't mean that the parent IUnityContainer is no longer available.
This space for rent
|
|
|
|
|
OK!
// Registration phase
1. Manager creates a container and registers modules.
2. Manager passes a child container to every module to registers it's services.
3. Module1 register LegitLogger as ILogger.
// Resolution
4. Manager passes root container to every module to able to find services added by other modules (on child containers).
Without IServiceLocator wrap, Module2 can register DummyLogger as ILoger on the root container so that LegitLogger will never be found (child containers will not be searched).
The only way of discovering the limits of the possible is to venture a little way past them into the impossible.
|
|
|
|
|
I'm a touch confused as to why you think you need to pass the child container in. Remember that unity looks for modules that implement IModule - so, create a base module class that takes the parent container and creates a child container internally. Something like this:
public abstract class ModuleBase : IModule
{
public IUnityContainer ParentContainer { get; private set; }
public ModuleBase(IUnityContainer container)
{
ParentContainer = container;
Container = container.CreateChildContainer();
}
}With that, you have a segregated module architecture that will allow you to set up the interfaces how you like. I would tend to create a fluent architecture here to simplify the registration in here, but that's just me.
This space for rent
|
|
|
|
|
In that setup the following code is possible:
public class DefectiveModuel : IModule
{
public DefectiveModuel(IUnityContainer container)
{
}
}
The setup I'm going for is more like:
public interface IModule
{
void RegisterServices(IUnityContainer container);
void Init(IUnityContainer container);
}
public class Manager
{
public void Init(IUnityContainer root)
{
Modules.Foreach(m => m.RegisterServices(root.CreateChildContainer()));
Modules.Foreach(m => m.Init(root.Wrap()));
}
}
So modules will only be able to configure there child container.
However, they will be able to use the root container to access services added by other modules on child containers under root.
The only way of discovering the limits of the possible is to venture a little way past them into the impossible.
modified 15-Feb-17 10:50am.
|
|
|
|
|
Unfortunately, because the parent container is still available to you, there's nothing stopping the inner services from trashing the root container - all they need to do is get the Parent from your IUnityContainer; you're not going to be able to prevent that.
This space for rent
|
|
|
|
|
 Just noticed.
Edit: However, It's still hard to predict the order in which the modules will be called.
Edit2: If there was an IServiceRegister interface. Then we could use it to wrap the container during registration.
"The only way of discovering the limits of the possible is to venture a little way past them into the impossible" Arthur C. Clarke
-- modified 15-Feb-17 12:07pm.
|
|
|
|
|
I have handled this, in the past, by hiding the module registration. This works by putting a proxy registrar in place and then exposing this through the module registration instead. At some point, I'll put out an article describing how I did this (part of the idea behind this is that this approach makes it easier to swap IoC containers around).
This space for rent
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
