Don't rerun pageant if there are no keys to add

Currently, if there is no key file, posh-git's Start-SshAgent runs pageant twice which causes pageant to show an error dialog about already running. This simple change stops that happening.

Thanks!


Fix for deprovisioning workflow

Description
Changes proposed in this pull request:

Fix for deprovisioning workflow
Add/Fix metrics tests

/test all

/test all

/test all


Build error

I'm getting this build error when I run npm install in the static directory:
gyp ERR! build error
gyp ERR! stack Error: `make` failed with exit code: 2
gyp ERR! stack     at ChildProcess.onExit (/home/user/Documents/workspace/github/React-Redux-Flask/static/node_modules/node-gyp/lib/build.js:262:23)
gyp ERR! stack     at ChildProcess.emit (events.js:223:5)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:272:12)
gyp ERR! System Linux 5.4.14-1-default
gyp ERR! command "/usr/bin/node12" "/home/user/Documents/workspace/github/React-Redux-Flask/static/node_modules/node-gyp/bin/node-gyp.js" "rebuild" "--verbose" "--libsass_ext=" "--libsass_cflags=" "--libsass_ldflags=" "--libsass_library="
gyp ERR! cwd /home/user/Documents/workspace/github/React-Redux-Flask/static/node_modules/node-sass
gyp ERR! node -v v12.14.1
gyp ERR! node-gyp -v v3.8.0
gyp ERR! not ok
Build failed with error code: 1
npm WARN notsup Unsupported engine for<EMAIL_ADDRESS>wanted: {"node":"0.10 || 0.12 || 4 || 5 || 6 || 7 || 8"} (current: {"node":"12.14.1","npm":"6.13.4"})
npm WARN notsup Not compatible with your version of node/npm<EMAIL_ADDRESS>npm WARN<EMAIL_ADDRESS>requires a peer of<EMAIL_ADDRESS>but none is installed. You must install peer dependencies yourself.
npm WARN<EMAIL_ADDRESS>requires a peer of<EMAIL_ADDRESS>|| ^3.0.0 || ^4.0.0 but none is installed. You must install peer dependencies yourself.
npm WARN<EMAIL_ADDRESS>requires a peer of<EMAIL_ADDRESS>but none is installed. You must install peer dependencies yourself.
npm WARN<EMAIL_ADDRESS>requires a peer of<EMAIL_ADDRESS>but none is installed. You must install peer dependencies yourself.
npm WARN<EMAIL_ADDRESS>No description
npm WARN optional SKIPPING OPTIONAL DEPENDENCY<EMAIL_ADDRESS>(node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for<EMAIL_ADDRESS>wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})

npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR<EMAIL_ADDRESS>postinstall: `node scripts/build.js`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>postinstall script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR!  I'm new so it will probably take me a very long time to unwind this. It seems like there's some version mismatch and missing packages; does it need node version 12.0 exactly or version 8 exactly? Why is 12.14.1 not good enough? Thanks,

Install the node-sass module as mentioned below. And then run nom install, npm start.
 npm install node-sass@latest   npm install   npm start

Thanks! @samrudh


Update top level readme on Font Validator

I think we can agree that nothing is happening upstream. As of 2.1.1, you don't need mono on your system either, with mac os x and linux.

thanks. I'll review that.

done.

Vanilla freetype is not sufficient for the rest. It depends. See the "ComputeMetrics patch" reference which was integrated into FreeType 2.6.1.

It is good enough for our purposes right now. Feel free to open a new issue pinpointing a specific test that the current approaches does not support and which are the benefits of it. Based on that we can decide on how to prioritize work on this.


Add support for cfs file

Please see this @ghedwards - I did not test it as I'm not sure how to

@isapir thanks for your help, I've updated the plugin to include coloring / various basic editor features for cfs files, hope you like it

Thanks @ghedwards !  This is awesome :)
The last thing I need to do is set the icon of CFML for .cfs files but that's a whole different extension I think.


Transformer Inference is very slow

Inference is very slow ...my max seqlen is 400 and it takes around 500ms to 800ms Is there a way to improve the the inference time?

This should be a standard implementation of transformer inference decoding. I'm not sure about further speedup
You may use multiple GPUs to do inference on a batch in parallel.

can you guide me how to inference on multiple gpus..?
can we do it on multiple cores on cpu as well..?

Just noticed that horovod (the library used in Texar for distributed training) does not directly support distributed inference at deployment time.
The simplest way then is to launch the program on different GPUs (or CPUs) separately, using different data shads.

Same question, thank you.


Global FTM view

As i18n takes off, it will be inspiring if we can pull the geocodes off the federation and plot 'em.  No need for clustering.
It may drive traffic, inspire others to build on FTM, etc.

I think this is the same as Ewa's request to show all points on the map (with clustering) on page load for all countries. Helps with the bootstrapping/credibility problems in new regions.

Do we still think we need this?

Dunno -- it looks cool :).
On Tue, Apr 14, 2020 at 10:54 PM Saikat Bhadra<EMAIL_ADDRESS>wrote:

Do we still think we need this?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/findthemasks/findthemasks/issues/330#issuecomment-613832102,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AA6L2GB7AUOPCOQIGNUSPIDRMVDZBANCNFSM4LVYHDRQ
.


fix: Fullstory Custom Events

We were mistakenly sending custom or track events as page events. This update fixes them to the correct event types.
Note: I’ve created a dummy session with App Version 5.9.5 that you can use for verification.

Igor and Kirill don't have the necessary permissions on Fullstory to test these out, so I'm merging this PR based on Farhan's review.


PowerToys Context Menu missing

Microsoft PowerToys version
0.78
Installation method
GitHub
Running as admin
Yes
Area(s) with issue?
File Locksmith, Image Resizer, PowerRename
Steps to reproduce
After install of a new Windows profile, and using PowerToys, I noticed that right click context menu options for File LockSmith and Power Rename were missing. I thought uninstall and reinstall would fix this issue.
Using Revo Uninstaller, I performed a deep uninstall and removed 1 registry addition, and then restarted the PC. Then, the system-wide install file through GitHub was used for re-install, the modules that were enabled with the old install still persisted (not sure why). In addition, right click context menu was not populated with File Locksmith and Power Rename options (they were enabled in the software). This did not change after a restart.

My user profile is the one that doesn't show the right click context menu on the PC; they are present on other Windows profiles on the PC. But, the registry shows the same entries present on the profile with issues and profile where the right click context menu is active for Powertoys. An example for File Locksmith is shared:

Bug report:
PowerToysReport_2024-02-06-15-11-47.zip
✔ Expected Behavior
See the context menu for right click on Windows Explorer to show File LockSmith and Power Rename
❌ Actual Behavior
Powertoys options in right click context menu not visible.
Other Software
No response

me too

Registry edits didn't work. Since, I didn't see any other recommendations in this thread, nuking the PC and putting on a fresh Windows install resolved the issue.

Still an issue. No Context menu items.

Has anybody found a solution or a workaround for this issue ? I have the same problem

Same issue here

Just reinstall Power Toys
I do it and it help me with this Issue

Same here. I just tried to reinstall PowerToys but the options on extended menu are still missing. I don't know what to do. I won't reinstall Windows but if it has to be need, I will...


Question: how to identify the app bots in Azure

Deployment Guide documentation at Step1.6 states "An AAD custom app, Bot are programmatically created in your tenant to power the Poll message extension app in Teams."
After successfully deploying app in the tenant and using it in Teams unable to locate corresponding bot in Azure.
Could you please provide documentation on identifying Bot and related resources created in Azure by npm run deploy command?

Bot is stored in the M365 subscription. So User does not have access to it.


Core UI overhaul

When I was toying around with a new Control (ProgressBar) in #34, I wanted to replace both the Turns completed and the material usage per turn in FactoryProduction into a layout structure that had text labels on the left, and progress bars to the right, spread over four lines.
So in essence, a table of four rows and two columns.
So I'd like to have a go at working out whether or not creating a HTML like Table Control makes sense and whether it is possible.
If older issues or discussions make clear if this is not possible due to certain design decisions or layouting conventions, let me know. I couldn't find any :)
I'm starting by checking what is already there and what still needs to be done, and whether there are big obstacles to be considered.
The idea is mainly to be able to display a set of controls in an orderly fashion, with a relation between child Controls defined by rows and columns.
StringsTable allows for such layout, but is limited to textual data. The Table Control would allow for the same sort of layouting, but with other Controls as children.
What is already there:

UIContainer, but for some reason this inherits from TextControl, whereas I find TextControl more specific that UIContainer feels it should be. The idea of Table is to be rows and columns framework that mainly is responsible for arranging layouts, and those might not need the extra methods that it gets by inheriting from TextControl. Therefor I want to let table just inherit from Control initially. If there is a good reason to use TextControl here rather than just Control, please inform me because then I might be missing something.
UIContainer doesn't allow to specify position of Controls in a row/column orientation.

Lessons learned:

From the game engine's point of view, a window is first rendered at the top left position of the game window, and then moved to wherever on the screen it should be shown. So when placing Controls at their correct position, if you notice the Control you added is not appearing in the parent Control window but instead is appearing at the top left corner of the screen, its position is not set at the correct time. Therefor the order of adding the Table first to the Window is important, as child Controls added to the Table will take the position of the Table as startpoint of their mRect. So I had to add the Table to the UI first, and then I had to add child controls to Table. But that alone was not sufficient, I had to implement the positionChanged function to fix this issue. (I gleaned that from UIContainer)

What is the simplest realisation of this concept without breaking anything:

I want to create a 1 column x 1 row that just wraps an existing control and then check if everything still works.

Expansion:

