This question has probably been asked and answered, but I can't seem to find any post that resolve my issue – mostly due to my lack of searching skills. So I apologize if my post is a duplicate and would appriecate if you either refer me to another post or answer my simple question.
When I first open -zsh terminal on my macOS, I am used to seeing the following prompt.
(base) kimsan#Kims-MacBook-Pro ~ %
On rare occasions, however, I see a totally random sequence of characters after #. For example,
(base) kimsan#MDOM10FX ~ %
As I said, the sequence of characters followed by # is – or seem to me, at least – random; thus, changes everytime. Above is just one instance of example.
Why is this???
It has been a while since I first noticed this issue. I freaked out at first thinking that I messed something up with my system memory – which, in hindsight, is not even possible. Now, I think of it as some random inconsequential glitch that don't cause any harm. Nonetheless, I would be more comfortable knowing the cause of such glitch.
Thanks in advance.
Related
I am trying to learn to code in UNIX and despite this question being all around I cannot seem to find any answer to what this instruction does. All of the answers I get either refer to the instruction exit() or _exit(0) and _exit(2). Am I missing something?
The values are the so-called exit-values of your application. Generally, when a program has zero as an exit-value, this means that everything was good, while other numbers generally indicate some kind of error value.
I've done some research online but I haven't been able to come up with any answer. I know this has been asked at least thrice, as I've viewed those posts, linked here:
First Question
Second Question
Third Question
However, it's been 5, 7, and 9 years since those questions have been asked, and technology is obviously rapidly evolving :) I don't know much about R, and I haven't worked with it for a long time, and so I ask those of you who know better and have more experience if you know of anything that would be useful to me.
If there's nothing that exists now, how hard would it be to create? The reason I ask is that the company I work for would like to obfuscate the proprietary code before it goes out. I would have the full 40 hours a week to work on creating it, and so time and/or difficulty isn't a major concern.
Thanks!
Found this: I'm not sure about the security, but this is definitely a deterrent and would take (I think) some fairly concentrated effort to crack. There is a byte code compiler for R based on the paper linked below. There is a method in library(compiler), which comes standard with R, that allows you to compile an R script to byte code. In the same library, you can load in the source files and use them as you'd like.
A Byte Code Compiler for R
New to posting here on stackoverflow, so please forgive any transgresses that occur.
So a little background....
My grandfather is a current computer science professor at a university. I have always taken a great interest in computers, and have really grown into dealing with the hardware side of things. However, him being how he is, he wants to me to have a broader understanding of computing in general. Including coding/programming.
SO to my question.... He has given me a Key P5FW-93F6. He told me, that if I am able to make other keys "with the same value" he will give me a reward. So as I am trying to solve this problem, I haven't a clue where to start. In the beginning, I have entered the code, and followed the pattern of Letter, Number, Letter, Letter, etc. into excel and used the random value function.. However, none of these keys work in his program. He told me there is a massive amount of different "Keys" that will work but will not provide hints on to how to solve the problem. What language should I learn to solve this? Should I be looking for a hash value to be the same as the one key listed above? I am completely lost... any help would be appreciated!
Thanks!!
P.S. I do have an unlimited number of attempts, however only have one line that I can enter at a time. So I can't make batch entries.
Please excuse my terminology as I am still getting my head wrapped around everything. I am trying to put together my first parser and have trying to find as many examples as I can to in trying to build my grammar. I've seen many situations where a non-termianal gets multiplie productions
<F>::=(<E>)
<F>::=id
Which is the same as writing
<F>::id|(<E>)
From everything I've read, this is perfectly fine. What I am looking to do is the following
<atsign>::=#
<expl>::=!
<special>::=!|#|#|$|%|^|&|*|(|)|+
Is there anything I need to be mindful of? Is my ordering correct for an LR parser? This isn't exactly homework as I am not in school at the moment, but it can be treated as such since I know this is a course I'll be taking in the future.
This question is inspired by the remark of Duncan Murdoch on the r-devel mailing list in response to a bug report about Sweave :
This is fixed in R-patched. (It would
have been fixed in 2.12.0 if more
people tested the betas...).
Honestly, I've stayed away from beta -aka development- versions for a number of reasons, and these are reasons I hear from more people :
I am a bit horrified it would
somehow cause conflicts with my
current R distribution. As I need it
for work, having to repair it regularly would be a loss of
time I can't explain to my boss
I wouldn't have a clue how to test
efficiently. I reckon every test I
could come up with has already been
run by the development team.
I still find it difficult to figure
out when something is a bug, and
when (most often) it is my own
stupidity kicking in.
But as I understood, it would be a valuable contribution to the R community, and I'm willing to do my bit of the testing as well if I can fit it somehow into my own work. I was thinking of keeping the beta on the side and running my scripts through it as well as a checkup. Saving the constructed objects allows a quick and easy all.equal() to see if something is wrong.
Anybody some more/better ideas on how I could help testing with a minimum amount of effort and a maximum amount of efficiency?
I'd also like to promote this a bit more on our department as well. Apart from the "It's time to give back to the community", any other good reasons why testing betas is worth the effort? How can I counter the arguments given above?
Edit:
As Dirk Eddelbuettel pointed out in the comments, part of the deal is preventing the path variables in Windows. I have some ideas on that, but pointers on how to practically organize your computer for testing R-devel versions are greatly appreciated as well.
I fear you misunderstand. This may not be straightforward or obvious at first so maybe this helps:
"patched" is not "beta". Patched is what R 2.12.1 will be.
There is no conflict. It drops in for 2.12.0.
It is a separate download, and a nightly build available from here.
This is not r-devel but r-patched.
It is our duty as users to test pre-releases as well. So if anything, in an ideal word you would have R-patched installed --- as well as R-devel!
Testing can be as easy as installing another version, keeping it outside your path and then adjusting PATH and R_HOME dynamicaly from a script. Testing means running it on your code and data to prevent you from getting bitten by bugs once the new code is released.
I wouldn't have a clue how to test efficiently. I reckon every test I could come up with has already been run by the development team.
I still find it difficult to figure out when something is a bug, and when (most often) it is my own stupidity kicking in.
The problem is, software is not (or not only) going to be used by developers. It is going to be used by people that may not have programming knowledge at all (I'm speaking generally, this is valid for R as well as for any other software).
If the help or the interface or the general way the software is built do not give you enough informations on how to do something, well, that is maybe not a bug, but it is something that can be improved (and pointed out to the devs).
Also, remember that the developers wrote the software. They know how to use it and often they will be biased in testing it mainly by using it correctly and see if it gives the good result rather than by "trying to break it".
By using it in YOUR way (which may possibly be "uncorrect"), you are effectively running tests that maybe escaped the developers, just because they were not thinking of using it like you did.