Computing desk
< April 11	<< Mar \| April \| May >>	April 13 >

Welcome to the Wikipedia Computing Reference Desk Archives
The page you are currently viewing is a transcluded archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages.

April 12

COBOL

The late, great Robert B. K. Dewar, author of Realia COBOL among other things, apparently thought (not exactly recently on the calendar, but at least in this somewhat modern era of computer geekery) that COBOL had things going for it that present-day language geeks were missing out on, and that we shouldn't make fun of it. COBOL is in the news lately because of unemployment systems strained under COVID19 needing software fixes. Can anyone suggest any interesting reading about it from a programming-language buff's perspective? Its heyday was before most of our times: are there still things that we should learn from it? Thanks. 2601:648:8202:96B0:E0CB:579B:1F5:84ED (talk) 01:54, 12 April 2020 (UTC)[reply]

Not an answer to your question, but I know that Dewar actually used COBOL for writing some compilers, not directly the area of application the language was designed for. Among the things COBOL has going for it are a clearly defined platform-independent semantics (if you ignore supplier-dependent extensions), as well as being well adapted for the intended type of applications. There are no Obfuscated COBOL Contests for a reason (but see the second contribution by Mike B on 10/23/05 in this comp.lang.cobol thread). --Lambiam 10:00, 12 April 2020 (UTC)[reply]

Thanks. I went from that thread to other Cobol-related posts by Dewar in other places, and found that he indeed somewhere mentioned writing a compiler (a Cobol compiler in fact) in Cobol. I didn't manage to find out what he liked about Cobol but maybe it is out there somewhere. I'm regretful that I never had a chance to talk to him before we lost him. I was once active in online circles that overlapped his, so I probably missed some opportunities. RIP. 2601:648:8202:96B0:E0CB:579B:1F5:84ED (talk) 00:05, 14 April 2020 (UTC)[reply]

I realize now that the compiler I mentioned I knew Dewar was writing using COBOL, which was in 1982 or 1983, must have been the Realia COBOL compiler. For your amusement, here is an ad announcing that compiler. --Lambiam 04:43, 14 April 2020 (UTC)[reply]

A bit late posting this, but one notable thing is that COBOL file access is all record-oriented, and it supports key-based random lookup of values. This is useful for database processing, which is frequently needed in business applications, what COBOL was designed for. Most of the popular "modern" languages have C/ALGOL heritage, and C in particular literally came from the Unix world, where all files are byte-oriented (a "bag of bytes"). In many of these languages, if you want support for database formats, you have to turn to libraries, although some modern "bells-and-whistles-included" languages like Python include basic database interfaces in their standard libraries. --47.146.63.87 (talk) 00:47, 20 April 2020 (UTC)[reply]

Display Resizing Itself

I am having a period minor annoyance that one or more windows are resizing themselves to be smaller than I have expanded them to. This is happening on a desktop computer with an E2241 wide-screen display that is connected to an Intel Graphics 630 and is running Windows 10. The desktop resolution is 1920x1080. What happens is that I have dragged some of the windows to increase their depth or width, but have not filled the screen, just almost filled the screen. Then I go away, and come back in more than 10 minutes. The display has turned itself off, but the system has not gone to sleep. Then I move the mouse, which of course turns the display back on, but some of the windows have downsized themselves. They are no longer as big as they were, but are not minimized or maximized. This has happened with Microsoft Word, Firefox, and Opera. I can drag them to expand them again. What can I do to ensure that the windows remain at the size that I have dragged them to after the display turns itself off and is turned back on? Robert McClenon (talk) 05:45, 12 April 2020 (UTC)[reply]

One possible fix here. The discussion on that page suggests there are other causes as well. 85.76.76.47 (talk) 09:50, 12 April 2020 (UTC)[reply]

Editing the Registry

Thank you, User:85.76.76.47. The fix appears to be to the registry. Is there a standard Windows 10 utility that I can use to edit the registry without the need to get a registry editor or whatever? Robert McClenon (talk) 00:23, 13 April 2020 (UTC)[reply]

Robert McClenon, to edit the registry you use a registry editor. "Regedit" is provided with Windows 10. You can severely damage your system by making the wrong edits to the registry! Back up your system before making any change. It would also behoove you to set a system restore point along with your backup. Don't edit the registry if you don't know what the settings will do. And be careful beliving what random blogs (not WP:RS) say about your Windows issues. (I see the one linked-to also links to a Microsoft article, a good sign.) Elizium23 (talk) 01:07, 13 April 2020 (UTC)[reply]

FAST's website

The website of the Five-hundred-meter Aperture Spherical Telescope appears to be down. Don't know if this a temporary issue or they moved (searching didn't help). Brandmeister^talk 15:38, 12 April 2020 (UTC)[reply]

