ayojs / ayo Goto Github PK
View Code? Open in Web Editor NEWA fork of Node.js. Humans before technology.
License: Other
A fork of Node.js. Humans before technology.
License: Other
It would be good to get some windows builds running alongside the travis ones. I'm not sure what the best way to do this is, but at a guess it would be appveyor? (very open to other suggestions though)
As they discussed in nodejs/TSC#174 the Joyent copyright attribution should never have been removed from the source files and they restored it in nodejs/node#10155.
21:00 (9:00pm) UTC, Friday the 13th October 2017. Convert to your local time here!
Additionally, any member of the Ayo.js moderation team is welcome to participate.
If you have points or issues you want to see discussed in this meeting, please comment down below!
Issues labelled with the core_meeting_agenda
label will be added to the agenda.
For the invited, a private link to join the meeting as a participant will be provided. TODO: how to view the meeting as a non-participant?
I accidentally committed to master and we should be saved from ourselves by protecting the master branch. Thoughts?
Edit: Friday 25th August, 2017. 11:10am (GMT + 1)
This comment was removed due to its inflammatory content.
-- @varjmes
Hello. Just to make it clear what is the purpose of this repo?
The tech feature in my meaning is something like rewriting http module to make it better, or just like adding http2, or module to support some protocol out-of-the-box like webrtc and so on,
As far as I can see so far the most contributions are some sort of:
So in order to make it clear and simplier to understand I'll divide the main question into a few:
Any ideas on the logo?
I think people want this
I'm interested in opening up a discussion of Ayo's plans for continuous integration and other testing, especially as it affects non-Intel target systems (Raspberry Pi, arm64, and others).
One of the things that's attractive about the Node.JS ecosystem is extensive testing on ARM platforms, and first-class support. This doesn't yet look like it's attainable with Ayo's current Travis-CI only testing. The only comment I saw was to the effect that Raspberry Pi builds were really slow, which got in the way of a fast CI loop.
I know it's early days but I'd like to see some guidance and/or a request for community resources.
Hello,
I'm trying to create a homebrew
script to install ayo. In order to do that, I need a tar.gz to be published with a release.
Can you tag a v0.0.1 (or whatever) version so I can start the process?
Thanks,
Just a note: I've been banned from Ayo.js for no reason specified other than my comments (but this was not even directly said to me) and find this entire situation extremely ironic considering the entire purpose of this Ayo.js fork to begin with was from bureaucracy in the Node.js community. The point of my proposal was because you intended on doing a fork and seemed like a good opportunity to ask for some MUCH needed design changes at the compiler level. Instead you ask me to "pick another language" when Javascript is literally embedded in our browsers... That kind of thinking is absurd. I wish I could boycott this especially given how community members act... But look at me now I'm on a browser...
I'm sure many of us use Node.js day to day due to obligations work related.
But let's actually solve problems with the core language design itself and not build off of the mediocre at best cost abstractions Javascript originated from.
Dynamic Type Inference
It's no surprise that types are god awful in Node.js. Whether you are casting from String to Integer and so forth. We don't even have the option between integers or unsigned integers. I think a simple pragmatic solution is to adopt a model similar to Golang where the compiler computes the type intelligently and we can also verbosely define types. Typescript kind of amplifies the problem with types by explicitly defining things as number
or string
as opposed to more granular types that are given in other languages.
Threading... beyond barely usable mutex like functionality.
I don't even think it's possible to utilize semaphore like primitives in Node.js. I believe there are some GYP implementations in the NPM ecosystem... However, proper threading management is pretty damn important. Especially if we want to build robust frameworks. Perhaps we can even adopt compiler logic like Erlang's or Rust's where we automatically utilize all threads for any computation.
Atomic Operations
Another huge problem with Node.js is the inability to utilize Atomic Operations. These are pretty important for critical computations. And Node.js kind of throws the entire idea of atomic computations out the window. This is a big reason why a viable database can't be built in Node.js due to lack of atomicity and inability to adhere to ACID compliance.
Improving bad cost abstractions
This goes beyond the async model in general... But rather... A lot of the core design of Javascript itself. For example we can't even utilize stacks or heaps in the native standard library. I could go on. But this can be improved by orders of magnitude to where it is now. Would be interesting to adopt data structures like Ring Buffers, Linked Lists and Double Ended Queues in the native library. Especially if we optimized abstractions in the assembly logic. I would be especially happy if we can utilize a lot of different graph techniques in the standard library... But that may be veering off more into a MATLAB approach to language design, but worth discussing anyway.
When are all the URMs going to come out of the woodwork and make this project great again? It's been 2 months and I thought that was the entire premise of the fork?
#36 touched on this briefly – there doesn't seem to be any disagreement between @bmeck in #36 (comment) and @zkat in #36 (comment).
Building on this cross-project alignment, thanks to the fine work by @bmeck 🥇 (and a whole bunch of other folks on the ES spec, .mjs
mimetypes, etc. etc. ... all work that is 💯 by me) the first ESM PR (see: nodejs/node #14369
) landed in nodejs/node#master
about a week ago.
The purpose of opening this issue is to request an ETA on when latest (or perhaps just nodejs/node#c8a389e
) will be pulled from upstream. Further, to foster and/or seek out any discussions around if there are currently plans on the ayojs/ayo
side to make any changes to the work when or after it is merged.
Like fibjs did?
discussion about a potential governance model i suppose? should we keep the ctc structure? what kind of working groups should we establish? (should we establish any at all?)
Hey everyone!
As per issue #57 Can an administrator please edit issues to update references to the old default branch to say latest
instead?
I don't feel we're promoting a safe space with references to such an offensive word in our in history (such as issues #44, #16, etc)
[Edited by @zkat: removed references to word on OP's request]
I suggested this in node.js, but the response was that it's not going in because it's a convenience function, and platforms lack the API to do this in one go. Does ayo.js value convenience here?
I also recommend an alias of copyFolder
.
The open-ness to re-merge with the Node project was a fundamental force holding io.js together for the very beginning. Does Ayo aim to do the same?
IMO, it would be an ideal goal to have.
[Edit by @zkat: Bye 👋 ]
nodejs/node@5be4dfaa13b0 & nodejs/node@3f1cca481765 changed text in the CONTRIBUTING.md
file, which might be worth including in our own files but which didn’t apply cleanly.
@srilq Do you want to take a look at this?
"IO" can be pronounced several different ways. consider replacing with "eye oh" or similar?
The governance doc says the following about sub-teams: [source]
Other teams focus on one particular area of the project. They have full autonomy over said area, their decisions do not need to be approved by any core team member. Every sub-team needs to have one member that is also a member of the core team, in order to notice and manage cross-cutting concerns.
Each team decides who gets permissions for their respective repository/repositories.
But... there are a lot of folks like myself around Node/Ayo that don't work in specific confined areas but also do not specifically need to be in a leadership position for their work.
For example - it would probably be useful for myself to be able to help with PRs and issues here - including approving PRs (for areas I am comfortable with), labeling issues / PRs, and closing / reopening PRs / issues when necessary.
Node.js solves this through a "Collaborators" group, as documented in its GOVERNANCE.md.
I feel that Ayo would also benefit for a more general group on "core" without the said group being a "core leadership" team.
Otherwise, it sounds like I'd (the governance doc does not say who can make a team?) have to form teams around the subsystems I am interested in, which are many and I highly doubt it would be easy to fill groups for those as separate entities, certainly at this point in time.
Raw & unmodified .github/ISSUE_TEMPLATE.md
follows to illustrate the issue.
<!--
Thank you for reporting an issue.
This issue tracker is for bugs and issues found within Node.js core.
If you require more general support please file an issue on our help
repo. https://github.com/nodejs/help
Please fill in as much of the template below as you're able.
Version: output of `node -v`
Platform: output of `uname -a` (UNIX), or version and 32 or 64-bit (Windows)
Subsystem: if known, please specify affected core module name
If possible, please provide code that demonstrates the problem, keeping it as
simple and free of external dependencies as you are able.
-->
* **Version**:
* **Platform**:
* **Subsystem**:
<!-- Enter your issue details below this comment. -->
This is something that will be a whole lot more prevalent with a modern fork, there is still going to be a large amount of ongoing work into nodejs/node that would be very useful to keep in sync with.
This wasn't really a problem at the time of io.js, so I'm not sure there is much to learn from there.
However, I think we may be able to make do by keeping a branch in sync with nodejs/node master, and a staging branch for our own commits - very similar to how node does its releases - and then cut releases by rebasing the two into a release branch.
Not the most pleasant perhaps, but It should be workable, I think.
Currently, there are ~100 semver-major changes pending for Node 9.0.0, see https://gist.github.com/addaleax/4528d8f16838db5aaf5d2ed879eb9475 for a full list.
I’d like to consider reverting 2 of them, because I think they wouldn’t serve Ayo.js users any good and instead are just changes for the sake of change:
468110b327
] - (SEMVER-MAJOR) tls: deprecate parseCertString & move to internalf6caeb9526
] - (SEMVER-MAJOR) os: make EOL configurable and read onlyDo you think this is reasonable? Are there other changes from the list that stick out as something we might want to revisit?
Do we want to copy across all/some/none the issue/PR labels that exist on upstream for use here?
More than happy to volunteer for the task.
Now that we have our governance model it is time to put together our core Ayo.js team.
As per our governance document:
The core team is a team with the purpose of deciding the general direction of the project and managing cross-cutting concerns. They only decide over the most high-level aspects, all other matters should be delegated to another, more specific team.
Every member of the core team is also an Owner of the ayojs GitHub organization.
The core team serves the interests of the Ayo.js project, suggesting ways in which to progress the project and overseeing things at a high level. Their job is not to have their hands in everything that happens within the project, but merely be aware and make sure we're achieving the general goal of Ayo. Each current and future working group (i.e not core) will be responsible for their own parts of Ayo. Core is a group to lean on when you're wondering "what next?" or "how can we achieve this?".
Express your wish to be part of this team by commenting on this issue, saying as much. Please bare in mind that due to the small size of the project, we'll be asking a maximum of ~five people to come on board.
To get the quickest response, please chat in our Discord: https://discord.gg/hCgptwH
[EN]
Good morning. Description the project involves the knowledge of English pronunciation, which exclude no English speakers. Please change it to more inclusions. Thank you.
[UA]
Доброго ранку. Опис проект передбачає знання англійської вимови, які виключають ні англійської мови. Будь ласка, змініть його на більш включень. Спасибі.
Edit: forget my naive languge
Hello,
It would be nice to have a list of technical projects for Ayo.
Some people may want to contribute, but without goals, priorities and aimed features, it's hard to jump in the bandwagon.
From what I read on other issues, there is at least:
I may suggest two new things:
I think the core value of Node/Ayo is the web, and IMHO it should come battery-included with all basic web stuff. The existing ws module has many years of maturity, I think it would be nice if it find its way to the core.
Anyway, having the technical todo list could help undecided people to make the move and pick one item.
I understand that your decision to fork node was caused by claim of numerous violations of Code of Conduct of node.js by @rvagg, and TSC's vote on the issue - this is public knowledge at this point.
While breach of CoC is a legitimate concern, there seems to be no details available to the public about exact nature of these violations. Secrecy of this process makes it impossible for me, and probably many other contributors and users of node.js, to judge decision about validity of your action, and therefore making informed choice of supporting either ayo.js, node.js or both.
In spirit of maintaining transparency of this issue I would like to request, assuming that Rod, as immediately interested party will grant permission to do so, disclosure exact nature of claims of violations of CoC, which led to this crisis.
Please do it!
Because everyone else thinks it is; but nobody finds it very funny.
Hi, thanks for inviting me into the repository to raise concerns I have.
Now that we have our governance model it is time to put together our most important group; the moderation team.
As per our governance document:
The moderation team serves to enforce the project's Code of Conduct and manage situations of conflict. There are no core team members on the moderation team, in order to not pick sides.
Every member of the moderation team is also an Owner of the ayojs GitHub organization.
Our moderation team must live by and enforce the Code of Conduct in all official Ayo channels. Right now this is our GitHub and Discord channels.
Express your wish to be part of this team by commenting on this issue, saying as much. Please bare in mind that due to the small size of the project, we'll be asking a maximum of five people to come on board.
To get the quickest response, please chat in our Discord: https://discord.gg/hCgptwH
Trying to npm i nodegit
with my build
Error: 404 response downloading https://unrelentingbuildbot.s3.dualstack.eu-west-1.amazonaws.com/ayo/v9.0.0-nightly201708257a10dc574
bbbeb6dc45c69f115967f2b17fc90c9/node-v9.0.0-nightly201708257a10dc574bbbeb6dc45c69f115967f2b17fc90c9-headers.tar.gz
I have renamed it in my bucket, but this is going to be an issue for everyone potentially.
Should the build process actually produce ayo-…
tarballs or node-…
? The latter might be potentially confusing, but should all the existing tooling adapt to the existence of ayo
? (I guess there might be a lot of tooling and not all of it might be maintained?) How was this handled in io.js
?
In #56, @jmeas suggests opening the module loading discussion & @jkrems points out that the discussion already has a long history in Node.js and has been a source of much frustration and little progress. @jmeas follows up that it seems like a fork is a good place to discuss such things and continues:
I don't know all of the goals of Ayo...
- @jmeas
It occurred to me that I don't really know the goals of this project either, and it seems it would be a fundamental question when considering changes that would potentially break compatibility with Node.js
I've read compelling explanations from @zkat about corporate domination of governance and organizational ossification that made a fork necessary, so "make bold design changes that benefit users/contributors" seems like a possible Ayo goal. There's also the political motivations for a fork which I won't go into here, but "run a node-like project that prioritizes inclusivity/diversity while maintaining interoperability with Node.js" seems like another possible goal.
To enumerate the major branches as I see them here (please correct me):
Put differently:
☭ | ⎇ | |
---|---|---|
Node.js | * | ❌ |
Ayo A | ❌ | ✅ |
Ayo B | ✅ | ❌ |
Ayo C | ✅ | ✅ |
* depends whom you ask-- not important for this discussion
It will be easier to approach and settle questions like #56 if it's clearly stated, in particular, whether Ayo is OK with breaking changes & whether the goal of Ayo is to address long-simmering challenges like this (I hope it is!).
There is demand for such changes [insert a bunch more complaints about promises here]. In this respect, explicitly defining "address long-running technical complaints with Node and break BC where necessary" as a goal of Ayo could provide users a really compelling reason to check out/use/get involved with the Ayo.js project, i.e. it could get the project off the ground and create momentum. Currently, it's not clear precisely what the project's goals are, and as long as that's the case, it seems unlikely to gain adequate popularity to sustain a project of this size/ambition.
ABI stable ayo based on https://github.com/nodejs/abi-stable-node. Existing Node 8 API described at https://nodejs.org/api/n-api.html.
This plus #50 (move non-essential C++ modules into addons) should enable this project to support iOS.
This + #50 + #40 (worker implementation) could be good enough to supersede the functionality offered by JXCore (https://github.com/jxcore/jxcore).
If you want to grow this new community over the long term, the project needs a trademark policy for ayo.js and whatever logos you come up with. Having a policy doesn't prevent all abuse of your project brand, but it helps reduce it and gives you the start of some tools to protect the name in the future.
Useful background on FOSS trademarks:
I'm happy to provide advice to the core team/committee/board here or elsewhere, if you can explain the long-term goals of how you're planning to run the project. You need to match a trademark policy with how you want the community and corporations to use your brand.
Dependency: #2
Currently, when using asynchronous functions without callbacks the system gives a deprecation warning. Can it return a promise instead? That way it can be used in an async/await style.
Based on what I know this couldn't be done in Node because of all user's legacy codes.
Reading #56, it became clear that the answer to "how should Ayo handle es6 modules" depends heavily on the answer to the question "Is it a goal/requirement of Ayo.js to maintain full operability with Node.js, without a compatibility layer, converter, preloader, etc.?"
mjs
question can only be answered with "depends on what Node.js does." (Any "extra" Ayo features effectively break interop if they prevent someone from moving their code back to Node, which means Ayo can neither add nor subtract from the node.js feature set.)There are people with solutions to long-running node issues ready-to-go (or at least ready-to-try), held back only by BC concerns. Allowing BC & interop break would open the flood gates for novel/exciting changes that could free up the governance log-jam, get the "innovation" flowing again, and demonstrate the value of the governance model Ayo is built upon-- a win-win that benefits Ayo's core goal of "creating a new foundation of project governance and management."
My hope is that Ayo chooses to address the long-running node.js issues head on and we'll see a big jump forward in the advancement of the JS-on-the-server project. 👍
Hi! I’d like to suggest that the @ayojs/core team holds a meeting in the near future. For at least me, @Qard, @TimothyGu and @Fishrock123, I assume that would be best in the week of Oct 9 – 14 (since in the upcoming week Node Interactive takes place).
Question: Does anybody want to take the lead on this, organizing-wise? I guess right now that wouldn’t entail more than making a doodle + curating a list of agenda items. (I can act as a fallback but I think it would be nice to have somebody else on this – esp somebody who is not busy this week :))
If we want to follow Node’s example here, this would basically be a Hangout session + live streaming to Youtube (I think I got it figured out how to do that) + the possibility of interaction through the Discord and the Youtube chat. We don’t have to follow this, I am obviously pretty biased!
Sound ok? :)
Is there a document or an authoritative post that outlines the reasons behind Ayo existing and lists the goals of this project?
Edit: I'm editing this post because I can't add a new one below (or on any other issue)
Take a look at the other (currently 2) issues in the repository, we'd love input!
I've gone through those issues but couldn't get a clear picture. It would be hard to provide any meaningful input without knowing the technical goals of the project.
Here's a couple things off the top of my head. I'm certainly willing to help do some guidance on any but I have limited experience in some of these areas. Digging though the commits back to January 2015 in the related files folders will surly turn up related reference-able commits for the io.js days.
Vcbuild.bat
build /ayo.exe
.
ayo
and a node
symlink.
ayo
(and possibly a node
symlink.)
... more to be added
It'd probably be useful to have an irc / slack channel (or anything else less asynchronous than github) for coordination.
At the very least, it would seem useful to me, as it was useful to io.js.
Sorry for not following the issue template, just wanted to inform you that the discord invite link doesn't seem to be working (it says it's expired).
Thanks!
E
Hey y'all.
You may have noticed that we've had some amount of really disruptive and unconstructive attention, largely from folks who aren't involved with either Ayo.js or Node.js.
Until this recent tide of attention dies down, I've set this repository to be collaborator-only as well as blocked any users with brand new accounts, since several people have made throwaways.
If you would like to collaborate on this project, please join the Discord channel and ask for access, we'll gladly hand it out! And, if you happen to try and abuse this process as well, be warned that you'll get the banhammer pretty quick. It is my hope that those who collaborate in this space do so in good faith: if you have issues that prevent you from doing that, I suggest you take your commentary to a different community.
Are there any plans to expand our CoC beyond the limiting bounds of the one currently linked to in Node.js? I would love to see some more hard work on our CoC, in order to make it larger and more specific to our needs as a new project with the community in mind.
This would keep the core leaner and safer, though with the risk of increased divergence from "upstream" Node.js (especially with the modules moved out).
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.