FWIW I've found by far the easiest way to work with microcontrollers is using micropython / circuitpython on any of these chips: ESP32, ATSAMD21/ATSAMD51 and RP2040. The esp32 is in many ways the easiest and most practical because it's extremely cheap and includes a wifi radio.

@avivey: a few folks have started discussing collaboration in the #phabricator channel on libera.chat irc network.

I'd be interested in collaborating with anyone who is interested in continuing community-supported maintenance of Phabricator.

In T13652#255834, @epriestley wrote:

I'm starting with an absolute bottom-of-the-line 3018, I've "upgraded" it with a plotter collet I made out of a pool noodle and a piece of cable gland so I'm less likely to hurt myself for now:

So far, I've mostly been implementing controller software, following heavily in the footsteps of GRBL. I think I'm maybe ~25% of the way toward having a similar-ish capability set? But I don't really know what I'm doing, I am doing a few things a bit differently, and haven't written any meaningful amount of C in many years, and suspect I may run into a wall with the CPU.

One thing I've changed is that the computer tells the board what hardware it is connected to at startup, e.g. "Linear Stepper Axis 1 is enabled by pin 8, driven by pin 2, and direction is controlled by pin 5", since I'd like to be able to rewire the board without updating the software, and generally have more control over the hardware configuration, and have an arbitrarily large number of axes and actuators and blinking lights and whatnot. My motion commands then reference axis IDs ("2D linear motion on axis 0 and axis 1 to relative position 15, 35") instead of spatial axes like "X" and "Y" directly.

Now that I realized this isn't an April fools joke (or if it is, it's kinda late...) anyway I have a whole lot of experience in this department, having built several cnc controllers. My latest one is using a beaglebone black but I also experimented quite a lot with an arduino running grbl and another one running on a $30 esp32 board. If you have any unanswered questions I'd be happy to comment. I should have slightly better than ignorant responses.

lol

Off the wall suggestion: how about a trigger that sets the subtype:

Probably related: According to https://phabricator.wikimedia.org/T261642, it seems that when leaving a project, phabricator leaves behind some cruft in the form of materialized memberships for milestones of that project.

I think that this is something we(Wikimedia) can patch downstream in our fork, I don't think there is anything further to add to this upstream discussion.

Thanks for the quick-look posts, these are nice.

Could this be related to the custom footer markup? The code in question hasn't changed in a long time but I suspect maybe it's related to changes in the remarkup rendering code that's adding metadata where it didn't previously?

I toggled developer mode on for a moment and managed to get a stack trace:

I wholeheartedly agree that all that proxy field mess needs to go away. With that gone the only moderately confusing part remaining would be the way in which custom fields interact with herald, email and notifications.

Making a way to set fields to default: disabled would make this feature even better ;)

quack

FWIW I appreciate and use the mute feature (though only occasionally)

This change broke the search dialog on tags typeaheads...

This would be incredibly useful for the things we are trying to do at WMF. I've gone so far as to duplicate lots of forms for each subtype and remove fields as needed. This results in N * N forms and it's not at all manageable beyond a very small number of sub-types.

In T12588#242719, @epriestley wrote:

If any of these lists only have one form (or the user can only see one form), we'll take the user directly to the specified form.

Awesome, thanks @epriestley!

I just tested and indeed @joshuaspence's steps are reproducible on https://phabricator.wikimedia.org

@dlgiang: if you go to maniphest and choose any of the existing saved queries, you will find the ID in the resulting url.

It seems to be a fairly recent problem so there must be some code change that started triggering it. The worst part, IMO, is that the workboard breaks in a not-entirely-obvious way instead of falling back to a default query. It took me a while to debug the issue the first time it occurred.

Could it be that a user assigns it to one of their "personal" custom queries and then later they delete that query by way of the maniphest saved query ui?

I'm not sure what's caused this either but I've seen it twice on wikimedia's production install.

@epriestley: I can help with testing and validating on elasticsearch, if that helps at all.

In T13062#235217, @epriestley wrote:

Can't wait for "connect 2" to come out on playstation six.

