-
Notifications
You must be signed in to change notification settings - Fork 372
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
1.0 Feature Lock #2025
Comments
1.0
I think we need to lock down what we consider priority items to prevent feature creep and help us get 1.0
out the door sooner while we have some momentum. I've gone through the entire outstanding issue list and categorized what I think are necessary features/bugfixes as well some some things we might want to include in 1.0
but I want to get more discussion on. Feel free to dispute the categorizing of any of these issues. Some of them may also have been fixed, but just never got updated so if you see one of those you know is fixed let me know. A lot of these still need some discussion as to how we want to deal with them, but that discussion should take place in their respective issues. this is just to figure out what we want to focus on.
I'm not sure what the distinction is between this issue and https://github.com/hylang/hy/projects/1 . Oh well. Hy's support for Windows is going to be nominal until we have a maintainer who cares about Windows and we regularly run the test suite on Windows. I wouldn't hold up 1.0 waiting for that. #741 and #1693 would be nice to have, but I wouldn't postpone 1.0 for them, either, especially the former, which I imagine would be a lot of work and would then be buggy for a while. I'm still opposed to "fixing" #1324. #1541, #1823, and #1690 are too peripheral to Hy itself for me to think of them as 1.0 blockers. At least #1921 is about a built-in Python module. |
This is just the discussion as to what goes in to that project. I just put everything in for now and will remove what we decide we don't want here. Once we get through the remaining critical issues, I can start looking in to getting Hy running on Windows.
Probably a good idea, they don't involve breaking syntax changes and we can look into them for 1.1. I'll move them out
I believe i mistook this issue for the pycache issue that's popped up about intermittent test fails surrounding macros #1970 (comment) Which I think should definitely be fixed for 1.0. Is there an existing issue for that bug? In my mind for us to be able to call something "1.0" it should at least work on the major platforms python supports. I've already offered to pick up Windows support once we get through the major syntax changes and I have an old mac lying around to see if #1690 is reproducible. #1541 and #1823 should probably be in nice to have and not necessary though. I think we've decided against introducing namespaced symbols to Hy at this point. So that might also be something to drop from the maybe list |
I think bf6aa92 took care of that. If not, see if you can reproduce it and then open a new issue. If you want us to get serious about Windows support, I think we need some kind of automatic test-running for it, like AppVeyor. Either that or somebody has to manually check for Windows regressions periodically. |
Good point. I'll take a look after I finish the compiler cleanup |
It seems me that outside of fixing obvious bugs, the best thing to do for Hy is to create better tooling. Outside of hy-mode and jedhy there doesn't seem to be anything Hy specific that actually works, and those are also rough around the edges. This is a little orthogonal to the issue of language features, but it's also important in the grand scheme of things. |
Are there tests for this? |
This has been a big one on my list as well. Once 1.0 is out the door i was going to pivot to focusing on tooling almost exclusively. |
Update on the above: we test on Windows now (#2149). |
I've not catched up with your team's progress for a year. I'd been a casual Hylang adopter back then. Can't wait for the tooling to be improved so that I could be with Hylang for long. |
Out of curiosity, is the list here final for ver. 1.0, or does it need to be updated? One bug left... |
It's out of date. Let's just retire this issue. |
On the way to Hy
1.0
I think we need to lock down what we consider priority items to prevent feature creep and help us get1.0
out the door sooner while we have some momentum. I've gone through the entire outstanding issue list and categorized what I think are necessary features/bugfixes as well some some things we might want to include in1.0
but I want to get more discussion on. Feel free to dispute the categorizing of any of these issues. Some of them may also have been fixed, but just never got updated so if you see one of those you know is fixed let me know. A lot of these still need some discussion as to how we want to deal with them, but that discussion should take place in their respective issues. this is just to figure out what we want to focus on.Necessary Features
Necessary Bugfixes
NameError
forHyList
etc (stopgap fix in pr Implement Hy builtins as actual builtins #1979)(= 'hello "hello")
etcunquote-splice
interacts with HySymbol weirdly #1509unquote-splice
interacts with HySymbol WeirdlyPygments
Hy lexer needs improvements (not actionable until 1.0?)__init__
return suppression automagic (still an issue?)hy-repr
mishandles lexically illegal symbols and keywordsunpack-mapping
hy-repr
shouldn't use the registered function of a supertyperequire
with relative path crashes the compiler #1897require
with relative path crashes the compilerMaybe Features
importlib
frames from traceback #1693 remove internalimportlib
frames from tracebackfn
form with something like@[dec1 dec]
python -m package.module
with package/module.hy. #1018 make hy work withpython -m package.module
(is this possible?).
form to accept calls #1108 extend.
to accept callshy -i
should support the debugger#,
tuple tag macro-
should not get converted to underscores. #1635 mangle leading-
differently to prevent them from becoming module privaterequire
into a macro #1692 turnrequire
into a macroinspect
module compatible with Hy #1696 makeinspect
module compatible with Hysys.executable
confuses python librariesmultiprocessing.set-executable
at startup #1786 callmultiprocessing.set-executable
at startupOriginally posted by @allison-casey in #2008
(this is more of an issue than a discussion topic i just got excited about our new discussions board lol)
The text was updated successfully, but these errors were encountered: