I would like to share data between a plugin and my main function (this is, use it outside the call to the SCIPsolve function). For example, a branching rule sets a certain int variable to 1 and then, after the optimization is done I can go and check wether the variable was changes or not.
I thought I could accomplish this by using the plugin data (e.g. SCIP_BranchruleData) but it can't be accessed from outside the plugin's source file.
How can I do it?
I will appreciate any help.
Rodolfo
An easy solution is to add a getter function to the branchrule which you implement in branch_xyc.c and prototype in branch_xyz.h. Then your code needs to include the header file and you can access the fields in the branchdata.
See also the documentation of branch_allfullstrong.cpp where an external function is defined and you can see how to get the branchdata and branchrule when passing just a SCIP pointer.
Related
In my project I use function, which calles find_library(...). Function is defined in SomeScript.cmake.
It works fine if called one time. But now I want to use it several time in my project. The problem is
that find_library caches the first result, and simply doesn`t run again.
So, the part I don't understand - function should provide it's own scope. But it looks like that there is,
only one "copy" of the function with all variables cached. Is it really so? And is there a correct way to use
find_library(...) inside a user function?
I prefer working with files that are less than 1000 lines long, so am thinking of breaking up some Erlang modules into more bite-sized pieces.
Is there a way of doing this without expanding the public API of my library?
What I mean is, any time there is a module, any user can do module:func_exported_from_the_module. The only way to really have something be private that I know of is to not export it from any module (and even then holes can be poked).
So if there is technically no way to accomplish what I'm looking for, is there a convention?
For example, there are no private methods in Python classes, but the convention is to use a leading _ in _my_private_method to mark it as private.
I accept that the answer may be, "no, you must have 4K LOC files."
The closest thing to a convention is to use edoc tags, like #private and #hidden.
From the docs:
#hidden
Marks the function so that it will not appear in the
documentation (even if "private" documentation is generated). Useful
for debug/test functions, etc. The content can be used as a comment;
it is ignored by EDoc.
#private
Marks the function as private (i.e., not part of the public
interface), so that it will not appear in the normal documentation.
(If "private" documentation is generated, the function will be
included.) Only useful for exported functions, e.g. entry points for
spawn. (Non-exported functions are always "private".) The content can
be used as a comment; it is ignored by EDoc.
Please note that this answer started as a comment to #legoscia's answer
Different visibilities for different methods is not currently supported.
The current convention, if you want to call it that way, is to have one (or several) 'facade' my_lib.erl module(s) that export the public API of your library/application. Calling any internal module of the library is playing with fire and should be avoided (call them at your own risk).
There are some very nice features in the BEAM VM that rely on being able to call exported functions from any module, such as
Callbacks (funs/anonymous funs), MFA, erlang:apply/3: The calling code does not need to know anything about the library, just that it's something that needs to be called
Behaviours such as gen_server need the previous point to work
Hot reloading: You can upgrade the bytecode of any module without stopping the VM. The code server inside the VM maintains at most two versions of the bytecode for any module, redirecting external calls (those with the Module:) to the most recent version and the internal calls to the current version. That's why you may see some ?MODULE: calls in long-running servers, to be able to upgrade the code
You'd be able to argue that these points'd be available with more fine-grained BEAM-oriented visibility levels, true. But I don't think it would solve anything that's not solved with the facade modules, and it'd complicate other parts of the VM/code a great deal.
Bonus
Something similar applies to records and opaque types, records only exist at compile time, and opaque types only at dialyzer time. Nothing stops you from accessing their internals anywhere, but you'll only find problems if you go that way:
You insert a new field in the record, suddenly, all your {record_name,...} = break
You use a library that returns an opaque_adt(), you know that it's a list and use like so. The library is upgraded to include the size of the list, so now opaque_adt() is a tuple() and chaos ensues
Only those functions that are specified in the -export attribute are visible to other modules i.e "public" functions. All other functions are private. If you have specified -compile(export_all) only then all functions in module are visible outside. It is not recommended to use -compile(export_all).
I don't know of any existing convention for Erlang, but why not adopt the Python convention? Let's say that "library-private" functions are prefixed with an underscore. You'll need to quote function names with single quotes for that to work:
-module(bar).
-export(['_my_private_function'/0]).
'_my_private_function'() ->
foo.
Then you can call it as:
> bar:'_my_private_function'().
foo
To me, that communicates clearly that I shouldn't be calling that function unless I know what I'm doing. (and probably not even then)
I'd like to have a project-wide variable which I can change during looking at that project. In other words, I'd like to get it affected whenever opening a file. Yes, I know .dir-locals.el exist in Emacs world. But I think it would be reset to the value set in .dir-locals.el whenever opening a file under that project.
Could I get some hints from you, please?
For this kind of thing you might want to use a function instead of a variable (directly). Specifically, use a getter and setter function.
All of your project code can invoke the getter function to get the value (which can be cached in a variable). And all of your code can invoke the setter function to change the value (which, again, can be cached in a variable).
These functions can be visible globally to your project. The cache variable would be accessed only by the getter and setter functions.
But as for code everywhere in your project being informed when the value gets updated and do what's appropriate with the new value whenever that happens, see #Phil's comment about the use of a variable - the same considerations apply.
You can have a hook in the setter function (or advise it), so that it does something additional (e.g. informs interested/subscribed code) whenever it updates the value.
For a variable you can do something similar using, as #Phils said in a comment, using add-variable-watcher.
For a user-option variable you can do something similar using :set and :get functions in the defcustom. (But those take effect only if changes are made using appropriate Customize functions or the Customize UI.)
You can eval in the dir-locals.el So, if you have a variable my-var that you want to be able to change with setq you could do something like
((nil . ((eval . (or (boundp 'my-var) (setq my-var 'default))))))
There are warnings about using eval in a dir-local though, since any code could be run there.
I have a variable currently set globally, that I am using in two different require() functions. How can I have it passed from first require() to the other?
As far as I know: you don't. The only way to make them read the same data is by putting it somewhere so they both can read it. Because both require() functions are placed inside a normal JavaScript file, the only scope they share is the global scope.
The other possibility is by passing it to the callback function of the require(), but that means you have to write a "module" that returns your data (or use dojo/text plugin to read a file read-only).
It's not recommended to have two require() statements at all. If we're still talking about the same stopwatch (I've read your code a bit), you should put all event handlers in one require() block. Then you can put the data they both need inside that require() block and they will all be able to read it.
Some reasons why having multiple require() blocks is not beneficial:
Harder to read/maintain: If you have multiple require() blocks, it's confusing. Most people don't use it anyways (recommended or not).
More duplicates: If you're using common modules like dojo/query and dojo/dom, you will have to add them to your module list every time. I don't think it will download the file twice, but it's still more to write/maintain.
Scope issues: As you just noticed, you will have scoping issues like this when multiple require() blocks needs to access the same data. This means you have to put them in global scope (which is another bad practice), write a module with just plain data (not really useful) or you have to wrap both of them in a function, which you have to execute manually (confusing)
Seperation concerns: If you have a valid reason to seperate them, you should be seperating them into modules.
I've written a module to work with IBMs ClearCase through Powershell. At first it just contained a couple of often used functions, but now I'm expanding it. Most of the commands have to use a ClearTool object ($ct = new-object ClearCase.ClearTool), but I'd rather not have to recreate that object in every function call as it's a bit of overhead.
I also create a ClearCase view in many of these functions, but I can simply check for existence of the view and decide not to recreate it.
My question is, what's the best pattern for this? I can have a "create ct object" function and put the onus on the calling code to maintain it, but I don't think I like that method. Is it possible to have a module-wide variable for the ClearTool object and have Powershell check to see if it's filled before trying to recreate it each time?
Thanks!
In the end I created a couple of module-wide variables. I could hide them if necessary, although I haven't explicitly done that yet. I have a single function to create a view which must be called before doing any actual work and included in that is code to create the ClearTool object. I also have code to set the module-wide variables with the correct ClearTool object for use in other functions and the name of the view.
In the code of each of the functions if the ClearTool object ($ct) has not yet been set, they return an error condition.