Take care of the C++ conventions and sharpen up my C++ skillset as it has rusted somewhat. Find an Eclipse extension to block my commit if I break a code convention rule. Will require code convention file though.
Introduce additional logic that can manage rows and columns. (int mColumns and int mRows) and multiple Controls (using std::vector most likely).
Currently the idea is to have pairs of Control* and NASD::Point, where Control is a pointer to a child control and Point is a valid column and row combination. So the pairs would go in the vector. Maybe I can just use a 2D array of Control*.
Validating "add element" logic and screen estate subdivision.
Scaling is still a question, what happens when a child Control wants more space than there is available, can we resize controls, or does that happen on the fly?
Would it make sense to define columns width usage and rows height usage in percentages, say for example a Table of 100px wide, divided into two columns. I want to place icons in the left column, and text in the right columns. Rather than having two columns of 50px wide, I would like to be able to say, first column gets 20% of the width, and second column gets 80 percent of the width.
Add table like behaviour by sizing a columns' width to the widest item in that column, and a rows' height to the highest element in that row.
When all the above is fleshed out, I'd like to look into orientation within a "cell", eg rendering a child Control left/right/justified.
Extra properties like margin, padding, empty cells, but that might be spun off into its own class that inherits from Table.
Examine whether the add element logic is intuitive, or whether additional (perhaps tuple based) addRow or addColumn logic is desired.

(If this issue somehow breaks any rules, feel free to mention them, or to summarily delete this issue :) )

So I like the idea here. I think you could have the table take Control* parameters and adjust the cells based on the controls themselves. There is a Label control for basic text labels and with your ProgressBar control this could work as well. Could be used for other types of controls as well including Checkbox's, Buttons, and so on.
The only caveat here is to ensure that you match current styling and naming to be consistent with the rest of the project. I can provide feedback on that as you progress.

Yes, to all your points.
With that said, I think this touches on quite a lot that's been discussed informally, which may result in multiple issues being opened to address the different aspects, and a lot of work to get the design right. We may need to really drill down and focus on small aspects to avoid getting bogged down trying to deal with too many intersecting concerns at the same time.
I agree that UIContainer should not inherit from TextControl. That's a design I've wanted to adjust for a long time now. That alone can probably be it's own issue, and would probably be a good place to start. Before we get too involved in UI updates, we should perhaps try to make the responsibilities of existing Control classes a little more crisp.
There has been talk of more generic layout classes, which would likely derive from UIContainer. I think this depends on the above cleanup before it will really get any traction. In terms of layouts, the most common ones are Horizontal, Vertical, and some kind of Grid or Table layout. It's the last one that seems to be the focus here, and of the StringTable class. I believe each layout format would be a separate class, and would be used to group component controls, and automatically layout their positions without having to manually specify them. In terms of operations supported, the key ones are to add and remove controls from a container, perhaps to disable a container as a whole, and possibly some features related to message routing such as disabling messages to all contained controls (when the container is disabled or hidden from view).
You may want to take a look at #636, as it's related. In that other issue, there was mention of Vaadin form layouts, which corresponds quite well with the tabular notion that people want to do here. Related, details on CSS Flexbox may also provide good inspiration, both in terms of potential capabilities, and the terminology to use. Granted, I'd be hesitant to implement the full feature set that Flexbox offers, as it sounds like it would be a lot of work. Though we might be able to pick out a few key aspects that are important and focus on those.
Relating to the idea of UIContainer derived layout classes, is updates to message routing. Currently each control is required to register with a global message source, and unregister before being destroyed, or when the control is hidden from view. This is somewhat error prone. Failure to unregister before a control is destroyed leads to dangling pointers and crashes. Failure to unregister when hidden from view means controls respond to clicks and keys when they aren't visible, or are under another view. Instead, I was thinking we could have some kind of hierarchical message routing, where UIContainer derived objects would pass on messages to contained controls (based on keyboard or mouse focus), while the derived controls would then respond to those messages. Only the top level container would need to worry about global message sources. That could greatly simplify how controls respond to messages, and eliminate many sources of errors.
From a high level, the mains steps I see are:

Cleanup current design, by making responsibilities a little more crisp
Implement layouts

Horizontal
Vertical
Grid/Table

Implement message routing

@DanRStevens : With the UIContainer now being more generic, what class(es) would be best to continue the effort with?
As I'm not that well versed in OPHD codebase yet, can you (or anyone else who reads this :) ) give me some pointers as to which classes could be made more crisp or which have some bad code smells?

Issue #479 deals with ListBox. I put a fair bit of effort into refactoring so the different ListBox derived classes could be consolidated into a single template class. There's still a bit more work to do. I just haven't been able to get back to it in a while now.
I had thought perhaps the Window class could be a bit more generic, and not include the title bar, and instead have a separate class for a window with a title bar.
There's probably a bit more we can do with UIContainer. Particularly if we start developing derived layout classes. I suspect attempting to build derived classes might force us to think about use a bit more and maybe lead to a more crisp sense of what UIContainer should be. Actually, I'm kind of thinking we may be able to add a template constructor with a parameter pack so we can set all contained controls right when the container is created. That probably makes more sense for derived classes though, that would automatically assign control position and possibly size too.
When adding Control objects to a UIContainer, they should probably be placed relative to the location of the UIContainer. If the UIContainer moves, the Control objects should move with it. Similarly, if a UIContainer is hidden, all Control objects should also be hidden. I don't remember if this already works or not, though perhaps we should revisit how it's done.
There might be something we can do in regards RadioButton groups. They make use of UIContainer to find sibling buttons so they can be un-checked when a new button is checked. The current organization seems a bit error prone, as every RadioButton must have the parent UIContainer set, and it leads to undefined behaviour (probably a crash) if the button is clicked and the parent was not set. We should perhaps have a RadioButtonGroup, which is responsible for owning all the buttons, and handling the checked/unchecked behaviour. Actually, it might make sense to restrict creation of RadioButton, so they can not be directly created, but only created through a group. Or maybe we can get rid of RadioButton and instead use normal buttons in a RadioButtonGroup? Might need to think about that and play with it a bit.
Currently the Button class handles both picture buttons and text buttons. Perhaps these should be split into separate classes, derived from a generic Button class? We should have a TextButton and a PictureButton (or ButtonText and ButtonPicture if you want class files to group nicely when sorted alphabetically). Might even want a Button derived class with both picture and text, such as when text is being overlaid onto a background image for the button texture.
We should take another look at constructors. Some controls need certain values set before they are usable. These values should be set in the constructor. For instance, a Button class (with text) should always have the text set during construction. It might be changeable later, though there should never be a moment when the text is not set. Similarly a picture button should be constructed with a picture. This reduces the possibility of a Control being visible without all parameters needed to display it properly, or worse, cause crashes due to nullptr dereferences, or use of uninitialized values.
For collection controls, we should probably offer the ability to set the collection contents in the constructor. Think ListBox and ComboBox. This is perhaps similar to the earlier idea of allowing a UIContainer to be constructed with a list of all contained Control objects.

Whew, that's a nice list, I'll get started on some of the smaller stuff first, as there are some pretty advanced topics mentioned in there! But we'll get there. I think I'll have a look at the Button and its variants.

I used a bright red fill to draw out the size I had passed to the table control.
I noticed that a control can claim more space than there is height or width available.
How should this be handled? Should the "parent" control resize it? Scale linearly?
This would then need to be enforced from within the outermost "Window", each child control would be granted some part of the screen estate the Window "owns". This could become very complex, very fast. It'd change from an absolute sizing set up by the developer for each control, to giving the outermost Window a screen estate "budget" and let its children divide it up amonst themselves.
On the other hand, not all controls scale well and some might stylistically want to resist it (icons shouldn't grow too large, the IconGrid might want to keep the number of items in its rows static, a horizontal layout might not want to wrap, etc...)

Yes, those are some of the details we'll need to discuss and figure out.
Automatic resizing seems most relevant to the automatic layout containers. I've been thinking about the resizing and screen space constraints problem, though haven't come to any conclusion on it yet. There will be difficulties when we have multiple constraints which can't all be satisfied simultaneously. Perhaps we'll end up working out a priority list for how constraints are met.
Initially though, we can probably ignore the problem of not enough space, and just let things overflow the border if they are too large. That's kind of how things work now. Only now we don't even have automatic layout. Everything is manually placed, and will overflow containers. We could potentially add clipping to the draw method of the Control. Would be nice to enable some kind of automatic clipping without having to insert manual calls in ever draw method.

That RadioButton hack makes sense now that I look at it. It ensures the parent pointer is never left unset. Though it seems to be blending in the concept of a RadioButtonGroup into the standard UIContainer. I think this is one of the areas where separating that out would make things more crisp.
In terms of default layout for a RadioButtonGroup. Yes, initially you could just choose a standard layout. More long term, we could parameterize it so you can pass in a custom layout container. I've kind of thinking a template parameter, though maybe a runtime parameter would make sense.

So there are a lot of ways this can be done 'correctly', and there are a lot of debates concerning it. My thinking is to just expand the parent container to cover its children. There's also the possibility of using a flag to let the developer decide if a container should expand or just clip children.
Clipping as it least really really easy. NAS2D::Renderer offers the following two functions:
void clipRect(const Rectangle<float>& clipRect);
void clipRectClear();

Okay, I've done some trial balloons with the RadioGroupButton, but some things still don't sit too well with me.
My main idea was that a single RadioButton instance doesn't make sense, there must always be at least two to define a choice of some sort.
The concept was to relieve the UIContainer of its RadioButton related duties, making UIContainer effectively treat it no different than any other Control the UIContainer could know about. So I introduced the RadioButtonGroup (hereafter referenced as RBG), effectively a container specifically built for RadioButton classes. It would not make sense to try and add other Control to the group, eg ListBox or IconGrid, so the RBG has an add() method that only allows for RadioButton classes to be added.
The idea was to make the RBG somewhat of a Facade which can be addressed by the game and RBG would know about the state of its contained RadioButtons, which one was selected, rather than having each RadioButton look for its siblings every time a click event happens.
But that idea breaks down as soon as we want to add signaling, as the signals are set on the 'leaf' nodes, eg on the children Controls of RBG, each RadioButton has a click() methods, e.g. what they have to do as a reaction to being clicked.
This is not something the RBG can easily manage. Unless the RBG becomes some sort of aggregate of its child events, but that would complciate "wiring up" these RadioButton Controls to their callbacks. And the RBG would need to know of all callbacks, as they might differ per specific RadioButton.
And then we still have the issue that there is nothing blocking someone from adding a RadioButton to any other layout (not a RBG) and expect it to work.
I played with the idea of making the RadioButton constructor private and letting RBG be a friend class that can access this constructor. But that also fails due to the way Control instances are now set up (at least as far as I know), for example in FactoryProduction. As it stands, you'd define the RadioButtons in the .h file, and set their size and position in the constructor of FactoryProduction. If the constructor is private at this point, this doesn't work, as FactoryProduction is not allowed to call it.
You could define an RBG in the FactoryProduction as well here, but the RBG cannot call the constructor as a proxy, as the signals must be either passed in the RBG constructor, which would be very messy. Or you'd have to be able to have a setCallback(RadioButton*, CallBack*) interface of some sort that FactoryProduction then could call on RBG.

What if the add method specified the text and a clickHandler. The RadioButtion could be constructed inside the add method, rather than passed in.
This may relate to that other idea about having constructor parameters to fully construct objects. In this case, a RadioButton needs both text and a clickHandler. Effectively the add method would then be like a factory method that delegates to such a constructor, only it would manage lifetime internally rather than return the instance.
I might suggest having RadioButton as a private inner class to RadioButtonGroup. That would be one way of limiting visibility so it could only be constructed inside a RadioButtonGroup object. There should be no need to declare anything as friend. The constructor on RadioButton would be public, but the class declaration would be in the private section of RadioButtonGroup.

@DanRStevens : Agreed, I'll give that a try. The friend class was already there btw, but I am in full agreement that an inner class is a more neat and tidy solution.

Hi @DanRStevens , any pointers (pun intended) how I would be able to pass the chkIdleClicked member function from the FactoryProduction class, which has a RadioButtonGroup member
RadioButtonGroup rbgOptions{};

, and I want to call the RadioButtonGroup add() function, which I want to pass:

a pointer to the origin (here FactoryWindow)
a pointer to the member function that must be passed to RadioGroup
a string label that will show on this instance of RadioGroup

e.g. in the FactoryProduction window, I had in mind something like this:
rbgOptions.add(this,  &FactoryProduction::chkIdleClicked, "One");

That add function would then add a RadioGroup to its internal Control* vector.
But I can't figure out how I would write that add() function, as I think it needs template function code, which I haven't ever used.
And all variations I tried, did not lead me to any compiling code.
So is there some documentation available or how would I accomplish this?

Umm, the chkIdle button is a CheckBox, not a RadioButton.

Since the Control type is exactly known, I would suggest using a std::vector<RadioButton>, rather than Control*.

In terms of implementing add, you'd want to take a text string and a Delegate (or the parameters to construct one). You can form a Delegate from the parameters using MakeDelegate. The unit test code has an example:
auto delegate = NAS2D::MakeDelegate(&handlerObj, &HandlerObj::HandlerMethod);

The Delegate parameter is a templated type, though in this case, the parameter and return type are fixed, so the function taking the Delegate won't also need to be a template. The type parameter is a function signature of the handler method. The click handler has no return value (return type of void), and no parameters (), so it would be declared as void().
void add(std::string text, Delegate<void()> handler)
{
    buttons.emplace_back(text, handler);
}

The emplace_back call here assumes that RadioButton has a constructor for the parameters being passed:
RadionButton(std::string text, Delegate<void()> handler)

Hi @DanRStevens, I seem to have missed your update, nonetheless, I've arrived at something functional on my local "playground" branch. I did use templating as I could not find any other way to wire up my add function.
Not to worry, the chkIdleButtonClicked is just the action that is executed when clicking, just a visual confirmation that my clicks are wired up and "do something". I used something I had handy and which also had a clear and distinctive visual change.
The visuals for a RadioButton are not there, though, so they look like checkboxes for now.
Good to know here is that the UI observes the state of the checkbox, and not the state of the factory , leading to a confused me when seeing my RadioButtons switch but no transparancy change in the structure (which is what becoming/recovering from idle does).
I spent the afternoon on YouTube, looking at what function templates are, and after getting the gist of templating (thank to TheCherno) I had an idea to implement my own templated "add" function. As I see it, it's the same story as connect() uses, at compile time these templates are populated with the code that needs them, which is how we can wire up these member functions.
https://github.com/belgianguy/OPHD/commit/39f146f059094dca53075774a10e063051a467f5
I just read your comment just now, and seem to have arrived at quite a different solution. Can you have a look and see whether there is some value to my current solution?
Screenshot:

I took a look over the code. It seems largely fine. My main recommendations were for the areas that differed from my suggestion. I elaborated a little bit on the details of why in my comments.
Summary:
Templating add allows for incompatible functions to be passed to add, which can result in a complicated compiler error message when compiling add. Template error messages tend to be extremely verbose and hard to decipher, so best to avoid them when possible. In this case, templates can be avoided by being strict and specific about the type, and there is only really one allowed type.
The RadioButton should only have the one constructor that takes a parentContainer.
You can use references instead of pointers when a parameter is non-nullable. References are designed to be non-nullable, and the only way to get a nullptr into a reference is through bad code with undefined behaviour (dereferencing a nullptr), and you'll often get compiler errors or warnings about such code unless they are silenced with awful casts.
You should avoid new/delete in C++17 and above. They are no longer needed in standard application code. Either use std::unique_ptr, std::shared_ptr, or better yet, avoid dynamic memory allocations as much as possible by using emplace style construction. That would be possible by using std::vector<RadioButton> to hold the controls, along with emplace_back.

I made the skin myself -- I can add a radiobutton skin, should be pretty simple, really. I'll add some visuals in a little bit.
I know I've been a little bit AFK -- been somewhat burned out the last week or so so I've been taking a bit of a break from coding all together.
Starting to get back into it though so woot! :D

Thanks for the RadioButton skin update Leeor. Submodule update looks good on my end.

@ldicker83  Thanks for the skin Leeor, I've added it!
@DanRStevens I've removed the RadioButton constructor that didn't make use of the parent container.
However, I'm still stuck with refactoring the add() code into a delegate (checking and trying to replicate the unit test without any luck), and also faced an uphill battle switching out the new/delete with unique_ptr. I've read myself in on the subject, but it causes all downstream interfaces to change with it.
As RadioButtonGroup extends from UIContainer, they have the mControls member, which is of type vector<Control*>, so I don't know how I would translate that into a vector without breaking away from UIContainer.
So still pretty confused here.

You may need to either 1) build a new type not based on UIContainer (not ideal) or 2) adjust assumptions being made. The UIContainer is intended to work on a low-level ... so while we'd want a RadioButtonGroup to handle only RadioButton controls, it will probably need to look at RadioButton's internally as Control*'s and cast if necessary to the derived RadioButton. Casting is not ideal but may be necessary for specific cases (e.g., static_cast<RadioButton*>(controlPtr).checked(true)).

This is why there's a distinction between interfaces and classes. Having mControls defined in a base class restricts what you can do with derived classes.
I would suggest not deriving from UIContainer. The UIContainer class is meant to contain arbitrary Control objects. The RadioButtonGroup is not meant to contain arbitrary objects. It only contains RadioButton objects. The RadioButtonGroup is more like a ComboBox in that it's a compound control, made up of other controls. Just that in this case it's not a fixed number of other controls. It is however quite restricted in what they can be and how they are laid out.
I generally recommend solutions that avoid casting. Casting used to be quite common, especially in early days when templates were not available. Now though, with templates, I find the need to cast is generally pretty rare. Templates should allow most code to be written in a type safe manner without needing casts.
I suggest ignoring the part about std::unique_ptr. It wasn't a suggestion to use std::unique_ptr here, but rather in general, you can use std::unique_ptr to replace new/delete. The other solution being to avoid new/delete by not managing the memory yourself. The use of std::vector can handle the new/delete for you internally, assuming the vector objects are the things being allocated and deleted. If you're storing pointers to those objects in the vector, rather than the objects themselves, that won't be the case anymore. My suggestion for this particular code was to use std::vector<RadioButton>, so the std::vector would manage the memory for the RadioButton objects, which would replace the need for manual new/delete.

Agreed with Hooman on this. I was looking over UIContainer and found this:
	if (auto* asRadioButton = dynamic_cast<RadioButton*>(&control))
	{
		asRadioButton->parentContainer(this);
	}

Definitely want to avoid this kind of special case code -- it's bitten me in the butt a number of times and is unfortunately prevalent in a lot of the OPHD code.
So there are two options here. Either modify UIContainer, declare UIContainer::add() as virtual and do that check there then pass on to the base implementation, or build a new class designed specifically for RadioButton's -- my personal choice here as it avoids unnecessary casting and we can even do away with pointers altogether. Would even simplify the code a bit since you can't ever add the same control twice.
E.g., something along the lines of:
class RadioButtonGroup
{
public:
    void add(const std::string name)
    {
        mRadioButtons.push_back(RadioButton(name));
    }

private:
    std::vector<RadioButton> mRadioButtons;
};

This sort of thing and then the RBG can handle laying out the buttons themselves. I'm making a couple of assumptions here but this is mostly to illustrate my thought process.

I think Leeor's code largely matches the general idea I have in my mind.
In terms of typos, the RadioButtonGroup should derived directly from Control (rather than being free standing, or deriving from UIContainer).
I would suggest replacing the push_back with emplace_back. The difference is that push_back takes a new object, which is then copy constructed into the std::vector, where as emplace_back takes constructor parameters, which are then forwarded to the constructor to build the object in-place in the std::vector.
The following two lines are equivalent in their intent (though the later is more efficient):
mRadioButtons.push_back(RadioButton(name));
mRadioButtons.emplace_back(name);

Though do be careful not to accidentally use the copy/move constructor with emplace, as that's a bit self defeating:
// Don't do this, even though it works
mRadioButtons.emplace_back(RadioButton(name)); // Bad: Construct temporary then copy/move construct to std::vector

This bad use of emplace_back would actually be equivalent in efficiency to push_back.

I would recommend upgrading the constructor for RadioButton to take a delegate, or the parameters to construct one. That would allow the RadioButton to be added to a RadioButtonGroup container, and have the handler set, in a single line:
// Allow for one of the following
mRadioButtons.emplace_back(name, this, &RadioButtonGroup::radioButtonStateChanged);
mRadioButtons.emplace_back(name, Delegate{this, &RadioButtonGroup::radioButtonStateChanged});

Hi @DanRStevens , I've added most of the recommended changes on the https://github.com/belgianguy/OPHD/tree/ExtractRadioButtonLogic branch, but I think we're still missing the actual function that must be fired when a RadioButton is clicked. We now have all RadioButtons alert the radioButtonStateChanged() function, but they are supposed to fire whatever function was connected to that RadioButton in the first place.
Currently, that is not the case, and I wonder where these ought to be added.

I would add the button delegate to the add method.
Original:
void add(const std::string& name)
{
    mRadioButtons.emplace_back(name, this, NAS2D::MakeDelegate(this, &RadioButtonGroup::radioButtonStateChanged));
    //mRadioButtons.back().stateChanged().connect(this, &RadioButtonGroup::radioButtonStateChanged);
}

Updated:
void add(const std::string& name, NAS2D::Delegate<> delegate)
{
    mRadioButtons.emplace_back(name, this, NAS2D::MakeDelegate(this, &RadioButtonGroup::radioButtonStateChanged));
    mRadioButtons.back().stateChanged().connect(delegate);
}

Effectively there are two callbacks that are triggered when a button is clicked. One for the group, which can handle unclicking the previously selected button, and then the button specific handler that actually does something.
I recommend attaching the RadioButtonGroup handler first, since you probably want to do any visual updates before possibly long running actions in the button specific handler.

I noticed you have a destructor, but I don't think it's required:
~RadioButtonGroup()
{
    for(auto& radioButton : mRadioButtons)
    {
        radioButton.stateChanged().disconnect(this, &RadioButtonGroup::radioButtonStateChanged);
    }
}

When the RadioButtonGroup is destructed, it's member variables are destructed, including std::vector<RadioButton> mRadioButtons;. That means the destructor for each RadioButton will be called, which in turns destructs the Signal objects they contain, which will effectively disconnect any still connected signals.
The disconnect call is mostly required when attached to a global signal source whose lifetime is not owned and controlled by the current object.

Okay, another update, I tried rewriting the code using the std::unique_ptr constructs and emplace_back call using the parameters that it passes to the RadioButton constructor and using a std::vector. The std:::unique_ptr causes a lot of breakage in interfaces, so I reverted that attempt. Then using the emplace_back construct, for a reason that is still unknown to me, connecting a delegate using vector::back() then ended up only working for the last item in the vector. This meant that only the last one got hooked to onMouseDown, and that the previous RadioButtons did not respond to mouse interaction at all. Which just seems so odd. So I reverted that back to the new/delete paradigm, but kept the delegate creation.

If anyone wants to review, it's on this branch: https://github.com/belgianguy/OPHD/tree/ExtractRadioButtonLogic
(To showcase the functionality, in this branch the StringTable in the FactoryProduction window is replaced with a group of three RadioButton objects (purely for showcase purposes), so after placing a Seed Lander and the Factory built, you could see the RadioButton group when right clicking the Seed Factory).
On the topic of working on a OPHD organization branch, I am really happy with working on my fork, leaving it behind would remove one of my favourite safety features, namely deleting my git fork when I have messed up something beyond recognition and resetting it to a clean copy to hide my shame :). Also, I am toying around with text-to-speech integrations like Festival (which isn't cross compilable but gave me an idea of how such thing works https://github.com/festvox/festival) and MycroftTTS (https://github.com/MycroftAI/mimic1, which I haven't yet tried but seems to be more modern, and cross-compilable) to elicit that Outpost-y feeling of the AI speaking to you (based on text in Strings.h), but they don't sound the part yet, and from YouTube alone they still have ways to go before being on par with commercial offerings.

Err, my first comment about std::unique_ptr and emplace_back was a choose one of them option. Not both. This is very much a case where emplace_back seems to be the correct solution. I dot not recommend using std::unique_ptr here. Sorry if there's been some confusion about that.
I'm curious about your emplace_back attempt and events only working for the last button. Do you still have that code available?

You can maintain your own fork for experimental reasons, and a direct clone for work you plan to submit. That choice is not exclusive. :wink:
In terms of erasing work, you can use force push on your own branches to reset them and remove work. As long as you don't open a PR, there will be no notifications for your changes. (If you want to try some experimental stuff on a branch that already has an open PR, then branch off of your branch, so you have a new branch with no associated PR).
Of course, if you never push the work for your branch, nobody else can possibly see it. I'll sometimes have experimental work that sits around locally for months without ever getting pushed. Like when compiler support for a new feature just isn't there yet among all supported compilers. For stuff that is ready to be merged, I usually cleanup my work with git rebase before I push things. And when I screw up and cause a CI build to fail, I'll sometimes fix errors and use git rebase to make it appear as if nothing bad had ever happened, and then force push the changes over top of the old branch. Usually that's done before opening a PR, so other people aren't bothered by the details of how the sausage is made.
When you push a branch, git will only push the branch you specify. Makes it very easy to keep some branches private and only share what you want to share.

I took a bit of a look over the code for the emplace_back solution. It seems there's some confusion over what certain methods do like click(). Admittedly such methods are not named very clearly. The click() method returns access to the SignalSource object for the click event. Or rather, in this case, it returns the full Signal object, as the split between Signal and SignalSource has only been recently made in NAS2D and the OPHD code hasn't yet been updated to make use of that. Anyway, the click() method returns an object that can be used to add and remove event listeners. It is not called when the click even is triggered. Some of the debug output code and delegate calling added in there would be the wrong place for that.
I would really like to rename a lot of those methods. They could be made much more clear.
As the button will call all registered listeners when clicked, there should be no need to manually call delegates.

I would prefer using NAS2D::DelegateX<> over NAS2D::DelegateX<void>. They both mean the same thing, just that explicitly specifying void for no parameters seems like a holdover from really old C code. I rarely see it anymore.

I would recommend accepting a delegate rather than writing a templated add method.
Original:
template<typename X, typename Y, typename ... Params>
void add(Y * obj, void (X::*func)(Params...), const std::string& name, bool checked = false)

Suggested:
void add(const std::string& name, NAS2D::Delegate<> clickHandler)

The reason being the already formed delegate offers more easy options for calling:
add("Some Text", clickHandlerDelegate); // Using already formed delegate object
add("Some Text", {&obj, &Object::Method}); // Forming a new delegate inline

A delegate can be constructed from the parameters by enclosing them in {}, so you actually have more flexibility if the method accepted a delegate. That would allow an already formed delegate object to be passed, or to easily construct a new one inline. With the templated method, it becomes impossible to pass an already formed delegate without having multiple overloads. There is no easy way to deconstruct an already constructed delegate into its component parts.

Showcase branch https://github.com/belgianguy/OPHD/tree/EmplaceProblems for no mouse click capture for items except for the last one when using emplace_back().
Changes (compared to branch ExtractRadioButtonLogic):

vector<RadioButton*> is now vector
emplace_back with constructor arguments is called instead of push_back
The code addressing items in a loop has been changed to now work with the actual object rather than a pointer to it.

Here 'One' was clicked twice, 'Two' was clicked twice and 'Three' was clicked twice. Only the events on Three are registering in onMouseDown.

I've had a bit of a chance to play with the code. I still don't know why only the last button is triggering events. I have noticed a few other oddities in the code though.

There seems to be some confusion over the purpose of the click() method.
RadioButtonGroup::RadioButton::ClickCallback& RadioButtonGroup::RadioButton::click()

Note the return type of ClickCallback, which is defined as:
using ClickCallback = NAS2D::Signals::Signal<>;

The click() method is a getter for the click Signal object. It is not an onClick() event. Rather it is used to attach/detach signal handlers:
obj.click().connect(&someObject, SomeObject::ClickHandler);

I should point out that anything in OPHD named "Callback" is probably named wrong. Those type aliases are typically applied to Signal objects, which are not actually the callbacks, but rather the object that handles dispatching to a list of callbacks. This is very confusing, and something I would like updated. Similarly there are many methods that return these Signal objects which are named according to the event, which makes them sound like event handlers, rather than getter methods for the associated Signal object. I apologize for the confusion here. This is something we haven't gotten around to addressing yet.

I noticed your code is mixing tabs and spaces. I highly recommend turning on "show whitespace" in your editor. It makes these inconsistencies much more obvious. Typically such inconsistency will show up in git diff with horrible looking red highlighted background, though if you're not using command line git you might not see this. I don't really mind between tabs or spaces (as long as it's consistent within a project), though the convention set by Leeor for OPHD is to use tabs for indentation.

I notice you're trying to use an updated Signal definition to communicate with the RadioButtonGroup. You've added a RadioButton* parameter. This makes a lot of sense. Though it does mean you won't be using the same Signal object to update all listeners, since different listeners will have different parameters.
This got me thinking about different ways to implement the callbacks. You could have each button trigger a unique callback, which would closely match the existing design. You might also provide context to the callback, such as passing the this pointer for the RadioButton or a related data object. Providing such an object to client code would require the class have more public visibility though. Another option would be to only notify the RadioButtonGroup, and have the RadioButtonGroup emit an event with a parameter to identify which button was selected. That might be done by index, or an associated stored data value, or with a pointer/reference to the RadioButton (again, requiring more public class visibility).
I'm open to discussions about what method to use. I think my default assumption is to continue using a parameterless callback which is unique to each button.

Ok, I now know what's going on, though I don't know why.
The first two RadioButton objects are being destroyed. Hence why their associated events are not being triggered. Only the third button still exists, so it is the one responding to all mouse events. The third RadioButton object doesn't fire the click even if the mouse position is outside of the area of the third button. Hence you get some debug output from before the hit test from the third button for clicks over the first two buttons, but not anything from after the hit test.
Tracing a bit, it seems the RadioButton objects are being destroyed as soon as the next one is created. I don't know why this is happening. If you put debug output in the RadioButton destructor, and wrap the emplace_back line with debug output, you'll see that's where the problem is happening:
std::cout << "RadioButtonGroup::add emplacing " << name << std::endl;
mRadioButtons.emplace_back(name, this, NAS2D::MakeDelegate(obj, func));
std::cout << "RadioButtonGroup::add emplaced " << name << std::endl;

RadioButtonGroup::RadioButton::RadioButton(/*...*/)
    // ...
    std::cout << "RadioButton created " << mLabel.text() << std::endl;
}

