bigmemory/windows compatibility - windows

Following on from this question(Can't install bigrf package);
Is there a version of the bigmemory package, and by extension bigrf that works with windows OS?
I understand that support has been removed in recent years but I can't seem to find when that support was removed and thus which versions should still work with windows??
compatibility

Related

Installing Julia BinaryBuilder.jl packages on Windows 7

I am having difficulty installing various Julia packages on my Windows 7 laptop. When trying to add certain packages I receive the following error:
(v1.3) pkg> add MbedTLS
Updating registry at `C:\Users\uname\.julia\registries\General`
Updating git-repo `https://github.com/JuliaRegistries/General.git`
Resolving package versions...
ERROR: Unable to automatically install 'MbedTLS' from 'C:\Users\uname\.julia\packages\MbedTLS_jll\wUtL4\Artifacts.toml'
Several packages install happily, and I think I've narrowed it down to those that are supplied via BinaryBuilder.jl, such as MbedTLS, Arpack, OpenSpecFun. If I try to install any packages that have any such packages as a dependency I get the same error message when it hits one of these (initially encountered when I was trying to install Genie.
I am using the latest Julia (1.3.1), although I encountered the same issue previously in 1.2 - I managed to fix things eventually in that case, and tried a similar approach (manually downloading and placing in packages folder) but have not been able to fix things in this instance (although I confess that my notes were a little lacking so can't be certain I'm doing the correct thing). The various packages seem to exist in ...\.julia\packages\ (although not in .julia\compiled), but julia complains whenever I try to add them to some environment.
I don't think I understand julia's package system well enough to see quite what is going on here. I have seen other people with similar issues but not found anything yet which has worked - any help would be much appreciated!
This usually is due to an issue with your powershell installation, which is what we use to download these binaries in Julia 1.3 and 1.4. In particular, most of the internet (including GitHub, where most of our binaries are hosted) disabled SSL v3, TLS 1.0, and TLS 1.1 in 2018. Windows 7 is old enough that it doesn't speak TLS 1.2+ natively; instead you must install two packages:
This TLS easy_fix
Windows Management Framework 3.0 or later, to get Powershell v3+
This is necessary on Windows 7, but not on Windows 10. For more instructions, you can read the Julia platform specific instructions: https://julialang.org/downloads/platform/

Go after 1.10 and support of Windows XP

First of all: I know that Windows XP is end of life, insanely insecure, a big risk and that everyone still using it will be doomed for ever.
Nonetheless I have to provide an application that can also run on Windows XP and I do so using Go.
In 1.10 it was announced that XP will no longer be supported and 1.11 confirms this in the release notes:
As announced in the Go 1.10 release notes, Go 1.11 now requires
OpenBSD 6.2 or later, macOS 10.10 Yosemite or later, or Windows 7 or
later; support for previous versions of these operating systems has
been removed.
I compiled my application with 1.11 and tried to execute it on a Windows XP SP3 virtual machine. It could be executed successfully !
Then I thought that the revoked support for Windows XP only applies to the development toolchain but even that can still be executed on Windows XP:
As you can see the main go binary still runs on XP too. Is it already known when it will no longer be possible to run golang compiled exes on Windows XP because of technical limitations or if certain methods will fail because they can no longer work because of missing APIs on XP ?
Issue #23380 is the relevant discussion.
In short:
Note that even if 1.10 is the last version to support XP, you'd get bugfix backports until 1.11 is out, and security backports until 1.12 is out. That means until January 2019 <…>
As to supporting Windows XP, there are both technical and non-technical reasons.
Supporting a platform requires:
Someone who has access to it, and an incentive to work on it
(either paid or unpaid).
The most active Go-on-Windows developer, Alex Brainman,
seems to have no interest in XP anymore.
This platform must be supported on autobuilders which are part of the Go release / QA process.
An autobuilder must be supported by someone.
Bugs specific to a platform must be fixed and tested.
For instance, that issue refers to #23375 which happens only on Windows XP (SP3).
But even if a bug was specific to Windows in general—as opposed
to Windows XP, a fix for it would have to be tested on XP anyway.
Hence, unfortunately, if there is no interest in supported Go on Windows XP coming from some "powerful entities"—such as corporations—the best you can do is to actually work towards still supporting this by yourself, FWIW.
Also note that even after the support is officially ended, you still might have success building newer Go releases from the source (which is reasonably simple since Go 1.5 as Go is now built using (an older release of) Go).
Hence a real show-stopper would be the Go team hitting some roadblock which would just require some kernel feature not present in Windows XP.
A good example was some difficulty with SEH handling on Windows 2000 which eventually led to dropping support for that OS.

gtk_builder_new_from_file not present under Windows?

I've been working for a couple of days with GTK3+ under Linux in C++ and I've used Glade to design my GUI. In my C++ code, I call gtk_builder_new_from_file instantiate the GUI.
Now I was trying to do the same under Windows. So, I downloaded the latest version of GTK+ (3.6.4, all-in-one 64-bit bundle). The problem is: I can't find the function gtk_builder_new_from_file. I've searched for it in all files too, but it seems not to be there. I've checked the documentation, and this function should be present since version 3.10.
So, why can't I find it? Is a Windows compatibility issue?
3.6.4 is a smaller version number than 3.10 so there does not seem to be any mystery here.
You should use gtk_builder_add_from_file () instead if you can't find a newer Windows bundle.

Install ColdFusion Builder 2 Update 1 Plug-in in Eclipse 4.3

I would like to install ColdFusion Builder 2 Update 1 as a Plug-in for Eclipse 4.3.
The install seems to work without errors but when I attempt to register my license code, I get an error dialog box that says:
"The chosen operation is not enabled."
None of the CFB features appear in Eclipse.
In some of the documentation that I've found it references installing to Eclipse 3.6.
Can CFB 2u1 get installed on Eclipse 4.3? If not, does someone know which version of Eclipse to use for CFB? Hopefully it is something recent or I'm doing something wrong for the install.
I don't know if it matters, but I'm running:
Windows 7 Pro 64-bit
16GB RAM
According to the ColdFusion Builder System Requirements page one needs Eclipse 3.7.1. Having tried to install it on versions later than that, failing, and talking to Adobe about it, they confirmed that one needs that precise version. More recent ones won't do. This is a bit subpar on the part of Adobe, but so be it.

../include/wx/mac/carbon/private.h:1459: error: ‘Cursor’ does not name a type

I have been using RapidSVN on a Linux machine for the past few years - it has become an excellent tool for managing my source.
Yesterday my trusty Linux laptop had a couple of strokes so I decided it was time to replace it. Today I went out and purchased a new Mac Book Pro with the flashy display and solid state drives.
Then I went hunting for an SVN tool to run on Mac. I found that RapidSVN will run on a Mac as it was developed using wxWidgets (cross platform windowing).
So, I needed to install wxWidgets, however this doesn't come as an executable so I had to download the tar ball. To compile I realised I don't have a compiler installed yet... so, install Xcode 4.4, then learn that doesn't install a compiler either... find the Xcode preference to install the command line tools (compiler).
So, now I have Xcode installed, a gcc compiler, and tracking back up it comes to wxWidgets. It takes a little working out but I manage to extract the files into a directory in my home folder, (following instructions of course), and from the 'build' folder I run the ../configure command (which seems to work) and then the 'make' command which fails:
In file included from ../include/wx/mac/private.h:4,
from ../src/common/dynlib.cpp:48:
../include/wx/mac/carbon/private.h:1459: error: ‘Cursor’ does not name a type
../include/wx/mac/carbon/private.h:1488: error: ‘ClassicCursor’ does not name a type
make: *** [baselib_dynlib.o] Error 1
So I go hunting for a solution only to find this bug: http://trac.wxwidgets.org/ticket/14536 which unfortunately indicates this is not going to be fixed.
Changed 10 months ago by csomor
* status changed from new to closed
* resolution set to wontfix
A dismal day in the land of computers. I am now stuck for the next 5-6 years on a computer that will never be able to compile anything using wxWidgets - I rather feel like taking it back to Apple and getting my money back.
So where to from here? Is there a binary version of wxWidgets available? Is there a binary version of RapidSVN available? Should I downgrade to OSX 10.x something less than I am currently on? Should I upgrade to unstable wxWidgets?
This is an interesting but not very understandable read. What exactly are you trying to achieve? If you're looking to use the best available version of wxWidgets under OS X, get 2.9.4 or the current svn version and build it using the Xcode version you have already with Cocoa support. If you absolutely need to continue to use Carbon (why?), either install Xcode 3, available from Apple, or get 10.6 (or 10.5) SDK in some other way and pass it as the SDK to use to configure using --with-macosx-sdk option as explained in the documentation.
VZ is right. If you need to use wxWidgets 2.8 on OS X (and there are legitimate reasons for needing to do so), get the 10.6 SDK. Copy it alongside the already installed 10.7 and/or 10.8 , and select it in the project/target's build settings.
From here I have given up trying to compile anything on my current OSX. I am not going to downgrade or install multiple versions of different libraries in order to satisfy the lack of support for the latest current stable versions.
From here I will download and install binaries only.
I have Mac OSX Lion and just did this:
brew install wxmac
and was able to get through the install with no issues.

Resources