My ultimate goal here is to get the system FLEXI-TRIVIAL-DIRED (http://common-lisp.net/project/ftd/) to compile, which I'm having trouble with because I can't find one of the required packages, CFFI-UNIX anywhere.
Does anyone know what happened to it, why it originally existed, if it was merged into another project, why this was, etc.
The system used to "provide a portable interface to Unix functionality, with a focus on networking". Looking at the source of FTD, you can see it calling cffi-unix::getgrgid. This functionallity is now provided (superseded) by osicat.
Related
I know its default value is 500 but I don't want to rely on it. It seems like a really basic thing but I couldn't find an answer.
There is no separate mechanism to read this value, because SQLite's compilation options are set when you compile the library, so you already know it.
If you use a library compiled by someone else, then you are at the mercy of whoever did this. This is why it is recommended to compile your own copy.
I'm stuck using the 4.0 version of lua which does not seem to support the os library. Is there a way to include this library into my project?
Or get another way to use the functionality contained within pertaining to date time calculations?
Preferably by using a *.lua file and not a *.c file since I don't have complete access to the code.
When I run the following line,
print(os.time{year=1970, month=1, day=1, hour=0})
I get an error stating:
attempt to index global 'os'(a nil value)
As #Colonel Thirty Two said it's not possible to use the os library. So the time() funciton is not available for me.
Adding to the (totally correct) currently accepted answer (that if "os" access was not allowed to you, you're generally done), there's some very slight chance the Original Programmer may have provided you with some alternative facilities to do your thing (fingers crossed). In a perfect world, those would be described in some kind of a User's Manual for your scripting environment. But if the manual was lost to time (or never existed in the first place), you might possibly try your luck at exploring any preloaded libraries by digging through the result of the globals() Basic Function. (At least I hope that's how it was done in 4.0 too.) That is, if the Original Programmer didn't block globals() for you too...
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'm not sure if this is standard behavior for IDEs, but I personally find it irritating. If a file produces warnings when built (unused variables, mismatched ints/longs/etc.), those warnings will cease to be displayed if another file is modified and the "Build project" button is clicked. Doesn't it make more sense for warnings pertaining to unmodified code to continue to be displayed? Is there a way to force this behavior?
The warnings are displayed when the compiler emits them -- unfortunately, that's the design decision taken by both VS team (up to 2008 at least) and by Qt Creator team.
It seems to be standard behavior, and I don't know of any options to override it. It should be easy to fix in Qt Creator, but may be hard to fix in Visual Studio unless relevant APIs are present. For VS you'd need to write an add-in and there would need to be an API available that gives you read-write access to the error list and to the build process. If such APIs exist, then it'd be a simple thing to do as well.
This is "standard behavior", and more specifically, behavior is an attribute of how build systems on Earth "are-designed-to-behave".
As #Kuba notes, the warnings are emitted by the compiler. They aren't stored (except in the "log-of-all-errors/warnings" for the build operation, which the IDE typically never reads-back-and-excerpts-from-for-future-build-operations, which would get their own log of their new warnings/errors). Thus, you won't see the warning again unless the compiler actually compiles the file again, and that's because they would be new warnings that are generated again by the new build operation.
To get what you want (a clever thought, IMHO), the build system would need to:
store warnings from each file-compile (probably on a "per-file-basis")
recall/display those warnings each time that file-output-product was "used"
Very clever. I'm not aware of any system that does that. It would require fairly significant IDE or build-tool-level management of build products, which IMHO, none of them do well (but some are better than others).
This is the year 2012, and not only are we missing our flying cars, but we're missing build systems that merely/quickly build-only-what's-required-using-all-cores while easily handling different configurations. Both were expected by now.
Then, sometime after that, you could probably get your feature. That would be a bonus, because then you could use it in your flying car.