search

marius311 / Memoization.jl

Easily and efficiently memoize any function, closure, or callable object in Julia.
MIT License
99 stars 2 forks source link

Combine with Memoize.jl? #3

Open kmsquire opened 4 years ago

kmsquire commented 4 years ago

See https://github.com/JuliaCollections/Memoize.jl/pull/52#issuecomment-589406279

I recently spent some time working on Memoize.jl--it was essentially unmaintained for 2-3 years, which is probably what prompted you to create this package.

If I had known about Memoization.jl, I might not have bothered, but would you be interested in replacing the functionality in Memoize.jl with this one (and becoming a maintainer)?

I found your discourse post from last fall where you declined to try to merge the two, but

If you'd rather not, no worries. Cheers!

Cc: @cstjean

marius311 commented 4 years ago

Hi, thanks for this suggestion. I'm not at all against it, but let me get back to you with some technical questions about how this would look like later in the week when I have a bit more time.

marius311 commented 4 years ago

Hey, sorry, just now got a chance to look at this again. Thanks again for the invitation to do this. I do see two ways of doing this:

1) A PR which just replaces all of Memoize with this package, like you mention, and I maintain this over there. Additionally, this package gets archived with a message (and maybe even an in-Julia dep warning) pointing to Memoize. 2) I transfer ownership of this repo to JuliaCollections and continue to maintain it there, and its Memoize which gets the archival / message.

I probably lean towards 2 since it keeps the repo histories in tact and somehow seems cleaner, and ultimately, no matter what, some users would have to swap using Memoize for using Memoization or vice-versa, depending on if 1 or 2. But if you guys feel strongly that it should be 1, I'm totally ok with that too, let me know either way.

cstjean commented 4 years ago

I'm impressed with your @memoize macroexpansion code, it's quite short!

kmsquire commented 4 years ago

Sorry, also been distracted for a while.

I like the Memoize name more because it's shorter and (I think) easier to find. It would be slightly more work, but it's possible to both change the name, and keep the git history, if you're willing:

git clone https://github.com/JuliaCollections/Memoize.jl.git
cd Memoize
cp Project.toml ../Project.toml.orig # Save this, for the project uuid
git rm $(git ls-files)
git commit -m "Remove all old files in preparation to merge Memoization.jl"
git remote add -f Memoization https://github.com/marius311/Memoization.jl.git
git merge Memoization/master --allow-unrelated-histories
# Global search and replace Memoization/Memoize
# Copy uuid from ../Project.toml.orig to Project.toml
# Commit, and submit a merge request

(And, of course, you'll get maintainer access to Memoize.jl.)

Obviously, this is a little more work, but it should be copy and paste (I just ran those commands). Actually, given that I've already done it, I could just create the merge request now...

If this is okay with you, let me know (and I'll monitor Github messages a little more closely).

kmsquire commented 4 years ago

Okay, this isn't actually as clean as I had hoped--the histories are intertwined, which is a little confusing/annoying. (It's mostly recent cleanup commits, before I knew Memoization.jl existed.)

kmsquire commented 4 years ago

One (slightly dangerous) option: https://stackoverflow.com/questions/8461528/replace-github-repo-while-preserving-issues-wiki-etc

marius311 commented 4 years ago

Okay, this isn't actually as clean as I had hoped--the histories are intertwined

That was a good idea, too bad. Unless you find a simple solution (like maybe rewrite all the Memoization commit dates so they're after everything in Memoize?) then I'm fine if you just make a single commit that replaces Memoize with the code which is currently in Memoization, and I'll eventually archive this repo. Ultimately Memoize is probably the better name so that its the same name as the macro itself. I'll also need to add that one new feature Memoize now has that Memoizatio doesn't that you mentioned in your top post.

marius311 commented 4 years ago

then I'm fine if you just make a single commit that replaces Memoize with the code which is currently in Memoization

Let me know if that's what you decide, in fact in that case I can just make the PR, so that git blame will (more helpfully for future contributors) fall on me.

bjarthur commented 1 year ago

how about renaming Memoization to Memoize2 and transferring it into JuliaCollections? just like with JLD2, JSON3, etc...

i just spent 15 minutes trying to understand the difference between the two. and it seems as if the consensus is that Memoization is better. yet many don't seem to appreciate that judging by the github star history:

star-history-2023714

would be great if developers could just agree to go forward with one or the other, to save new users from having to spend the time trying to differentiate.