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

ran generate_sprites.php

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

This has been tested in wmf production and the fix is working.

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.

Thanks!

@epriestley: Try removing a comment, it throws an exception

Apparently commits don't support CAN_INTERACT capability?

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've been wishing for this literally forever. If I could award more mountains of wealth tokens, I most certainly would!

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)

roughly similar: D20161: Add basic, rough support for changing field behavior based on object subtype

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 D17593#243874, @epriestley wrote:

In theory, probably. In practice, anything not coming through a support pact is probably going to sit in queue for an eternity nowadays.

@epriestley: I'm thinking about changing this to make it look more like your example (quoted below) as I think that would make custom fields and subtypes quite a lot more useful. Is this something that you would consider merging in the upstream?

In T13062#235217, @epriestley wrote:

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

@epriestley: Thanks! Hope you're having a great holiday weekend :)

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.

@epriestley: Sweet, thanks! landing...

@epriestley I have no problem patching it locally (already have) it just seemed like an obvious thing to show on the differential screen. If it's not wanted upstream then it's no sweat off my back :)