News for hackers. Stuff that matters.

chaitanya

You can’t, because JavaScript date objects are just timestamps.

Here’s what I wrote on this (along with a small library to handle this problem): https://lisper.in/javascript-date

Re:Ask HN: What is your Git commit/push flow? on Thursday March 17, 2022 @01:58PM (#30714048)
You can have the best of both worlds -- "commit early, commit often", and "nice clean commit histories" -- with git, and it is easier than most people think.

- So you start work on a new branch, and reach a checkpoint. Create a new commit with "git commit".

- Continue working, and when you reach the next checkpoint, create another commit. But this time, use "git commit --amend". Contrary to what the flag says, this doesn't modify the previous commit, instead it modifies your commit history and replaces the last commit with a new one[1]. So instead of having two new commits in your branch's history, you only have one.

- Repeat the process until you have something worth pushing to the remote.

- Once you've pushed to remote, remember to not make any further modifications to your git history[2] i.e. going forward, create a new commit and only then run "git commit --amend".

Now, there's an obvious question here: if "git commit --amend" keeps replacing the last commit with a new one, what happens when you mess things up and want to revert to NOT the last checkpoint, but some checkpoint before that?

The trick here that git has up its sleeve is called "git reflog". You see, while "git commit --amend" replaces the last commit in your branch's history with a new one, the older commit is not actually gone, its still there. And you can see all of them with "git reflog". Basically "git reflog" returns every commit at which the local HEAD (i.e. the commit checked out in your working directory) has been. So none of the commits that you replaced with --amend are actually lost, and you can find them all in the reflog.

Restoring to an older checkpoint becomes as easy as running "git reset --hard <previous-commit-id>", or if you want to play safe, "git checkout -b <new-branch-name> <previous-commit-id>".

Hope this helps!

Notes:

1. By design, a commit, or in fact most objects in git cannot be modified. They are immutable.

2. Basically you can play with git history as long as it is private to you and not shared with others. But the moment you push it to a remote you share with others it's no longer private and you must not modify that history anymore. Read Linus's note on keeping a clean git history: https://www.mail-archive.com/[email protected]...

Only plausible explanation I can think of is that perhaps you or your girlfriend looked something up about drying a wet memory stick.
> This would benefit from a "select all/none" option for the regions.

Yeah, that would help. I'll add this.

> Also, adding spot pricing would be SUPER helpful!

Unfortunately spot pricing is not available in the bulk pricing API, which is what I am using here. But there does seem to be a separate API to get the spot pricing history - I will try to use it.

Growing up in the pre-Internet era Reader’s Digest was such a good resource due to stories like these. Was always excited to see a new magazine arrive every month.

I wonder if it’s any good now. Haven’t looked at it in years.

Re:Run More Stuff in Docker on Saturday December 26, 2020 @07:33PM (#25547683)
If you are on a Mac or Windows, this approach only works for utilities that can run on Linux. If you need to run a native Mac program for example, docker won't be able to run that.

Perhaps Nix might help here, but I've never used it, so can't say for sure.

Re:Roughly 2000 blogs running on a $7/month dyno on Wednesday September 23, 2020 @09:45AM (#24566974)
If the upstream returns an error over HTTP, the CDN won’t hide it.
Re:Restarts in Common Lisp on Wednesday April 01, 2020 @01:57PM (#22751605)
Many years ago I wrote about restarts in CL using the example of a CSV parser: https://lisper.in/restarts

Fun fact: the restarts based CSV parser was based on some real world work me and a colleague had done for an online travel portal. I wrote about it here: https://www.reddit.com/r/lisp/comments/7k85sf/a_tutorial_on_...

Re:Why does 1.1.1.1 not resolve archive.is? on Friday October 04, 2019 @08:56AM (#21157135)
Does 1.1.1.1 send ECS info to Cloudflare’s own nameservers? More generally, does 1.1.1.1 in any way treat Cloudflare’s own nameservers in a special way and send it information that it doesn’t send to others?

If the answer to these questions is no, then Cloudflare’s reasons for blocking ECS (ie privacy) carry weight. Otherwise no.

> Surviving rising water levels is trivial of course - just walk away from the beach.

I don’t want to take away from your other point but this is not so trivial for the hundreds of millions living in low lying countries like Bangladesh.

Re:Project Svalbard: The Future of Have I Been Pwned on Tuesday June 11, 2019 @05:02AM (#20153873)
Many people here assuming that Troy Hunt will leave HIBP after selling it. He explicitly mentions that he will remain a part of it:

> I'll remain a part of HIBP. I fully intend to be part of the acquisition, that is some company gets me along with the project. HIBP's brand is intrinsically tied to mine and at present, it needs me to go along with it.

Re:AWS costs every programmer should know on Sunday June 09, 2019 @01:25PM (#20140492)
Right. At a previous company our Cloudfront bill ran up to $2000/mo because someone ran a test script a few times every minute that fetched a few resources from CF. Once we killed that script our CF bill dropped down to $200/mo.

Cloudfront’s pricing can absolutely bite you if you are not careful. Which is one of the reasons why I prefer Cloudflare over it.

Aren’t TLS certificates also sent in plaintext?
Re:PySnooper: Never use print for debugging again on Tuesday April 23, 2019 @02:05AM (#19725982)
Nice. Does CPython have something like this?
Re:PySnooper: Never use print for debugging again on Tuesday April 23, 2019 @02:02AM (#19725968)
Yeah but the idea is that, with TRACE, most of the time you shouldn't need to drop into the debugger (all CLs come with an interactive debugger too). If TRACE is not sufficient, only then do I go down the debugger route (or strategic print statements).
Re:PySnooper: Never use print for debugging again on Tuesday April 23, 2019 @01:56AM (#19725948)
Thanks! Yeah this should do the trick I think.
Re:PySnooper: Never use print for debugging again on Monday April 22, 2019 @09:40AM (#19718811)
Is there an equivalent of Common Lisp's TRACE in the Python world?

IMO it is the most value for money (i.e. time and convenience) debugging tool I've used till now. Simply write (TRACE function1 function2 ...) in the REPL and you will get a nicely formatted output of arguments passed and value(s) returned for each invocation of the given functions. Another nice feature is that a deeper an invocation is in the stack the more it is indented -- so recursive functions are fairly easy to debug too.

You can't use it for everything but its sufficient most of the time.

PySnooper looks good, but it is inconvenient in a couple of ways:

1. It prints every line of the traced function -- most of the time this is overkill and not what one needs. 2. To snoop on a function you need to modify the source file. Not a deal breaker but you still have to remember to revert this.

Older »