I'm working on a project in C# .NET (Visual Studio 2010) with a number of generated partial classes, metadata classes, etc. (if you know Entity Framework, you know what I mean)
My question pertains to the practice of correlating namespaces with directories, whereby each directory denotes a sub-namespace.
Now, I'd like to move the metadata classes into a sub-directory, purely for organizational purposes. Since partial classes must exist within the same namespace, the Metadata sub-directory can no longer denote a namespace (otherwise it'd break the partial classes) I'd be departing from the aforementioned practice; not a big deal, but I like sticking to a standard.
Is there a convention to denote that a given directory is purely organizational?
Off-hand, prefixing the directory name with "." (dot) or "_" (underscore) seems appropriate, the former more than the latter since it would result in an invalid namespace name.
#Pheonixblade9, something like this:
:
|
+- ProjectFolder/
| +- App.config
| +- Packages.config
| +- ClassA.cs
| +- ClassB.cs
| +- ClassC.cs
| +- ClassD.cs
| +- Metadata/
| | +- ClassA.Metadata.cs \
| | +- ClassB.Metadata.cs \ These are the partial classes that shouldn't
| | +- ClassC.Metadata.cs / be namespaced differently than their respective
| | +- ClassD.Metadata.cs / partials in the parent folder
: :
Select the folder in solution explorer
In properties set NameSpace Provider to false
Despite #JohanLarsson providing the correct answer for 2012+, I've opted for the . prefix on the directory:
:
+- ClassC.cs
+- ClassD.cs
+- .Metadata/
| +- ClassA.Metadata.cs
| +- ClassB.Metadata.cs
: :
This renders the namespace name provided to classes created in that folder invalid. It's more of an implicit indicator than an explicit rule as I'd have preferred (and as #JohanLarsson's answer provides) but then again, I'm the sucker running 2010.
I'm still open to answers, and will gladly change acceptance to something better.
Related
I am new to Bazel. I have a project which is built with Bazel.
But some of the source files are pre-codegened and then compile them with Bazel.
Now I can run the bash script standalone and run the bazel command:
.
|-- project
| |-- BUILD (will depend on temp_output:codegen)
| |-- scripts
| | |-- codegen.sh (read config.yaml and generate codegen.cpp/hpp and a BUILD.bazel)
| |-- config
| | |-- config.yaml
| |-- temp_output
| | |-- codegen.cpp (not existed before running codegen.sh)
| | |-- codegen.hpp (not existed before running codegen.sh)
| | |-- BAZEL.build (not existed before running codegen.sh)
|-- WORKSPACE
$ ./scripts/codegen.sh
$ bazel build :project
What are done in the codegen.sh:
Read the config.yaml where the contains some other WORKSPACE path and name.
Query the targets in that WORKSPACE.
Create cpp/hpp files to include some headers files.
Create a new BUILD file, adding the depends on those targets.
My goal is to embed the bash script in the bazel system. I tried with rule + action.run. But the failures are for:
sandbox directory is not readable nor writable.
input files cannot be found in sandbox.
Is there a fancy way to do this? Or any examples I can refer to?
The simple way to do this is with genrule. Something like this in project/BUILD:
genrule(
name = "run_codegen",
srcs = [
"codegen.sh",
"config.yaml",
],
outs = [
"codegen.cpp",
"codegen.hpp",
],
cmd = "$(location codegen.sh) --config $(location config.yaml) --cpp $(location codegen.cpp) --hpp $(location codegen.hpp)",
)
cc_library(
name = "codegen",
hdrs = [ "codegen.hpp" ],
srcs = [ "codegen.cpp" ],
)
Some things to note:
Using $(location) to get the paths for the input and output files. If the script uses relative paths, I'd modify it to take the paths as arguments, or write a wrapper script that creates a temporary directory and moves things to/from there based on flags. The only other reliable way to create paths is with "make" variables, but those are generally harder to work with and more brittle with respect to modifications to the genrule.
Not generating a BUILD file. You can only do this from a repository rule, and it gets significantly more complicated. I don't think you need to for this use case, just write the rule in project/BUILD.
If you want to embed this in a rule instead of using genrule for some reason, make sure you're using File.path to get all the paths to embed in the command. That's the equivalent of $(location). It's hard to be more specific about why your rule doesn't work without seeing a copy of it.
I need GUI in which I have a number of strings regularly changing for instance in a multilanguage environment. So how can I enter these strings as variables instead as constants and still use the Gtkbuilder routine and be able to change the strings runtime. If that is impossible how can I tranlate the .glade file to an ADA file that doe the same.
Edit: I don't think the answer you gave me are real answers to my question, because I want the GUI changing languages without rebuilding the program, i.e. only one version of the program and not a version per language. Second point is that however I have not found then yet, but it can be possible that in other cases, it can be nice to have variables I can change during running the program instead of constants.
GtkAda https://www.AdaCore.com/gtkada should have a sufficiently complete coverage of the Gtk featureset for internationalization of strings https://developer.gnome.org/gtkmm-tutorial/stable/chapter-internationalization.html.en via POT & PO files as explained well https://www.drupal.org/community/contributor-guide/reference-information/localize-drupal-org/working-with-offline/po-and by the Drupal community for any UI that ultimately borrows from GNU gettext's leadership http://www.gnu.org/software/gettext/manual/html_node/PO-Files.html on this POT & PO file approach to internationalization of strings.
GtkAda has support
https://docs.AdaCore.com/live/wave/gtkada/html/gtkada_ug/glade.html
for Glade 3.
Then gate3
https://SourceForge.net/projects/lorenz/files should produce a GtkAda
code sketch in Ada source code.
Here are the steps for re-creating a minimal example on Debian. I can't tell how portable this example actually is to other OS'es, but at least it's some starting point. Working with locales is not straight forward IMHO. Most of the mechanics in internationalization in GtkAda revolves around the package gtkada-intl.ads.
First of all I enabled the locales of interest by running
$ sudo dpkg-reconfigure locales
I wanted test translations for Dutch and French so I selected fr_FR.UTF-8 and nl_NL.UTF-8 in addition to those already selected (like, in my case, en_US.UTF-8). I also kept en_US.UTF-8 as the default locale. This was my locale configuration after the reconfiguration:
$ locale -a
C
C.UTF-8
en_US.utf8
fr_FR.utf8
nl_NL.utf8
POSIX
I then created a simple Glade UI file with a window (with title "English") containing one label (with text "Hello world!"). I made sure that all the texts were marked "translatable". This is a property attribute that can be enabled via the "Edit Text" dialog box. This dialog box can be accessed by clicking the button on the right side of the text area where you enter, for example, the label text.
example.glade (note in particular the translatable="yes" attributes)
<?xml version="1.0" encoding="UTF-8"?>
<!-- Generated with glade 3.16.1 -->
<interface>
<requires lib="gtk+" version="3.10"/>
<object class="GtkWindow" id="Window">
<property name="can_focus">False</property>
<property name="title" translatable="yes">English</property>
<property name="window_position">center</property>
<property name="default_width">300</property>
<property name="default_height">60</property>
<child>
<object class="GtkLabel" id="Label">
<property name="visible">True</property>
<property name="can_focus">False</property>
<property name="label" translatable="yes">Hello world!</property>
</object>
</child>
</object>
</interface>
I now created two translation files (.po files) as shown below: one for Dutch and one for French. Note how the msgid matches the window title text and label text.
translations_nl.po
msgid "English"
msgstr "Nederlands"
msgid "Hello world!"
msgstr "Hallo wereld!"
translations_fr.po
msgid "English"
msgstr "Français"
msgid "Hello world!"
msgstr "Bonjour le monde!"
These files must be converted to machine readable files using the msgfmt tool that ships with GtkAda (see GtkAda's bin directory), i.e.
$ msgfmt translations_nl.po -o messages.mo
I finally created a project and the required Ada sources using GNAT Studio CE 2020 (sources are at the end of this answer). I made sure all files were organized as follows:
example/
+- example.glade
+- default.gpr
+- obj/
| +- <various build files>
+- src/
| +- main.adb
| +- translation_demo.ads
| +- translation_demo.adb
| +- po/
| +- translations_nl.po
| +- translations_fr.po
+- locales/
+- nl_NL/
| +- LC_MESSAGES/
| +- messages.mo (generated using msgfmt)
+- fr_FR/
+- LC_MESSAGES/
+- messages.mo (generated using msgfmt)
If all goes well, then after building and running the executable, the proper translations will appear in the UI depending on the setting of the LANGUAGE environment variable.
Note that in this example I set the LANGUAGE environment variable from within the program using the Ada.Environment_Variables.Set procedure (see main.adb). This is only to show how to control the language from within your program at application startup (e.g. in case you want to control the language via a configuration file read at startup; an approach that might be needed on OS'es other than Linux). On Debian (and Linux in general), the LANGUAGE environment variable is typically set by the OS on behalf of the user (check output of the env command).
As an alternative, you might also try the example without setting the environment variable in main.adb and check the result if you start the program via
LANGUAGE=nl_NL ./obj/main
or
LANGUAGE=fr_FR ./obj/main.adb
In conclusion, note that the process of getting this to work is a precise process: Debian must know the locales nl_NL.UTF-8 and fr_FR.UTF-8, the .mo files must be available in the correct directories and the LANGUAGE environment variable must be set. Furthermore, because I use relative paths in the example code, the application must be started from project root directory, i.e.
$ ./obj/main
If something is wrong, then the translation will just not happen and no error and or warning will be provided.
main.adb
with Ada.Environment_Variables;
with Translation_Demo;
procedure Main is
NL : constant string := "nl_NL:nl";
FR : constant String := "fr_FR:fr";
begin
-- Set environment varianble.
Ada.Environment_Variables.Set ("LANGUAGE", NL);
Translation_Demo.Run;
end Main;
translation_demo.ads
package Translation_Demo is
procedure Run;
end Translation_Demo;
translation_demo.adb
with Ada.Text_IO;
with Gtk.Main;
with Gtk.Widget;
with Gtk.Builder;
with Gtk.Window;
with Gtk.Button;
with Gtkada.Intl;
with Glib; use Glib;
with Glib.Error; use Glib.Error;
package body Translation_Demo is
-- Name of the .mo file without extention.
Text_Domain : constant String := "messages";
-- (Relative) location of the <lang>/LC_MESSAGES/<domain>.mo files.
Text_Domain_Dir : constant String := "./locale";
-- (Relative) location of the Glade file.
Glade_File : constant String := "./example.glade";
Builder : Gtk.Builder.Gtk_Builder;
Window : Gtk.Window.Gtk_Window;
procedure Destroy_Event_Callback
(Widget : access Gtk.Widget.Gtk_Widget_Record'Class);
---------
-- Run --
---------
procedure Run is
use Gtk.Builder;
use Gtk.Window;
Success : GUint;
Error : aliased GError;
begin
-- Initialize GtkAda.
Gtk.Main.Init;
-- Setup the translation domain and directory where to find the .mo files.
Gtkada.Intl.Setlocale;
Gtkada.Intl.Text_Domain (Text_Domain);
Gtkada.Intl.Bind_Text_Domain (Text_Domain, Text_Domain_Dir);
-- Construct a Gtk_Builder instance and load our UI description.
Gtk_New (Builder);
-- Set the translation domain for the Glade file.
Builder.Set_Translation_Domain (Text_Domain);
-- Read the Glade file.
Success := Builder.Add_From_File (Glade_File, Error'Access);
if Success = 0 then
Ada.Text_IO.Put_Line ("failed to read Glade file");
Error_Free (Error);
Gtk.Main.Main_Quit;
end if;
-- Window
Window := Gtk_Window (Builder.Get_Object ("Window"));
Window.On_Destroy (Destroy_Event_Callback'Access);
Window.Show_All;
-- Start the main event loop
Gtk.Main.Main;
end Run;
----------------------------
-- Destroy_Event_Callback --
----------------------------
procedure Destroy_Event_Callback
(Widget : access Gtk.Widget.Gtk_Widget_Record'Class)
is
begin
Gtk.Main.Main_Quit;
end Destroy_Event_Callback;
end Translation_Demo;
default.gpr
with "gtkada";
project Default is
for Source_Dirs use ("src");
for Object_Dir use "obj";
for Main use ("main.adb");
end Default;
A Puppet module of my application must execute a script that comes with that application. The directory layout is well-known, but the absolute path (of src_root) is variable.
src_root/
my_script.sh <----+
.puppet/ |
modules/ |
my_module/ |
manifests/ | executes
init.pp --+
From where do you want to access the path of your environments?
If from a script, you can find it like so:
puppet config print| grep environmentpath
If from inside puppet, you have it in this variable: $::settings::environmentpath
I'm working on a PowerShell script to dynamically create and add a Visual Studio project with its folders and assets to a solution.
I'm using Visual Studio DTE.
My directory structure on the file system is the following:
C:\Dir1\Dir2\Stuff
|
+--Stuff <-- folder
| |
| `Stuff.csproj <-- existing project, included in sln
|
+--Subfolder <-- Subfolder in which I want to include my new csproj
| +--Project1 <-- folder
| | |
| | `Project1.csproj <-- existing project, included in sln
| |
| +--Project2 <-- folder
| | |
| | `Project2.csproj <-- existing project, included in sln
| |
| `--Project3 <-- this, subs below and csproj are created from my script
| |
| `Project3.csproj
|
`Stuff.sln
My script creates Subfolder\Project3\Project3.csproj correctly, and I can add it to the solution without any problems, using DTE.
I want, however, to add Project3 in the solution folder 'Subfolder', so it looks like this (dummy image, red arrow shows where I want to have Project3):
How can I accomplish this using Powershell (and optionally EnvDTE)? Any example code would be appreciated. Thanks!
The SolutionFolder interface has an "add from file" method:
http://msdn.microsoft.com/en-us/library/envdte80.solutionfolder.addfromfile
Project AddFromFile(
string FileName
)
So you just need to get a handle to the solution folder. I don't know if you are adding the solution folder through the DTE or it already exists.
If you add it with Solution2.AddSolutionFolder
http://msdn.microsoft.com/en-us/library/envdte80.solution2.addsolutionfolder%28v=vs.110%29.aspx
Project AddSolutionFolder(
string Name
)
It returns a reference to the solution folder and you can just call the above method. If it already exists, I think you'll have to use Solution2.FindProjectItem.
http://msdn.microsoft.com/en-us/library/2zszfd26%28v=vs.110%29.aspx
Something like the following should work. I don't have a way to try it out at the minute so tweaking might be necessary.
Solution solution = System.Activator.CreateInstance(Type.GetTypeFromProgID("VisualStudio.Solution")) as EnvDTE.Solution;
Solution2 sol2 = solution as Solution2;
sol2.Create(solutionPath, solutionName);
Project folder = sol2.AddSolutionFolder("Subfolder");
folder.AddFromFile(pathToProject);
First create a 'Solution Folder' with the desired relative path. Note that Visual Studio 2012 does not create a system folder with the same relative path.
Now inside that 'Solution Folder' add a new project, but you must be careful when defining it that the relative path in the system matches the relative path of your new 'Solution Folder'. If the folder you want does not exist, VS 2012 will now create it for the new project.
If you want to add an existing file with the matching relative path, you must first create the file in the matching system relative path, from outside of VS. Then you can 'add existing file' in Visual Studio.
Considering that a book in DocBook format can be done in a "modular" fashion, I hoped I can do similar with AsciiDoc and split chapters and first-level sections in separate files. Unfortunately documentation does not say anything about this. The only possible solution I see so far is to write my own AsciiDoc preprocessor that will merge all "part"-files and generate the book.
Did someone solve this problem by now?
Two example ways from the asciidoc cheatsheet: http://powerman.name/doc/asciidoc
include::footer.txt[]
or
[source,perl]
----
include::script.pl[]
----
I have set up a book template that I use in all by book, you can find it here: asciidoc-book-template-with-rake-and-github
= Nome da disciplina
:doctype: book
:lang: pt-BR
:ascii-ids:
:showcomments:
:gitrepo: https://github.com/xxx/yyy
:code_dir: code
:image_dir: imagens
include::capitulos/prefacio.adoc[]
////
= Nome da Parte =
////
include::capitulos/cap1.adoc[]
include::capitulos/feedback.adoc[]
include::capitulos/cap2.adoc[]
include::capitulos/feedback.adoc[]
include::capitulos/cap3.adoc[]
include::capitulos/feedback.adoc[]
// ...
include::capitulos/glossario.adoc[]
include::capitulos/respostas.adoc[]
////
Always end files with a blank line to avoid include problems.
////
Note the blank lines between the include directives: they prevent the first and last lines of the included files from being adjoined. I don't split chapter on more files because when you include a file asciidoc takes the included file path to be the parent of new includes, look this tree:
.
|-- capitulos
| |-- cap1.adoc
| |-- cap2.adoc
| |-- cap3.adoc
| |-- code
| | `-- cap1
| | |-- helloworld.c
| | `-- Makefile
| |-- feedback.adoc
| |-- glossario.adoc
| |-- prefacio.adoc
| |-- respostas.adoc
| `-- symbols.adoc
|-- docinfo.xml
|-- livro.asc
`-- wip.adoc
When I'm at the file livro.adoc and I what to include feedback.adoc I will use include::capitulos/feedback.adoc[]
But if I'm at the file cap1.adoc you will have to use include::feedback.adoc[] (since they are at the same directory).
I think it's more easy to keep all includes in one same place, it works for me. I only include codes using the other way.
Here is another example in case anyone is looking how to do this.
Book Title Goes Here
====================
Author's Name
v1.1, 2012-11
:doctype: book
:icons:
:max-width: 45em
// Push titles down one level
:leveloffset: 1
include::chapter1.asciidoc[tabsize=4]
include::chapter2.asciidoc[]
include::chapter3.asciidoc[]
include::../../common/appendix/MigrationNotes.asciidoc[]
include::glossary.asciidoc[]
// Return to normal title levels
:leveloffset: 0
Index
=====
One option is covered in the user guide: https://asciidoc.org/userguide.html#X90
To paraphrase the user guide, create a top level wrapper document which uses include:: macros to add the desired content and :leveloffset: attributes to adjust the heading levels.
Another option would be to write a script that would cat all the part files together then pass the result to asciidoc using stdin. That might look something like cat part1.txt part2.txt part3.txt | asciidoc -. Please note that there appears to be issues sometimes when providing input via stdin. Also note extra line breaks may be needed at the end of each part file to prevent cat from affecting the formatting.