Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider joining fast-pack org? #9

Open
nyurik opened this issue Dec 28, 2024 · 14 comments
Open

Consider joining fast-pack org? #9

nyurik opened this issue Dec 28, 2024 · 14 comments

Comments

@nyurik
Copy link
Collaborator

nyurik commented Dec 28, 2024

Recently @lemire, author of the core fastpfor algorithm, transferred all his code to the new github org fast-pack. Would it make sense to move this project to that org too, so that all implementations can be kept closer together and maintained by a community? Current project admins will continue being admins after the transfer, and we could automate publishing to the package registry. Thx!

@lemire
Copy link
Contributor

lemire commented Dec 31, 2024

I support this.

@zhenjl
Copy link
Collaborator

zhenjl commented Jan 13, 2025

hey folks, sincere apologies. I got this during vacation and forgot about it after. Yes I'd be happy to move it. Please tell me what needs to be done.

@nyurik
Copy link
Collaborator Author

nyurik commented Jan 13, 2025

I think the simplest way is to add me as an admin to your project, and I will move it, and give you access?

@zhenjl
Copy link
Collaborator

zhenjl commented Jan 13, 2025

Done

@nyurik
Copy link
Collaborator Author

nyurik commented Jan 14, 2025

Thx! One more thing before i move it - how should we call it (repo name)? @lemire you might have some thoughts on this... Some ideas:

  • GoFastPFOR (similar to JavaFastPFOR which is already there)
  • FastPFOR-Go
  • ...?

@lemire
Copy link
Contributor

lemire commented Jan 14, 2025

I recommend using the Go naming practices:

Keep package names short, preferably one word or a very short phrase.
Use lower case for package names (e.g., net/http, encoding/json).

@nyurik
Copy link
Collaborator Author

nyurik commented Jan 14, 2025

sure, but the github repo name should not confuse people either - i.e. someone looking through the list of repos shouldn't be confused about the content of the encoding repo, unless you want to move all languages into a single monorepo? (it would create issues with the releases)

@lemire
Copy link
Contributor

lemire commented Jan 14, 2025

@nyurik

sure, but the github repo name should not confuse people either

Right. But taking into account that the name will be prefixed by fast-pack.

I think that including 'go' or 'Go' in the name of a Go package goes against the Go naming practice.

Please see the following organization where one package is a Go package:

https://github.com/RoaringBitmap

:-)

@nyurik
Copy link
Collaborator Author

nyurik commented Jan 14, 2025

I must be getting confused already :) Is this a requirement for the git repo to have the same name as the go package?

@nyurik
Copy link
Collaborator Author

nyurik commented Jan 14, 2025

P.S. Note that in Rust, it is usually the same convention - the git repo may have an -rs suffix to indicate repo's content, but the rust crate name would not have it

@lemire
Copy link
Contributor

lemire commented Jan 14, 2025

@nyurik

I must be getting confused already :) Is this a requirement for the git repo to have the same name as the go package?

The typical usage is like so...

import "github.com/fast-pack/nameofrepo"

...

nameofrepo.FunctionFromRepo

You do not include the word 'go' in the repo (usually).

@lemire
Copy link
Contributor

lemire commented Jan 14, 2025

(Note that I am not telling anyone how to name it, I am just stating what the usage is.)

@nyurik
Copy link
Collaborator Author

nyurik commented Jan 14, 2025

@lemire thx for the explanation, makes sense. Are you ok to preserve the name as encoding in the new org, or should it be called fastpfor or something similar?

@lemire
Copy link
Contributor

lemire commented Jan 15, 2025

Are you ok to preserve the name as encoding in the new org, or should it be called fastpfor or something similar?

I am neutral but fastpfor won't work because there is FastPFor and I do not think GitHub will allow it.

Grok suggests the following names:

  • intpack
  • bitpack
  • intcomp
  • numcrunch
  • bitcrunch
  • intencode
  • numshrink
  • effint
  • numpack
  • compactint

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants