I am teaching some matlab classes and we have some version-ing issues ... some students use versions as old as 2008b and some of the computers in the lab have versions as old as 2007a (or as new as 2012b). I want to create some pcode files which will run on all of these versions ... that way they can check their results without seeing the actual code that created them.
I know that Matlab 2013a (the version I use daily) can operate pcode files made from any previous version but the older versions can't run pcode made with my computer.
Is there any way to create backwards compatible pcode files? I know I can just find the oldest version and make a pcode on that computer and distribute it ... but that's really annoying. Especially because I don't have licences for versions that are as old as some of the students (my oldest is 2010a and some students/lab-computers are still stuck on 2008b)
Thanks,
Will
From the documentation:
The pcode algorithm was redesigned in MATLAB 7.5 (Release R2007b). You can run older P-files in any current version of MATLAB; however, upcoming releases will not run P-files created before version 7.5. Files generated in 7.5, or later versions, cannot run in MATLAB 7.4 or earlier.
(Use docsearch pcode to view, expand "More about, Tips").
Based on the lack of any related tips or help, I suspect that pcode cannot be transitioned either way between pre-2007a and post-2007b.
From my experience, I have never had problems using pcode between versions. I think that this algorithm change in release 7.5 is a relatively rare thing.
Related
I want to have 2 versions of Gensim for using summarization and keyword function from old Gensim.
How can I setup this senario?
In general, a single Jupyter notebook is backed by a single Python interpreter/environment, and popular packages at their 'official' installation paths can only be installed once.
There are a few hackish workarounds suggested in answers like:
Installing multiple versions of a package with pip
However, each workaround presents operational problems.
One approach is to install the older package to a non-standard path (directory) that's still found by Python importing logic (controlled by PYTHONPATH). For example, put/move the older copy of Gensim to a gensim_old package directory. But: this is only likely to work well with very sime (single-.py-file) packages.
With any signficant library (like Gensim) which cross-imports a lot of things from its own utility modules, using the standard paths, lots of things are likely to break unless you dig into all involved individual files to change their import paths. That's kind of kludgey & hard-to-maintain. (Though, to the extent you're just using one old version, say gensim-3.8.3 for the removed summarization feature, perhaps it'd be worth fighting through this process once, then keeping the changes around.)
Another approach is to create a totally-separate Python environment with the alternate version, and only use that other environment from the notebook by a system-call – via either something in Python-code like subprocess.call(), or the notebook-cell ! or !! magic-escapes to run a shell command. That is, you give up the ability to run individual interactive lines of Python in that alt environment - but could still send it batches of data, and either capture the console output or observe its output files to continue processing in your notebook.
I'd expect this to be a better option – cleaner & more-maintainable – provided that either the old-version-functionality (summarization) or new-version-functionality (whatever else) can be condensed into one (or a few) single-step scripts.
Another option would be to try to completely copy the gensim.summarization source code files to some new location inside your own project – performing whatever (few, minor) edits are necessary to ensure it works from the alternate location.
One of the reasons that functionality was removed was that its approach to things like tokenization was not consistent/integrated with other Gensim practices – which actually means it's likely to be a little easier to keep it working (given its use of its own idiosyncratic approaches) separately.
Personally I'd rank these three options desirability as:
(best) Section off the summarization tasks to be run via subprocess executions in a separate Python environment, which has only the older package installed.
(maybe ok) Copy the 10 .py files that implement the gensim.summarization' to your own local module. Edit lightly as necessary to ensure they still work. (That should mainly be updating import` lines, but might reuire a few other adaptations to other Python 3.x/Gensim 4.x changes.)
(probably too messy) Install the whole old package to a non-standard directory, edit lots of files to ensure anything you're using still works.
Finally, note that the main reason the feature was removed is that it did not offer very impressive or adaptable results. While I've seen some people say it's worked OK for their applications, I've never seen even so much as a demo where its practices/algorithm – which can only extract some subset of important sentences, never paraphrase – gave impressive results.
So unless you already know that its approach works well for your needs, don't get your hopes up! Good luck.
Can someone help me on porting a game written in BlitzBasic to BlitzMax IDE. I tried running the .bb file into MaxIDE but it says "process failure with file.bb". Also where can i find more information regarding this?
You must rename the .bb files to .bmx. Though a superset, BlitzBasic is a completely different language than BlitzMax.
You can use the BlitzMax IDE Community Edition project which has the feature to import .bb files then convert them to .bmx files.
In regard to the 3D commands part and as Spark Fountain as mentioned, it is not supported by default, but you can use MiniB3D or OpenB3DMax.
http://blitzmax-ide.sourceforge.net/
BlitzMax IDE Community Edition
BlitzMax introduces several new features such as classes, real object orientation, inheritance and many more. Anyways, most of the BlitzBasic syntax elements remain or can at least be re-used.
To port your BlitzBasic programs to BlitzMax, I suggest you learn and understand the basic language elements. You can also use the following guide as a starting point.
comments start with ' or REM instead of ;
arrays are defined with Local array[10] instead of Dim array(10)
3D commands are not supported but you could use i. e. MiniB3D
I usually have an environment setting for MAKE_MODE (Windows XP, using GNU make, both under Cygwin and native)
set MAKE_MODE=UNIX
I now found differences between my build server (which has no MAKE_MODE defined) and a local build. This may be something completely different, but it got me wondering what other values I could specify for MAKE_MODE.
I think I know that MAKE_MODE=UNIX is suppose to tell GNU make to use /bin/sh - if it finds it - , but I quickly checked the GNU make manual and couldn't find a description. A google search only told me what I already know, but doesn't give a valid alternative.
Is the only alternative to not define the variable? Does it have influence at all when using CMD.exe and a native version of GNU make?
EDIT: So far I have found references for the values 'unix', 'win32', 'null' and undefined, but no explanations, and no specifications. But a look at the source code for GNU make 3.82 shows not a single occurrence of the string "MAKE_MODE", so GNUmake itself apparently doesn't change its behavior when this environment variable is set or not.
EDIT2: I checked the source code for GNU make for MinGW, and again found nothing. Maybe it's CygWin specific?
EDIT3: I found a reference that it might be property of an old version of GNU make, so I checked version 3.75. No luck, the string MAKE_MODE does not appear in the source code at all. The next step really must be the Cygwin version of GNU make. I know from 10 years ago that the Cygwin port in those days was not integrated in the regular source tree.
I found an ancient mailing list entry on the Cygwin site, explaining the basic operational effect of MAKE_MODE. This definitely indicates that the variable has to do with the Cygwin implementation of GNU make.
I'll dig around in the source code, and add to this answer when I find more details.
UPDATE: In a more recent post by maintainer Christopher Faylor I found the following update for GNU make version 3.81:
Note that the --win32 command line option and "MAKE_MODE" environment
variable are no longer supported in Cygwin's make. If you need to use a
Makefile which contains MS-DOS path names, then please use a MinGW
version of make.
I've not really found the values allowed for MAKE_MODE, but it's not any more necessary or supported in most recent versions of GNU make for Cygwin, and it was used for supporting DOS filenames in Cygwin's make.
And if you really want to know the set of allowed values, look in the source for Cygwin's make version before 3.81-1. I guess the only useful value was unix, all others will have meant the same.
Case closed? There's still not many views here...
I am working on Matlab R2011a student edition. I want to run some demos provided in Matlab which require some toolbox like Embedded Coder and EDA Simulator Link.
I want to check if those toolboxes are installed in my current version of matlab and if yes how can I check if the licenses are valid.
The reference to this link didn't help me:
How would one check for installed MATLAB toolboxes in a script/function? because I need at least the short name of those toolboxes like "control" states for "Control System Toolbox" by using the command ver control.
Any suggestion...
To check that the toolbox is installed, use
v = ver;
any(strcmp(toolboxName, {v.Name}))
where toolboxName is the name of the toolbox you want to check.
To check that the licence is valid, use
license('test', toolboxName)
easily use ver command. it will list all installed toolboxes and their versions. the other way is to check from the start button.
Also you can use the existing function in FileExchange called isToolboxAvailable. The usage is as follows:
result = isToolboxAvailable('image processing toolbox','error');
you can always check out the main help documentation which generally lists the toolbox.
Or if you press "Start" (the Matlab start, not Windows) the list of installed toolboxes will be organised by category
Here is a dirty solution:
try
<funktion from specific toolbox>
<do this if it is available>
catch
<do this if it is not
end
The names of the toolboxes that are returned by the license function are the same as what is in the license file. The license file will either be on the local PC or on a FLEXlm license server, depending on your environment. On Windows, check in C:\Program Files\MATLAB\R2011a\licenses for a license file, which is typically named something like license.lic or network.lic. Open the file in your favorite editor (notepad will do). If you see text that says SERVER followed by a hostname, MAC address, and port number, then you're using a network license and you'll have to ask your systems administrator. Otherwise, there should be an INCREMENT line for each licensed product and the name of the product as used by the license function is given following the INCREMENT keyword. If you're on a UNIX or Linux system, you may have to dig around a bit to find the path for the license file (or perhaps someone else can provide this?).
Edit: My MATLAB install is in a non-standard path. Changed instructions to give the default path.
Just in case somebody stumbles upon this in 2022. There are now several built-in add-on utilities to check if add-ons are installed. Notably:
matlab.addons.installedAddons: Will list all installed add-ons with (long) Name, Version, Identifier (aka short name/hash)
matlab.addons.isAddonEnabled: To check if a given add-on is enabled
I've been told by my coworkers that rpy2 is a great tool to work with data that benefits from the back and forth between python and R. But I am a perl monger, so I wonder if RSPerl will be as wonderful as I've been told rpy2 to be.
The website was last updated in 2007...
Cheers
To me, the main difference is that things from Omegahat are exceedingly clever and far-sighted yet don't always build reliably. It's more of an R&D lab.
Rpy2 on the other hand has a dedicated and focussed core developer in Laurent.
[Disclaimer: I'm the Debian maintainer for RPy2 (and a few related things) and tried in vain to package RSPerl, RSPython, ... and a few other Omegahat pieces by Duncan.]
Beside wonderful features in an interface between language X and R, continued support is of utmost importance.
RSPerl might have built at some point in time, but there is a non-negligible chance that it does not any longer. In your situation, Perl did not know major transformations over the last years, but R surely did.
[Disclaimer: I am quite involved in rpy2, and within its ~3 years of existence the code base has required several changes because of changes in R and Python - in fact, I am not yet completely out of the woods with Python 3]