RadioButtonGroup::RadioButton::~RadioButton()
{
    std::cout << "RadioButton destroyed " << mLabel.text() << std::endl;
    // ...
}

Ok, in case you didn't notice my edits above:
The problem appears to be a copy/move constructor issue with RadioButton. The RadioButton object currently has default copy/move constructors, which don't properly handle the event connection. When the std::vector in RadioButtonGroup is resized, the old objects are copy/move constructed to a new buffer, then the old copies are destructed. The destructor of RadioButton will detach from events, but the copy/move constructor will not attach the new copied objects to the event source.
I was working on a SignalConnection object for NAS2D. I had pushed a branch with some initial code, though I was still refactoring the design, so no PR yet. Perhaps the new object will help to properly manage such copy/move semantics without having to explicitly write copy/move constructors for UI classes.

I'm beginning to see why terse function names can be problematic. I did not understand the potential for ambiguity here. I'm beginning to see your points here.
As for the SignalSource update that you mentioned, I see how much easier it is to handle signal connect/disconnects when you don't have to do it manually. Kinda reminds of new/delete operators. Powerful but very easy to make mistakes.

Names always make more sense when you're the one writing them. :wink:

After my last post, I finished https://github.com/lairworks/nas2d-core/pull/843, which adds an RAII type object to manage signal connections.
Turns out there's no good way to automatically update the connection during an object copy. That means objects that need to maintain a connection during a copy/move operation will need to have custom copy/move code. The new Connection object is designed in such a way that you'll get an error if you try to copy/move an object containing one of those instances, and don't have a custom copy/move operation to support it. Basically, it disables default copy/move operations, which won't work correctly.
The unit test code has an example of how the Connection class can be used.
I suppose we still need to update the NAS2D submodule referenced by OPHD to make use of the new code. Though there was some planned API re-organization and renaming in https://github.com/lairworks/nas2d-core/issues/830, so it might make sense for that to be done first before writing a bunch of code that depends on the new feature. A bit of experimentation should be fine though.

Ok, the NAS2D submodule has been updated with the new SignalConnection class. That should make the new class readily usable in OPHD.
Hopefully the update hasn't caused any merge conflicts. It's possible though, since quite a few files were updated with minor path or namespace changes.
I'll try to be on Discord tomorrow in case you want to chat real-time. We could even do a screen share session to try and get this code working.

We touched upon some confusing aspects of the UI code earlier in this issue. I've opened a few new issues to address some of those confusing points.

#853
#854
#855

It's quite possible some of those changes may have merge conflicts with changes for this issue, so it might be best to find some sensible order and do them serially.

Speaking of merge conflicts, I noticed my recent update of the NAS2D submodule has caused some merge conflicts with the changes @belgianguy worked on here. Terribly sorry for the inconvenience. I feel bad about kind of ripping the rug out from under people with those changes.
I've rebased the EmplaceProblems branch to resolve the merge conflicts, added some fixes for the submodule change, and pushed the result to the OutpostUniverse/OPHD repository. Results:
https://github.com/OutpostUniverse/OPHD/compare/EmplaceProblems?expand=1
@belgianguy: If you wanted to continue work without having to deal with the merge conflicts, you can use that branch (from the OutpostUniverse repository, rather than your fork, which I don't have write access to). If there are any other branches you'd like me to deal with, just let me know.
I noticed there are CI build failures for Clang and MSVC. Looks like the MSVC project file is still referencing the old RadioButton.cpp file.

@belgianguy: If you wanted to join us for real-time chat, there's a Discord server. Details:
https://www.outpost2.net/chat.html
@ldicker83: If there's a better link or info, please let me know.

So @belgianguy and I worked on the code yesterday and got the new RadioButtonGroup working. We discussed plans to cleanup the code a bit with git rebase before submitting for a PR. Today I've been thinking about how to do the cleanup.

The easiest way to clean up history might be to do a squash merge:
git co master
git co -b squashedRadioButtonGroup
git merge --squash EmplaceProblems

That will create a new branch squashedRadioButtonGroup based off of master and stage changes for a single commit with all of the worked on changes. This seems fairly reasonable as a starting point since the changes are basically an addition to the API, with relatively few changes to existing code. As some of those changes are test changes, it may make sense to only commit some of them, and to potentially break the changes up into multiple commits. This can be prepared by running:
git merge --quit
git reset

Then add the files or changes you want with git add, or possibly git add --patch to select only some changes from a file. You can then use git stash --keep-index to stash all the other changes, and do a test compile and run.
If you want to see what this might look like, I committed the result of the squash merge and pushed it:
https://github.com/OutpostUniverse/OPHD/compare/squashedRadioButtonGroup?expand=1
This approach gives a somewhat clean slate with all the branch changes, which can then be reformed into new commits. That reforming into new commits will still be a manual process though.

Another solution is to run a rebase:
git rebase master

I tried this out. There's a number of merge conflicts to deal with, though it's not too terribly hard to resolve them. Part of that was removing the Signals namespace specifier, and updating header include paths to account for the new Signal/ folder. There were also some renames to deal with, and a few other merge conflicts too. This process is a lot more time consuming than the squash merge.
I also did a pass over all the commits, compiling them to ensure they compiled. That resulted in a few more fixes that were needed that were not caught by the merge conflict resolution process. That can be done with:
git rebase -i --exec make master

That will run through each commit on the branch (now forked off from master), and attempt to compile each commit. If the compile fails, the rebase operation will pause, and give you a chance to fix and stage any needed changes before using git rebase --continue to resume.
I pushed the result of that attempt into a branch:
https://github.com/OutpostUniverse/OPHD/compare/radioButtonGroup?expand=1
In the end, I didn't like this solution too much since there was still quite a bit of noise in the history with experimental changes, which were undone in later commits. The squash merge approach does away with all of that.

Actually, if you're going to start a squash merge and then back out of it and reform new commits, that can be done slightly easier with read-tree.
git checkout master
git checkout -b squashedRadioButtonGroup
git read-tree -u -m EmplaceProblems
git reset

Basically no need for the git merge --quit.

Hi @DanRStevens , today I plan on creating that squash commit, but before I do that, I must also roll back the changes that were made in FactoryProduction, as it doesn't feature any RadioButtons in normal usage and was used as a showcase only.
As there currently are no RadioButtons in use in the game, I suggest we document its usage in UI here for starters.
FactoryProduction.h
#include "Core/RadioButtonGroup.h"

...
       RadioButtonGroup rbg{{
               {"One", NAS2D::MakeDelegate(this, &FactoryProduction::onCheckBoxIdleChange)},
               {"Two", NAS2D::MakeDelegate(this, &FactoryProduction::onCheckBoxIdleChange)},
               {"Three", NAS2D::MakeDelegate(this, &FactoryProduction::onCheckBoxIdleChange)}
       }};

FactoryProduction.cpp
FactoryProduction::FactoryProduction() :
	Window{constants::WINDOW_FACTORY_PRODUCTION}
{

...
       add(rbg, {mProductGrid.size().x + 12, 25});
       rbg.size({50,50});
       rbg.setSelected(2);
}

Which then looks like:

I'll also remove the  includes where they were used to provide textual confirmation of button clicks.

PR created, comments welcome: https://github.com/OutpostUniverse/OPHD/pull/879

Quite a few UI improvement ideas were discussed here. I've attempted to create new standalone issues for these ideas. Meanwhile, this issue got pretty heavily focused on RadioButtonGroup, which is now implement, so we should probably close it.
Related issues:

#896
#894
#895
#884
#636
#637

Or, check for the UI API tag


Merge filters + upstream changes since 8/4

Closing in favor of https://github.com/CityOfDetroit/bloom/pull/358
This needs to be rebased so it doesn't include a bunch of extra commits:

I initially merged contribute/avaleske-filters into this branch, which included the unsquashed commits for merging filters upstream.
Now I've merged the squashed commit from upstream as well, so we can rebase it so it doesn't include the other commits

Pull Request Template
Issue #293
Addresses #293
Description
Merge filters work back to main, including upstream changes from 8/4
Type of change
How Can This Be Tested/Reviewed?
Please describe the tests that you ran to verify your changes. Provide instructions so we can review. Please also list any relevant details for your test configuration

[ ] Desktop View
[ ] Mobile View

Checklist:

[ ] My code follows the style guidelines of this project
[ ] I have performed a self-review of my own code
[ ] I have reviewed the changes in a desktop view
[ ] I have reviewed the changes in a mobile view
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes
[ ] Any dependent changes have been merged and published in downstream modules
[ ] I have assigned reviewers
[ ] I have updated the changelog to include a description of my changes

Closing in favor of just using https://github.com/CityOfDetroit/bloom/pull/358, which doesn't have commits in it that were squashed during a different merge.


Transfering liquids between the mop, trolly and floor just was wrong

Liquids kept spilling, no idea why, even thought the actual trolly itself was at 800u, the mop would fail to transfer all of it's liquid to the trolly and replace it with water, then clicking it again would cause a bunch of liquid falling out
happened in round 62125

oh fun


Adds sampler which can sample only parameters needed for site selection

changes to sample() to allow specific model components to be sampled
addition of sample_site_selection, which allows sampling of only parameters needed for site selection.
Addresses issue #296

I think I've addressed your comments, let me know if I've missed anything

Actually, still need to fix something with the datatype of the process_inputs! function... is there a data type that covers vectors and tuples? Like AbstractVector, or something?

Actually, still need to fix something with the datatype of the process_inputs! function... is there a data type that covers vectors and tuples? Like AbstractVector, or something?

Just convert to a tuple?

Thanks for doing the hard work on this. I've made some adjustments to simplify things - particularly the flow between each sampling use case and how parameter bounds are adjusted.
I'd like you to have a look over the code when able to get a sense of what the changes were.
The very last thing I'll ask for before I merge is that you look at the tests I've written - perhaps there are other edge cases you'd like to check.
Note that I've associated #296 to be closed with this PR manually. As mentioned previously, GitHub doesn't seem to recognize the closing keywords if it is not in the main text (i.e., it has to be in the main body proper, it can't be in a list or the title).
FYI - I think I mentioned this a while back - while I don't mind, it is a little unusual to use list format in the PR description. Typically you would describe how the PR resolves a given issue, rather than an overview of changes (which we'd able to discern from your commit logs anyway). You can look at other projects on GitHub to see what the norm is.

Thanks for cleaning it up :) I'm looking over tests and things now

