September 30

like 'Yahoo mail' & 'Twitter'. What happens is this: the current page doesn't remain the one I chose, like an open message in the 1st or a 'tweet' & 'home' in the 2nd, and jumps backwards, automatically, to its previous phases. Namely, back to the mail directory in the 1st or back to my main page in the 2nd, or even out of 'Twitter' (back to the original new tab or google search page). Sometimes it remains stable for many minutes, but many times I'm thrown away in seconds or less. It just happened to me also here, a moment ago, while writing down this question, forcing me to rewrite it from the beginning. This problem occurs only with web page (not in 'Word', for example). My OS is the latest version of Win. I don't what causes this, and any assistance will be appreciated. בנצי (talk) 11:56, 30 September 2017 (UTC)[reply]

Are you somehow pressing alt+left arrow? Sometimes backspace can have the same effect, but not when you are typing. Does this happen when you are not typing? Do you have a faulty mouse? (You've probably checked all of these.) Dbfirs 15:36, 30 September 2017 (UTC)[reply]

Thank you for responding. It happened tens of times by now already. even as I speak, right now. No, the keyboard isn't interrupted. You might interrupt once by mistake, but not so many times without touching anything (or typing). Sure something's wrong, and don't how to handle it. בנצי (talk) 16:12, 30 September 2017 (UTC)[reply]

Obviously something is sending a "go back" signal to the browser. Can you disconnect the keyboard and mouse to see if it still happens? Have you tried a different browser? Dbfirs 07:38, 1 October 2017 (UTC)[reply]

How much power do individual laptop components (screen, chip, HDD) consume? What's their share in the energy consumption? --Hofhof (talk) 13:26, 30 September 2017 (UTC)[reply]

This article is a little bit old (almost 15 years old), but pretty thorough: [1]. In summary, in a running system, the CPU is at the top, followed by the display. When the system is idle, the display consumes more than the CPU. Network adapters and disks can consume a big chunk of power, when running, but they are often idle.

Reducing your display brightness can help you save power.

In the mean time, HDD were partially replaced by SSDs, which consume less too. I'm pretty sure battery management and stand-by management has improved in the meantime.--B8-tome (talk) 15:20, 30 September 2017 (UTC)[reply]

I have just deleted a file from my drive. Is there any way I could get it back? 116.58.202.248 (talk) 15:55, 30 September 2017 (UTC)[reply]

https://www.piriform.com/recuva (((The Quixotic Potato))) (talk) 15:59, 30 September 2017 (UTC)[reply]

To offer the best advice, it would be helpful if you said what operating system you are using. --Phil Holmes (talk) 16:41, 30 September 2017 (UTC)[reply]

It's also relevant how the file was deleted. Maybe the OP hasn't even emptied the trash bin. But if he has, then something like EaseUS Data Recovery Wizard can help both in a Mac or Windows. In Linux the user would be kind of out of luck, but there are a couple of things he could try. --B8-tome (talk) 20:01, 30 September 2017 (UTC)[reply]

The first software suggestion did not list the file. The second suggestion did not look like an opensource software.

I'm using Windows 7. The deletion method was completely delete from the computer automatically; every time I press the "Delete" button...

103.67.157.21 (talk) 18:09, 2 October 2017 (UTC)[reply]

hello everyone. One of the things I do is produce publication-quality PDF images of mathematical concepts. My workflow is: first, write an R script to produce a PDF; second, use inkscape to convert the PDF to SVG format and tweak the image (usually layout changes---such as moving axis labels---that improve the visual appearance) and then save-as a PDF which I then send for publication. So, I potentially have five files: foo.R, foo.pdf, foo.svg, foo_post_inkscape.svg, and foo_post_inkscape.pdf. I want to place the whole process under version control on GitHub.

I know that neither PDF nor SVG are supposed to be human-readable, which means that these files should not (?) be on the github repository. So my question is: what is Best Practice to record this kind of workflow on GitHub? thanks, Robinh (talk) 21:45, 30 September 2017 (UTC)[reply]

I agree that PDF is hardly human readable, unless analyzing it with a hex editor counts as human readable. However, SVG is an xml file, isn't it? This is a text not a binary file for me.

And couldn't you just skip the second step just exporting directly from R into SVG?--B8-tome (talk) 22:56, 30 September 2017 (UTC)[reply]

@Robinh: This page https://help.github.com/categories/working-with-non-code-files/ mentions both SVG and PDF viewers as a GitHub feature, which I take to mean you can store both of those formats in GitHub. RudolfRed (talk) 23:10, 30 September 2017 (UTC)[reply]

I suppose the OP wants to put them in the rep and compare differences, which is not very meaningful with non-human-readable files. B8-tome (talk) 00:00, 1 October 2017 (UTC)[reply]

(OP) thanks guys. I didn't know about R's svg(), it's a big improvement over pdf() for my purposes; thanks B8-tome. SVG is indeed ascii but not human-readable in the way that R source code is. But suppose I have foo.R and foo.svg on the repository. Then foo.svg has *two* methods of creation: first directly by R (and svg()); the second by inkscape editing (and subsequent saving) of foo.svg. This does not feel right, but I can't quite say why. Any more advice guys? Robinh (talk) 00:37, 1 October 2017 (UTC)[reply]

You could also use some form of Prettyprint or XML-beautifier on the SVG file for making it more readable. B8-tome (talk) 11:28, 1 October 2017 (UTC)[reply]

As someone who has manually edited SVGs from time to time, I can honestly say that an XML-beautifier may or may not buy you much. It depends on what the SVG contains and what software was used to create it. The SVG standard allows for the full embedding of base64 encoded images (typically PNG or JPEG), fonts, and other binary data. If you are exploiting that feature, then the SVG source may include large blocks that are not human readable. Some production software also embeds huge binary "metadata" segments. For example, I've seen software that converts XYZ format to SVG but nonetheless decide to include an entire base64 encoded copy of the XYZ format in the SVG metadata. Presumably this is to allow people to convert back flawlessly, but it makes for huge and ugly SVG source. Similarly, production software often includes more attributes than is needed. Where a human might only specify element attributes that are necessary or changed (leaving missing elements to take on their default or inherited values), production software often specifies every possible attribute on every element, making the resulting output unnecessarily verbose. Human beings rarely look at SVG source, which is probably one of the reasons that graphics software that writes SVGs often creates incredibly messy files. Dragons flight (talk) 07:25, 2 October 2017 (UTC)[reply]

The first criterion for "goes in the repository" is "Does it directly reflect human creativity?". The .R and the final .svg meet this requirement, but not the intermediate and output files (be they .pdf or other .svg). Once you've identified what goes in, then you consider human-readability, principally as a means of determining what formats in which to do your creative work. The biggest reason for human-readability (as regards version control) is that given by B8-tome: diffing and merging. You're close with SVG, especially if (from B8-tome's other post) it's pretty-printed (which introduces more newlines that diff(1) can use).

So store the original source (of course) and store the hand-editing result (before conversion (back) to PDF) under a file name that indicates that. You can easily write a shell script to compare the original (i.e., reconstituted from source) SVG to your edited version to inform (via patch(1) or just via human reading) the preparation of a new polished version from new R source. --Tardis (talk) 20:31, 1 October 2017 (UTC)[reply]

(OP) OK guys, thanks for this. @Tardis, let me check I understand. We have foo.R on the repository, which creates foo.svg (not on the repository). I then create, using inkscape and human judgement, foo_post_inkscape.svg (on the repository), which inkscape can then export to a PDF file, foo_post_inkscape.pdf (not on the repository). I feel that foo_post_inkscape.pdf should be on the repository anyway, so folk without inkscape can download it if they wish. Any comments anyone? Robinh (talk) 07:47, 2 October 2017 (UTC)[reply]

Git supports all kinds of workflows. For me, I'd just throw the entire folder into Git. It's less hassle (git commit -a), and you can check everything out at once on a different computer. I would only exclude files larger than 2 MB because of GitHub file limits. C0617470r (talk) 22:09, 2 October 2017 (UTC)[reply]

FYI, rather than 2 MB, the link you gave actually says the GitHub limits are 100 MB per file and 1 GB per repository. They do discourage the inclusion of large files though. Dragons flight (talk) 07:28, 4 October 2017 (UTC)[reply]

You translated what I said correctly. As for foo_post_inkscape.pdf, all I can say is that version control is not a deployment system. If you want to give people PDFs, great: put them on a website, not in a repository. --Tardis (talk) 06:57, 4 October 2017 (UTC)[reply]

I can't speak to GitHub's particular rules, which may be a limitation on what is included, but I think you are drawing a distinction between version control and distribution that isn't well followed in practice. Repositories are, obviously, a means of distributing code and supporting materials. Whether or not it would be regarded as a best practice, when the output of the code is some form of reusable material (say graphics or data), I have often seen repositories include multiple versions of that output with the intent of being flexible about reuser needs. In my experience, including both an SVG and a PDF would be pretty commonplace even if there is really no difference between the two except for mechanical translation. Obviously there are arguments against that, not least of which is that PDFs are not very machine readable, but if we are talking about small-scale repositories (as I think we are), then as a user I certainly wouldn't be upset if such files were also included. Dragons flight (talk) 07:43, 4 October 2017 (UTC)[reply]