I seek a little help to wrap a package for meteor. It has always been my weakness on this framework. I know it is not difficult, I read tutorials and some articles like :
https://www.discovermeteor.com/blog/wrapping-npm-packages/
http://www.meteorpedia.com/read/Packaging_existing_Libraries
However I get lost in export and stuff, and it is time to understand !
I tried to wrap this package :
https://github.com/fians/Waves
(I knew one day I was going to not find the package already made by someone on atmosphere :()
So I wanted to do the thnings right, following guidelines made by dandv. I forked the repo, add the meteor packages with the files : export.js and package.js. Following the example of moment As you can see here :
https://github.com/Voyag3r/Waves
Finally, in my app, I created the local package folder with the meteor command : meteor create --package voyag3r:waves I tried to called the waves variable, bit it is not defined. I tried with and without a capital letter. (like in the source code waves.js). No, I tried with this.Waves instead of just Waves in export.js, neither.
There is something I do not understand with namespace and visibility I think, and errors are not displaying useful information this time. Is there someone to explain to me ? Because I would like to do a lot of other packages !
Thanks !
Glad to see that you read through those documents above, as they're quite helpful. However, I understand that it can be confusing to work through the details. Hopefully, I can assist you.
I recently finished packaging up a couple of libraries for Meteor, so you should take a look at those repositories as examples:
jspdf:core
jspdf:autotable
More specifically, take a look at the jspdf:core repository above and inspect the meteor-pre.js and meteor-post.js files for how to handle exporting variables:
meteor-pre.js
var window = {};
meteor-post.js
jsPDF = window.jsPDF;
Other important files include package.js and package.json, and of course autopublish.json, for integrating version updates with http://autopublish.meteor.com/, a fantastic tool written by Luca Mussi #splendido.
Additionally, I would recommend that you review the Official Meteor integration directly from 3rd party libraries discussion and ask #splendido or #dandv for assistance with reserving the namespace for this library.
This process has gone through rapid change over the last few months, and although not perfect, it's improving steadily. I'm encouraged to see that, like me, you want to assist the Meteor ecosystem.
Related
While it doesn't appear that this is a duplicate based on my searches, I'm sure other people have complained about this in many places.
I play minecraft and know java pretty well, so I thought it would be interesting to make mods with the minecraft forge. However, most tutorials are outdated or incomplete and I can't find a complete documentation. Now, if someone says, for instance, that existing blocks can be accessed through the Blocks class, I don't know what package that class is in. My more specific question was about modifying the properties of TNT(I wanted to do this as a test mod). Based on what I've been able to scrounge from various forums, using reflection on existing blocks in the game is possible, and what I found surrounding food would suggest there is a class for TNT somewhere that can be modified to boost its power. Just so someone can explain the not-well-explained principles of forge mod making, where would I find this TNT-related class that I could use reflection on, and how would I go about doing that(I've never done stuff with reflection before)?
To be clear, I've gotten forge minecraft all set up, I don't need an explanation of that. Just how to modify the properties of TNT(and hopefully this explanation will help me understand some broader principles)
I've been using https://nekoyue.github.io/ForgeJavaDocs-NG/ for a while. It has 1.12.2, 1.13.2, 1.14.4, 1.15.2, 1.16.5 and 1.17.1
I've been looking for a complete documentation/tutorial too, and I haven't fount a lot of stuff to be clear, but I found a wiki that might be useful. Here it is if you want to check it out:
Mcjty's wiki: https://wiki.mcjty.eu/modding/index.php?title=Main_Page
Forge's official documentation can be found here, versions:
1.15.x
1.16.x
1.17.x
I'm using openapi-generator for jersey-jaxrs (OpenAPI 3.0). I'd like to control the package where my code is being generated.
I'm setting the api-package, model-package, package-name, and invoker-package options, all to a xxx.yyy.zzz value.
My problem is that most of the code is generated under gen.xxx.yyy.zzz, and it's not discoverable by the part of the code generated under xxx.yyy.zzz. Implicitly, gen is prepended to the package name. I understand this is convenient in many cases, but not mine. Is there any generator option to avoid this?
I've learned a bit about the Mustache templates and they seem like a possible solution, but maybe a bit too much for my requirements.
Ultimately, I can move the code in gen to the other (non-gen) package manually, and it works, but this is quite inconvenient.
Finally, I found out that you can mark folders in IntelliJ IDEA as "generated sources root", which makes it discoverable to the rest of the project's code.
This doesn't solve my question, but it does solve the problem that originated the question.
My package introduces registry entries. Changes by site administrator should not be overwritten on reinstall of the package.
Many ways to Rome. I chose ftw.upgrade. I like the declarative way of the upgrade step syntax. Its possible to use an upgrade directory for generic setup xml-Files like propertiestool.xml. No need to define handler python code. The upgrade works well. The admin can upgrade from control panel and in my case the new property is added. Insomma: For a new property just these have to be added: an upgrade-step declaration for source and destination version and directory where to find the properties.xml. Thumb up! –
You can pilot what to do when installing a Plone add-on by providing an Extension/install.py file with a install method inside:
def install(portal, reinstall=False):
if not reinstall:
setup_tool = portal.portal_setup
setup_tool.runAllImportStepsFromProfile('profile-your.pfile:default')
This way you are driving what Plone should do when installing.
If you need it: the same if for uninstall:
def uninstall(portal, reinstall=False):
if not reinstall:
setup_tool = portal.portal_setup
setup_tool.runAllImportStepsFromProfile('profile-example.gs:uninstall')
This way you can prevent the uninstall step to be run when reinstalling.
Warning: as Mathias suggested using quickinstaller -> reinstall feature is bad.
Warning: this will not probably work anymore on Plone 5 (there's open discussion about this).
I think what you describe is one of the problems upcoming with the increasing complexity of Plone's stack, and one of the reasons, why it is not recommended to execute a re-install anymore, but to provide a profile for each version of the Add-On, via upgrade-steps (as Mathias mentioned). That increases dev-time significantly and results in even more conflicts, of my experience. Here are the refering docs:
http://docs.plone.org/develop/addons/components/genericsetup.html#add-upgrade-step
Elizabeth Leddy once wrote an Add-On to ease that pain and I can confirm it does:
https://github.com/ampsport/amp.ezupgrade
And the great guys from FTW, too, I never used it, but looks promising:
https://pypi.python.org/pypi/ftw.upgrade
Neither used this one, even claims to have some extra goodies, like cleanup broken OFS objects and R. Patterson's on it:
https://github.com/collective/collective.upgrade
As we're here, the first good doc I could find about it ~ 1.5 years ago, comes from Uwosh, of course:
http://www.uwosh.edu/ploneprojects/docs/how-tos/how-to-use-generic-setup-upgrade-steps
Another solution can be, to check, if it's an initial- or re-install, and set the properties programatically via a Python-script, conveniently called 'setuphandlers.py', like described in this answer:
How to check, if my product is already installed, when installing it?
That way one can still trigger re-installs without blowing it all up.
Lastly, a lot of the GS-xml-files understand the purge-property, setting it to False, will not overwrite the whole file, just your given props. This might, or not, apply to your case, you can find samples in the above referenced official doc.
first of all, i will explain what i would like to do here : given a C big programm, i would like to output a list of producers/consumers for a data and a list of calling/called-by functions of the function where this data is.
for doing this, i am thinking about using what computes some modules of frama-c, like dataflow.ml or callgraph.ml in my own plugin.
however, as i read the plugin developper doc, i can't manage to see how we can have access to the data of those modules.
is a "open.cyl_type" sufficient here in my own plugin?
moreover, here are my other questions :
i tried using by the way pdg plugin for my purposes but when i call it and it says "pdg graph computed", how can i access it?
is there any more documented thing about "impact" plugin than the official webpage, in depth, how it works fondamentally? (i have to say that i'm in like a pre-project phase, and that i installed frama-c with the apt-get on ubuntu and that i did not get an impact plugin working (i'll see by compiling the sources))
by the way, do you think i'm using the right method to get to my purposes?
Your question is quite unclear, and this answer is thus very generic. As mentioned in the developer documentation, there are two main classes of plugins: static plugins, compiled with the kernel and whose API is exposed in a module (usually of the same name of the plugin) in Db. Dynamic plugins, such as Semantic_callgraph register dynamically their entry points through the Dynamic module.
If you do make doc in Frama-C sources (I'm not sure that there is a corresponding package in Ubuntu) you can access documentation for the Db module in FRAMAC_SOURCE_DIR/doc/code/html/Db.html and the list of functions registered by dynamic plugins in FRAMAC_SOURCE_DIR/doc/code/dynamic_plugins/Dynamic_plugins.html.
I think that, following Virgile's advice, you should get the source code anyway because you will most of the time need to browse the code to find what you are looking for. Beside, you can have a look at the hello_word plug-in (in src/dummy/hello_world) to have an example of a very simple plug-in. You can also find some examples on my web site at https://anne.pacalet.fr/Notes/doku.php?id=notes:0061_frama_c_scripts to find out how to have access to some information in the AST.
I was working on harbuzz old one. now a new version of harbuzz-ng has came. now this structure is completely changes in comparison of old code. Without API docs its really hard to work/use this library. I google about it but didnot find any relavent details.
How can i start using it. Any test program to understand the input and output for this library.
If anybody have a test /hello world type from or any reference docs for API please share.
Some good and simple examples are listed on Harfbuzz wiki, 1, 2
I suggest you a higher level library, Pango if you need layout things like line wrap and I guess you would find better doucmentation for it than HarfBuzz itself.
You may have a look at State of Text Rendering also.
adding to the above examples i have also made and collected some sample harfbuzz examples which you can find it here
this link https://lazka.github.io/pgi-docs/HarfBuzz-0.0/index.html might aid you
I would say you should read all Harfbuzz mail archives
plus go to harfbuzz github acc try reading pr and issues threads.
at last due to scarcity of documentations,the only doc you got is the sourcecode itself :P