If in your application you import a package, which has a translation
and in your application create a translation, you get:
Duplicated library name 'messages_all'. library messages_all;
when using the generate_from_arb functionality.
This applies also to the library in the translated files, e.g. messages_es
The cause is that in generate_localized.dart, the library name(s) are hardcoded.
Is there a good work around ... other than renaming the translation libraries?
... and what exact impact does it have?
Is there a "best practice" for translating multiple libraries?
Related
I'm working on a library with multiple layers of functionality. I want developers to be able to import only the parts they need, ie mylib-core, mylib-feature1, mylib-feature2, etc. Each lives in its own git repo. I'd also like to provide a simple mylib package which exposes a default set of functionality which is useful for developers new to the library. See d3.js version 4+ for something very similar to what I'm trying to accomplish.
The problems I've run into are
Apparently you can't share a package name between packages. This is a problem because it would be nice to import all the desired repos and then simply have everything available under the mylib name.
I don't see an obvious way to re-export functionality, in order to build the default mylib package.
Are there good solutions or a more idomatic go way to accomplish what I'm shooting for?
Answering your question, there is no idiomatic way of doing what you want. It is common in JavaScript to import a library and export its members without interference. This is not the case in Golang.
I advise you to host your whole library under a single repo, and split the functionality to packages. The Go compiler will only compile and use the imported packages.
And a tip for the future, Go is very different than almost any other language you previously know 😅
How Will I import package dynamically and invoke its method in golang like java reflection package, there are solutions of how to invoke method in the same file using golang reflection but what about invoking from different package
What you're describing isn't dynamic package loading, it's just reflection. As long as the package is included in the binary and the types are exported, you can reference it the same way you can reference types in the same package.
Dynamic package loading is a different matter entirely; there's the new plugin support, which is still in its early stages, and not yet supported on all platforms. That's the closest you'll get.
Bear in mind that Go is not Java. Don't try to write Java in Go. It won't work. The platform, language, and standard library are very, very, very different between the two. Java can do dynamic class loading because it has a class loader. All types are dynamically loaded in Java. In Go, nothing is dynamically loaded; the Go compiler produces a native binary, there's nothing dynamic about it.
If you're trying to replicate something you're used to in Java, you're probably best served by rethinking your design entirely in a way that's more suitable to the technology you've chosen (Go), or to choose a technology more suited to the problem you're trying to solve.
Are there official rules/guidelines for including boost headers? I'm wondering as up until recently I almost always used the format #include <boost/library.hpp>. Then I came across Boost.Timer, whose documentation states that there are 2 versions of the library, a deprecated and a new one.
The deprecated version resides in <boost/timer.hpp> whereas the new one resides in <boost/timer/timer.hpp>. The two version seemingly exist without any interaction...
So I thought: "well obviously one should prefer the 'internal' headers". So I looked at some of my more regularly used headers and noticed that for example <boost/format.hpp> simply includes the headers of boost/format plus several external dependencies. So including the specific headers doesn't seem like the best idea.
So I thought: "well maybe that's a transitional artifact and they're working towards the boost/library/header'scheme".
The I noticed the new Boost.Atomics library - only just recently added - and was stunned: there's a header boost/atomics.hpp and a folder with headers of the same name.
Now I'm somewhat confused: Is there an official guideline on which headers are to be considered public (similar to the standard headers) and where the internal aspects of the api starts? Or is it completely up to the library to decide the structure of it's headers?
As far as I know, the Boost Library Requirements and Guidelines does not define the scoping and separation of header files. The Boost Header Policy defines guidelines to allow headers to co-exist with other headers. Nevertheless, many of the libraries provide a distinction by:
Providing separate files for logical divisions of types/functionality users may want.
Placing header files internal to the library within a detail directory.
Declaring internal types, functions, etc. in a detail namespace.
Some even make another level of distinction by separating a function declaration from its definition within header files by placing the definition in an impl directory.
It is suppose to be safe to include the highest-level header file. Additionally, it should generally be safe to include more specific files. For example:
If I want boost::thread, boost::mutex, and boost::lock, or do not mind the additional includes, then I may include boost/thread.hpp.
If I only want boost::thread, then I would include boost/thread/thread_only.hpp. I would not directly include boost/thread/detail/thread.hpp.
I need to use one module, I created previously using vhdl in another module and I cant find any info on how to do this. I'm forced to use maxplus2, and the only thing I found there is that I can create include file there (will have .inc extension), but I still cant get it included in my second module. I've spent the whole morning searching for this info but found nothing.
Can anybody help me with it?
You don't.
VHDL doesn't have include files, it avoids that whole horrid disastrous unreliable mess.
VHDL uses separate compilation, and good VHDL tools (not all of them!) track all the dependencies correctly without includes or Makefiles.
So you compile your other modules into a library - maybe "my_modules" - or if you don't specify a library, just compile it, it'll go into the default library called "work".
Then in your main module you name the libraries (except "work" which is always there)
library ieee;
library my_modules;
and name the things (modules, packages) you want from them (except "work" ...)
use ieee.numeric_std.all;
use my_modules.all;
and you can now use whatever you want from these libraries. The simplest way to use a module is "direct entity instantiation" - searching this and "VHDL" will show you how.
Or you can declare a component in your main module with the same ports as your other module, and the correct module will replace the component at elaboration (VHDL term for linking). Where you would need a component is if you haven't written the library modules yet - i.e. top down design... otherwise direct entity instantiation is simpler.
For now, ignore "my_modules" and just use "work" - when you get to a big design, use libraries to organise it, e.g. keep hardware and testbenches separate.
Brian has the right answer for you. Something I'd add which is related to your question in that it's something else people use include files for:
packages are VHDL's way of sharing data-types, constants, functions and procedures.
I have the following requirement.
I need to implement dll kind of thing on mac.I need to create a backend library which can be loaded dynamically.This backend library will contain the cocoa classes and c++ classes.
What is advantage/disadvantage of cocoa framework,I was googling so far,I was not able to figure out the best one.Please give me some suggestion.Is cocoa framework also loaded dynamically?
The main difference between a dynamic library and a framework is that a framework can contain resources (images, sound files, nibs, etcetera) and header files. When you use a dynamic library, these are separate.
Both a framework and a dynamic library are loaded at runtime. If your library will only be used on Mac OS X, I recommend creating a framework because it is easier to manage since everything is in one folder.
Bundles (the white LEGO bricks) are almost exclusively used as plug-ins. If you want to create a plug-in interface you should accept bundles and you should provide a framework the bundles can link against. Bundles are also loaded at runtime.
Here's a decent tutorial (PDF form) that goes a little more in depth explaining the differences between ordinary libraries and frameworks.