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...
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.
I am using emacs 23 on two computers.
On both, dpkg -s emacs outputs the following version number.
However one has window.el and the other not. This make some function such as split-window behave differently. The help page of this function on the computer that apparently has not window.el installed reads that it comes from C source code instead.
Where does this difference comes from?
I prefer the behaviour of the one that says that split-window comes from window.el: it allows to specify the SIDE when splitting window and provide additional function such as window-resize.
I suppose this is the most recent one but I do not know how to check it nor how to upgrade the other to this state.
Library window.el is as old as the hills. Perhaps you meant that one of your Emacs installlations has window.elc but not window.el?
More likely, you are referring only to function split-window. Yes, it used to be a built-in function (i.e., defined in C), and now it is defined in window.el (which file exists also for the older Emacs versions where that function is a built-in).
FYI, lots of window and buffer-display stuff was changed around the same time as split-window was rewritten in Lisp. Lots of behaviors changed, in minor or major ways.
What is not at all clear is what the problem is that you are reporting. You ask, "Where does this difference comes from? How to fix it?" I've explained a bit about the difference. As for how to fix it -- what is the "it" that needs fixing, and what would the fixed behavior be like?
IOW, your question is, so far, unanswerable. If you specify things more exactly, perhaps we can help more.
I'm not certain what's going on with your debian packages, but if memory serves the readable .el(.gz) files are not supplied in the basic package, but in a separate package. This is because all you strictly need is the byte-compiled .elc files, so they can reduce the base package filesize by omitting them (at the expense of enabling you to read the elisp code).
Is M-x load-library RET window RET successful?
Note that Emacs 24 is the current stable version. You might want to upgrade.
Edit:
M-x emacs-version tells you which version of Emacs you're running, which will always give you a definitive answer.
(And if the versions are identical, then run emacs -Q to eliminate and site- and user-specific config files from the picture, as those are always a likely culprit for differing behaviours.)
I'm Flexing a file with the
%option nounput
Option and using the command line
flex --nounput
And flex version 2.5.35.
However, the cpp output still contains the line
#define unput(c) yyunput( c, (yytext_ptr) )
And this causes compilation problems with g++ since unput is not used.
Is there some way to fix this problem in a "clean" way? The two dirty ways are obvious:
Use unput in some useless way.
Remove the line automatically from the generated cpp file using some script.
(I tried to flag this question as "problem no longer reproducible" but the flag timed-out/aged away. I'm answering it so that it does not remain an open unanswered question.)
As mentioned by #akond:
I don't experience this problem. The version I am using is the same (flex 2.5.35). %option nounput does the trick for me.
I also tried this on version 2.5.4 and can confirm there is no issue. The option --nounput is no longer recognised or documented; however, the %option nounput remains in the manual.
The cpp output still does contain the line #define unput(c) yyunput( c, yytext_ptr ) but this does not seem to generate any g++ errors for me. Are you using -pedantic-errors or some other similar option perhaps?
Good program but badly out of date documentation.
I found that version 2.6.4 accepts the nounput option and does the right thing.
This was asked before, but the solution doesn't seem to work on MacOS. Wolfram Library has a package for 7 year old Matlab version. Is there a solution that works on MacOS 10.6 and Matlab 7.9?
I want to call CVX from Mathematica
You could use RunThrough["command",expr], this runs the external command command, and feeds expr (a Mathematica expression) as input to command
An example of a suitable command would be "matlab -r \"matlab expr\"", you could place your CVX specific code in the "matlab expr" string.
Update: Right now, probably MATLink is the best way to do this. It works on Windows/Linux/Mac.
Disclosure: I'm one of MATLink's authors.
Have you tried using the newer mEngine instead? I can only try it on Windows, but after looking at the sources, I believe it might work on other platforms too.
Hopefully you only need to modify main.c, actually just copy and paste the main function from one of the MathLink examples (e.g. addtwo), as mEngine's main.c has the non-Windows-specific part removed. Then compile the package as a MathLink program.
Take an undocumented executable of unknown origin. Trying /?, -h, --help from the command line yields nothing. Is it possible to discover if the executable supports any command line options by looking inside the executable? Possibly reverse engineering? What would be the best way of doing this?
I'm talking about a Windows executable, but would be interested to hear what different approaches would be needed with another OS.
In linux, step one would be run strings your_file which dumps all the strings of printable characters in the file. Any constants chars will thus be shown, including any "usage" instructions.
Next step could be to run ltrace on the file. This shows all function calls the program does. If it includes getopt (or familiar), then it is a sure sign that it is processing input parameters. In fact, you should be able to see exactly what argument the program is expecting since that is the third parameter to the getopt function.
For Windows, you can see this question about decompiling Windows executables. It should be relatively easy to at least discover the options (what they actually do is a different story).
If it's a .NET executable try using Reflector. This will convert the MSIL code into the equivalent C# code which may make it easier to understand. Unfortunately private and local variable names will be lost, as these are not stored in the MSIL but it should still be possible to follow what's going on.