I am using CuPy for testing cuda kernels from a library. More specifically I use the cupy.RawModule to exploit the kernels in python. However, the kernels are templated and enclosed in a namespace. Before the name_expressions parameter to RawModule in CuPy 8.0.0, I had to copy the c++-mangled names into the get_function() method manually of the RawModule. Using name_expressions I thought that this should be possible, nevertheless, this requires the code to be compiled from source using the code parameter in combination with backend='nvrtc'.
Should it be possible to enable (any of the below)?:
name_expressions in conjunction with path
name_expressions in conjunction with backend='nvcc'
Should it be possible to enable (any of the below)?:
'name_expressions' in conjunction with 'path'
'name_expressions' in conjunction with 'backend'='nvcc'
The answer is no for both questions.
The name_expressions feature requires the source code for just-in-time (JIT) compilation of your C++ template kernels using NVRTC, whereas the path argument is for loading external cubin, fatbin, or ptx code. If you want to compile an external source code, you can do so by loading it in Python first, and then pass it as the code argument:
with open('my_cuda_cpp_code.cu') as f:
code = f.read()
mod = cp.RawModule(code=code, name_expressions=(...), ...)
Unfortunately unlike NVRTC, NVCC does not provide an API to return mangled names, so using NVCC is not possible. If you pass backend='nvcc' to RawModule, it'd raise an error.
I'm new to elixir and phoenix and I wanted to doctest a newly created context (using mix phx.gen.context).
I have an Accounts context with a User schema.
I added to accounts_test.exs the following lines:
alias MyApp.Accounts.User
doctest MyApp.Accounts.User, import: true
And even fixed the default change_user documentation:
- %Ecto.Changeset{source: %User{}}
+ %Ecto.Changeset{data: %User{}}
But I still have many, many, errors and warnings, as if it was basically not made to be doctested...
For example, the default generated doc puts:
iex> update_user(user, %{field: new_value})
{:ok, %User{}}
This would issue:
warning: variable "new_value" does not exist and is being expanded to "new_value()"...
warning: variable "user" does not exist and is being expanded to "user()"...
test/my_app/accounts_test.exs:45: undefined function new_value/0
test/my_app/accounts_test.exs:45: undefined function user/0
My question is: is there something I'm missing? Or is it generally not common to doctest one's context (which would explain why it doesn't work out-of-the-box)
Generally speaking we do not doctest functions that have side-effects, such as context functions that have to read/write to the database, because they would require some amount of setup that is hard to cleanly portray in the doctest itself.
It is certainly doable but you should ask yourself if it is worth the effort. The Phoenix team itself seems to think it isn't. :)
here is the function that worked prior to upgrading to 7.0
function set_session_vars() {
$nb_args=func_num_args();
$arg_list=func_get_args();
for($i=0;$i<$nb_args;$i++) {
global $$arg_list[$i];
$_SESSION[$arg_list[$i]] = $$arg_list[$i];
}
}
now it causer error that says:
Parse error: syntax error, unexpected '[', expecting ',' or ';' in /home/mvyc1956/public_html/members/includes/functions.php on line 322
I believe its related to non backward compatable changes to GLOBAL and the use of $$ and arrays, but my PHP is not good enough to figure it out.
Is there someone who is familiar with why this line :
global $$arg_list[$i];
which is line 322 that is being reported as the cause of the error, would be failing now, and what would you recommend I change the code to in order to have it work with PHP 7?
I did some googling and found this page but again, im not understanding what needs to be changed.
thanks
says syntax error so some of the code in the function is no longer valid, but it would take a php 7 expert to see it.
UPDATE
I removed the word GLOBAL from the above code and the app "seems" to be now working fine so I will now ask:
Does anyone know specifically, why Global was the non compatibility issue? and is my fix of simply removing it a solid one or will is there a better practice or will this removal come back to haunt me?
Backward incompatible changes:
global only accepts simple variables
Variable variables can no longer be used with the global keyword. The curly brace syntax can be used to emulate the previous behaviour if required:
// Valid in PHP 5 only.
global $$foo->bar;
// Valid in PHP 5 and 7.
global ${$foo->bar};
So in your case it should become:
global ${$arg_list[$i]};
The global keyword tells PHP to access a global variable (per launch of the script) instead of a local variable (per function). For example,
global $foo;
means that future uses of the variable $foo in that function refer to the global variable with that name, rather than a variable within the function itself.
What this is trying to do is look up a variable by arbitrary name in the global namespace. That's entirely the wrong way to do things. Instead, you should have a global array and use keys in the array. In fact, $$ is arguably a bad idea in general.
But that's neither here nor there. The problem is that the parsing rules changed in PHP 7.0 in a non-backwards-compatible way (because they're using a more traditional parser now, and thus had to make their associativity rules self-consistent).
More details here:
http://php.net/manual/en/migration70.incompatible.php#migration70.incompatible.variable-handling.indirect
To make a long story short, you need to rewrite that as:
global ${$arg_list[$i]};
and then your code will work correctly on both PHP 7 and PHP 5.
Incidentally, the function only appears to work without the global keyword. In fact, it is always getting empty values for those variables.
There are two packages I want to use: CorpusLoaders.jl, and WordNet.jl
CorpusLoaders.SemCor exports sensekey(::SenseTaggedWord)
WordNet exports sensekey(::DB, ::Synset, ::Lemma)
I want to use both sensekey methods.
Eg
for some mixed list of items: mixedlist::Vector{Union{Tuple{SenseTaggedWord},Tuple{DB, Synset,Lemma}}.
Ie the items in the list are a mixture of 1-tuples of SenseTaggedWord, and3 tuples of DB, Synset, and Lemma.
for item in mixedlist
println(sensekey(item...)
end
should work.
This example is a little facetious, since why would I be mixing them like this.
But, hopefully it serves for illustrating the problem in the general case.
Trying to using CorpusLoaders.SemCor, WordNet to bring in both results in WARNING: both WordNet and Semcor export "sensekey"; uses of it in module Main must be qualified.
Manually importing both: import CorpusLoaders.SemCor.sensekey; import WordNet.sensekey results in WARNING: ignoring conflicting import of Semcor.sensekey into Main
What can be done? I want them both, and they don't really conflict, due to multiple-dispatch.
Given that CorpusLoaders.jl is a package I am writing I do have a few more options, since I could make my CorpusLoaders.jl depend on WordNet.jl.
If I did do than then I could say in CorpusLoaders.jl
import WordNet
function WordNet.sensekey(s::SenseTaggedWord)...
and that would make them both work.
But it would mean requiring WordNet as a dependency of CorpusLoaders.
And I want to know how to solve the problem for a consumer of the packages -- not as the creator of the packages.
tl;dr qualify the functions when using them in your script via their module namespace, i.e. CorpusLoader.sensekey() and WordNet.sensekey()
Explanation
My understanding of your question after the edits (thank you for clarifying) is that:
You have written a package called CorpusLoaders.jl, which exports the function sensekey(::SenseTaggedWord)
There is an external package called WordNet.jl, which exports the function sensekey(::DB, ::Synset, ::Lemma)
You have a script that makes use of both modules.
and you are worried that using the modules or "importing" the functions directly could potentially create ambiguity and / or errors in your script, asking
how can I write my CorpusLoaders package to prevent potential clashes with other packages, and
how can I write my script to clearly disambiguate between the two functions while still allowing their use?
I think this stems from a slight confusion how using and import are different from each other, and how modules create a namespace. This is very nicely explained in the docs here.
In essence, the answers are:
You should not worry about exporting things from your module that will clash with other modules. This is what modules are for: you're creating a namespace, which will "qualify" all exported variables, e.g. CorpusLoaders.sensekey(::SenseTaggedWord).
When you type using CorpusLoaders, what you're saying to julia is "import the module itself, and all the exported variables stripped from their namespace qualifier, and bring them into Main". Note that this means you now have access to sensekey as a function directly from Main without a namespace qualifier, and as CorpusLoaders.sensekey(), since you've also imported the module as a variable you can use.
If you then try using the module WordNet as well, julia very reasonably issues a warning, which essentially says:
"You've imported two functions that have the same name. I can't just strip their namespace off because that could create problems in some scenarios (even though in your case it wouldn't because they have different signatures, but I couldn't possibly know this in general). If you want to use either of these functions, please do so using their appropriate namespace qualifier".
So, the solution for 2. is:
you either do
using CorpusLoaders;
using WordNet;
, disregarding the warning, to import all other exported variables as usual in your Main namespace, and access those particular functions directly via their modules as CorpusLoaders.sensekey() and WordNet.sensekey() each time you need to use them in your script, or
you keep both modules clearly disambiguated at all times by doing
import CorpusLoaders;
import WordNet;
and qualify all variables appropriately, or
in this particular case where the function signatures don't clash, if you'd really like to be able to use the function without a namespace qualifier, relying on multiple dispatch instead, you can do something like what FengYang suggested:
import CorpusLoaders;
import WordNet;
sensekey(a::SenseTaggedWord) = CorpusLoader.sensekey(a);
sensekey(a::DB, b::Synset, c::Lemma) = WordNet.sensekey(a, b, c);
which is essentially a new function, defined on module Main, acting as a wrapper for the two namespace-qualified functions.
In the end, it all comes down to using using vs import and namespaces appropriately for your particular code. :)
As an addendum, code can get very unwieldy with long namespace qualifiers like CorpusLoader and WordNet. julia doesn't have something like python's import numpy as np, but at the same time modules become simple variables on your workspace, so it's trivial to create an alias for them. So you can do:
import CorpusLoaders; const cl = CorpusLoaders;
import Wordnet; const wn = WordNet;
# ... code using both cl.sensekey() and wn.sensekey()
In this case, the functions do not conflict, but in general that is impossible to guarantee. It could be the case that a package loaded later will add methods to one of the functions that will conflict. So to be able to use the sensekey for both packages requires some additional guarantees and restrictions.
One way to do this is to ignore both package's sensekey, and instead provide your own, dispatching to the correct package:
sensekey(x) = CorpusLoaders.sensekey(x)
sensekey(x, y, z) = WordNet.sensekey(x,y,z)
I implemented what #Fengyang Wang said,
as a function:
function importfrom(moduleinstance::Module, functionname::Symbol, argtypes::Tuple)
meths = methods(moduleinstance.(functionname), argtypes)
importfrom(moduleinstance, functionname, meths)
end
function importfrom(moduleinstance::Module, functionname::Symbol)
meths = methods(moduleinstance.(functionname))
importfrom(moduleinstance, functionname, meths)
end
function importfrom(moduleinstance::Module, functionname::Symbol, meths::Base.MethodList)
for mt in meths
paramnames = collect(mt.lambda_template.slotnames[2:end])
paramtypes = collect(mt.sig.parameters[2:end])
paramsig = ((n,t)->Expr(:(::),n,t)).(paramnames, paramtypes)
funcdec = Expr(:(=),
Expr(:call, functionname, paramsig...),
Expr(:call, :($moduleinstance.$functionname), paramnames...)
)
current_module().eval(funcdec) #Runs at global scope, from calling module
end
end
Call with:
using WordNet
using CorpusLoaders.Semcor
importfrom(CorpusLoaders.Semcor, :sensekey)
importfrom(WordNet, :sensekey)
methods(sensekey)
2 methods for generic function sensekey:
sensekey(db::WordNet.DB, ss::WordNet.Synset, lem::WordNet.Lemma)
sensekey(saword::CorpusLoaders.Semcor.SenseAnnotatedWord
If you wanted to get really flash you could reexport the DocString too.
Hi everyone.
I have to work with old utility: which converts xls into txt.
There was a small problem in logic of the utility, but the problem is in other thing...
The utility consists of two parts: exe module and dll module, and uses MFC.
In exe project we have
pInit = (t_bXR_Init)GetProcAddress(hExcel, _T("bXR_Init"));
and
pInit("logfiles",false);
In dll project we have
typedef bool (*t_bXR_Init) (CString const &strlogfilespath, bool btxtfile);
XLSREADER_API bool bXR_Init(CString const &strlogfilespath, bool btxtfile);
The problem is when we send argument "logfiles" into the function it doesn't get it. It's strange, 'cause all other parameters are send properly.
The reason is somehow connected with using of CString. But I don't know how...
XLSREADER_API is defined as:
#define XLSREADER_API extern "C" __declspec(dllimport)
Also I've added
AFX_MANAGE_STATE(AfxGetStaticModuleState());
in the beginning of function's body (for bXR_Init). But it didn't help.
Also I tried to change some settings for these two projects, all settings are the same (e.g. calling conversion is __cldecl(/Gd); I build either debug versions exe and dll or release version of exe and dll simultaneously).
Also I tried to use CString instead of CString& - the same situation. It works properly if use char*, but boss says to find what the origin of the problem is at first.
What may lead to the problem (the function doesn't get CString parameter)?
To pass a complex type such as a CString across a DLL boundary you have to make sure that both the DLL and the exe are using the exact same DLL libraries. Set "Runtime Library" to multi-threaded DLL and set "Use of MFC" to Use MFC in a Shared DLL. Also, don't mix debug and release modules: Both must be the same.
Without these conditions you get two different heaps, and you can't keep the allocations/deletions compatible with two heaps.
Try passing an actual CString parameter to the call:
CString sPath = "logfiles";
pInit(sPath,false);
wtfigo! (what the f is going on)
the problem is solved.
I discovered, that exe project had "character set" = "use multibyte character set"
and dll project had "character set" = "use unicode character set".
So, dll function got CString with char* inside, but considered it as CString with wchat_t* inside. And it looked as garbage (as complete garbage on my pc and as chinese symbols on my workmate's pc).
I changed "character set" for exe project to "use unicode character set" and discovered about 60 errors.
Then I read an article http://habrahabr.ru/post/164193/ (in russian; or in english: http://www.codeproject.com/Articles/76252/What-are-TCHAR-WCHAR-LPSTR-LPWSTR-LPCTSTR-etc).
And fixed all errors, widely used macroses from TCHAR.h (MSDN helped me).
Thanks everybody for your help.