I'm trying to integrate CocoaLumberjack into a project that I inherited. I've seen it work fine in the past with other projects, but for some reason, I'm getting several errors in CocoaLumberjack's code. Examples include:
Suddenly I'm getting "Assigning to 'void *' from incompatible type 'const char [1]'" compile errors on struct properties when passing in a C string.
I'm getting warnings on C arrays of C strings saying "Conversion from string literal to 'char *' is depreciated.
"class" has suddenly become a keyword (the lowercase version)
Has anyone ever seen anything similar to this? The build settings on the project have definitely been changed a bit, but I'm not sure what was done.
Any chance you're accidentally compiling the code as C++/Obj-C++? The third point there with class becoming a keyword makes that sound plausible.
i have had this happen in vs, where the errors show up from newest to oldest as the compiler runs through the source code.Try to if your doing something like this always remember to trace to the first error and go from there. I have had some pretty crazy results by putting a semicolon (;) after an include statment
ie
<string>;
<vector>;
will throw a crazy set of errors if it is in the wrong place.
Related
I am getting an error only when the code is entered line by line in the repl. It works when the whole program is pasted at once, or from the command line.
class A {
method a () {
return 1;
}
}
class B {
method b () {
return 2;
}
}
This is the error statement:
===SORRY!=== Error while compiling:
Package 'B' already has a method 'b' (did you mean to declare a multi method?)
This screen shot might make it clearer. On the left I just pasted the code, and on the right I entered it line by line. The code is still working but what is causing the error?
For some reason, I could not reproduce this using just one class.
I can reproduce that error, and looks like a REPL bug, or simply something the REPL is not prepared to do. This, for instance, will also raise an exception:
class A {
method a() {
return 1;
}
};
class foo {
has $.bar = 3;
};
In either form, either pasting it directly or in pieces. It's always the second class. It's probably related to the way EVAL works, but I really don't know. At the end of the day, the REPL can only take you so far and I'm not totally sure this is within the use case. You might want to use Comma or any other IDE, like emacs, for anything that's more complicated than a line; Comma also provides help for evaluating expressions, and even grammars.
I think Comma is the bees knees. And I almost never use the repl. But I enjoy:
Golfing Your example is a more than adequate MRE. But I love minimizing bug examples.
Speculating I think I can see what's going on.
Searching issue queues Rakudo has two issue queues on GH: old and new.
Spelunking compiler code Rakudo is mostly written in Raku; maybe we can work out what this problem is in the REPL code (which is part of the compiler)?
Golfing
First, the bug:
Welcome to 𝐑𝐚𝐤𝐮𝐝𝐨™ v2021.03.
Implementing the 𝐑𝐚𝐤𝐮™ programming language v6.d.
Built on MoarVM version 2021.03.
To exit type 'exit' or '^D'
> # 42
Nil
> { subset a
*
===SORRY!=== Error while compiling:
Redeclaration of symbol 'a'.
at line 3
------> <BOL>⏏<EOL>
Commentary:
To get on the fairway, enter any line that's not just whitespace, and press Enter.
Pick the right iron; open a block with {, declare some named type, and press Enter. The REPL indicates you're on the green by displaying the * multi-line prompt.
To sink the ball, just hit Enter.
Second, golfing in aid of speculation:
> # 42
Nil
> { BEGIN say 99
99
* }
99
>
(BEGIN marks code that is to be run during compilation as soon as the compiler encounters it.)
Speculating
Why does the initial # 42 evaluation matter? Presumably the REPL tries to maintain declarations / state (of variables and types etc) during a REPL session.
And as part of that it's presumably remembering all previous code in a session.
And presumably it's seeing anything but blank lines as counting as previous code.
And the mere existence of some/any previous code somehow influences what state the REPL is maintaining and/or what it's asking the compiler to do.
Maybe.
Why does a type declaration matter when, say, a variable declaration doesn't?
Presumably the REPL and/or compiler is distinguishing between these two kinds of declaration.
Ignoring the REPL, when compiling code, a repeated my declaration only raises a warning, whereas a repeated type declaration is an error. Quite plausibly that's why?
Why does a type declaration have this effect?
Presumably the type successfully compiles and only after that an exception is thrown (because the code is incomplete due to the missing closing brace).
Then the REPL asks the compiler to again try to compile the multi-line code thus far entered, with whatever additional code the user has typed (in my golf version I type nothing and just hit Enter, adding no more code).
This repeated compile attempt includes the type declaration again, which type declaration, because the compilation state from the prior attempt to compile the multi-line code is somehow being retained, is seen by the compiler as a repeat declaration, causing it to throw an exception that causes the REPL to exit multi-line mode and report the error.
In other words, the REPL loop is presumably something like:
As each line is entered, pass it to the compiler, which compiles the code and throws an exception if anything goes wrong.
If an exception is thrown:
2.1 If in multi-line mode (with * prompt), then exit multi-line mode (go back to > prompt) and display exception message.
2.2 Else (so not in multi-line mode), if analysis (plausibly very basic) of the exception and/or entered code suggests multi-line mode would be useful, then enter that mode (with * prompt). In multi-line mode, the entire multi-line of code so far is recompiled each time the user presses Enter.
2.3 Else, display exception message.
(Obviously there's something else going on related to initialization given the need to start with some evaluation to manifest this bug, but that may well be a completely distinct issue.)
Searching
I've browsed through all open Rakudo issues in its old and new queues on GH that match 'repl'. I've selected four that illustrate the range of difficulties the REPL has with maintaining the state of a session:
REPL loses custom operators. "Interestingly, if a postfix operator like this is exported by a module which is loaded by the REPL, the REPL can successfully parse that operator just once, after which it will fail with an error similar to the above." Is this related to the way the bug this SO is focused on doesn't manifest until it's a second or later evaluation?
Perl6 REPL forgets the definition of infix sub. Looks like a dupe of the above issue, but includes extra debugging goodies from Brian Duggan. ❤️
REPL messes up namespaces when Foo is used after Foo::Bar.
In REPL cannot bind to scalars declared on earlier lines.
One thing I haven't done is checked whether these bugs all still exist. My guess is they do. And there are many others like them. Perhaps they have a somewhat common cause? I've no idea. Perhaps we need to look at the code...
Spelunking
A search of the Rakudo sources for 'repl' quickly led to a REPL module. Less than 500 lines of high level Raku code! \o/ (For now, let's just pretend we can pretty much ignore digging into the code it calls...)
From my initial browser, I'll draw attention to:
A sub repl:
sub repl(*%_) {
my $repl := REPL.new(nqp::getcomp("Raku"), %_, True);
nqp::bindattr($repl,REPL,'$!save_ctx',nqp::ctxcaller(nqp::ctx));
$repl.repl-loop(:no-exit);
}
Blame shows that Liz added this a couple months ago. It's very tangential to this bug, but I'm guessing methods and variables with ctx in their name are pretty central to things so this is hopefully a nice way to start pondering that.
method repl-eval. 30 lines or so.
REPL: loop { ... }. 60 lines or so.
That'll do for tonight. I'll post this then return to it all another day.
I am attempting to install a help browser starting from
http://www.walletfox.com/course/qhelpengineexample.php
For the line
tWidget->addTab(helpEngine->contentWidget(), tr("Contents"));
I receive error message
no known conversion from QHelpIndexWidget* to QWidget*
and really, if I make explicite casting with
tWidget->addTab((QWidget*)helpEngine->contentWidget(), tr("Contents"));
the program compiles and runs fine. What is going on here?
Most likely you forgot to #include <QHelpIndexWidget>.
Then the compiler can't deduct that a QHelpIndexWidget inherits from QWidget.
If you would try to access the QHelpIndexWidget*, like e.g.
qDebug() << helpEngine->indexWidget()->objectName();
without the include, you would get the better compiler error "QHelpIndexWidget is of incomplete type" or similar, which means that the type is forward declared, but the complete declaration is not accessible.
Additionally, I would suggest avoiding c-style casts and use static_cast<TYPE>(var) instead.
I am trying to compile a Xamarin.Mac project with Monodevelop+Monomac (3.0.5 from source).
I changed the reference from XamMac to MonoMac, and everything seems to be fine except this:
Error CS0019: Operator '==' cannot be applied to operands of type 'MonoMac.Foundation.NSObject' and 'string' (CS0019)
The error occurs at a line if (tableColumn.Identifier == "Name") where tableColumn is a NSTableColumn.
Can I make this compile without modifying the code?
Or if I must modify the code, what is the best practice in this case?
surely....
if (tableColumn.Identifier.Equals("Name"))
would be better?
XamarinMac most likely has operator for == between NSString/NSObject and string. Either modify MonoMac source code to add the operator (nice chance to contribute to the community edition) or change your code to compare NSString("Name") instead of string.
My error message is as listed in the header "Input string was not in a correct format" however the stack trace is even more cryptic
Microsoft.VisualBasic.CompilerServices.Conversions.ParseDouble(String Value, NumberFormatInfo NumberFormat) at Microsoft.VisualBasic.CompilerServices.Conversions.ToDouble(String Value, NumberFormatInfo NumberFormat)
This is worse due to the fact that nowhere in the project does it use "ParseDouble". I believe that this has something to do with the objectfactorylibrary but can't pin anything down.
Has anyone seen something similar or point me in a general direction?
Edit:
Additional information, this is a production only issue with local, dev, and QA unable to reproduce the error in any environment but Production.
The stack trace is referring to a method inside of the .NET Framework code, called ParseDouble. It does not exist in your code. This is why the entire namespace is included, so that you can tell where the method is defined. If it starts with Microsoft or System, it's not something you wrote.
You probably used the CDbl operator (it's that thing that looks like a function call to the uninitiated), and internally, the .NET Framework translated that to a call to the Conversions.ToDouble method, which internally calls the Conversions.ParseDouble method. These are implementation details that you should not have to be concerned with. Keep traveling up the stack trace until you find the last method called that is part of your code.
As far as why your code is throwing that error, it's almost impossible to say without seeing some code that reproduces it.
However, my psychic debugging powers tell me that you're probably trying to parse a string value into a number, and the method is failing because the string does not contain a valid number. Check the value of the string you're passing into the method and update your question. It's probably an issue of the language settings on your computer. Do you use a language where , (a comma) is the decimal separator rather than . (a period)?
It's basically telling you that you that it tried to convert a string to a number but couldn't as the string was not numeric (could have alpha or other characters in it).
The stack trace should point you towards the offending piece of code, if you're lucky you will have a line number. If this is a piece of code that usually works then take a look at the data (whatever it is).
Today I discovered that something I had assumed about VB.NET for many years was not true (worrying!). I assumed that a variable declared within a loop had a lifetime of the iteration it was declared in, but in fact it seems it has a lifetime of the whole procedure.
For example:
For i As Integer = 0 To 1
Dim var1 As Boolean
Console.WriteLine(var1.ToString())
var1 = True
Console.WriteLine(var1.ToString())
Next
Console.ReadKey()
I had assumed an output of False, True, False, True but instead it is actually False, True, True, True.
In C# the equivalent code would not compile as you would get a compile time error of Error "Use of unassigned local variable 'var1'".
I realise there are many ways to fix this and that best practice would be to declare the variable outside of the loop and reset it at the beginning of every loop through.
I find this behaviour so counter-intuitive to me that I would like at least a compile time warning in VB.NET when/if I do this. (I could also then set this on any projects I already have and get warning that would allow me to check that my assumptions aren't causing errors).
Does anyone know how/if I can get this to generate a compile time warning in VB.NET? Am I the only one that finds this counter-intuitive?
We'll have to work on fixing your intuition because getting an error out of the compiler is not an option. It is partially implemented, you can get this warning:
error BC42104: Variable 'mumble' is used before it has been assigned a value. A null reference exception could result at runtime.
And elevate it from a warning to an error with Project + Properties, Compile tab. However, as the warning message indicates, this is only supported for reference type references, it won't budge for a variable of a value type.
Okay, intuition. If the runtime would implement your desired behavior then it would have to allocate a new variable for each iteration of the loop. Which implies that the number of local variables is bounded only by the number of iterations. This is very wasteful and a very easy trigger for StackOverflowException. The JIT compiler doesn't do this, it re-uses the variable. This happens in C# as well, minus the option of letting you not initialize the value explicitly of course.
Fwiw: I very much agree with you that this is unhelpful behavior. You'll probably find receptive ears at connect.microsoft.com, post your feature request there and the VB.NET team will see it. There has been strong backing from customers as well as within MSFT to make VB.NET and C# feature comparable. If you post a link to your feedback report then I'll be happy to vote it up.