I’ve suddenly started getting this error compiling an OS X console application in Fire.
The error is not coming from my code (as far as I can tell) but seems to be something internal in the compiler and seems to be fairly late in the process, occuring after/during the “generating output” stage.:
mono /Applications/Fire.app/Contents/Resources/Mono/lib/mono/4.5/xbuild.exe /var/folders/68/gw5g_t9j2qn6kwpw19l0knr00000gn/T/Untitled.fire.temp.sln /nologo /target:Build /verbosity:normal /property:Configuration=Debug “/property:ElementsXbuildNougatSDKFolder=/Applications/Fire.app/Contents/Resources/Nougat SDKs” “/property:ElementsXbuildReferencePathsXMLFolder=/Applications/Fire.app/Contents/Resources/Reference Paths with Data Abstract Trial” /toolsversion:4.0
If I try and build from Visual Studio (on the same Mac via Croxxbox, naturally) Visual Studio just crashes (jumps down a hole, disappears, vanishes without trace - no errors, no messages, nothing).
Any clues ?
Solution attached (also contains a .NET application which compiles and runs fine both as a mono solution under Fire and .NET under VS).Graphene.zip (248.6 KB)
Um, that’s good to know but can anyone help me resolve the problem in my particular case ? What is it about this project/solution that causes the problem ? Was it a corrupt project file that I can fix by re-creating the project from scratch (a new empty Console application compiles just fine).
Is it something in my code that I can change or work-around ?
I would have posted that, however a different problem showed after fixing your issue so the workaround useless. Next v (tomorrow’s release actually) fails on the array assignment from var x: array[0..1023] of Byte; to ByteArray
because in Nougat, “x” is stackbased, and bytearray is a heap based dynamic array, it should never let you pass it that way,changing it to var x: array of Byte := new Byte[1024] fixes that.
But that ended up failing on your extension methods on the bytearray, a bug in the extension code, which I also fixed. I just don’t have a workaround till you have the build.
If you really want to work around it, turn your extension methods into some static methods on a static class, or global methods, that or wait till tomorrow when the build is out.
Thanks for the details Carlo (sidebar: any idea when the Bugs Database will be opened up for access? presumably then these sorts of details would be accessible there).
I was afraid I might be needing a new build. My subscription just expired (literally, 3 days ago!) and the $'s went toward buying the MacBook I’m doing this all on. So I can’t get any new builds for a while.
Looks like I’ll have to look into the static methods approach, which is a shame - those extension methods are sweet as!
A while back we decided instead of opening up our bug tracker, we’d implement synchronization with this forum. As you can see from the “RemObjects Bugs Bot” above, it shows when a bug is logged, and when it gets closed. Our bugtracker itself doesn’t really have much more information in it related to workarounds, when I have those I usually post them here. What it does have is a lot of things we can’t make public. It would be a gigantic effort to open that up, time we’d rather spend on well, fixing things.
That said, we’re open for suggestions on what we can change, what information you’d want to see from the bugtracker.
Ah I see. Hard to think of suggestions without knowing what’s in the bugs system. But (puts on “Speculation” Hat) presumably there is some one-liner description associated with a given bug # ? I don’t know how hard it would be to have that incorporated in those auto-generated (?) posts here, as well as the bug # ?
e.g. (and again, totally speculating at how you might have described the problem internally here…)
Thanks, logged as bugs://75130 75130: Using fixed array where dynamic array expected (should be compiler error, causes crash)
At that point though the title of the bugreport is “Error: Invalid constant reference” build failure" with the first post as body, sometimes we adjust the title, but more often than not we leave it as is. A little later someone takes or assigns that bug and tries to solve it.
Once someone looks at it we know what the bug is, if it’s a bug at all etc. Once fixed when we resolve the bug in the bugtracker the @RemObjectsSoftware bot replies here that it got fixed with the status. Often if there’s a workaround we open the talk post associated with it and reply.
So when the first reply comes in, there’s not much, if anything to add to the report. When closing the bug we do sometimes update the title when it makes sense, but at that point it’s kinda late.
Fwiw, i do wanna look at providing a list of (public subset of) bugs own thew website, with issue id, title, priority and target release. just haven’t gotten around to it yet, and it’s mad more difficult by the fact that i have existing code that walks tom our budge for internal tillage that i wanna reuse, but that code is all async (pads himself on the back), but while that is awesome for GUIn client apps, it make that code harder to use in the context of a ASP.NET website. I need a day where i am bore and have nothing else to do, and i’ll work own this further
Hmmm, that’s a little different from the workflow we had in a previous incarnation when I worked for a product company (though not software development tools).
In our case (different, not necessarily better). The initial issue was recorded with the user/reporter’s own words (suitably edited for conciseness). The issue would be investigated under that title (since there was nothing else to go on at that point). Once the underlying problem (or functionality gap) was identified then the issue would be re-categorised as required (bug, as-designed, enhancement, documentation etc). This would often be before the issue had been fixed, but in simple cases the fix would happen as part of the investigation, but we would still re-categorise.
If the issue was found to be different than the symptom as reported the title would be changed to reflect the actual issue, as opposed to the symptom in the specific users case (this wasn’t always different of course).
We used FogBugz which enabled us to email directly from the issue (subject: (Case #) Issue title). If the recipient replied to that email (via email) then that reply went to a FogBugz address which would identify the case from the subject and add that reply to the case history.
As I say, not that I’m trying to suggest this was “superior”, jut noting a difference in the workflow and perhaps capabilities in the tools involved, which of course informs how I might think a similar system might be used.
when the build is out.