D18836 probably isn't the right solution, however, it's the only straightforward fix I could come up with. I didn't dig into the details of why it 404s when I fix the code in PhabricatorProjectViewController to avoid the fatal. The patch is probably good enough for Wikimedia, however, I'm not sure if it's good enough for upstream.

Another approach that might make sense would be to highlight the hash and then show a hovercard which lists the commits with that hash. Of course this wouldn't scale too far but it should handle the case where 2 or 3 commits have the same hash.

I tried to work around the immediate fatal by checking the return value of $engine->getDefaultItem() in PhabricatorProjectViewController, however, that resulted in hitting a 404 so it's a bit deeper of an issue. Perhaps the right solution is to prevent users from disabling both of the default items in the project "manage menu" UI?

In T4369#232848, @epriestley wrote:

I don't see any easy way to cheat through $_FILES, though. We could remove it, but we have a nonzero number of users who compile their own copy of Linux and use a window manager that doesn't support drag and drop and disable Javascript and don't believe a monitor should ever have more than 256 colors, so that would leave them out to dry. The conversion also isn't trivial, so even if we want to move in this direction eventually I think it's a significant scope expansion over just building a synthetic $_FILES.

Whoops this is probably my bad :-/

For phabricator.wikimedia.org, we decided to go with elasticsearch, partially because we already have a massive elasticsearch cluster and a lot of institutional elasticsearch knowledge / experience. My opinion is that we made the right choice. I believe this opinion is shared by most of the folks who use our phabricator on a daily basis. I've seen zero complaints about search since we made the switch, which is a huge improvement from what I saw with mysql FTS. Conclusion: Elasticsearch seems to perform well and the results are generally better (obviously this is subjective, but like I said, no complaints from users)

In T12896#228825, @jmeador wrote:

We"solved" the problem with a small python daemon that pings repository_statusmessage.epoch every minute and calculates the delta. When these deltas surpass Phabricator's max delta (21,600 sec) we page the oncall. For repositories that are mission critical, we use a smaller value. It obviously isn't a perfect solution, but it gets the job done and it's been extremely stable.

I've seen complaints about this on phabricator.wikimedia.org as well, so I can confirm that this is an issue.

doh! nice. I obviously need more coffee.

I know just maintaining the hooks is more work but certainly less than what's involved in maintaining the graph code.

Maybe provide some extension hook-points in diffusion so that the community can maintain the commit graph visualization as an extension?

https://www.wired.com/2016/06/hey-stop-using-texts-two-factor-authentication/

That does sound powerful. +1

I have spent a little time poking at code, trying to figure out how to build a simple template engine into the description field, so that you can reference hidden custom fields by {field-identifier} or similar from within the remarkup. I resigned myself to building something just like publish.php, where the descriptions are maintained via conduit, however, I still long for it to be built in.

It would be really nice to default newly added fields to hidden. Going through 20+ forms to hide the fields is tedious.

FWIW we have seen several users attempting to distribute l33t w4r3z via Wikimedia's instance of Phabricator. I had to set file upload limits to < 8MB in order to prevent chunked file storage.

This sounds REALLY useful. Relatedly, it would be useful if I could auto-generate a task for each recurrence of an event.

:(

In T12804#226348, @epriestley wrote:

You can use, for example, -C3 with git grep to show 3 lines of Context around each match.

About 95% of the time when I'm searching for content it's because I want to edit a subset of the callsites. I do this with git grep some_function | maybe_more_grep | give, which opens all matches in my editor. This would take me about 100 years from the web UI for a nontrivial number of results. Do you have some other use case for searching for content?

In T12804#226366, @epriestley wrote:

When I view a repository, it would be incredibly helpful if the files I most recently touched were at the top of the UI.

What I would really love to see is global filename search. Currently you can search for a filename within one repository but you have to know which repo to look in first.

We have thousands of repositories and it's hard to differentiate in a list which repository I need.

FWIW I partially implemented this in Wikimedia's fork, and I did so in a reusable way. I'd like to eventually upstream it but I'm not sure that my approach is desired upstream. I'll give it another shot though.

not upstream-able.

phabricator trading cards ftw.

I think that @epriestley just made capitalism and socialism obsolete by re-imagining everything in terms of Mana points. You sir, have won the internet.

This should clearly be priority: Unbreak now!