Video files become larger after I edit them

I have downloaded MP4 video files from the Internet and used OpenShot Video Editor on Fedora Linux to edit them. The only edits I do to them are to remove sections of the video I don't need, so the videos become shorter. I don't edit anything else. When I export the edited video to a new MP4 file, it is somehow much larger than the original file, by a factor of almost ten. What is causing this? JIP | Talk 16:26, 12 April 2020 (UTC)[reply]

That depends on a few things. Mainly, how are you measuring their size? ls -l?

Unix has, for a long time, had a concept of "sparse files". These are files which contain long strings of "0" bytes. They can be created by using lseek(2) to "skip" the zero chunks. The underlying filesystem (such as ext4) understands the seeks and preserves the zero chunks when read back, but the file occupies far fewer blocks on disk. ~~The ls -l should show the same byte size (5th column) for a sparse file, but a different block size (2nd column).~~ (See below for usage).

That's just one guess. There are other guesses based on the codec behavior that I couldn't begin to answer. But I suspect them more than the "sparse file" answer. Elizium23 (talk) 16:32, 12 April 2020 (UTC)[reply]

Yes, I'm measuring them with ls -l. JIP | Talk 16:34, 12 April 2020 (UTC)[reply]

You can detect when a file is sparse by using ls -ls on it. This will show the physical size in filesystem blocks as well as the logical size in bytes. If you don't know your filesystem's block size, just use the same command on a file that isn't going to be sparse. --76.71.6.31 (talk) 19:27, 12 April 2020 (UTC)a[reply]
Oh yeah, thanks IP. I misread the "# of links" field as the "# of blocks" field. Elizium23 (talk) 19:30, 12 April 2020 (UTC)[reply]
I just did that on two MP4 files, one that I had edited and one that I hadn't. The number of bytes divided by the number of blocks was 1024 on both. So it's probably not because of sparse files, but because of OpenShot re-encoding them like User:Finlay McWalter wrote below. But the advantage of using OpenShot over using ffmpeg is that I can see the video as I'm editing it and so can detect the exact place that I want to cut it at. And is ffmpeg able to cut out a piece in the middle of a video and concatenate the resulting parts? JIP | Talk 19:39, 12 April 2020 (UTC)[reply]
I wouldn't want to deny you the ability to use a simple GUI-based application when that is what you are comfortable with. And no, from studying ffmpeg options, I don't see a straightforward way to do what you want.

I would say to check your "target profile" in Openshot. Do "File properties" on the source MP4 and conform your export parameters to the source file as much as possible. Even a reduction in one parameter at a time should show a difference, as far as file size goes. Elizium23 (talk) 20:03, 12 April 2020 (UTC)[reply]
I think we should back up a minute. Two programs have been suggested. It doesn't mean either have been used. There must be thousands of GUI Windows programs capable of splitting, cutting or combining exact same settings MP4s without re-encoding. (Well maybe some minimal re-encoding for the beginning and end if you require frame accuracy rather than accepting cutting to keyframes, which admittedly is quite a bit harder to find although I'm fairly sure I could find one that is free within minutes if I don't worry too much about patents or quality of that minimal re-encoding.) Are there really none for Linux that can do this? Nil Einne (talk) 12:51, 14 April 2020 (UTC)[reply]

JIP, to explore the OpenShot codec issue a little bit, you would do well to note down the parameters when you import the video file. What codec does it use? What bitrate/framerate? What resolution? What quality is set? Audio track(s)? Things like these will affect the filesize.

Then when you go to export, make sure your settings are the same, or smaller, than the imported file. You may be importing a low-quality small-resolution video and exporting it as high-quality, high-resolution. OpenShot will gladly and transparently do that conversion for you, resulting in the larger file. Elizium23 (talk) 16:45, 12 April 2020 (UTC)[reply]

The trouble with using a digital NLE like OpenShot for such simple cutting is that it will typically render (which means reencode) its entire output. As you're using a lossy codec, that risks noticeable loss of quality, takes a long time, and as Elizium23 notes, you have to worry about setting the many output codec parameters (for both video and audio). Ideally you wouldn't reencode at all, but just copy the sections you want, and have the editor rebuild the internal indices in the video container. I don't know if OpenShot is smart enough to do that. You can do it yourself, manually, with ffmpeg:

ffmpeg -i in.mp4 -ss 01:02:03 -to 01:03:04 -c:v copy -c:a copy out.mp4

Crucially there's the -c:v copy -c:a copy part, which sets the video codec to "copy" and likewise for audio (so it doesn't try to encode the output, it just copies the data from the input). So there's no reencoding, no loss of quality or inflation of filesize, and it's very quick indeed. -- Finlay McWalter··–·Talk 17:30, 12 April 2020 (UTC)[reply]