(also sorry about the dotpoints, I'll remember this next time)

Looks good to me! I can't think of any other cases we'd need to catch.


Update MSBuild, NuGet.Client to build as used in 2.1.5

New versions of these packages were used by the 2.1.5 build, but the repos weren't built during ProdCon so we didn't receive updates. NuGet.Client commit found via tag, MSBuild found by looking at the DLL version in the package.
This case would have been caught by the "Compare the source-built version of a package to the checked-in dependency's version" check proposed in https://github.com/dotnet/source-build/issues/748.
The update had me remove the only MSBuild patch!

For in-place context, the plan is to get https://github.com/dotnet/source-build/pull/791 merged if possible--this is the backup.


don't know why

Analyzer Feedback from IntelliJ
Version information

IDEA AI-183.6<IP_ADDRESS>92245
2.4.0
AI-183.6<IP_ADDRESS>92245, JRE 1.8.0_152-release-1343-b01x64 JetBrains s.r.o, OS Mac OS X(x86_64) v10.14.5, screens 1280x800  Retina

Please include full details of the crash. This isn't enough information to debug!


Throwing an exception instead of reconnecting

As I tested reconnecting by using loopForever() and restarting the local mqtt-broker mosquitto, my script stops. The output was:

PHP Fatal error:  Uncaught exception 'Mosquitto\Exception' with message 'The connection was lost.' in /home/user/public_html/test.php:41
Stack trace:
#0 /home/user/public_html/test.php(41): Mosquitto\Client->loopForever()
#1 {main}
thrown in /home/user/public_html/test.php on line 41

I expected a reconnect, but this wasn't the case. Whats wrong here?

@bitfreak25  Hello sir, How did you solved this issue ?

I used to use the mosquitto_loop_forever() function from the underlying library to handle the reconnects, but unfortunately that means that the function never returns at all, so if you attempt to break out of the loop, throw an exception, or similar, PHP doesn't know about it. That means I need to reimplement the function myself, which I've done, but I didn't get to implementing all of the reconnection logic. That's on my to-do list, and I hope to have it ready to look at in the next few days. In the mean time I'm afraid you need to do it the long way in your own code.

I solved it by using a php-restart-script similar to an answer on stackoverflow. But for me this looks like a workaround, so it would be nice, if this will be implemented in the library itself.


Ceres nonlinear refactor

Add ModelFitter class that encapsulates ceres fitting logic. Using it the user can build needed cost function. Also, it supports a few cameras fitting. Pull request changes ceres example too.

About general comment: it is not a problem to base on develop branch but it can't be compiled. So I can't check that everything OK with my work.
Error:
/Users/alpus/Work/prisma/eos_fork/include/eos/render/texture_extraction.hpp:609:68: error: no viable constructor or deduction guide for deduction of template arguments of 'tvec4'
        auto clip_coords = projection_matrix * view_model_matrix * glm::tvec4(vtx.x(), vtx.y(), vtx.z(), 1.0f);

I can push new changes, but I can't build devel "as is". So I can't test my new code :-)


Support for transforms / filters

In a recent project I have JSON-data that contains \n which I want partially (= when the screen designer decides its good to do) convert to <br />. So I needed a way for applying transforms (or may call it filters) in the template. This PR introduces a syntax like {{myvar | transfrom}} where transform is a callback that can be registered in the options. I have added documentation and tests. So please take a look and if you agree that this is a good feature, please accept the PR. I did not touch the existing tests, so I think it does not cause backward compatibiltiy issues.

I really like it. Additionally to some small code changes, I was wondering if we could merge some of the test cases in one or two test files. Currently this introduces 5 more test files, which is fine, but maybe we can narrow that down a bit?

I am happy to hear that you like the idea. I fully agree with your remarks; code is updated. Regarding narrowing down the tests: Do you have an idea for reduction in your mind? I think it's better to have small tests which make it easy to track down a problem of failing tests.

I see your point about the failing tests. Probably easier to see which one failed. Other than that I was gonna say we could put all files other than the deep transform into one test file. As they are not conflicting with each other.
But I'm perfectly happy with this solution as well. Thank you for the PR. I'm gonna merge this now.

Available under version 0.3.18


Using async/await with Babel in migrations

I'm trying to implement Knex migrations with async/await in combination with babel-cli and babel-preset-env, but I'm not sure it's supported in its current implementation. Can someone shed some light on this matter?
This is my migration file:
export const up = async (knex, Promise) => {
  return await knex.schema.createTableIfNotExists('user')
}

export const down = async (knex, Promise) => {
  return await knex.schema.dropTableIfExists('user')
}

I'm calling Knex using an NPM script as such:
"scripts": {
  "knex": "babel-node ./node_modules/.bin/knex"
}

My .babelrc file looks like this:
{
  "presets": ["env"]
}

This is the output in the terminal:
$ yarn run knex migrate:latest
yarn run v0.19.1
$ babel-node ./node_modules/.bin/knex migrate:latest
Using environment: development
Knex:warning - sqlite does not support inserting default values. Set the `useNullAsDefault` flag to hide this warning. (see docs http://knexjs.org/#Builder-insert).
Knex:warning - migrations failed with error: A callback function must be supplied to calls against `.createTable` and `.table`
TypeError: A callback function must be supplied to calls against `.createTable` and `.table`
    at new TableBuilder (/Users/deniz/Code/example/node_modules/knex/lib/schema/tablebuilder.js:47:11)
    at Client_SQLite3.tableBuilder (/Users/deniz/Code/example/node_modules/knex/lib/client.js:143:12)
    at SchemaCompiler_SQLite3.createTableIfNotExists (/Users/deniz/Code/example/node_modules/knex/lib/schema/compiler.js:59:31)
    at SchemaCompiler_SQLite3.toSQL (/Users/deniz/Code/example/node_modules/knex/lib/schema/compiler.js:51:26)
    at SchemaBuilder.toSQL (/Users/deniz/Code/example/node_modules/knex/lib/schema/builder.js:57:43)
    at /Users/deniz/Code/example/node_modules/knex/lib/runner.js:52:32
    at tryCatcher (/Users/deniz/Code/example/node_modules/bluebird/js/release/util.js:16:23)
    at /Users/deniz/Code/example/node_modules/bluebird/js/release/using.js:185:26
    at tryCatcher (/Users/deniz/Code/example/node_modules/bluebird/js/release/util.js:16:23)
    at Promise._settlePromiseFromHandler (/Users/deniz/Code/example/node_modules/bluebird/js/release/promise.js:512:31)
    at Promise._settlePromise (/Users/deniz/Code/example/node_modules/bluebird/js/release/promise.js:569:18)
    at Promise._settlePromise0 (/Users/deniz/Code/example/node_modules/bluebird/js/release/promise.js:614:10)
    at Promise._settlePromises (/Users/deniz/Code/example/node_modules/bluebird/js/release/promise.js:693:18)
    at Promise._fulfill (/Users/deniz/Code/example/node_modules/bluebird/js/release/promise.js:638:18)
    at PromiseArray._resolve (/Users/deniz/Code/example/node_modules/bluebird/js/release/promise_array.js:126:19)
    at PromiseArray._promiseFulfilled (/Users/deniz/Code/example/node_modules/bluebird/js/release/promise_array.js:144:14)
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

Error says:
Knex:warning - migrations failed with error: A callback function must be supplied to calls against `.createTable` and `.table`
TypeError: A callback function must be supplied to calls against `.createTable` and `.table`

http://knexjs.org/#Schema-createTable


FR: Multiline / Linebreak Support

I solely use this plugin to archive memorable chats from messengers and if its a longer message with linebreaks, links, lists, etc. it's hard to read in Chat View.
Here an example:
Messenger:

Chat View:

I could imagine the following sulotions:

a special seperator char for multiline, so it doesn't have to be a oneliner anymore (wrap it in {} or something)
another special char or sequence like \newline to keep the single line but break it on render

Would that be possible?
Anyway - thanks for your plugin! 😊

Hi @msnr. Thank you for your feedback! As of Version 1.3.0, I've added Markdown & HTML Rendering Support to Chat View Messages. Which means you can now use Markdown and HTML syntax inside the message section of your Chat View. Now you can write Chat View blocks like this:
```chat
{mw=80}
> Me | Duis autem vel eum iriure dolor in hendrerit in vulputate velit esse molestie consequat, vel illum dolore eu feugiat nulla. <ol><li>Facilisis at vero eros et accumsan et iusto odio dignissim.</li><li>Qui blandit praesent luptatum zzril delenit augue duis dolore.</li><li>Te feugait nulla facilisi. Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam. Nonummy nibh euismod tincidunt ut laoreet dolore. Magna aliquam erat volutpat. 😄</li></ol> Ut wisi enim ad minim veniam, quis nostrud exerci tation ullamcorper suscipit lobortis nisl ut aliquip ex ea commodo consequat:<br>[https://github.com/adifyr/obsidian-chat-view/issues](https://github.com/adifyr/obsidian-chat-view/issues)<br><br>Duis autem vel eum iriure dolor in hendrerit in vulputate velit esse molestie consequat, vel illum dolore eu feugiat nulla facilisis at vero eros et accumsan et iusto odio dignissim qui blandit praesent luptatum zzril delenit augue duis dolore te feugait nulla facilisi. | 16.11.2022 11:39
```

And it will render as follows:


Update maven deployment workflow to execute on micro-manager/NDTiffStorage only

This update will prevent the maven deployment workflow to execute on repo forks as that fails. If this works well, I can transfer that to the other repos as well

Nice! I had been doing this on my fork by going to the actions tab and disabling all, but this will be more precise and save the trouble of having to do that


any plans to allow searching for keys using regex etc?

my users may eventually end up having millions of records (possibly on sqlite) and I am not sure how efficient it'd be to traverse through all keys just to find some of them.

No plans but I would be open to any patch. It would need to look through all keys in localStorage but indexeddb and websql queries could be fast.
If you wanted to write a PR that would be great! :-)

tofumatt (Sent from mobile)

On 30 Oct 2015, at 12:18, siddo420<EMAIL_ADDRESS>wrote:
my users may eventually end up having millions of records (possibly on sqlite) and I am not sure how efficient it'd be to traverse through all keys just to find some of them.
—
Reply to this email directly or view it on GitHub.

@siddo420 The nicest solution for this would be for someone (I might take a stab at it) to implement an indexing solution on top of localForage.  It could really just be an in-memory map of the keys you have in localForage, perhaps with "indexed" properties being stored as well.  Traversing that object in memory would be much more efficient than searching with data persisted to disk.

Right now this seems pretty out-of-scope for localForage. An entire indexing solution would be heavyweight and not in the spirit of the simplistic nature of localForage.
I think I'll close this for now, but a PR would be welcome in the future.


I did not find it。

@Serendipity-hjn, dark mode isn't implemented yet, maybe it'll be available in future!

@Serendipity-hjn, dark mode isn't implemented yet, maybe it'll be available in future!

i'm working on it, it will implement soon!


Computer description changes to model_lookup_failed

Every couple of days we have ~4-5 machines that loose the description.
Eg. a computer that used to be MacBook Pro (15-inch, Early 2011)  becomes model_lookup_failed until we re-check the warranty status.
We should prevent updating the field when Apple servers are not responding

I think we should also decouple the warranty lookup from the model lookup.


Move serialization to CDP

Specification bases serialization logic on the JS internal slots. E.g. value has a [[DateValue]] internal slot.
In JS there is no way to implement this logic. Current BiDi implementation is based on checking the prototypes, which can lead to incorrect or unwanted results.
The only way to implement the serialization properly according to the spec is to move it to CDP level by adding a field bidiValue to the CDP Runtime.RemoteObject and a flag generateBiDiValue to the CDP Runtime.callFunctionOn method. On the CDP level there is an access to all the internals of the V8, and implementation can be done according to spec.

Done in #123


Rename repo and release on NPM

"polyfill" is taken https://www.npmjs.com/package/polyfill. But it would be nice to see this available as a npm module.

So it's been a while since I've updated this library, but I actually just started doing some new work on it today. My plan is to move the CSS parsing to the server side in a build step, and in that case I'll definitely want it to be available on npm.
Any suggestions for what to name it?

css-polyfill, css-next?

css-polyfiller

My plan is to move the CSS parsing to the server side in a build step [snip]

@philipwalton not sure you want this in all cases; there exist cases where you only want to polyfill certain properties on certain browsers and operating systems. Not sure how you would work that into a build step sanely.

+1


eeip.ru

@yasha4u You probably meant to add this file  lib/domains/ru/eeip.txt to add a domain eeip.ru to this repository. If so, please rename lib/domains/ru/eeip/eeip.txt to  lib/domains/ru/eeip.txt.
Also, please provide us with an URL of a page on the official website where an IT-related long-term (>1 year) course is offered by this university.

@yasha4u You might miss my previous comment. Please react.


Support Homeassistant Restart

First off, thanks for creating this software!
One thing that would help me a bit, if it would support the mqtt messages sent during startup of the platform.
https://www.home-assistant.io/docs/mqtt/birth_will/
I've got issues with my bluetooth devices, so I am keeping quite detailed track of the state of the airthing entity sensors, and on restart of homeassistant, they go unavailable for 15-20 min (depending on refresh interval).
I would be nice if the utility would simply detect that HA has restarted, and instantly publish its latest values.

Your suggestion is a good one and I have been thinking about how to best implement it. Monitoring the Home Assistant birth and last will messages in MQTT is one way, but that could be challenging because I do not currently store the values of the last sensor values received. However, while I am not an MQTT expert by any stretch I think using retained MQTT messages would achieve the same goal. This would be easy to implement, but I believe it would be best to delete those retained messages when the addon stops. I currently do not have any "cleanup" code so I would have to have a trigger for when the addon stops. Let me think about this a bit more and see what I can do.

I have released a new version that includes a new "retain" configuration option that may do the trick for you. It defaults to 'false', but please try setting it to true and see if it works for you. If you ever want to clear the retained values you can set it back to false and the addon will send the required messages to clear the value.

Strange I didnt get a notification of these messages, or the release, but I'll try to give it a test during the weekend!

Ok, time wasnt really on my side the past few days/weeks (baby and 3yr old at home :-) ),  so I never got around to testing this. However, there is another embarrasing issue, and that is that since I am not using hassio, I am actually using the repo https://github.com/mjmccans/airthings-mqtt-ha, and thats were I really should have created this ticket.
Any chance of "backporting" the logic to that repo?
Sorry about the confusion :-/

No issue at all, and I totally understand (I have three parasites / children of my own). This has actually been the kick in the pants I needed to reconcile the changes I have made to the addon with the non-addon repository. When you have a chance it would be great if you could check out the "dev" branch of the airthings-mqtt-ha repository. I have pulled across the changes made to the addon. Note that the config file format has changed, and is now in json instead of toml. If you pull the "dev" repository and run the script it should suggest a configuration file, and you can try changing the "mqtt_retain" value to "true". Please let me know if it works for you, or if you have any other issues. Thanks, and good luck with the kids!

Sorry for the non-existent feedback, but...you know...time..:-/ Anyway, I did try the concept with the retain flag, but I havent been able to thoroughly analyse the behavior in error scenarios. At least not enough to give quality feedback.
I do wonder though, since I had issues with my device once the battery got low, if there can be issues with the retain, if the container isnt able to acquire values from the device? What will be published then?

No problem at all. If the addon cannot get values from the device it should not publish anything to the mqtt broker, meaning that the retained value would continue to be the value shown in Home Assistant. However, please let me know if you do have a chance to do any testing and let me know if it works. Thank you.

But, thats just it, I dont want it to show the old value, since it makes it impossible to know that the service isn't able to fetch accurate values. If the code isnt able to get a valid value, I would personally want it to publish a bad value (or unavailable or similar so (maybe) it doesnt cause issues with statistics), so that I know that something is actually wrong.

Just as a good (or bad) example today. I've been having bluetooth issues again, ever since I updated to HA 2008.x and tried the updated bluetooth support (as well as updating to your 1.2 release that uses bleak and dbus).
But...I havent notices the issue. My radon counter has been looking fine at '1xx Bq/m3'.... until I noticed today, that this is because the airthings container isnt able to get any values, but the retain causes the old value to be displayed, instead of indicating an error.

I think I misunderstood your original ask and I see why the retain flag does not work well for you given the connectivity issues you have with your devices. Perhaps the best thing for your use case would be to set up an automation triggered on the homeassistant event "start" and then use the hassio.addon_restart service to restart the addon. If that works it would cause the addon to restart when Home Assistant restarts, thus causing the addon to try to get new values.

Unfortunately, I am not running hassio, but HA Container (I mixed up the repos as mentioned above).
But regardless of the HA restart issue, surely it cant be good that it cant be properly detected that the application isn't receiving good values?
A container health-check would be nice :-)

I totally forgot that you were not using the addon so I agree that my last suggestion would not work. I could add a health check to the docker container, but that would not help those not using a docker setup and is not really what docker health checks are for (in this instance the container is still working fine, it just cannot connect to a device). Would adding a new sensor value, such as boolean "failed" or "dead", that changes when there have been a certain number of failures to contact a device or a certain amount of time has gone by since the last successful connection? I was thinking that could be more helpful because it would work for everyone, and you could run automations or display warning (such as a "stale values" display) in your Home Assistant dashboard. Let me know what you think. If that would work I can look into implementing it, but I may not be able to do it right away given competing priorities. In the meantime you could also track one of the sensors that changes frequently, like temperature or co2, and issue a warning if that value does not change for a while.

A new sensor indicating "staleness" would be superb! :-) Then I can avoid my own hacks with Flask RESTFul endpoints for running various CLI commands and checking things :-)
Related to the issue about checking a value that changes often, I have wondered about that, that using last_updated is not really useful for these mqtt sensors. Is that a limitation of the mqtt sensors themselves in HA? At least the once created by the auto-discovery mechanism?
Since if I create a "manual" mqtt sensor, there's the  "force_update" that makes the last_updated work properly even if the value hasn't changed.


Evaluation scripts of multi-task tight-weight refineNet.

would you like to share the evaluation scripts of multi-task tight-weight refinenet?Thank you.

you can run validation as in the example here: https://github.com/DrSleep/DenseTorch/blob/master/examples/multitask/train.py#L83-L90

Would you provide a more detailed test.py script to evaluate the test set? Thank you

what do you mean by "a more detailed script"?
The provided example does both training and testing. If you comment out the training part (e.g, line 82), it will only run the testing part

Thank you for helping me solve this problem.


Scripts for building slim/fast images 19c native on ARM

The scripts allow to build slim/fast images using 19c official image for ARM, tested on Mac M1 procesor.
Description is at Oracle on ARM, Mac M1/M2 Docker images
Marcelo.

Thanks a lot for this PR, @marcelo-ochoa, but this repository only concerns itself with Oracle Database Free and not SE2 or EE, hence this PR cannot be accepted.


Listener state not listening [fully supported]

I'm thinking its because my term service doesnt match my windows version? I have looked everywhere and tried manual solutions multiple times to no avail, hoping someone here can help me out

Duplicate of https://github.com/stascorp/rdpwrap/issues/2390

Read from here https://t.me/rdpwrap/63551

Duplicate of https://github.com/stascorp/rdpwrap/issues/2359


Remove master branch

https://github.com/golang-templates/seed/pull/115 follow-up
kudos for @jizusun

#115 follow-up
kudos for @jizusun

Oh thank you sir ♥

#115 follow-up
kudos for @jizusun

Oh please think twice.
I'm not sure what will happen, when our downstream pull and merge from us, but didn't rename their default branch to main.
I just this will break our downstream maybe.

#115 follow-up
kudos for @jizusun

Oh please think twice.
I'm not sure what will happen, when our downstreams pull and merge from us but forget to rename their default branch to main.
Maybe this will break our downstream.

Bagdes will not work. Moreover build and codeql workflows will not work as expected. However changing the default branch even afterwards will fix it. It is not possible to support two main branches at once.


[3.0.0-beta1] generated _Table.getProperty does not put foreign key in ´´

    switch (columnName)  {
      case "`deposit`":  {
        return deposit;
      }
      case "tax_id":  {
        return tax_id;
      }
      case "productGroup_id":  {
        return productGroup_id;
      }
      case "`expandGroup`":  {
        return expandGroup;
      }
      default:  {
        throw new IllegalArgumentException("Invalid column name passed. Ensure you are calling the correct table's column");
      }

yes the tax_id and productGroup_id are the foreign keys in your table (it appears).

but productGroup_id is not quoted, that is why it goes to
throw new IllegalArgumentException("Invalid column name passed. Ensure you are calling the correct table's column");

Ooo now it makes sense

fixed in develop


"Read buffer does not match write buffer size" when change object detection model

Hi all,
when I change the model in mediapipe object detection gpu
it shows an exception as below
may I ask how to fix it?
thanks a lot

model is downloaded from TensorFlow Hub
https://tfhub.dev/tensorflow/lite-model/efficientdet/lite0/detection/default/1
I only modify BUILD file and object_detection_mobile_gpu.pbtxt

2021-03-11 19:21:38.851 13221-13245/? E/FrameProcessor: Mediapipe error:
com.google.mediapipe.framework.MediaPipeException: invalid argument: Graph has errors:
Calculator::Process() for node "TfLiteTensorsToDetectionsCalculator" failed: Read buffer does not match write buffer size.
at com.google.mediapipe.framework.Graph.nativeMovePacketToInputStream(Native Method)
at com.google.mediapipe.framework.Graph.addConsumablePacketToInputStream(Graph.java:360)
at com.google.mediapipe.components.FrameProcessor.onNewFrame(FrameProcessor.java:442)
at com.google.mediapipe.components.ExternalTextureConverter$RenderThread.renderNext(ExternalTextureConverter.java:364)
at com.google.mediapipe.components.ExternalTextureConverter$RenderThread.lambda$onFrameAvailable$0$ExternalTextureConverter$RenderThread(ExternalTextureConverter.java:309)
at com.google.mediapipe.components.ExternalTextureConverter$RenderThread$$Lambda$0.run(Unknown Source:4)
at android.os.Handler.handleCallback(Handler.java:883)
at android.os.Handler.dispatchMessage(Handler.java:100)
at android.os.Looper.loop(Looper.java:214)
at com.google.mediapipe.glutil.GlThread.run(GlThread.java:141)

@IvesHsu Please find the similar issue , this may resolve your issue

@sgowroji
thanks for reply
how to know if a model can use  GPU delegate or not?

Hi @fanzhanggoogle ,
do you have any suggestion?
thanks a lot

Hi, you can try the tflite benchmarking tool  first to make sure the model can be supported. It'll be difficult to debug in MediaPipe graph by just switching model. There's could multiple reasons why the model isn't working, e.g. ops in the model are supported by the GPU, e.t.c.


New version: Dummerle.Rare version 1.10.5

Pull request has been created with WinGet Automation :rocket:
Microsoft Reviewers: Open in CodeFlow

Hi @vedantmgoyal2009,
This manifest adds Apps and Featues entries that aren't present in previous PR versions. Should these entries be added to the previous versions also?


BOSH post deployments api

BOSH post deployments api returns back task and isn't a redirect to new url
https://bosh.io/docs/director-api-v1.html#post-deployment

Maybe I misunderstand, but I think it is indeed a redirect based on code and curling...
curl -k -vvvd @- --user admin:admin -H 'Content-Type: text/yaml' https://director:25555/deployments < sample.yml
*   Trying director...
* Connected to director (director) port 25555 (#0)
* TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
* Server certificate: *
* Server auth using Basic with user 'admin'
> POST /deployments HTTP/1.1
> Host: director:25555
> Authorization: Basic YWRtaW46YWRtaW4=
> User-Agent: curl/7.43.0
> Accept: */*
> Content-Type: text/yaml
> Content-Length: 880
>
* upload completely sent off: 880 out of 880 bytes
< HTTP/1.1 302 Moved Temporarily
< Server: nginx
< Date: Tue, 10 May 2016 23:51:31 GMT
< Content-Type: text/html;charset=utf-8
< Content-Length: 0
< Connection: keep-alive
< WWW-Authenticate: Basic realm="BOSH Director"
< Location: https://director/tasks/42
< X-XSS-Protection: 1; mode=block
< X-Content-Type-Options: nosniff
< X-Frame-Options: SAMEORIGIN
<
* Connection #0 to host director left intact

hmm weird.. let me check my client code again

closing. if this is an issue please open it in the cloudfoundry/bosh repo.


Missing V15 features.component_model in config

Missing V15 features.component_model in config.
Where can I find component_model, thanks for the tip.

Wasmtime-go currently does not provide component capabilities. Originally, I intended to add support for components to Wasmtime-go, but I found that the C-API also lacks support for components, which makes it challenging.
I'm uncertain about when the C-API will support components. Once it does, I can work on adding the corresponding functionality for Go.

Tyler Rockwood has made some progress on bringing the component model to the C API. Check out the discussion here .


关于运行train_rnn.py的问题

C:\Users\yhq.conda\envs\pytorch\python.exe D:/Dual-Path-RNN-Pytorch-master/Dual-Path-RNN-Pytorch-master/train_rnn.py
C:\Users\yhq.conda\envs\pytorch\lib\site-packages\torchaudio\extension\extension.py:14: UserWarning: torchaudio C++ extension is not available.
warnings.warn('torchaudio C++ extension is not available.')
Traceback (most recent call last):
File "D:/Dual-Path-RNN-Pytorch-master/Dual-Path-RNN-Pytorch-master/train_rnn.py", line 91, in
train()
File "D:/Dual-Path-RNN-Pytorch-master/Dual-Path-RNN-Pytorch-master/train_rnn.py", line 61, in train
opt = option.parse(args.opt)
File "D:\Dual-Path-RNN-Pytorch-master\Dual-Path-RNN-Pytorch-master\config\option.py", line 4, in parse
with open(opt_path, mode='r') as f:
TypeError: expected str, bytes or os.PathLike object, not NoneType
Process finished with exit code 1
请问一下出现这个错误怎么解决，或者说是哪方面出现了问题，求答复，感谢！

应该是未检测到opt_path的输入文件路径


Seen error message: "Another program has changed this wallet"

Operating System:win7 64
MultiBit Version:MultiBit 0.5.18
Steps to replicate the problem:Another program has changed this wallet. To avoid errors this MultiBit has stopped updates

This will occur if MultiBit detects that the wallet file has changed in size or time stamp from what it is expecting. You need to verify that you don't have another application making changes to this file.
See this article for the file locations: https://multibit.org/en/help/v0.5/help_troubleshooting.html

My wallet has tried several computers to try to recover it, but all the above error prompt! The time is right! I can not understand!

Even Close wallets suspended animation

0.5.19 will tackle this in #693.
Closing here.

I am having same issue - please advise
Existing wallet that has worked well until now for both send and receive - Using version 0.5.18 on mac os/x. All system and Java up to date.
needing to send funds to new Multibit HD - but everytime I open Multibit, it synchs then when I hit "New" for send - it stops with the error -Another program has changed this wallet"
Moved files to a clean new mac - same issue. Rebooted - ps -ax shows no other instnce of app or java running.
At this point I cant send or even export keys !!!!
Please help , desperate times here
Paul

This will be fixed in version 0.5.19 which we are in the final stages of testing at the moment.


Condition Zero World Texture error

Get a lot of errors from running this on cs:cz. All the right dependencies are installed:

No detail texture mapping file: maps/w_weaponbox_detail.txt
Mod_LoadBrushModel: models/zombiepanic/v100/items/w_weaponbox.mdl has wrong version number<PHONE_NUMBER> should be 30)

No detail texture mapping file: maps/lightcone_detail.txt
Mod_LoadBrushModel: models/zombiepanic/v100/lightcone.mdl has wrong version number<PHONE_NUMBER> should be 30)

Client world model is NULL
Client world model is NULL

Please, send me a list of installed plugins
P.S: Did you put models into the map folder?

It's running all off the defaulted plugins in zombie panic ini file, and the default amxmodx plugins. Sadly I can't list the amxx plugins since my console doesn't output anything (the panel I have uses scrds protocol, not hlds).
Models in the maps folder? I just dragged and dropped the resources from 1.3.0 into the appropriate folders

Did you install RegameDLL and ReAPI?

I've just downloaded czero server using steamcmd, installed rehlds, regamedll, reapi and the latest mod build from github, works without any issues. Try to make clean install, don't forget to install mp.dll to the czero/dlls folder

Did you install RegameDLL and ReAPI?

Yes, both were installed.

I've just downloaded czero server using steamcmd, installed rehlds, regamedll, reapi and the latest mod build from github, works without any issues.
Try to make a clean install, don't forget to install mp.dll to the czero/dlls folder.

I'll try this again. May be related to https://github.com/ValveSoftware/halflife/issues/74

This may be a problem with the downloaded archive, try to download it again. If that doesn't work, try downloading using a different browser or extract it using a different extractor.


add @ivancorrales as a  CODEOWNER

Is this a new chart
What this PR does / why we need it:
Which issue this PR fixes
(optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged)

fixes #

Special notes for your reviewer:
The purpose of this PR is being added as a CODEOWNER
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[ ] Chart Version bumped
[ ] Variables are documented in the README.md
[ ] Title of the PR starts with chart name (e.g. [mychartname])

We could also apply the same change to all other charts.
I also see this line in the file:
https://github.com/newrelic/helm-charts/blob/96951d2c789449878aec55f9dc4bd3305b054cf4/CODEOWNERS#L4
Could you investigate if this is still true? Seems like a bit painful to have to list all the subfolders in the file

From the docs I see the following:
# These owners will be the default owners for everything in
# the repo. Unless a later match takes precedence,
# @global-owner1 and @global-owner2 will be requested for
# review when someone opens a pull request.
*       @global-owner1 @global-owner2
[...]
# In this example, @doctocat owns any files in the build/logs
# directory at the root of the repository and any of its
# subdirectories.
/build/logs/ @doctocat

So to me it would seem we could get rid of the rest of the lines that mean "coreint" and keep just the exceptions. WDYT?