I don't know why load_from_path does not work during sudo ninja install. It returns:
warning: unhandled error `GLib.Error'
css_provider.load_from_path ("com.github.saidbakr.quick-shutdown.css");
I tried to catch the exception, but the same Warning:
Gtk.CssProvider css_provider = new Gtk.CssProvider ();
try {
css_provider.load_from_path ("com.github.saidbakr.quick-shutdown.css");
}
catch (IOError e){
GLib.error("", e.message);
}
I checkedout the meson.build:
...
install_data(
join_paths('data', meson.project_name()+ '.css'),
install_dir: join_paths(get_option('datadir'))
)
The path of the file is added and it is installed to /usr/local/share
I don't know how to solve this issue.
The docs for Gtk.CssProvider.load_from_path() make no mention of searching in /usr/local/share/<app-data-dir> or any other standard directory. It's expecting an absolute path.
The standard way to solve this is to use GResource. If you're using a tutorial or template, it probably has something on GResource that you can use.
If not:
Create a file, quick-shutdown.gresource.xml, with the following:
<?xml version="1.0" encoding="UTF-8"?>
<gresources>
<gresource prefix="/com/github/saidbakr/quick-shutdown">
<file>com.github.saidbakr.quick-shutdown.css</file>
</gresource>
</gresources>
Add this to your meson.build:
gnome = import('gnome')
resources = gnome.compile_resources('com.github.saidbakr.quick-shutdown',
files('quick-shutdown.gresource.xml'),
)
Add resources to the list of sources in your executable() call in meson.build
Use Gtk.CssProvider.load_from_resource() instead: css_provider.load_from_resource ("/com/github/saidbakr/quick-shutdown/com.github.saidbakr.quick-shutdown.css")
Remove the meson code where you install the CSS file. It is now built directly into your executable.
For a real-world example of how to do this, check out the GNOME Clocks source code.
This may sound like a lot of steps, but it's the same steps as adding GtkBuilder UI files (or really any other kind of static file you need in your program). If you need to do that later, all you'll have to do is add <file> entries to the .gresource.xml file.
Related
After following the composer installation guide for v10 of typo3. I pointed apache vhost to the public folder. Once I navigate to the index.php location in the browser, I get this error
Fatal error: Uncaught ArgumentCountError: Too few arguments to function
TYPO3\CMS\Core\Imaging\IconFactory::__construct()
0 passed in /home/user/projects/typo3/public/typo3/sysext/core/Classes/Utility/GeneralUtility.php
on line 3423
and exactly 2 expected in
/home/user/projects/typo3/public/typo3/sysext/core/Classes/Imaging/IconFactory.php:71
It looks like a dependency injection problem. Please can anybody help with this error
For me this issue occured after moving an existing project from a server into DDEV (which is similar to changing the path/URL by a vhost config). My guess is it has to do with changed paths/URLs in cached files. This is how I solved it:
A) Manually delete all cached files:
t3project$ rm -rf public/typo3temp/*
t3project$ rm -rf var/*
B) Also I had to change the ownership of some autogenerated folders/files to my current user (sudo chown -R myuser:myuser t3project/), then I was able to use the "Fix folder structure" tool in "Environment > Directory Status", now everything was working fine again. Not sure if the last step is helpful for you, as it might be only related to my case where certain folder/files had a wrong owner as they was copied.
I had the same problem today and it occured because I was XClass'ing one of the Core Classes and used GeneralUtility::makeInstance(IconFactory::class) in this code.
The fix is to use DI in this class, just as you suggested. Also flush all caches afterwards to rebuild the DI container.
From this:
class CTypeList extends AbstractList
{
public function itemsProcFunc(&$params)
{
$fieldHelper = GeneralUtility::makeInstance(MASK\Mask\Helper\FieldHelper::class);
$storageRepository = GeneralUtility::makeInstance(MASK\Mask\Domain\Repository\StorageRepository::class);
...
To this:
class CTypeList extends AbstractList
{
protected StorageRepository $storageRepository;
protected FieldHelper $fieldHelper;
public function __construct(StorageRepository $storageRepository, FieldHelper $fieldHelper)
{
$this->storageRepository = $storageRepository;
$this->fieldHelper = $fieldHelper;
}
public function itemsProcFunc(&$params)
{
$this->storageRepository->doStuff();
$this->fieldHelper->doStuff();
...
For future reference for others:
This can also happen in own extensions when the Core uses GeneralUtility::makeInstance on your classes. (e.g. in AuthenticationServices).
The trick here is to make these DI services public like so:
(in extension_path/Configuration/Serivces.yaml)
services:
_defaults:
autowire: true
autoconfigure: true
public: false
Vendor\ExtensionName\Service\FrontendOAuthService:
public: true
Here's documentation for it:
https://docs.typo3.org/m/typo3/reference-coreapi/master/en-us/ApiOverview/DependencyInjection/Index.html#knowing-what-to-make-public
I had this error because i used the Services.yaml file in one of my extensions, but did not configure it correct.
More infos about the file itself can be found here
Since the file is responsible for the dependency injection, small mistakes e.g. in namespaces lead to the above mentioned error.
To locate the error you can uninstall extensions with a Services.yaml.
When you have found the file/extension, you have to check if all Namespaces in the Classes Directory are correct.
This means:
All filenames are correct regarding the Class they contains
All Namespaces in the files are correct for path and filename
The Namespace can be found via composer. So the extension have to be installed via composer or must have an entry in the autoload list of composer.json
I am trying to understand the workflow presented in https://github.com/microsoft/vscode-extension-samples/tree/master/i18n-sample for localizing Visual Studio Code extensions.
I cannot figure out how the i18n directory gets created to begin with, as well as how the set of string keys in that directory get maintained over time.
There is one line in the README.md which says "You could have created this folder by hand, or you could have used the vscode-nls-dev tool to extract it."...how would one use vscode-nls-dev tool to extract it?
What I Understand
I understand that you can use vscode-nls, and wrap strings like this: localize("some.key", "My String") to pick up the localized version of that string at runtime.
I am pretty sure I understand that vscode-nls-dev is used at build time to substitute the content of files in the i18n directory into the transpiled JavaScript code, as well as creating files like out/extension.nls.ja.json
What is missing
Surely it is not expected that: for every file.ts file in your project you create an i18n/lang/out/file.i18n.json for every lang you support...and then keep the set of keys in that file up to date manually with every string change.
I am assuming that there is some process which automatically goes "are there any localize("key", "String") calls in file.ts for new keys not yet in file.i18n.json? If so, add those keys with some untranslated values". What is that process?
I have figured this out, referencing https://github.com/Microsoft/vscode-extension-samples/issues/74
This is built to work if you use Transifex for your translator. At the bare minimum you need to use .xlf files as your translation file format.
I think that this is best illustrated with an example, so lets say you wanted to get the sample project working after you had deleted the i18n folder
Step 1: Clone that project, and delete the i18n directory
Step 2: Modify the gulp file so that the compile function also generates nls metadata files in the out directory. Something like:
function compile(buildNls) {
var r = tsProject.src()
.pipe(sourcemaps.init())
.pipe(tsProject()).js
.pipe(buildNls ? nls.rewriteLocalizeCalls() : es.through())
.pipe(buildNls ? nls.createAdditionalLanguageFiles(languages, 'i18n', 'out') : es.through())
.pipe(buildNls ? nls.bundleMetaDataFiles('ms-vscode.node-debug2', 'out') : es.through())
.pipe(buildNls ? nls.bundleLanguageFiles() : es.through())
Step 3: Run the gulp build command. This will generate several necessary metadata files in the out/ directory
Step 4: Create and run a new gulp function to export the necessarry translations to the xlf file. Something like:
gulp.task('export-i18n', function() {
return gulp.src(['package.nls.json', 'out/nls.metadata.header.json', 'out/nls.metadata.json'])
.pipe(nls.createXlfFiles("vscode-extensions", "node-js-debug2"))
.pipe(gulp.dest(path.join('vscode-translations-export')));
}
Step 5: Get the resulting xlf file translated. Or, add some dummy values. I cant find if/where there is documentation for the file format needed, but this worked for me (for the extension):
<?xml version="1.0" encoding="utf-8"?>
<xliff version="1.2" xmlns="urn:oasis:names:tc:xliff:document:1.2">
<file original="package" source-language="en" target-language="ja" datatype="plaintext"><body>
<trans-unit id="extension.sayHello.title">
<source xml:lang="en">Hello</source>
<target>JA_Hello</target>
</trans-unit>
<trans-unit id="extension.sayBye.title">
<source xml:lang="en">Bye</source>
<target>JA_Bye</target>
</trans-unit>
</body></file>
<file original="out/extension" source-language="en" target-language="ja" datatype="plaintext"><body>
<trans-unit id="sayHello.text">
<source xml:lang="en">Hello</source>
<target>JA_Hello</target>
</trans-unit>
</body></file>
<file original="out/command/sayBye" source-language="en" target-language="ja" datatype="plaintext"><body>
<trans-unit id="sayBye.text">
<source xml:lang="en">Bye</source>
<target>JA_Bye</target>
</trans-unit>>
</body></file>
</xliff>
Step 6: Stick that file in some known location, let's say /path/to/translation.xlf. Then add/run another new gulp task to import the translation. Something like:
gulp.task('i18n-import', () => {
return es.merge(languages.map(language => {
console.log(language.folderName)
return gulp.src(["/path/to/translation.xlf"])
.pipe(nls.prepareJsonFiles())
.pipe(gulp.dest(path.join('./i18n', language.folderName)));
}));
});
Step 7: Run the gulp build again.
The i18n/ directory should now be recreated correctly! Running the same build/export/translate/import/build steps will pick up any new changes to the localize() calls in your TypeScript code
Obviously this is not perfect, there are a lot of hardcoded paths and such, but hopefully it helps out anyone else who hits this issue.
Using Cudafy version 1.29, which can be downloaded from here
I am executing the examples that are found in the install folder CudafyV1.29\CudafyByExample\
Specifically, "chapter 3" example that begins line 42 of program.cs calls the following:
simple_kernel.Execute();
which is this:
public static void Execute()
{
CudafyModule km = CudafyTranslator.Cudafy(); // <--exception thrown!
GPGPU gpu = CudafyHost.GetDevice(CudafyModes.Target, CudafyModes.DeviceId);
gpu.LoadModule(km);
gpu.Launch().thekernel(); // or gpu.Launch(1, 1, "kernel");
Console.WriteLine("Hello, World!");
}
The indicated line throws this exception:
Compilation error: CUDAFYSOURCETEMP.cu
'C:\Program' is not recognized as an internal or external command,
operable program or batch file. .
Which is immediately obvious that the path has spaces and the programmer did not double quote or use ~ to make it operational.
So, I did not write this code. And I cannot step through the sealed code contained within CudafyModule km = CudafyTranslator.Cudafy();In fact I don't even know the full path that is causing the exception, it is cut-off in the exception message.
Does anyone have a suggestion for how to fix this issue?
Update #1: I discovered where CUDAFYSOURCETEMP.cu lives on my computer, here it is:
C:\Users\humphrt\Desktop\Active Projects\Visual Studio
Projects\CudafyV1.29\CudafyByExample\bin\Debug
...I'm still trying to determine what the program is looking for along the path to 'C:\Program~'.
I was able to apply a workaround to bypass this issue. The workaround is to reinstall all components of cudafy in to folders with paths with no ' ' (spaces). My setup looks like the below screenshot. Notice that I also installed the CUDA TOOLKIT from NVIDIA in the same folder - also with no spaces in folder names.
I created a folder named "C:\CUDA" and installed all components within it, here is the folder structure:
SharpDevelop compiles fine, but trying to compile through booc doesn't work.
Boo Compiler version 0.9.4.9 (CLR 2.0.50727.8000)
Program.boo(4,8): BCE0021: Namespace 'Microsoft.Xna.Framework' not found, maybe
you forgot to add an assembly reference?
booc -resource:"C:\test\" Program.boo , the command used in Windows cmd tool.
Thank you. Alisa.
Sharpdevelop most likely already references the libraries to the compiler for you. What that means is, when you manually invoke the booc command line compiler, you will have to tell the compiler where exactly the MonoGame library is. I haven't been able to check myself yet, but I did have a quick look at the command lines and the Boo source code, and I think you have to do the following:
-lib:C:/Path/To/MonoGame/Libraries
This will tell the compiler where to look for additional libraries.
The next thing you should then do is add the libraries you want, eg:
-r:Microsoft.Xna.Framework.dll,Microsoft.Xna.Framework.Game.dll
Add these two additional compiler options to your command line and I think it should work.
I haven't compiled this myself really, because I found it rather tedious. Instead, I decided to create my own build script in Boo itself in order to compile my Boo programs. That way I still had to add the library path and reference the libraries, as in the following snippet:
def CompileEngine() as bool:
"""Compiles the engine and puts it in ./lib/SpectralEngine.dll"""
compiler = BooCompiler()
compiler.Parameters.Pipeline = CompileToFile()
compiler.Parameters.OutputType = CompilerOutputType.Library
compiler.Parameters.Ducky = true
compiler.Parameters.LibPaths.Add("./lib")
compiler.Parameters.OutputAssembly = "./lib/SpectralEngine.dll"
# Add libraries.
compiler.Parameters.References.Add(compiler.Parameters.LoadAssembly("OpenTK.dll"))
compiler.Parameters.References.Add(compiler.Parameters.LoadAssembly("NAudio.dll"))
compiler.Parameters.References.Add(compiler.Parameters.LoadAssembly("Boo.Lang.dll"))
compiler.Parameters.References.Add(compiler.Parameters.LoadAssembly("Boo.Lang.Parser.dll"))
compiler.Parameters.References.Add(compiler.Parameters.LoadAssembly("Boo.Lang.Compiler.dll"))
# Take all boo files from the Engine source directory.
files = (Directory.GetFiles(Directory.GetCurrentDirectory() + """/src/Engine""", "*.boo", SearchOption.AllDirectories)
.Where({file as string | return not file.Contains("Gwen")})) # Filter out old GWEN files.
for file in files:
print "Adding file: " + file
compiler.Parameters.Input.Add(FileInput(file))
print "Compiling to ./lib/SpectralEngine.dll"
context = compiler.Run()
if context.GeneratedAssembly is null:
print "Failed to compile:\n" + join(e for e in context.Errors, "\n")
return false
else:
return true
I've put two of these build scripts at here and here. It's perhaps a bit overkill for you, though.
I'm doing VPATH builds with automake. I'm now also using generated source, with SWIG. I've got rules in Makefile.am like:
dist_noinst_DATA = whatever.swig
whatever.cpp: whatever.swig
swig -c++ -php $^
Then the file gets used later:
myprogram_SOURCES = ... whatever.cpp
It works fine when $builddir == $srcdir. But when doing VPATH builds (e.g. mkdir build; cd build; ../configure; make), I get error messages about missing whatever.cpp.
Should generated source files go to $builddir or $srcdir? (I reckon probably $builddir.)
How should dependencies and rules be specified to put generated files in the right place?
Simple answer
You should assume that $srcdir is a read-only, so you must not write anything there.
So, your generated source-code will end up in $(builddir).
By default, autotool-generated Makefiles will only look for source-files in $srcdir, so you have to tell it to check $builddir as well. Adding the following to your Makefile.am should help:
VPATH = $(srcdir) $(builddir)
After that you might end up with a no rule to make target ... error, which you should be able to fix by updating your source-generating rule as in:
$(builddir)/whatever.cpp: whatever.swig
# ...
A better solution
You might notice that in your current setup, the release tarball (as created by make dist) will contain the whatever.cpp file as part of your sources, since you added this file to the myprogram_SOURCES.
If you don't want this (e.g. because it might mean that the build-process will really take the pregenerated file rather than generating it again), you might want to use something like the following.
It uses a wrapper source-file (whatever_includer.cpp) that simply includes the generated file, and it uses -I$(builddir) to then find the generated file.
Makefile.am:
dist_noinst_DATA = whatever.swig
whatever.cpp: whatever.swig
swig -c++ -php $^
whatever_includer.cpp: whatever.cpp
myprogram_SOURCES = ... whatever_includer.cpp
myprogram_CPPFLAGS = ... -I$(builddir)
clean-local::
rm -f $(builddir)/whatever.cpp
whatever_includer.cpp:
#include "whatever.cpp"
Usually, you want to keep $srcdir readonly, so that if for instance the source is distributed unpacked on a CDROM, you can still run /.../configure from some other part of the file-system.
However if you are using SWIG to generate source code for a wrapper library, you probably want to distribute that SWIG-generated code as well so that your users do not need to install SWIG to compile your code. Then you have indeed a choice: you can decide that the SWIG-generated code should end in $builddir (it's OK: make dist will collect it there and include it in the tarball), or you could decide to output SWIG-generated code in $srcdir since it is really a source from the point of view of the distributed package. An advantage of keeping it in $srcdir is that when make distcheck attempts to build your package from a read-only source directory, it will fail on any attempt to call SWIG to regenerate the wrapper source. If you have your wrapper source in $builddir, you might not notice you have some broken rule that cause SWIG to be run on the user's host; by generating in $srcdir you ensure that SWIG is not needed by your users.
So my preference is to output SWIG wrapper sources in $srcdir. My setup for Python wrappers looks as follows:
EXTRA_DIST = spot.i
python_PYTHON = $(srcdir)/spot.py # _PYTHON is distributed by default
pyexec_LTLIBRARIES = _spot.la
MAINTAINERCLEANFILES = $(srcdir)/spot_wrap.cxx $(srcdir)/spot.py
_spot_la_SOURCES = $(srcdir)/spot_wrap.cxx $(srcdir)/spot_wrap.h
_spot_la_LDFLAGS = -avoid-version -module
_spot_la_LIBADD = $(top_builddir)/src/libspot.la
$(srcdir)/spot_wrap.cxx: $(srcdir)/spot.i
$(SWIG) -c++ -python -I$(srcdir) -I$(top_srcdir)/src $(srcdir)/spot.i
# Handle the multi-file output of SWIG.
$(srcdir)/spot.py: $(srcdir)/spot.i
$(MAKE) $(AM_MAKEFLAGS) spot_wrap.cxx
Note that I use $(srcdir) for all targets, because of limitations of the VPATH feature on various flavors of make. My setup to deal with the multiple files output by SWIG could be improved, but as these rules are not run by users and it has never caused me any problem, I do not bother.