I have found an old prettier-plugin that isn't maintained anymore, and I wan't a small change within its codebase. The src for it is a simple 1-file-script with imports for prettier-parser and parser-babel.
I was wondering if I can somehow copy this file and tell prettier to execute the code on format? That way I can have the script on my own repository without the need for a third party deprecated dependency.
Related
Not sure what the best way to explain what I want is, but here goes...
I have a header file ('generated.h') that is generated from another header file ('interface.h') using some python script.
If I add a custom build step to generated.h, that's a circular dependency. Also, 'generated.h' doesn't even exist in a new workspace, so it gets a bit more confusing there.
Should I instead change interface.h to a custom build tool?
'generated.h' is only for use in testing (generated.h's are mock headers) and there may be several.
Therefore I don't really want to add a custom build step to interface.h, since that's used in "real" code. It's not really interface.h's responsibility to generate 'generated.h' (or is it?).
I could add the script as an item next to 'generated.h', but if there are many such generated.h-like-files, I would need to modify the script to accept multiple sets of args, or otherwise find a way to add the generation script several times.
What would you recommend?
I am trying to define 2 custom filetypes that I want them to feature thumbnail previews within windows explorer and I used this code sample (https://code.msdn.microsoft.com/CppShellExtThumbnailHandler-32399b35) to register the new shell extension but I can only make one of them work at a time.
The moment I try to register the second one it seems it replaces the IThumbnailProvider's Handler Subkey {E357FCCD-A995-4576-B01F-234630154E96} and breaks the first filetype's registration. If anyone has some experience with this, my question is,
can I register more than 1 filetypes at a time using this code sample?
Is there an alternative?
Thank you!
I managed to register more than 1 custom files, but the way I did it leaves me baffled... So if anyone could take the time to explain it to me I d sure appreciate it.
I copied the c++ project/solution to a new folder, changed the custom filetype parameters inside the code to match my 2nd custom filetype needs, build this new project and registered the resulting .dll.
So basically, what made it work, is that when you build the project/ solution the files that are being produced (the .dll being just one of them) are essential for the thumbnail handler to work.
And this is what baffles me.
I would expect that after you register the .dll, the new filetype is established and that I could even get rid off the aforementioned files. But apparently not only you have to register the .dll, but also make sure you keep the other files that are being produced upon built, unchanged in everyway.
So that basically means, 1 project/solution per custom filetype, nicely saved in its own folder :)
Is this the right way to do this, or am I just hacking it here?
I'd like to get scons to read a previous version number from a file, update a source file with a new version number and current date and then write the number back to the original file ready for the next build.
This needs to happen only when the target is out of date. IOW the version number doesn't change if no build takes place. The original file is source controlled and isn't a source file else it could trigger another build on check-in (due to CI). CLARIFICATION From scons' point of view the code will always be out of date due to the auto-generated source file but scons will only be run from a Continuous Integration job (Jenkins) when a SCM change is detected.
I've looked into AddPostMethod, but this seems to fire for all files within the list of source files.
Command and Builder methods use the VARIANT_DIR so I can't edit these files and then check them back in as they no longer map to the repo.
I'm hoping I'm just misunderstanding some of the finer details of scons else I'm running out of ideas!
Update
Thinking this through some more, Tom's comment is correct. Although I have two files, one version controlled text file (non-source code) and one non-source controlled source file there is no way to check one file in and prevent a continuous build/check-in cycle. Jenkins will see the new text file and spin off a build, and scons will see the new generated file. So unless I delete the generated file at some point, although this seems to go against the workflow of both tools.
Does anyone have any method for achieving this? It seems pretty straightforward. Ultimately I just want to generate build numbers each time a build is started.
From SCons User Guide section 8, Order-Only Dependencies, you can use the Requires method:
import time
# put whatever text you want in your version.c; this is just regular python
version_c_text = """
char *date = "%s";
""" % time.ctime(time.time())
open('version.c', 'w').write(version_c_text)
version_obj = Object('version.c')
hello = Program('hello.c',
LINKFLAGS = str(version_obj[0]))
Requires(hello, version_obj)
Two things to note: first you have to add the explicit Requires dependency. Second, you can't make version_obj a source of the Program builder, you have to cheat (here we pass it as a linkflag), otherwise you'll get an automatic full dependency on it.
This will update the version.c always, but won't rebuild just because version.c changed.
My problem is that I'm having trouble specifying paths for Lua to look in.
For example, in my script I have a require("someScript") line that works perfectly (it is able to use functions from someScript when the script is run standalone.
However, when I run my app, the script fails. I believe this is because Lua is looking in a location relative to the application rather than relative to the script.
Hardcoding the entire path down to the drive isn't an option since people can download the game wherever they like so the highest I can go is the root folder for the game.
We have XML files to load in information on objects. In them, when we specify the script the object uses, we only have to do something like Content/Core/Scripts/someScript.lua where Content is in the same directory as Debug and the app is located inside Debug. If I try putting that (the Content/Core...) in Lua's package.path I get errors when I try to run the script standalone.
I'm really stuck, and am not sure how to solve this. Any help is appreciated. Thanks.
P.S. When I print out the default package.path in the app I see syntax like ;.\?.lua
in a sequence like...
;.\?.lua;c:...(long file path)\Debug\?.lua; I assume the ; means the end of the path, but I have no idea what the .\?.lua means. Any Lua file in the directory?
You can customize the way require loads modules by putting your own loader into the package.loaders table. See here:
http://www.lua.org/manual/5.1/manual.html#pdf-package.loaders
If you want to be sure that things are nicely sandboxed, you'll probably want to remove all the default loaders and replace them with one that does exactly what you want and nothing more. (It will probably be somewhat similar to one of the existing ones, so you can use those as a guide.)
I wish to store a single variable in my application that will be saved between runs. This will be a version number that will be used to trigger an update option and so will change only rarely.
Does anyone have suggestions on the best way of implementing this? Considering it's such a simple requirement I am interested in the simplest solution.
Thanks!
Normally, that sort of information will be held in a constant (not a variable) in the binary, and the binary will contact an external site to find out whether there is a more recent version of the software. When it downloads the new, the newly downloaded file will have a new constant embedded in it.
Alternatively, you could keep the information in some sort of file in the file system. I'm not familiar with the Symbian environment, but something similar most likely exists.
It has already been mentioned, so I am going to elaborate on it. Create a file in your project directory that will contain the version number. Make that file a part of final SIS file by adding a line about it in the PKG file---for example, put a line in the PKG file to tell the installer to copy the file to a place like c:\System\Apps\${AppName}\${filename} on the device. Within code, read the version number from that file. The advantage you will have from doing it this way is that when you update your code and edit the file in your project directory and recreate an updated SIS file, on updating the SIS on the device, the version file will automatically get replaced with the current one.