I've got a fairly stock stack based project that uses proto-lens-setup to generate some Haskell code from some .proto files. I'm using haskell-language-server with wonderful success in emacs for everything except when my code imports any of the Proto.Myproto modules. It can't find them and thusly can't properly check the files I'm editing.
The project builds perfectly, but I'd like to have the lsp working. It's very helpful!
I get errors highlighted anytime my code uses an identifier from the proto-lens-generated code. I've tried looking into hie-bios configurations but didn't see anything obvious to put in a manual config to make it work. I don't normally have a manual hie-bios config.
Related
I have been using a graphics library from Smaller Animals Software called ImgSource. Unfortunately, Smaller Animals Software has closed and is no longer available to answer questions. Recently, I had a system failure that deleted my only up-to-date copy of the library (I thought I had a backup but was wrong). I did, however, have the source code. I recompiled the library, both release and debug. (Both are static .lib files) I am also using MSVS 2019 Community edition and the project is an MFC project. The problem, and why I'm posting here, is that when I link the new release library with a previous project, the project compiles properly. However, when I build the debug version, it will compile, but not link and produces the linker error discussed LNK2038: mismatch detected for 'RuntimeLibrary': value 'MT_StaticRelease' doesn't match value 'MD_DynamicRelease' in file.obj
A reasonable conclusion is that there is something wrong with the debug library. However, if I build a new project and link the debug library, everything works fine. So, the error does not appear to be in the library. It seems I could start from scratch and completely redo these projects, but they do reflect a tremendous amount of work.
I can't figure out how to modify the settings in the existing projects so that they will compile in debug mode. I have tried the suggestions offered in the article referenced above. Further suggestions would be greatly appreciated.
I am attempting to convert parts of an Android app to iOS using Doppl, and I am getting a strange result: Doppl keeps trying to pull in android.arch.lifecycle:reactivestreams, even though I don't want it to.
Specifically, in app/build/j2objcSrcGenMain/android/arch/lifecycle/, there is a reactivestrams/ subdirectory with R.h and R.m files in it. This seems to make Xcode cranky and may explain why I had some oddities with pod install.
My app/build.gradle has compile "android.arch.lifecycle:reactivestreams:$archVer", because my activity is using LiveDataReactiveStreams.fromPublisher(). However:
The activity is not in the translatePattern (and since its code is not showing up in app/build/j2objcSrcGenMain/, I have to assume that the translatePattern is fine)
I do not have a doppl statement related to reactivestreams, because there does not appear to be a Doppl conversion of this library (nor should it be needed here)
AFAIK, nowhere else in this app am I referring to LiveDataReactiveStreams, which AFAIK is the one-and-only public class from the reactivestreams library
So, the questions:
What determines whether Doppl creates R.h and R.m files for some dependency? It's not the existence of a doppl statement, as I have doppl statements for a lot of other dependencies (RxJava, RxAndroid, Retrofit) and those do not get R.h and R.m files. It's not whether the dependency is referenced from generated code, as my repository definitely uses RxJava and Retrofit, yet there are no R files for those.
How can I figure out why Doppl generates R.h and R.m for reactivestreams?
Once I get this cleared up... do I re-run pod install, or is there some other pod command to refresh an existing pod with a new implementation?
Look into 'app/build/generated/source/r/debug' and confirm there's an R.java being created for the architecture component. It'll be under 'android/arch/lifecycle/reactivestrams'.
I think there are 2 problems here.
Problem 1
Somehow Doppl/J2objc is of the opinion that this file should be transpiled. It could be either that 'translatePattern' matches with it, or that something in the shared code is referencing it. If you can't figure out which, please post a comment and I'll try to help (or post in slack group).
Problem 2
Regardless of why that 'R.java' is being sucked into the translate step, because of how stock J2objc is configured, the code is being generated with package folders instead of creating One Big Name. That generated file should be called 'AndroidArchLifecycleReactivestramsR.h' (and AndroidArchLifecycleReactivestramsR.m). Xcode really doesn't like package folders. That's why there's a slightly custom J2ojbc being used with Doppl, so we can have files with big names instead of folders.
In cases where you intentionally use package names that match with what J2objc considers to be "system" classes, you need to provide a header mapping file to force long names. The 'androidbase' doppl library needs to add a lot of files that are in the 'android' package, which J2objc considers "system". We override those names in the mapping file.
build.gradle
https://github.com/doppllib/core-doppl/blob/master/androidbase/build.gradle#L19
mapping file
https://github.com/doppllib/core-doppl/blob/master/androidbase/src/main/java/androidbase.mappings
I screwed up.
In my dopplConfig, I have:
translatePattern {
include '**/api/**'
include '**/arch/**'
include '**/RepositoryTest.java'
}
In this case, **/arch/** not only matches my arch package, but also the arch package from the Architecture Components.
Ordinarily, this would not matter, because the Architecture Components source code is not in my project. But, R.java gets generated, due to resources, and the translatePattern includes generated source code in addition to lovingly hand-crafted source code. So, that's where my extraneous Objective-C was coming from.
Many thanks to Kevin Galligan for his assistance with this, out on the #newbiehelp Doppl Slack channel!
I had resigned myself to the fact that every require statement in Typescript had to be relative to the file you were typing in, but I recently discovered an application that does this differently and it confuses me. I was hoping someone with enough skill could explain how this is working to me.
The application in question is the new Raven DB HTML5 Studio, which uses typescript, you can find the whole application here:
RavenDB HTML5 Studio
When browsing its source code, I came across something interesting... if you go and look at many of the files; In specific the one I am looking at... app/viewmodels/deleteItems.ts, it has a reference at the top that reads..
import document = require("models/document");
but models/document isn't a path relative to deleteItems.ts, but this works. Can someone explain how this is happening? I'm linking you RIGHT to the exact files I'm talking about. This kind of behavior is littered all over this application.
app/viewmodels/deleteItem.ts
app/models/document.ts
This is exactly the kind of behavior I really wanted to try and emulate in my own code, since trying to keep all of the paths relative to the file I'm working in is a headache, but this program seems to be completely free of that requirement.
This doesn't necessarily involve RavenDB, but I am tagging it anyway, because perhaps someone who has read over the Raven repository will understand it and be able to answer.
Update
I am trying to mimic this behavior in my own code, and not finding any success. I am sorry if I seem outright stupid, but this is all really confusing me. Here is what my structure looks like; My repository is private, so I cannot really just link to it.
app_content
scripts
home
controls
models
editors
utils
UserControls.ts
UserMapping.ts
UserElements.ts
ui
lib
jquery
jquery.js
jquery.validate.js
jquery.ui.js
kendo
kendo.all.js
kendo.aspnetmvc.js
// other libraries
Alright, that's a general feel for my folder layout. All typescript files are under the /home folder so that I can prevent github from saving their compiled javascript and locking that.
So then, in the file UserControls.ts, it looks like this right now...
import userElements = require('./UserElements');
import userMapping = require('./UserMapping');
export class UserControls {
// code
}
No matter what combinations I have tried, this is the only format/syntax that doesn't throw errors in Visual Studio. But from what I see in the RavenDB project, I should very much be able to declare it like ...
import userElements = require('utils/UserElements');
import userMapping = require('utils/UserMapping');
export class UserControls {
// some code
}
No matter what combinations I have tried, this is the only format/syntax that doesn't throw errors in Visual Studio. But from what I see in the RavenDB project, I should very much be able to declare it like ...
That is because they are using a drandalJS configuration to tell it how to resolve the file path. (see https://github.com/ayende/ravendb/blob/New3/Raven.Studio.Html5/App/main.js)
There isn't a similar configuration (basePath) for TypeScript at the moment. Your best option is to use relative paths as you've already noticed.
PS: an old but still relevant video that shows you how requirejs config works and relevance when using TypeScript https://www.youtube.com/watch?v=4AGQpv0MKsA&hd=1
The TypeScript compiler's module resolution algorithm is essentially undocumented, unfortunately. It tries to "split the difference" between AMD and CommonJS's module resolution rules, so it's somewhat hard to reason about.
What you're seeing here is an attempt to mimic CommonJS's "walk up the tree" resolution rule. When in the path C:\a\b\c\d resolving x, first C:\a\b\c\d\x is tried, then C:\a\b\c\x, then C:\a\b\x, and so on until it hits the root folder and gives up.
I'm working on a project that creates a DLL in C for Windows CE 5.0 using STANDARDSDK_500. The project is relatively simple with just one C source file. What I've noticed is that when I clean and build the project using Visual Studio 2005, it fails to create my Import lib. When I tell Visual Studio to rebuild it, it correctly creates the import lib.
Turning on verbose linking, I discover that in the failure case (clean and build) CVTRES.exe is discarding my functions, like so:
Invoking CVTRES.exe:
/machine:thumb
/verbose
/out:"C:\...\Temp\lnkC7E.tmp"
/readonly
/windowsce
".\standardsdk_500 (armv4i)\release\WLTBApi.res"
Microsoft (R) Windows Resource To Object Converter Version 8.00.50727.42
...
adding resource. type:VERSION, name:1, language:0x0409, flags:0x30, size:892
Discarded '.idata$4' from coredll.lib(COREDLL.dll)
...
Discarded WLRegisterStartupApp from WLTBApi.obj // my functions! Oh noes!
...
This discards all of my functions, which causes the linker to not create an import lib because there are no exported functions.
I figured that the input was the .res file mentioned in the commandline - WLTBApi.res. This file is identical in the intermediate directory after trying to compile both the working way (rebuild) and the non-working way (clean. build).
So, my first question is: what are the other inputs to the CVTRES.exe program so that I can find discrepencies between the two builds?
Second: what other troubleshooting techniques would you recommend?
Additional Info - I thought perhaps the .obj files were additional inputs - they differ between the builds. I now believe that they are outputs of CVTRES.exe. If anyone knows whether or not I'm correct in this, let me know.
Okay, so I found a solution, but I'm terribly dissatisfied with it. I discovered that the project I was building had a Dependency, but one that wasn't actually a dependency. In other words, the project, WLTBApi was building a DLL, and had a dependency configured, WLTBApiLib, but it wasn't actually using any of the output of that project. By removing the dependency, the problem went away.
I'd still love to know more about how to find an actual answer to what was going on, but maybe this answer will help someone else in the future.
I have a Flash component that's just a library of compiled code with some exposed API calls. Normally we distribute this as a SWC or MXP, and it works just fine. Recently I had a client express interest in using my component, but they do all their development in MTASC only. MTASC doesn't support SWC files, so ss there a good way to send precompiled code that would work in MTASC? I'm not able to send them the original source code, but if there's some other method I'd appreciate it. I do have access to the source, so I can recompile it however necessary. Thanks!
I did find an answer, and I'm not 100% sure if this is exactly the process since I'm no longer at that job and don't have the computer/process in front of me anymore. It was a bit of a hack.
What it involved basically was unzipping the SWC file and getting a .swf and a bunch of .asi files out.
The .asi files are really just ActionScript files, but they contain intrinsic definitions, or just prototypes or footprints of whats actually there. The real meat of it is still in the .swf.
So you rename all those .asi files to .as and then put them into your MTASC classpath. Since they contain definitions, you shouldn't be getting any more "undefined variable" or "undefined function" errors at compile time. Now you just need to pull in the SWF, where the actual function bodies are defined, using loadMovie. once the loadMovie is complete, you should be able to use all of the functions.
The only caveat of course is that you have to wait for that SWF to load before calling of any of the functions from the SWC.
so step-by-step, it looks like this:
1.) unzip the SWC file. this can be done using WinZip or OS X terminal unzip command
2.) Rename .asi files to .as
3.) add new .as files to MTASC classpath
4.) add AS code to load the .swf in and make sure none of the SWC functions are called before the SWF is loaded
5.) compile
I'm pretty sure this is what we did, but i'm not in a spot to try it out right now.,
Hope this helps, let me know if you have any other questions and I'll see if I can help figure it out any more.