I needed to compile a Windows g95 binary for someone. I have Win 7 in a VM on VirtualBox. I had the g95 install tree from a (quite old) back-up of a previous computer, but not a proper install.
The install tree looks like this:
C:\util>dir /s g95 Volume in drive C has no label. Volume Serial Number is 8440-3CD9 Directory of C:\util\g95 23/08/2012 09:42 AM . 23/08/2012 09:42 AM .. 23/08/2012 09:42 AM bin 23/08/2012 09:42 AM doc 23/08/2012 09:42 AM lib 23/08/2012 09:42 AM 55,782 uninstall-g95.exe 1 File(s) 55,782 bytes Directory of C:\util\g95\bin 23/08/2012 09:42 AM . 23/08/2012 09:42 AM .. 26/03/2008 11:49 AM 553,984 ar.exe 26/03/2008 11:49 AM 827,904 as.exe 17/06/2009 09:44 PM 123,046 g95.exe 26/03/2008 11:49 AM 782,848 ld.exe 28/12/2007 12:23 AM 15,964 mingwm10.dll 26/03/2008 11:49 AM 554,496 ranlib.exe 26/03/2008 11:49 AM 685,568 strip.exe 7 File(s) 3,543,810 bytes Directory of C:\util\g95\doc 23/08/2012 09:42 AM . 23/08/2012 09:42 AM .. 16/10/2004 09:36 PM 17,015 bg.gif 27/11/2004 03:51 AM 18,007 COPYING.txt 08/12/2005 06:19 AM 22,431 docs.html 23/11/2004 12:00 PM 107,122 g95.bmp 02/01/2007 01:59 AM 170,619 G95Manual.pdf 31/05/2008 06:59 AM 11,858 Readme.html 31/05/2008 07:00 AM 6,687 README.txt 7 File(s) 353,739 bytes Directory of C:\util\g95\lib 23/08/2012 09:42 AM . 23/08/2012 09:42 AM .. 28/12/2007 12:23 AM 2,192 crt1.o 28/12/2007 12:23 AM 2,288 crt2.o 28/12/2007 12:23 AM 1,239 dllcrt2.o 23/08/2012 09:42 AM gcc-lib 22/10/2006 01:27 AM 408,608 libadvapi32.a 30/10/2005 11:13 AM 253,890 libgdi32.a 22/10/2006 01:27 AM 594,018 libkernel32.a 28/12/2007 12:23 AM 458 libm.a 28/12/2007 12:23 AM 7,514 libmingw32.a 28/12/2007 12:23 AM 267,880 libmingwex.a 28/12/2007 12:23 AM 82,558 libmoldname.a 28/12/2007 12:23 AM 503,692 libmsvcrt.a 22/10/2006 01:27 AM 128,262 libshell32.a 22/10/2006 01:27 AM 435,754 libuser32.a 30/10/2005 11:13 AM 82,086 libws2_32.a 14 File(s) 2,770,439 bytes Directory of C:\util\g95\lib\gcc-lib 23/08/2012 09:42 AM . 23/08/2012 09:42 AM .. 23/08/2012 09:42 AM i686-pc-mingw32 0 File(s) 0 bytes Directory of C:\util\g95\lib\gcc-lib\i686-pc-mingw32 23/08/2012 09:42 AM . 23/08/2012 09:42 AM .. 23/08/2012 09:42 AM 4.0.4 0 File(s) 0 bytes Directory of C:\util\g95\lib\gcc-lib\i686-pc-mingw32\4.0.4 23/08/2012 09:42 AM . 23/08/2012 09:42 AM .. 23/08/2012 09:42 AM 1,022 cc1.lnk 17/06/2009 09:44 PM 5,242,021 f951.exe 17/06/2009 09:44 PM 859,168 libf95.a 17/06/2009 09:44 PM 61,284 libgcc.a 4 File(s) 6,163,495 bytes Total Files Listed: 33 File(s) 12,887,265 bytes 20 Dir(s) 42,207,707,136 bytes free
Now, all that is required to make this work is to set some environment variables. (Start → Control Panel → System → Advanced System Settings → Environment Variables).
First, I had to put some directories in the path, so I edit the PATH variable. It works if I have the path to the g95.exe binary and also to the f951.exe file. That is:
PATH=C:\util\g95\bin;c:\util\winvi;c:\util\g95\lib\gcc-lib\i686-pc-mingw32\4.0.4;[[INSERT REST OF PATH HERE]]
I’ve put [[INSERT REST OF PATH HERE]] at the back, but I’ve actually got the g95-related paths at the back (you want the most commonly used bits of the path at the front, not that it matters with modern fast coomputers). Then, I want to create a new variable called LIBRARY_PATH:
Now, I don’t know if I need all three directories in the LIBRARY_PATH, but it works so I am not complaining.
So to compile my tiny little program I can now type:
X:\Downloads\Brill_dir>g95 -o Brill.exe brillouin.f90
And it works. Is it statically linked? Well, on Linux, dynamically linked, compiled with GFortran, it’s about 68 kB. This binary is about 360 kB, so I sure hope it is statically linked!
Caveats: I have not tried anything fancier than this absolutely basic compile. It works. Compiling with the -static flag makes no difference to the size of the binary.
How’d I do it? It was quite a while ago and I can’t remember, I can’t recall. I’m trying to reconstruct it…
I grew up in the IBM compatible, DOS era. That VGA font that you got by default in DOS still, to this day, looks ‘right’ to me on a terminal screen, even after years of using Linux and Mac OS X and what not. I know it is not a great font in numerous ways, but I am so familiar I don’t even see it. It’s invisible, like a good writing tool should be. So I wanted to use it in my terminal window on Debian. It’s not very hard, maybe. I can’t remember if these were all the things I needed to do…
Mrxvt.sl: 65535 MRxvt.ps: true Mrxvt.xft: 1 Mrxvt.xftFont: Perfect DOS VGA 437 Win Mrxvt.xftSize: 16 Mrxvt.xftAntialias: 1 Mrxvt.saveLines: 10000
And I have aliased the command mrxvt to this string:
alias mrxvt='mrxvt-full -fade 50 -ps -title " " -tn rxvt'
So to get the VGA font, I first went and found a good X windows font, called “Perfect DOS VGA 437 Win”, which is a ttf (TrueType font) when I unzip the archive. I put the file (called Perfect_DOS_VGA_437_Win.ttf) in a subdirectory of my .fonts directory
1 create ~/.fonts/perfect
2 copy files into it
3 mkfontdir ~/.fonts/perfect/
4 xset fp+ /home/goossens/.fonts/perfect/
5 xset fp rehash
I put it under ‘perfect’, and ran fc-cache to update the list of available fonts:
$ ls ~/.fonts/perfect Perfect_DOS_VGA_437_Win.ttf $ fc-cache -f -v .fonts
And, on a modern Linux system, that seems to be all that is required. Except I do notice that my .fonts.conf file looks like this (also serves as an example of what the font looks like in action):
Notice that the line at the end lists my local ~/.fonts directory? I think that might be important, but like I said it was a long time ago and I’m not sure.
So there you have it. Finding Perfect_DOS_VGA_437_Win.ttf somewhere on the web and putting it in your ~/.fonts directory and making sure that that directory is listed in your ~/.fonts.conf file and then changing the font selection line in the config file for whichever terminal emulator you are using might or might not let you use a font you don’t like.
So this little script just uses scanimage, tesseract and vim to scan and process pages from my typewriter. It tries to produce sensible paragraphs, and outputs the results of multiple pages to a text file which can be read in and formatted using a word processor, such as LibreOffice.
It is an interactive script because I do not have a scanner fitted with a sheet feeder. To make it non-interactive, modify the scanimage line after reading the scanimage man page, and remove the line read Response. Nothing fancy, no error checking, no clean-up afterwards, no niceties. But it works pretty well, so far. If you want to use it, install any packages you need to to get scanimage, tesseract and vim to work, and cut and paste the below into a file in your path, and make the file executable.
cat type_ocr.sh # /bin/bash # # type_ocr.sh v. 1.0 # # Script to scan, ocr, process and concatenate pages, e.g. from a # typewriter. # # D.J.Goossens, 14 July 2016. email@example.com # # Start at 1001 so we can be (pretty!) sure all filenames have 4 digit # numbers # # Create the output file. echo This is type_ocr.sh v. 1.0 echo echo Make sure you give it the output filename as a command line argument. echo Ctrl-D escapes from the scanning, Ctrl-C quits elsewhere. echo The resulting images and text files are not deleted. echo They are of the form outXXXX.pnm and outXXXX.pnm.txt and echo may be quite big. echo echo Hit Ctrl-C to exit now or Enter to continue. read Response echo 'Text file from type_ocr.sh v. 1.0' > $1 echo Processed `date` to $1 >> $1 echo 'Note: When it says "document 1001", treat it as document (page) 1' scanimage --batch --batch-prompt --batch-start 1001 -p --mode=Gray --resolution=600 # Outputs are of the form out????.pnm. Loop over them for f in out????.pnm; do tesseract $f $f # The above produces out????.pnm.txt, which we can process, # where first we replace double occurrences of newline with a placeholder # string, then replace single occurrences with a space, then replace the # placeholder with a return character (it is a trick of regular # expressions that we search for \n (newline) but write \r (return) when # we mess with the file). vim -c "%s/\n\n/pLaCeHoLdErStRiNg/g" -c "wq" $f.txt vim -c "%s/\n/ /g" -c "wq" $f.txt vim -c "%s/pLaCeHoLdErStRiNg/\r/g" -c "wq" $f.txt cat $f.txt >> $1 done echo Try typing libreoffice $1 to see what you have got. echo Setting paragraph formatting to indented and one and a echo half space is a good start.
Your mileage may vary. Buyer beware. You get what you pay for. No guarantees implied or given. No warranty as far as possible. (Add here any other escape clauses you can think of.)
I have lots of datafiles I want to plot. gnuplot is scriptable. Since I don’t need any fancy output yet — this is data investigation, not manufacture of publication-quality diagrams — I can get multiple plots out quickly by writing a simple (simplish) couple of scripts.
I am sure people who know bash and perl and stuff can do this much better, but this works for me.
I have a wrapper script that simply consists of multiple calls to an inner script. It is here that I select the files I want to plot:
$ cat make_lots_of_plots.sh ./script_auto.sh r_0001_o_xy_TPA_21_Biso4p8_reread.inp ./script_auto.sh r_0001_o_yz_TPA_21_Biso4p8_reread.inp ./script_auto.sh r_0001_o_zx_TPA_21_Biso4p8_reread.inp . . etc . . ./script_auto.sh r_0050_o_yz_TPA_21_Biso4p8_reread.inp ./script_auto.sh r_0050_o_zx_TPA_21_Biso4p8_reread.inp
I know I could do this in a single script, but I like to be able to call the inner one directly if I just want to make one plot. The inner script, script_auto.sh looks like this:
$ cat script_auto.sh epsname=`basename $1 .inp`.eps echo $epsname scriptname=`basename $1 .inp`.gp echo $scriptname echo "set term postscript eps solid enhanced font 'Times,24'" > $scriptname echo $epsname > temp1111 echo 'set output "' > temp2222 echo '"' > temp3333 paste -d '' temp2222 temp1111 temp3333 >> $scriptname echo "set angles degrees; set polar" >> $scriptname echo "set size square" >> $scriptname echo "set xrange [-0.8:0.8]" >> $scriptname echo "set yrange [-0.8:0.8]" >> $scriptname echo $1 > temp1111 echo 'plot "' > temp2222 echo '" w l lw 3' > temp3333 paste -d '' temp2222 temp1111 temp3333 >> $scriptname echo "set output" >> $scriptname echo "set terminal x11" >> $scriptname echo "quit" >> $scriptname cat $scriptname rm temp1111 temp2222 temp3333 gnuplot $scriptname ls -ltrh $epsname
What’s going on here?
epsname=`basename $1 .inp`.eps echo $epsname scriptname=`basename $1 .inp`.gp echo $scriptname
The bit above just uses basename to create the two filenames I need, one for the encapsulated postscript output, and one for the gnuplot script. Then I basically assemble the lines I want to see go into the gnuplot script. Mostly I can just echo stuff into the file, but I have various quote marks within quote marks, and (for simple-minded me) the solution that I know works is to go via the paste command, and write stuff out to little text files. I am sure there are much tidier ways to do this, but this works for me.
paste -d '' temp2222 temp1111 temp3333 >> $scriptname
causes the contents of the temporary files to be pasted together and put into the script, where the delimiter (‘-d‘) is the thing between the single quotes — which is nothing since the quotes are adjacent. This pastes stuff together with no gaps. The things being echoed into the file are gnuplot commands of various kinds.
Then I cat the script to the screen so I can see what it is doing (if I direct the output from the plotting script into a file, this lets me capture the commands I used), then I remove the temporary files, run gnuplot, and list the newly made file.
Clunky, but simple and effective. Useful changes could include outputting to pdf or some other format, and adding a step at the end (perhaps using pdfjoin) to combine all the resulting files in a single file.
Here is a png of the result. The gnuplot formatting could be made much nicer (title is too big, etc), but the overall process can always be improved, so I’m not worried about that. And the fact that it is a script means I can replot quickly when I know what the final format should be. For now I just want to see what I’ve got.
I want to make little ‘notes to self’ so don’t forget stuff, and I want it on the command line and to be really simple. There are plenty of calendar tools for this, but I thought I would put together s tiny little thing for myself.
No dependencies or downloads (well, none for me, since my system already has zenity)… here is my little script, called ‘remind‘:
cat ~/bin/remind echo 'DISPLAY=' > ~/.reminders/temp1remind echo $DISPLAY > ~/.reminders/temp2remind echo ' zenity --warning --text="' > ~/.reminders/temp3remind echo $2 > ~/.reminders/temp4remind echo '"' > ~/.reminders/temp5remind paste -d '' ~/.reminders/temp[1-5]remind > ~/.reminders/"atjob$1" rm ~/.reminders/temp[1-5]remind chmod 700 ~/.reminders/"atjob$1" cat ~/.reminders/"atjob$1" at $1 -f ~/.reminders/"atjob$1"
So what this does is create a little file in the newly-made directory .reminders. The file name looks like atjobTIME where TIME is a time expression complying with the syntax of the at command. The idea is that the file will act as input to at.
The remind script above is stuck in my ~/bin directory and made executable. I call it like this (dollar is command prompt):
$ remind "12:52 tomorrow" "Lousy test"
(note the quotes, needed if the entry has any spaces or other tricky characters) and it creates a little file in .reminders (a directory created for this purpose) and then runs at, calling that job. So the little file looks like this:
$ cat .reminders/"atjob12:52 tomorrow" DISPLAY=:0.0 zenity --warning --text="Lousy test"
And it creates a little zenity dialogue box that looks like this:
“Gee, wow.” Well, no, no wow at all, but it works. I suppose .reminders might fill up with tiny little files, but I can’t say it troubles me. I’ll clean them up some time. And I know all the piping stuff to little files is clumsy, but it works for me.
I have an HP200LX. It is a real computer — a DOS 16-bit computer, yes, but one with the flexibility that comes with being able to run various (old) compilers. As a science-ist, I recommend and use Fortran, though preferably a modern variant. There are not many Fortran compilers that work on a 16-bit system, and I did not want to bother with a DOS extender on such a constrained environment. Of course, in truth running any language on this old thing is no more than a curiosity.
For the record, I’m writing this in an old DOS port of vi (calvin) on the LX.
On the Web one can find a thing called BC Fortran. It is in German. It is not terribly modern — essentially, FORTRAN 77 — but it works. This is how I used it on the LX. Works in DOSBox as well.
1. Googled around for the archive bcf7713b.zip (‘Use of the compiler is free for non-commercial uses.’)
2. Copied it to my CF card in directory \BC. See this post for how to use a Compact Flash card on a modern computer, if you do not have a card reader with a CF slot in it.
3. Put the card back into the LX. Turned on the LX.
4. Closed down the program manager (Menu -> File -> Terminate all).
5. The CF card is A: so changed to directory A:\BC.
6. Unzipped the archive.
7. For simplicity, I decided to simply copy all the Fortran files into the \BC directory, so I don’t need to worry about the path or anything.
8. I loaded the resident part (necessary for compiling and running programs; not doing this can lock up the LX such that neither the on/off button nor Ctrl-Alt-Del will work… a problem!).
Only do this once; I recommend using command mem /c to look at what has already been loaded. Also, I do not know how to unload it (short of rebooting), or if that is even possible. There used to be old DOS utilities for unloading arbitrary TSRs.
9. It is now ready. There is a compiling step followed by a linking step.
To compile file.f:
bcf -u file.f
To link, explicitly include the library on the command line:
bcl -o file.exe file lib
Here is a session, grabbed from a DOSBox window, not from the LX:
bcf -u short.f BC-FORTRAN77 Compiler 1.3b1711, (c)1990 Andre Koestli, Stuttgart File short.f bcl -o short lib BC-Linker 1.3b1711, (c)1990 Andre Koestli, Stuttgart short.b 2996 lib.b 71948 2 Commons 1600 79 Module 74876 frei 407220 25 Module geloescht 2 Commons 1600 54 Module 58204 frei 423892 13 Module geloescht 2 Commons 1600 41 Module 44764 frei 437332 4 Module geloescht 2 Commons 1600 37 Module 42172 frei 439924 1 Module geloescht 2 Commons 1600 36 Module 41388 frei 440708 short.exe 42416
Now, it seems to be Fortran 77 without any extensions (‘BCC-FORTRAN77 compiles the complete standard from ANSI/ISO’ — from ENGLISH.TXT, which is included in some of the archives); it does not have ‘end do’ for example, though it does have ‘endif’ and ‘else’.
FYI: ‘geloescht’ = ‘deleted’.
This link gives a random number generator that works with the compiler: https://www.cisl.ucar.edu/zine/96/spring/articles/3.random-6.html
Intel 6th-Gen i7 6700K SSD DDR4 4.0GHz CPU, 16GB DDR4 RAM, 2TB SATA III 6GB/s HDD,N600 Wireless Dual Band PCI-Express Network Adapter with 2 Antennae. (Just a cut and paste from the specs.)
Ordered it from D&D Computer Technology Pty Ltd, and delivery was pretty quick. At my work the standard Linux ‘solution’ is RHEL, so it is running RHEL 6.7 (the IT guys here don’t like 7 — it uses the controversial systemd, for one thing…)
Wireless internet so I can put it wherever I want to.
Compared to our previous generation of boxen (4+ years old), it runs a fairly typical Monte Carlo simulation in 20m55s instead of 27m21s, which is a useful but not massive improvement, which is really the result of code that is really just a single, single-threaded process which results in it scaling more with the clock speed than anything else.
I’ve put LaTeX on the box, but I am going to manage it via TeXLive’s tlmgr rather than RHEL’s package management, so we’ll see how that works out…
This old DOS program has no use today. It is easy enough to run it in DOSBox of course, but why would you?
I just like the look of it.
The ‘almost analogue’ clock offers a novel way to watch time go past, with three bar charts, one for each of hours, minutes and seconds. It comes with source code but the program needs DOS-specific files like DOS.H. So it cannot be just quickly recompiled for Linux/Windows as far as I know.
Finding it on the web is a bit hit-and-miss. A bit of semi-random searching on terms like ‘BCLOCK.ZIP’ and ‘SIMTEL’ and ‘DOS CLOCKS” tends to turn it up in the archive ‘BCLOCK.ZIP‘. Something like this: http://www.filewatcher.com/m/bclock.zip.33143-0.html. I suppose some of the files might be virus-ed, so be careful.
Recompiling for Linux, say, would be best done by a significant rewrite that uses some kind of cross platform graphics library. My C coding is not up to that, I’ll admit, though it is a little project I have in the back of my mind. The layout is rather amenable to sprinkling the display with vertical bars to indicate appointments or deadlines, and I can imagine it being quite a nifty little application.
Advances in Condensed Matter Physics is an open access journal. I have published in OA journals before, but I am pretty selective about them. For example IUCrJ is is published by the IUCr, and I strongly believe that their name is a ‘guarantee of quality’ as good as any. The other open access paper was in ISRN Materials Science, which was more of an unknown quantity for me, and being a publisher who seems to have expanded via the OA model, the idea of sending work there initially filled me with skepticism. This rather abated when it turned out they wanted a commissioned article and they were even prepared to pay me for it. I am quite happy with how it turned out. The picture below is not that paper but the new one.
Recently, I got an email from Advances in Condensed Matter Physics asking me for an article. Now, I delete several of these sorts of emails a day, and was about to delete this one when I thought, well, perhaps I should give the publisher — Hindawi, publishers of ISRN Materials Science — a second look. The fact that they were prepared to commission something from me showed (of course) remarkable good taste, and the fact that they were prepared to pay for it (and did) suggested that they have an intention of climbing out of the ruck and mall of crappy OA publishers.
So I reread the email. It appeared that they were prepared to waive the fee. Good start. I then went to the ACMP website and searched for the names and work of some scientists that I respect. And they had indeed published there. The journal has a proper impact factor, even if not especially high, and is not just indexed on google scholar (ie, not really indexed at all) but in proper databases like Web of Science. Okay, so it seems like a real journal.
There was an article I wanted to write, one of a very specific kind. I have been developing and using the ZMC software for modelling diffuse scattering from molecular crystals — looking at subtle orderings in materials to improve understanding of structure and function. The process is non-trivial, and not easy for the novice to get a grip on. So what I wanted to do was create an example of a simulation of a crystal, write a paper about it, then upload a bundle of files (as ‘additional material’) that would let a user recreate the simulation.
This seemed like an ideal opportunity, because the software would then be available and not hidden behind a paywall. Indeed, that is how it has worked out — the simulation (‘supplementary material’) can be downloaded by anyone by going to this page.
So not all OA publishers are alike, but it is important that a prospective author does their research into the journal and makes sure they are credible.