I have 2 classes lets call them A and B, I also have a function that converts an instance of A to an instance of B.
My code that is causing issues is basically:
fun fromAtoB(a: A) = B (fb1 = a.fa1, fb2 = a.fa2, fb3 = a.fa3)
val listOfA: List<A> = ...
val listOfB: listOfA.map { fromAtoB(it) }
This won't build due to the line:
fromAtoB(it)
With the error:
Due to the error Type checking has run into a recursive problem. Easiest workaround: specify types of your declarations explicitly
I Have no clue what I can do to fix this, Google had provided no results that seem to apply to my issue...
Thanks in advance for any help!
EDIT:
Here are the actual source files:
TenantEntity.kt - https://pastebin.com/mdSWiA1Y (Line 51 of this file
is the issue)
TenantDto.kt - https://pastebin.com/83UP9Cwe
ReceiptEntity.kt - https://pastebin.com/BjP2ikg9
ReceiptDto.kt - https://pastebin.com/Kpt9dSAp
This type of problem means that the compiler can't infer what the type of listOfB should be, because you have a recursive call somewhere in its definition. That's curious as I can't see any in your example code, but maybe you left out the offending code inadvertently. Anyways, this problem is usually resolved by doing what the error message suggests, manually specifying the return type like so:
val listOfB: List<B> = listOfA.map { fromAtoB(it) }
Edit:
After trying the real code, I just went after a hunch and changed line 45 in TenantEntity.kt from this:
fun fromDto(dto: TenantDto) = TenantEntity (
to this:
fun fromDto(dto: TenantDto): TenantEntity = TenantEntity (
and the error was gone. I'm not really sure why, but it should compile now.
Second edit:
Upon further inspection, you're going to run into a StackOverflowException with this code, which is ultimately why the compiler couldn't resolve the type. When you call TenantEntity.fromDto(...), that will call ReceiptEntity.fromDto(...), which will in turn call TenantEntity.fromDto(...), and back again, into eternity (or the stack limit). That's not going to work, you'll need to fix your logic there.
Related
Google turns up nothing on this error: Combination of indirect name lookup and call not supported
My code:
use Vimwiki::File::TextProcessingClasses;
unit class Vimwiki::File::ContentStr;
has Str $.content;
method process($class) {
$!content = Vimwiki::File::TextProcessingClasses::($class).process($!content);
}
The compiler is not happy with this and complains with aforesaid error. If I hard-code in in the $class name, everything works.
Anyway around this?
OK, solution is to precede the package name with ::, like so:
$!content = ::Vimwiki::File::TextProcessingClasses::($class).process($!content);
Documentation is here: https://docs.raku.org/language/packages#Looking_up_names
Though I don't know precisely why what I was doing originally behaves differently.
I am trying to abstract inserting objects of different types into sql tables of similar structure. Here's what I'm trying to do:
class TableAccess[A : Meta](table: String) {
def insert(key: String, a: A): ConnectionIO[Unit] = {
(fr"insert into " ++ Fragment.const(table) ++ fr" values ($key, $a);").update.run.map(_ => ())
}
}
But I get this compile error:
[error] diverging implicit expansion for type doobie.util.param.Param[A]
[error] starting with method fromMeta in object Param
[error] (fr"insert into " ++ Fragment.const(table) ++ fr" values ($key, $a);").update.run.map(_ => ())
All I can find in the documentation is:
doobie allows you to interpolate values of any type (and options
thereof) with an Meta instance, which includes...
But it seems that is not enough in this case; what's the right typeclass/imports/conversions I need?
I'll go ahead an answer my own question, almost a year later. I never fully understood what was happening, and I have since updated to a newer version of doobie, so I am not sure how relevant this is. But now the documentation contains this clue:
Note: it is important to understand that Meta exists only to introduce
Get/Put pairs into implicit scope. You should never demand Meta as
evidence in user code: instead demand Get, Put, or both.
def foo[A: Meta](...) // don't do this
def foo[A: Get: Put](...) // ok
And indeed, between that change and the new version, this now compiles just fine for me:
class TableAccess[A: Get: Put](table: String) {
When the compiler is resolving implicit its searches for one of a specific type in the current scope. Here it seems like his finding more than one in his tree search.
It's not a matter of a missing typeclass or imports, it's more like you have too many of them and the compiler cant figure the right one.
Try removing some implicit and see how that works or pass them explicitly.
One way I resolved this was to localize the type parameters (and their evidence) onto the method (on a static/companion object), and then it compiled.
Something like
object MinimalGood {
def good[A: Meta, B: Meta](a: A, b: B): Update0 =
sql"""$a $b""".update
}
In the process of learning Rust, I am getting acquainted with error propagation and the choice between unwrap and the ? operator. After writing some prototype code that only uses unwrap(), I would like to remove unwrap from reusable parts, where panicking on every error is inappropriate.
How would one avoid the use of unwrap in a closure, like in this example?
// todo is VecDeque<PathBuf>
let dir = fs::read_dir(&filename).unwrap();
todo.extend(dir.map(|dirent| dirent.unwrap().path()));
The first unwrap can be easily changed to ?, as long as the containing function returns Result<(), io::Error> or similar. However, the second unwrap, the one in dirent.unwrap().path(), cannot be changed to dirent?.path() because the closure must return a PathBuf, not a Result<PathBuf, io::Error>.
One option is to change extend to an explicit loop:
let dir = fs::read_dir(&filename)?;
for dirent in dir {
todo.push_back(dirent?.path());
}
But that feels wrong - the original extend was elegant and clearly reflected the intention of the code. (It might also have been more efficient than a sequence of push_backs.) How would an experienced Rust developer express error checking in such code?
How would one avoid the use of unwrap in a closure, like in this example?
Well, it really depends on what you wish to do upon failure.
should failure be reported to the user or be silent
if reported, should one failure be reported or all?
if a failure occur, should it interrupt processing?
For example, you could perfectly decide to silently ignore all failures and just skip the entries that fail. In this case, the Iterator::filter_map combined with Result::ok is exactly what you are asking for.
let dir = fs::read_dir(&filename)?;
let todos.extend(dir.filter_map(Result::ok));
The Iterator interface is full of goodies, it's definitely worth perusing when looking for tidier code.
Here is a solution based on filter_map suggested by Matthieu. It calls Result::map_err to ensure the error is "caught" and logged, sending it further to Result::ok and filter_map to remove it from iteration:
fn log_error(e: io::Error) {
eprintln!("{}", e);
}
(|| {
let dir = fs::read_dir(&filename)?;
todo.extend(dir
.filter_map(|res| res.map_err(log_error).ok()))
.map(|dirent| dirent.path()));
})().unwrap_or_else(log_error)
I'm getting the following error when trying to execute my custom build definition (containing only 1 custom CodeActivity):
Exception Message: Expression Activity type 'CSharpReference`1' requires compilation in order to run. Please ensure that the workflow has been compiled. (type NotSupportedException)
I've tried multiple suggested answers to this error, but none of them are applicable to my activity. My CodeActivity only has a couple of methods that search through directories for specific files, and then returns a delimited string containing the file names.
I don't use any WorkflowInvoker or any DynamicActivities. For what reason would I keep getting this error?
Thanks
I had the same error on an assignment step.
System.NotSupportedException: Expression Activity type 'CSharpValue`1' requires compilation in order to run.
Please ensure that the workflow has been compiled.
The resolution was to remove the carriage returns from statement.
For example this works:
new Foo() { Bar = new Bar() { MyProp1 = "123" } }
This does not:
new Foo()
{
Bar = new Bar()
{
MyProp1 = "123"
}
}
I decided not to work in a clean xaml file, but instead to use the Default Template provided by TFS. The Default template ran my activities without errors.
I was able to fix this solution as well by using the Default Template provided by TFS, clearing all of their activities, and adding the custom activities and arguments in my original custom template.
However, more insight in to this issue, it seems to be caused by the fact that custom template use C# expressions to handle the arguments. Where as the default template is set up to use VB Expressions for it's arguments.
In my case, the language didn't matter because the values were simply strings.
I have this code:
id error;
// a bunch of stuff, including using error
Finalization finalization = ^(int status) {
id error; // <--- Declaration shadows a local variable
// a bunch of stuff, using error
}
// a bunch of stuff, using error
I use GCC_WARN_SHADOW because it's what I want in every case in my code except this one. In this case, it gives me a warning that I want to suppress.
Is there a way to suppress this one shadow warning without turning off GCC_WARN_SHADOW or renaming the inner error to something else? Some way to mark that declaration of error?
I'm using clang with Xcode 4, if it matters.
First, as a matter of opinion, it's really bad karma to shadow a local variable within an inner block (its bad enough shadowing a global variable in a function). Now "error" can take two different values within a function, and until whomever is reading your code figures it out, they will bang their head quite incessantly. I have seen this issue in real life among paid professionals developing apps. I really suggest renaming the inner error variable.
Answering your question, you can use the GCC/clang compiler pragma to suppress a warning.