I tried out scriptcs on OSX using a script that was previously written for the C# interactive (Roslyn) runtime and it fails with mysterious errors (which I tracked down to being related to C# 6.0 property syntax).
I read that scriptcs should support the Roslyn execution engine, and indeed I can see it is installed:
$ ls ~/.svm/versions/0.15.0/*Engine*
ScriptCs.Engine.Mono.dll
ScriptCs.Engine.Roslyn.dll
Now, while the documentation tells me how to switch to the Mono engine (-modules mono), it does not tell me how to switch from Mono to Roslyn. I tried -modules roslyn, but saw no change (running with -debug shows that it executes my script using the Mono engine).
I must have missed something fundamental here. How do you switch to/force the Roslyn engine?
Related
I'm trying to get a Mono development environment set up on a Windows box. Basic install was dead simple, but I'd like to get the VB.NET compiler set up. Only problem is, there doesn't seem to be an installer for it. The official page on VB.NET support implies that there should be, but there isn't; it hasn't been incorporated into the main installer, either. I can download the source package from the mono-basic Github, but since the compiler is self-hosting, that just leaves me in a catch-22 situation where I need the compiler to compile the compiler... :/ On top of which, it doesn't look like the compiler code has been touched in a couple years...is this still supported? Is there any way to get it set up apart from doing a build from source on a machine with the official VS toolchain (or a Linux box with the package installed from a repository) and then copying it over?
I use Cygwin to build source code to DLL used by windows app.
When I use GCC core / GCC g++, the app crash if it calls function (which includes printf or malloc) in DLL.
When I use Mingw64-x86_64-gcc-core / Mingw64-x86_64-gcc-g++ it reports error like sys/socket.h：No such file or directory.
Can anyone explain how to do it? Thanks.
The first problem is due to the tentative to build a stand alone DLL (not depending on cygwin1.dll) using cygwin only specific tools.
You have collision between multiple malloc and other C library call present in cygwin1.dll.
The second is due to the fact that sys/socket.h does not exist on Windows
see for possible solution:
Using sys/socket.h functions on windows
So you need to define what is your target : Cygwin/Posix or Windows and choose programming style and tools accordingly, you can not mix.
I'm attempting to build TensorFlow's C++ library for Windows XP. While I've been able to build and use it on Windows 10, 32-bit XP isn't working. The background: I'm working on a COM module that calls fuctions from tensorflow.dll. My build environment:
Visual Studio 2017 15.7
CMake 3.11.1
TensorFlow 1.8
Windows 10
The sequence I use to build tensorflow.dll is:
Open "x64_x86 Cross Tools Command Prompt for VS 2017"
Try to force the use of functions availablbe in Win XP: set CXXFLAGS=/D_WINVER=0x0501 /D_WIN32_WINNT=0x0501
Add Git to path: set PATH=%PATH%;C:\Program Files (x86)\Git\bin
Fix CMake file for converting *.proto files to *.pb.h files as described here.
Configure CMake: cmake .. -A Win32 -T v141_xp,host=x64 -DCMAKE_SYSTEM_VERSION=7.0 -DCMAKE_BUILD_TYPE=Release -DPYTHON_EXECUTABLE=C:\Users\williams\AppData\Local\Continuum\Anaconda3\envs\tensorflow\python.exe -Dtensorflow_BUILD_SHARED_LIB=ON -Dtensorflow_BUILD_PYTHON_BINDINGS=OFF -Dtensorflow_WIN_CPU_SIMD_OPTIONS="/arch:IA32"
Build: cmake --build . --target tensorflow --config Release -- /fileLogger /m:1 /p:CL_MPCount=1
The last step also involves some manual labour as the build process doesn't copy .lib files from the 3rd part dependencies to where they are needed. For whatever reason, a bunch of INSTALL projects never get run so I had to do that manually each time the build would fail while looking for a missing lib file. Once that was done, the build completed successfully.
Next I copy my COM module (a DLL) and the TensorFlow DLL over to a Windows XP virtual machine for testing and try to register the COM module, but get an error LoadLibrary("MyDLL.dll") - The specified procedure could not be found. I don't know what procedure it is looking for, so the best I can offer is that Dependency Walker highlights WS2_32.DLL and tells me it can't find inet_ntop and inet_pton.
Any suggestions on how to build TensorFlow so that it doesn't use these two functions?
P.S. suggestions of "Stop using XP, its old and no longer supported" don't help here. Upgrading to Windows 10 is an absolute last resort because of the disruption it would cause at the facility where this software will be tested.
Edit 1:
These two functions inet_pton and inet_ntop were only used in one file that forms part of Google Cloud Storage support in TensorFlow. The build process generated a tensorflow_static.lib in addition to tensorflow.dll. Linking against the static version and adding a few dependencies that aren't included in tensorflow_static.lib got rid of the code using inet_* functions.
My COM module still isn't working on Windows XP though because the file tensorflow\core\platform\windows\env.cc uses functions like CloseThreadpoolWork, submit SubmitThreadpoolWork, etc. that were only introduced in Windows Vista. It looks like I'll have to replace them with something else, as I don't see an alternative implementation in TensorFlow.
Additionally, I found that tensorflow\contrib\cmake\CMakeLists.txt forces _WIN32_WINNT=0x0A00 and that CXXFLAGS is the wrong environment variable to use. Changing it to CMAKE_CXX_FLAGS at least gets my macro definitions included, FWIW.
It is almost impossible to port tensorflow to windows xp, because:
TF's platform depedent code requires some Windows APIs later than winxp such as Thread Pool API. This would possibly bypassed by using third party thread pool libs.
The nsync, protobuf and eigen, which are core parts of TF, use C++11 thread_local, which makes them unable to run-time load as dll, see https://learn.microsoft.com/en-us/cpp/parallel/thread-local-storage-tls?view=vs-2017 for details. This later feature can theoretically be replaced by old windows TLS API, which requires many modifications on TF's core framework.
Anyway, if you really need the xp support, good luck with that.
In the end I gave up on this as simply being impossible. Even replacing the thread pool functions with something from Boost didn't help. If someone else manages to get this working, I'll gladly accept that as the answer, but so far this looks impossible.
I wonder if it is possible to make an Objective-C project (no UI, no simulator is needed, hosted on Github) to be built on Travis?
Current Travis docs seems not to contain any information regarding the option to have Objective-C projects built on Travis.
But Building a C Project says that:
Travis VMs are 32 bit and currently provide
gcc 4.6
clang 3.1
core GNU build toolchain (autotools, make), cmake, scons
and that default test script is run like
./configure && make && make test
So, to rephrase the subject question:
Do any workarounds exist to make SenTestingKit test suite, that my project currently uses, behave like a C test suite, so it could be treated as such by Travis VM?
NOTE 1: Here is the list of resources, which seem to be related to the question:
Compiling Objective-C without a GUI. It claims that Both gcc and clang compile Objective-C 2.0 and that sounds very promising!
NOTE 2: I suspect that it is possible to use some testing tool other than SenTestingKit:
this tool should be easy to be run without a GUI and without xcodebuild etc: I've opened related issue for that: Is there any non-Xcode-based command line testing tool for Objective-C?. I am even thinking about writing an easy one just to be used by my project.
A few days Travis announced that they are now also supporting objetive-c projects. See Building An Objective-C Project for more info.
Update
It is even possible to make Travis launch the simulator so that you can run application tests and UI related stuff. I required a little extra work, but it's pretty straight forward. I wrote about it here.
I downloaded and installed the latest version (6.12.2.633) of Debugging tools for windows. Running it with .NET 4.0. When I run !address -summary command seem like its output is different than what I used to see with previous version of Windbg/SOS for .NET 3.5. Anyone knows where can I find document for latest !address -summary command. SOS build-in help is not very helpful
!address is a native extension command that is always available during user mode or kernel mode debugging. It displays information about the memory of the target application or computer. See also the documentation for this command.
It is possible to have multiple extensions loaded in WinDbg. You can use the .chain command to list the loaded extensions.
SOS is an extension dedicated to .NET debugging. It comes with its own set of commands to analyse memory used by managed applications, e.g. !eeheap -gc.