v3.0.0 Roadmap

Overview
v3.0.0 (Gluon) is going to be a step in a different direction from Fermion, as it will be built from the ground up, with certain differences in focus and scope. Many breaking changes will be present, however some core concepts and ideas will be staying the same.
Some of the key features that will be present in the new Gluon branch are support for CSS3 variables, which will impact most aspects of the current codebase, possible support for CSS3 grid, additional components and replacement components, as well as many UI/UX improvements, which will be the focus of the next major release. To meet these goals, the framework will be rebuilt with a focus on better aesthetics, easier customization and better user experience, even if this impacts adoption rates, due to the discontinuation of support for legacy and proxy browsers, as Gluon will be built with a focus on the future. There is also the slight possibility that Gluon will be a bit larger than 7KB in certain of its flavors, however there will always be some light flavor meeting the core goal of 7KB.
That being said, the current Fermion branch will be supported actively, with fixes and possibly updates rolling out regularly, while Gluon is in development. After Gluon is released (estimated release date is Q1 2018 for now - this is subject to change), Fermion will be considered a legacy branch, but it will still be supported and its documentation will be available for a long time. On a side note, if you are reading this and use a Fermion build in production, make sure to point to a link with v2.x.x in its name and not the default one which loads from the last commit of the master branch.
Finally, the Neutrino branch will not be supported any further, as it is hereafter considered a legacy version.
Gluon - List of changes, updates, features
Note that all of this is subject to change and that it is very importan to get as much feedback as possible to provide the best possible experience for everyone. The lists below will be populated as progress is being made in each module.

Updated core module, featuring less legacy fixes, along with restyling of multiple elements.
A cleaner, leaner and legacy-free flexbox-based grid module. There might be something like a tile system as well, utilizing CSS grid.
Better navigation elements, with focus on mobile usability.
Clean rebuild of input_control to allow for easier customization and better user experience.
Rebuilt table module, utilizing flexbox and infinitely scrollable tables for a better user experience.
Improved card layout, allowing for more versatile layouts.
Rebuilt tab systems or even removal of tabs in favor of a better, easier-to-use system.
Extended contextual module with more components that are easier to use and customize.
Improved progress module, mainly removing legacy support and slightly improving on the aesthetics of components.
Updated utility module with easier to use components and new modifiers.
Javascript examples and support scripting, allowing users to get more bang for their buck, if they need in specific components (e.g. table sorting).
Small icon pack (20 - 50 essential icons) for a better UI/UX experience.
Improved and updated tutorials.
Utilization of CSS variables.
Tools that allow for a flavor build on-the-fly, altering CSS variables in certain parts of the framework.
Website update to turn the documentation into a progressive web app, allowing users to access it offline.

Compatibility
As stated in the Overview section, the Gluon update will be a brand new framework, meaning a lot of the existing conventions and semantics will be changed. If you are using a previous version of Fermion, remember to point to a version-specific link.
Migrating to Gluon might take a little bit of effort, but I will try to make it as smooth as possible, by providing guidelines and help every step of the way.
Release date
It's too soon to tell, but the aim is to release sometime in the first quarter of 2018.

I definitely like the idea of a small icon pack. I'm currently using a handful of inline SVGs. It would be nice to have a little pack of them from a project I know and trust. I like all the other bullet points also, but the icons popped out to me.

@Raindeer44, thanks for your support. At this time I am looking into SVG icon packs whose licenses are compatible, so that I can figure out what can be added to the framework. I was thinking about contacting @colebemis, creator of Feather, whose icon pack I have used a lot in the past and seems (at least to me) to fit the aesthetic of the framework. However, I am not yet set on any icon pack, so if you have any other suggestions, please comment below, so I can check them out.

Feather is a great icon pack and I would love to see icons from it integrated into mini.css. Are icons going to be their own module or part of something like the utility module?

@mariastervic I have not thought about it yet, but the plan is to add accessibility and improve UX using icons in forms' input fields etc. The icons themselves will be class-based with inlined svg's in their code, so that they can be added using a <span> element or something similar. The most sensible thing would be to make them part of the contextual or utility module. That, however, is up to the community to decide, as I am not yet set on anything.
On a side note, I will be starting work on the framework's core module possibly even today, after having debated a lot of the upcoming changes with myself. Expect screenshots and updates to this issue as work on the framework progresses. Feedback is essential to the final product, so please pitch in whenever you can. Thanks!

I have already contacted the developer of Feather and I am very excited to announce that some of its icons will make it into the next major release of the framework.
As far as module structure goes:

An icons module would be an extra step in the build and documentation process, which might not be a terrible idea, I am just trying to keep the documentation and code structure consistent and easy-to-use. The counter-argument would be that hiding an icon set in another module can be unintuitive and confusing.
contextual could be an option. The way I see it, icons are used for accessibility, clarification and improved user experience. Thus their role is to provide context to some element or piece of content.
utility is the least favored option as of now, as it is basically where anything that doesn't fit elsewhere goes. It could make some sense, but I would rather use one of the other two options mentioned above.

Update
The core module is already halfway through the baking process. If everything goes according to plan (you know it won't), I will have it up and running soon, meaning I can actually focus my efforts on building the first demos and a draft landing page for Gluon so that you guys can preview it.

I really like what I see in the Sass code. CSS variables seem to be complementing the style-agnostic aspect of the framework, plus I haven't seen any other framework utilize them yet. Really looking forward to the alpha release. Keep up the good work!

@mariastervic Indeed they do and they make it so much easier to create tooling that will allow for easy customization before downloading. I expect flavor-making to be really easy in the future, using the CSS variable aspect of the codebase, especially if I manage to create the proper systems for developers.
As far as I know, no other UI kit uses CSS variables at the moment, so mini.css will be the pioneer really, if I manage to release Gluon before any other framework implements this functionality. Hope it's the right choice, as it made me abandon a lot of legacy code and browser support is slightly on the low side as of now.

Update
The new website is (almost) upon us. I just redesigned the splash screen and logo of the framework for Gluon and I am pretty excited to share it with you guys:

Image credit: Christopher Gower
Let me know what you think!

I definitely like the logo and the splash screen! My only thought with the splash screen is that the second half of "framework" has a dark background. How would it look if that line were moved down a tish so it fits in the lighter area just below where it is now?

I noticed that, too. The deisgn is not yet finalized, so some changes will be made, I'm just trying to get a rough sketch down for now. Accessibility and ease-of-use (ie legibility) are always top-priority, so I will do something about this for sure. 😉

Sounds good! Other than that (admittedly minor) thought, I love it!

Update
Oddly enough, everything is still on schedule, so the first alpha of Gluon might arrive around the end of this month or the first few days of November. I'm pretty happy with the resulting CSS so far and the code is a lot easier to maintain, tweak and customize as far as I can tell.
Apart from that I have to share the great news that, even though the code is 90% ready as of now and some things are missing, the new compiled CSS file is actually about 10 bytes leaner than the original equivalent from the Fermion branch, which I definitely did not expect. If this trend continues, the only thing bloating Gluon up a little bit will be the icon set, which is totally fine and justified.
The website is coming along nicely, I will try to get started on the documentation so that the two modules that are complete are mostly documented on release of the alpha, allowing me to get some feedback about it all.
Finally, it's reasonably probable that a couple of elements from other modules might make it into the release, such as a <header> element and a couple of <button>s and <mark>s, just because I will need them for the website, so I might as well build prototypes for them and see how they fare in the wild from day one of the alpha.
Stay tuned for updates and thanks a lot for all the feedback and ideas! 👍

Browsing through the code of the Grid module, I can tell that it's looking far more appealing to deal with than before. Extra points for allowing extra breakpoints using the mixin, this will come in handy.

Update
The new website and docs are coming along nicely, altough it seems like the deadline for v3.0.0-alpha.1 will be pushed back by a week or two for two main reasons:

I want to take some extra time to polish a few of the existing components and make sure everything in core and grid works as expected. Some styles are missing and a few of the currently styled elements are unfinished. I will also be working on a few parts from other modules, such as buttons and some navigational elements, because I need them for the website to function properly, so I might as well build them already and improve them later on. Thus, expect button, .button and probably header, nav and footer to ship with this release.
I am going to build the new Docs using React and react-static, which will ensure the website is as well-optimized as possible and packs a lot of functionality. However, there is currently a slight hiccup with their code (see #97 in react-static), which is sort of making me have to wait for a fix for the problem to fully utilize the static rendering. As of now, I am working on some of the data structures and parts of the Docs, but I need to be able to actually test the whole thing to release the new website to the world.

I'm really sorry about the delay, but I want the Gluon alpha to launch as smoothly as possible, so it's probably for the best. Stay tuned for updates!

Why not build the site with a static site generator?
https://www.staticgen.com/ (I'm using Hexo, which is nice and simple)
Having seen the current doc, not sure you need a framework (client or server) on top of this.
But that's only a suggestion :)

@tomap The current doc is usable, but maintenance is a huge pain. I was planning on using React (and Redux quite possibly) to allow all of the documentation to be stored in JSON files, so that it can be easily altered and maintained. Most of the documentation follows a specific pattern, so creating a reusable React component seems like a very practical way of separating the data and presentation, so that the documentation can be eventually duplicated in the wiki and from the wiki (there are plans for that). Also, I am planning to implement a search bar into the new docs to allow everyone to find what they need without navigating through menus.
To be honest, I am not a big React fan, as it's pretty heavy, but I think it would be a decent enough fit for the new doc pages and will allow more people to help with the documentation in the long run.

Update
I have just completed scraping the current Fermion documentation and got myself some data to start working with towards the new docs for Gluon. If everything goes according to plan, I should have most of the work done by the end of this week.

Shipping 5 modules sounds more reasonable than just 2. The alpha will have everything one needs to set up a website already.

Announcement: External Modules
It's been a long time coming, so it might as well be coming in Gluon. External Modules will now be a thing. Certain components that are not regularly used or that fit a very specific site type will be moved to external packages, allowing their maintenance to be easier and people who do not need them to skip them by default. See #115 for more details. The .switch, .tabs and customized select will not be making it into Gluon, at least for now. The target of the main framework is to provide the elements and components that 95% of the users need 100% of the time.
Apart from that, the framework is coming along nicely, navigation, core and grid are complete, input_control is missing checkbox and radio elements and card is going to be implemented tomorrow (I don't expect any problems). The documentation will be the top priority immediately after these are implemented, so expect me to need 7-10 days until the alpha is released with about half of the components. Also, expect card and grid to be merged into a layout module. card is dependent on grid anyways, so I might as well merge it into grid to make sure that the one is not included without the other. Also, a lot of layouts use .card elements, so it would be nice to have them as part of the grid in that sense. Thank yoou for all your patience and the feedback!

I think the new version is coming along nicely. Combining cards and the grid system seems like a great idea, provided that the cards are dependent on the grid already. As far as the switches and tabs go, I haven't used them almost at all, so I don't really mind them going to make space for other things. Can't wait to test everything out!

Icon selection

After some careful consideration, I came up with a 20-icon set draft from feather that is pretty much all-purpose and should be useful to the majority of the framework's users. I'm open to expanding the icon set further, adding another 10 icons or so to accommodate as many people's needs as possible. Please tell me what you guys think of the selection and which other icons you would like to see added in the icon set.

I like the selection! It has all the icons I can think of most users needing in most situations. I like the design (I like feather), and I can see this fitting into the framework. What do you think about adding a couple of the common social icons like for Twitter, Facebook, and a select few others?
I think mention of Feather should also be in the documentation with these so people know where to get more icons like them (for example, if I want a GitHub logo or something).

@Raindeer44 I will definitely mention Feather. I love that icon set and I want to expose as many people as possible to it, so I will link to it and maybe even add a custom banner in the documentation to make it abundantly clear that it's not my work, but another open source project I am using to improve the framework.
Social icons are a little bit of a mixed bag, as they will take up some extra space and I will probably need to choose a few, which will lead to arguments like why did you add Facebook but not [insert social media x]. I might do this, but I think a simple share icon works for many situations.
Another plan, which I will definetly get on board with eventually is to make a little tool that will not be part of the framework, just part of the docs, that people can use to customize their icon set. Provided that people have different needs and that using svgs in background limits color customization, this could be a lifesaver for the icon module, as people will have a chance to pick their own set and get the colors they want for individual icons. It's not even very difficult to implement, so I will try to get it started before the second alpha release.
On a side note, I am currently using two icons from Feather for the navigation drawer component, but I will scrap them to use Unicode characters. The main reason for this is that I want everything except for the icon set itself to be fully customizable in terms of colors, using CSS variables and this is simply impossible in background svgs (as far as I know at least).

That all sounds great! I think that tool for customizing icons would absolutely solve the need for social icons, especially if it gave access to the entire arsenal of Feather. Maybe leave the set you mentioned earlier as default (it's a strong set for default), then make them customizable like choosing flavors. Awesome idea!

Update
The alpha release is coming really soon. The docs seem to be taking too long, so if anyone wants to test the upcoming Gluon release, you should be able to grab the mini-default.css compiled flavor file and play around with it. I made sure that most :bug:s were squashed before posting this announcement, so expect pretty much half of the things to break within the first day (everybody knows that as soon as I tell people to use it, it breaks). Post your feedback in this issue, let me know what you think.
P.S: If anyone has a better idea on how to name the colored card section variant (currently .special), please let me know. It's a dreadful name, but I seem to have run out of ideas at the moment. This name is not final most likely, someone will figure out a better title!

v3.0.0-alpha.1
After a significant delay, here it is! Check out the live documentation and website and let me know what you think!
There is more work being done behind the scenes and a lot of stuff being added and evaluated, but it might be a little while until the next alpha is out. The current plan is to release one more alpha with one or two important modules in it (probably contextual and table) and then move to a beta phase, which will release with pretty much everything afterwards. After a couple of beta releases, I will rebase the master branch and use Gluon as the stable branch. This is still a long way down the road and I'm pretty sure a ton of bugs will pop up everywhere, but this what alphas are for!

I like the new site a lot. It looks a lot more like most documentation websites I have seen before and the search is a great addition.
So far I have encountered a few problems when combining headers and grids after testing the alpha for about an hour. I'll try and understand what might be wrong there, but I think that columns in the header need to be styled separately from normal buttons. Fluid columns work well so far, but it seems that columns with preset width sometimes exceed the container. This might be a padding issue as far as I understand it or a flexines problem.
On the subject of the icon set, get rid of the X, add the telephone like you said and you're good to go. Most of these icons would work for a lot of designs and websites, so I guess you don't need more than that. You could also drop the menu icon for something more useful, as you already use an icon in your drawer component, so this one is pretty much redundant.

Thanks @Zorba1987, the whole point of the new website was to provide better UX for devs, while keeping it simple and all in one place.
Headers and grids have given me some trouble, too. I could use a helping hand with those, as they are really a mindbender to me at times and I have a bunch of things I am working on in the meantime. These bugs will be ironed out before the beta release one way or another.
Good point on the icons, both the X and menu have no particular use-case except for the ones I have already covered with Unicode symbols. I'll probably find a replacement for menu and I think it should all be good to go afterwards. Icons are still a little bit away, but the icon set is pretty much decided already, so there's one less concern for me.
Update
I just started working on the contextual, progress, table trifecta (contextual is first) today. If all goes well, contextual and progress should be done by the end of next week, then I'll take a break for the holidays etc. and get table and documentation done until mid-January. No promises, as things tend to slow down seemingly at random, because other responsibilities get in the way, but the sure thing is that the next alpha will contain all three of these modules.

Update (this is a weekly thing nowadays)
The contextual module is coming along nicely, all the previous components are already written and I will document them over the course of the next few days. I will also take some time to move the old vertical version of tabs into the contextual module as a spoiler component (name not set yet), so that I can eliminate the extra module and combine the vertical tab component into it. The old-school tab system will be an external module and examples will be provided to allow people to build a tab-based layout, utilizing some Javascript for better results.
After contextual is done, I will jump into coding the progress module, as it is probably the tiniest one and the one that requires the fewest changes and little work in general. Bear in mind that there will probably be some stylistic changes to the module's components.
Last thing before the next alpha is the table module, which could take a little while to work on, as there are far too many hacks in that module and a few things need to be clarified. Apart from that, it is pretty important that the table styling is modernized. Expect this module to be complete by mid-January, just in time for the launch of the next alpha version.
Tools, such as the promised flavor tool, will be pushed back to the beta release most likely, but I will try to get working Codepen links for code snippets from the documentation. You can also expect some examples that might involve Javascript (i.e. responsive tooltips etc.) under the Best practices sections of components (just a few basic ones should do the trick, I think).
Finally, I will try to troubleshoot any bugs I find and clean up the code before this alpha, so that most of the framework is up and running by mid-January, missing only icons, UX changes and tooling.

Update
These past two weeks have been pretty crazy, due to me working on 30 seconds of code and taking a short vacation. However, I'm starting to have more spare time to work on the framework, so I should resume working on the contextual module and then the progress module, as promised. If everything goes well, both modules should be done by the end of next week and I might have managed to put some time into the table module.
What this means for the next alpha release is that there might be a short delay (a week or two), so expect the next alpha to ship around mid-January to late-January, at which point it will have what was promised previously. I understand that this delay is sub-optimal, but the alternative (rushing through these updates and releasing on time) is even worse as I do not want to ship a broken product. That being said, I'm doing my best to tackle as many issues as possible and keep the quality of code and documentation high.
I'm really sorry that I got carried away and had so much work on my other project, but I promise to deliver exactly what I promised. The contextual module should be fully documented today and I will start working on the rest of the modules for this alpha release as soon as I can and as much as I can. Stay tuned for more information and updates!

I am a novice web builder I do it as a hobby.  What I’m trying to say is, i don’t speak the lingo.  All I can do is try to explain what is occurring for me in hopes this helps you solve any problems.
I’m reading the documentation and noticed very quickly the page not flowing smoothly on my iPhone 8 Plus nor are they loading fully.  While I try to scroll down to veiw the rest of the article the page will not show also, I start to scroll back to the top and the page sticks.  I have to repeatedly touch and retouch the screen to gain at most time just a small amount of movement.  Also, the side bar is lagging and choppy during the slide in and out.
Keep up the good work.
I am using this framework on a new site.

Update (the toolset of a web developer)
It's been a little while and I have been working on a ton of other projects, while I also finally got a day job. The last piece left over before the next version is released is to add the flavor and icon tools. I am going to set a schedule for myself and work on them over the course of this month, so that we can hope for a release around early April (Easter holiday, should be a good time to debug any left over problems and iron out any issues there might be). Hopefully, everything will go smoothly and you will hear from me again very soon (probably next week). Thank you all for you patience, more goodies are coming and they are gonna be pretty cool if everything goes according to plan!

Been a little while (again)
After a prolonged absence from the project, I am happy to announce that work on the flavor tool has already begun. There's a rough draft ready for the whole of the flavor tool, but so far only the first module's inputs have been added to the form. I hope that the tool (and subsequently the whole of Gluon) will be ready for release sometime this month. Sorry for the delay, but other things got in the way and I didn't want to deliver a half-baked product in the end.
As an added bonus, here's what a flavor's variables will include and a rough draft of what I'm planning to do with them:
var flavorData = {
  core: {
    baseRootFontSize: 16,         // in px
    baseLineHeight: 1.5,          // unitless
    foreColor: '#111',
    backColor: '#f8f8f8',
    secondaryForeColor: '#444',
    secondaryBackColor: '#f0f0f0',
    borderColor: '#aaa',
    secondaryBorderColor: '#ddd',
    universalMargin: 0.5,         // in rem
    universalPadding: 0.5,        // in rem
    universalBorderRadius: 0.125, // in rem
    universalBoxShadow: 0,        // uses presets
    headingLineHeight: 1.2,       // unitless
    headingRatio: 1.19,           // unitless
    headingFontWeight: 500,       // unitless (weight)
    subheadingFontSize: 0.75,     // in em
    subheadingTopMargin: -0.25,   // in rem
    smallFontSize: 0.75,          // in em
    boldFontWeight: 700,          // unitless (weight)
    horizontalRuleLineHeight: 1.25, // in em
    blockquoteSidebarColor: '#f57c00',
    blockquoteQuoationSize: 3,    // in rem
    blockquoteCiteSize: 0.75,     // in rem
    codeFontSize: 0.85,           // in em
    preSidebarColor: '#1565c0',
    supTop: -0.5,                 // in em
    subBottom: -0.25,             // in em
    aLinkColor: '#0277bd',
    aVisitedColor: '#01579b',
    mobileBreakpoint: 768,        // in px, generally needed in other modules
    largeScreenBreakpoint: 1280,  // in px, generally needed in other modules
  },
  // Also needs to build on top of mixins
  layout: {
    enabled: true,
    gridColumnCount: 12,          // unitless (count)
    gridMediumBreakpoint: 768,    // in px, auto-ties to mobileBreakpoint
    gridLargeBreakpoint: 1280,    // in px, auto-ties to largeScreenBreakpoint
    cardNormalWidth: 320,         // in px
    cardSectionMediaHeight: 200,  // in px
    cardForeColor: '#111',        // Tied to foreColor, auto-updates if defaulted
    cardBackColor: '#f8f8f8',     // Tied to backColor, auto-updates if defaulted
    cardBorderColor: '#ddd',      // Tied to secondaryBorderColor, auto-updates
  },
  // Also needs to build on top of mixins
  inputControl: {
    enabled: true,
    formBackColor: '#f0f0f0',     // Tied to secondaryBackColor, auto-updates
    formForeColor: '#111',        // Tied to foreColor, auto-updates
    formBorderCoor: '#ddd',       // Tied to secondaryBorderColor, auto-updates
    inputBackColor: '#f8f8f8',    // Tied to backColor, auto-updates
    inputForeColor: '#111',       // Tied to foreColor, auto-updates
    inputBorderColor: '#ddd',     // Tied to secondaryBorderColor, auto-updates
    inputFocusColor: '#0288d1',
    inputInvalidColor: '#d32f2f',
    buttonBackColor: '#e2e2e2',
    buttonForeColor: '#212121',
    buttonHoverBackColor: '#dcdcdc',
    buttonBorderColor: 'transparent',
    buttonHoverBorderColor: 'transparent',
    buttonGroupBorderColor: 'rgba(124,124,124,0.54)', // Probably needs a decent control
  },
  navigation: {
    enabled: true,
    headerHeight: 3.1875,         // in rem, probably auto-calculate from line heights
    headerBackColor: '#f8f8f8',   // Tied to backColor, auto-updates
    headerForeColor: '#444',      // Tied to secondaryForeColor, auto-updates
    headerHoverBackColor: '#f0f0f0',  // Tied to secondaryBackColor, auto-updates
    headerBorderColor: '#ddd',    // Tied to secondaryBorderColor, auto-updates
    headerLogoFontSize: 1.75,     // in rem
    navBackColor: '#f8f8f8',      // Tied to backColor, auto-updates
    navForeColor: '#444',         // Tied to secondaryForeColor, auto-updates
    navHoverBackColor: '#f0f0f0', // Tied to secondaryBackColor, auto-updates
    navBorderColor: '#ddd',       // Tied to secondaryBorderColor, auto-updates
    navLinkColor: '#0277bd',      // Tied to aLinkColor, auto-updates
    navSublinkDepth: 2,           // unitless (count)
    footerBackColor: '#f8f8f8',   // Tied to backColor, auto-updates
    footerForeColor: '#444',      // Tied to secondaryForeColor, auto-updates
    footerBorderColor: '#ddd',    // Tied to secondaryBorderColor, auto-updates
    footerLinkColor: '#0277bd',   // Tied to aLinkColor, auto-updates
    footerFontSize: 0.875,        // in rem
    drawerBackColor: '#f8f8f8',   // Tied to backColor, auto-updates
    drawerHoverBackColor: '#f0f0f0',  // Tied to secondaryBackColor, auto-updates
    drawerBorderColor: '#ddd',    // Tied to secondaryBorderColor, auto-updates
    drawerCloseColor: '#444',     // Tied to secondaryForeColor, auto-updates
    drawerToggleFontSize: 1.5,    // in em
    drawerWidth: 320,             // in px
    drawerCloseSize: 2,           // in rem
  },
  table: {
    enabled: true,
    maxHeight: 400,               // in px
    captionFontSize: 1.5,         // in rem
    mobileCardLabel: 'data-label',
    mobileLabelFontWeight: 600,   // unitless (weight),
    borderColor: '#aaa',          // Tied to borderColor, auto-updates
    borderSeparatorColor: '#666',
    thBackColor: '#e6e6e6',
    thForeColor: '#111',          // Tied to foreColor, auto-updates
    tdBackColor: '#f8f8f8',       // Tied to backColor, auto-updates
    tdForeColor: '#111',          // Tied to foreColor, auto-updates
    tdAltBackColor: '#eee',
    tdHoverBackColor: '#90caf9',
  },
  // Also needs to build on top of mixins
  contextual: {
    enabled: true,
    markBackColor: '#0277bd',
    markForeColor: '#fafafa',
    markFontSize: 0.95,           // in em
    markLineHeight: 1,            // in em
    toastBackColor: '#424242',
    toastForeColor: '#fafafa',
    tooltipBackColor: '#212121',
    tooltipForeColor: '#fafafa',
    modalOverlayColor: 'rgba(0, 0, 0, 0.45)', // Probably needs a decent control
    modalCloseColor: '#444',      // Tied to secondaryForeColor, auto-updates
    modalCloseHoverBackColor: '#f0f0f0', // Tied to secondaryBackColor, auto-updates
    modalCloseSize: 1.75,         // in rem
    collapseLabelHeight: 1.5,     // in rem
    collapseContentMaxHeight: 400, // in px
    collapseContentBackColor: '#fafafa',
    collapseLabelBackColor: '#e8e8e8',
    collapseLabelForeColor: '#212121',
    collapseLabelHoverBackColor: '#f0f0f0', // Tied to secondaryBackColor, auto-updates
    collapseSelectedLabelBackColor: '#ececec',
    collapseBorderColor: '#ddd',  // Tied to secondaryBorderColor, auto-updates
    collapseSelectedLabelBorderColor: '#0277bd', // Tied to aLinkColor, auto-updates
  },
  // Also needs to build on top of mixins
  progress: {
    enabled: true,
    backColor: '#ddd',            // Tied to secondaryBorderColor, auto-updates
    foreColor: '#555',
    height: 0.75,                 // in rem
    maxValue: 1000,               // unitless (count),
    inlineWidth: 60,              // percentage
    spinnerDonutSize: 1.25,       // in rem
    spinnerDonutBorderThickness: 0.25, // in rem
    spinnerDonutBackColor: '#ddd', // Tied to progress.backColor, auto-updates
    spinnerDonutForeColor: '#555', // Tied to progress.foreColor, auto-updates
  },
  icon: {
    enabled: true,
  },
  utility: {
    enabled: true,
    genericBorderColor: 'rgba(0, 0, 0, 0.3)', // Probably needs a decent control
    genericBoxShadowColor: 'rgba(0, 0, 0, 0.125)', // Probably needs a decent control
  }
}

I'm excited for the flavor tool! I'm using mini on a project at work, and the only customization I really have to make is colors (to match our 'brand'), which right now means I'm sort of making my own flavor, and this tool looks like it will make that task much nicer!

Flavor tool progress
Hey, everyone! I'm still working on the flavor tool. So far, the structure of most of the form controls for it are complete, except dynamic elements for mixins. I have started hooking up the forms to variables and generating the Sass code, later I will have to compile that code into a flavor file and then produce the final CSS file. So far core, icon and module are fully hooked up and I am hoping to get at least another 1-2 modules done until Monday. Hopefully, I won't be slowed down by work, so I expect to have most modules (except dynamic fields/mixins) hooked up to variables and Sass generation by the end of next week.

Almost there
Flavor tool is ready to rock. It generates the .zip file with all of the framework, flavor file and compiled CSS files. If everything goes according to plan, I will polish everything up, add some missing flavors and release during this week. After the longest time, Gluon will be released! 😄

After almsot 8 months in the making, Gluon has been finally released. Hope you'll enjoy using it in your projects! 😃

Fermion will be considered a legacy branch, but it will still be supported and its documentation will be available for a long time.
Maybe this is something obvious I'm missing, but how do we get to the Fermion documentation now? I am unable to find it.

@andrewharris-workstate The docs are still available at https://minicss.org/v2/.


feat: let LSP work will with code generated by macros

Description
Problem
Code generated by macros (aztec_macros) ends up overlapping real code. The reason this happens is that, for example, this code is injected into a program:
let serialized_note = ...

The program above ends up with spans that are relative to that small snippet (for example serialized_note ends up in bytes  4..=19) and that might overlap some code that happens to be in that position in the same file.
Summary
In this PR we clear (set to a default of 0..0) any spans that happen in generated code, if running in LSP mode. The result is that generated code doesn't overlap anymore with real code, and references, inlay hints, go to definition, etc., start working fine.
There's no need to stop showing inlay hints inside contracts, as there's no generated code that interferes there.
Additional Context
Maybe in the near future aztec macros will not be needed anymore. Implementing emptying spans is straight-forward so until that happens I think it might be worth having these LSP features work well when macros exist.
Documentation
Check one:

[x] No documentation needed.
[ ] Documentation included in this PR.
[ ] [For Experimental Features] Documentation to be submitted in a separate PR.

PR Checklist*

[x] I have tested the changes locally.
[x] I have formatted the changes with Prettier and/or cargo fmt on default settings.

Can you elaborate on the reason to pass empty_spans everywhere instead of just always issuing empty spans?

Can you elaborate on the reason to pass empty_spans everywhere instead of just always issuing empty spans?
I'm assuming we're worried about tracking callstacks within generated code for the purpose of building flamegraphs?

Not just flamegraphs I believe, as I remember the aztec team getting errors at the default span at the top of a file which could lead to confusion for users.

Can you elaborate on the reason to pass empty_spans everywhere instead of just always issuing empty spans?

I thought about that too, maybe an option to pass to the parser to produce empty spans instead of regular spans... but then we'd have to revert those changes if we stopped relying on these macros. With this way we'd just delete the unused code. I think I didn't want to make the parsing code more complex.


[ADAP-639] [CT-2708] [Feature] Add rows affected to AdapterResponse → run_results.json

Is this your first time submitting a feature request?

[X] I have read the expectations for open source contributors
[X] I have searched the existing issues, and I could not find an existing issue for this feature
[X] I am requesting a straightforward extension of existing dbt functionality, rather than a Big Idea better suited to a discussion

Describe the feature
I noticed that in the differents versions of json template of run_results the "rows_affected" field was in there. I wonder if you tell me that the field come back or the best was to get it? It is a very important field for the controls in our models.
Thanks.
Describe alternatives you've considered
No response
Who will this benefit?
No response
Are you interested in contributing this feature?
No response
Anything else?
No response

thanks @dbeatty10
In fact I thought that this field was populate in any adapater but according to what you say it is not so.
I'll wait for the respose by dbt-labs.
Thanks you so much.

We have another (older) issue for this!

https://github.com/dbt-labs/dbt-spark/issues/497

Thanks @jtcohen6
BTW, It had been any advance with this issue? Do you know if it is possible get this field for Spark?

It seems unlikely.
It might be supported via ODBC: https://github.com/dbt-labs/dbt-spark/issues/142 / https://github.com/dbt-labs/dbt-spark/issues/497#issuecomment-1266302906.
But it looks like it's explicitly not supported by PyHive (always returns -1): https://github.com/dbt-labs/dbt-spark/issues/497#issuecomment-1574885586 links here


dm online validation could be broken when binlog reader reconnect when not using gtid

What did you do?
binlog reader for dm online validation has DisableRetrySync set to true because https://github.com/pingcap/tiflow/blob/master/dm/syncer/util.go#L213, this could lead to Err: table id xxx: invalid table id, no corresponding table map event error, if the connection is broken in the middle of a transaction.
when this happens, the online validation will stuck forever
What did you expect to see?
the online validation could handle binlog broken and continue
What did you see instead?
assume this is the binlog
SET TIMESTAMP=1676594544/*!*/;
BEGIN
/*!*/;
# at 38845389
#230217  0:42:24 server id 900099330  end_log_pos 38845467 CRC32 0xf6701849     Table_map: `xxx`.`xxx` mapped to number 140
# at 38845467
#230217  0:42:24 server id 900099330  end_log_pos 38845538 CRC32 0x0357e7c9     Delete_rows: table id 140 flags: STMT_END_F

...

#230217  0:42:24 server id 900099330  end_log_pos 38845569 CRC32 0xeb59e74c     Xid =<PHONE_NUMBER>83
COMMIT/*!*/;

then in dm-worker log
[2023/02/18 02:58:10.907 +00:00] [ERROR] [streamer_controller.go:367] ["meet error when get binlog event"] [task=tidbmigration-sample-task] [unit="continuous validator"] [error="Header &replication.EventHeader{Timestamp:0x63eecd70, EventType:0x20, ServerID:0x35a66d02, EventSize:0x47, LogPos:0x250bc62, Flags:0x0}, Data \"....\", Err: table id 140: invalid table id, no corresponding table map event"] [errorVerbose="Header &replication.EventHeader{Timestamp:0x63eecd70, EventType:0x20, ServerID:0x35a66d02, EventSize:0x47, LogPos:0x250bc62, Flags:0x0}, Data \"\....\", Err: table id 140: invalid table id, no corresponding table map event\ngithub.com/pingcap/errors.AddStack\n\tgithub.com/pingcap/errors@v0.11.5-0.20211224045212-9687c2b0f87c/errors.go:174\ngithub.com/pingcap/errors.Trace\n\tgithub.com/pingcap/errors@v0.11.5-0.20211224045212-9687c2b0f87c/juju_adaptor.go:15\ngithub.com/go-mysql-org/go-mysql/replication.(*BinlogSyncer).parseEvent\n\tgithub.com/go-mysql-org/go-mysql@v1.6.1-0.20220718092400-c855c26b37bd/replication/binlogsyncer.go:782\ngithub.com/go-mysql-org/go-mysql/replication.(*BinlogSyncer).onStream\n\tgithub.com/go-mysql-org/go-mysql@v1.6.1-0.20220718092400-c855c26b37bd/replication/binlogsyncer.go:748\nruntime.goexit\n\truntime/asm_amd64.s:1571"]
[2023/02/18 02:58:10] [info] binlogsyncer.go:196 syncer is closing...
[2023/02/18 02:58:10.877 +00:00] [INFO] [streamer_controller.go:109] ["last slave connection"] [task=tidbmigration-sample-task] [unit="continuous validator"] ["connection ID"=54712275]
[2023/02/18 02:58:10] [info] binlogsyncer.go:893 kill last connection id 54711567
[2023/02/18 02:58:10] [info] binlogsyncer.go:226 syncer is closed
[2023/02/18 02:58:10] [info] binlogsyncer.go:400 begin to sync binlog from position (mysql-bin-changelog.058161, 38845467)
[2023/02/18 02:58:10] [error] binlogsyncer.go:887 kill connection 54711567 error ERROR 1094 (HY000): Unknown thread id: 54711567
[2023/02/18 02:58:10] [info] binlogsyncer.go:164 create BinlogSyncer with config {429546523 mysql xxxxx xxxxxx    false false <nil> false +00:00 false 0 30s 1m0s 1 true true 0 <nil> 0xc01a641f20 0x74e860}
[2023/02/18 02:58:10] [error] binlogstreamer.go:78 close sync with err: io.CopyN failed. err unexpected EOF, copied 0, expected 66: connection was bad
[2023/02/18 02:58:10] [error] binlogsyncer.go:697 io.CopyN failed. err unexpected EOF, copied 0, expected 66: connection was bad
[2023/02/18 02:58:10.866 +00:00] [ERROR] [streamer_controller.go:367] ["meet error when get binlog event"] [task=tidbmigration-sample-task] [unit="continuous validator"] [error="io.CopyN failed. err unexpected EOF, copied 0, expected 66: connection was bad"] [errorVerbose="connection was bad\ngithub.com/go-mysql-org/go-mysql/mysql.init\n\tgithub.com/go-mysql-org/go-mysql@v1.6.1-0.20220718092400-c855c26b37bd/mysql/error.go:10\nruntime.doInit\n\truntime/proc.go:6222\nruntime.doInit\n\truntime/proc.go:6199\nruntime.doInit\n\truntime/proc.go:6199\nruntime.doInit\n\truntime/proc.go:6199\nruntime.doInit\n\truntime/proc.go:6199\nruntime.main\n\truntime/proc.go:233\nruntime.goexit\n\truntime/asm_amd64.s:1571\nio.CopyN failed. err unexpected EOF, copied 0, expected 66\ngithub.com/go-mysql-org/go-mysql/packet.(*Conn).ReadPacketTo\n\tgithub.com/go-mysql-org/go-mysql@v1.6.1-0.20220718092400-c855c26b37bd/packet/conn.go:168\ngithub.com/go-mysql-org/go-mysql/packet.(*Conn).ReadPacketReuseMem\n\tgithub.com/go-mysql-org/go-mysql@v1.6.1-0.20220718092400-c855c26b37bd/packet/conn.go:97\ngithub.com/go-mysql-org/go-mysql/packet.(*Conn).ReadPacket\n\tgithub.com/go-mysql-org/go-mysql@v1.6.1-0.20220718092400-c855c26b37bd/packet/conn.go:89\ngithub.com/go-mysql-org/go-mysql/replication.(*BinlogSyncer).onStream\n\tgithub.com/go-mysql-org/go-mysql@v1.6.1-0.20220718092400-c855c26b37bd/replication/binlogsyncer.go:688\nruntime.goexit\n\truntime/asm_amd64.s:1571"]
[2023/02/18 02:58:10.866 +00:00] [INFO] [streamer_controller.go:234] ["reset replication syncer"] [task=tidbmigration-sample-task] [unit="continuous validator"] [location="position: (mysql-bin-changelog.058161, 38845467), gtid-set: "]
[2023/02/18 02:58:10] [warn] binlogsyncer.go:707 retry sync is disabled
[2023/02/18 02:58:10] [info] binlogsyncer.go:196 syncer is closing...
[2023/02/18 02:58:10.272 +00:00] [INFO] [data_validator.go:1008] ["persist checkpoint and intermediate data"] [task=tidbmigration-sample-task] [unit="continuous validator"] ["pending size"=0] ["pending count"=0] ["new error"=0]

Versions of the cluster
DM version (run dmctl -V or dm-worker -V or dm-master -V):
v6.2.0

Upstream MySQL/MariaDB server version:
aurora-mysql-5.7

Downstream TiDB cluster version (execute SELECT tidb_version(); in a MySQL client):
v6.2.0

How did you deploy DM: tiup or manually?
tidb-operator

Other interesting information (system version, hardware config, etc):
>
>

current status of DM cluster (execute query-status <task-name> in dmctl)
{
    "result": true,
    "msg": "",
    "sources": [
        {
            "result": true,
            "msg": "",
            "sourceStatus": {
                "source": "tidbmigration-sample-src",
                "worker": "test-single-cell-dm-worker-0",
                "result": null,
                "relayStatus": null
            },
            "subTaskStatus": [
                {
                    "name": "tidbmigration-sample-task",
                    "stage": "Running",
                    "unit": "Sync",
                    "result": null,
                    "unresolvedDDLLockID": "",
                    "sync": {
                        "totalEvents": "90872497",
                        "totalTps": "229",
                        "recentTps": "198",
                        "masterBinlog": "(mysql-bin-changelog.058406, 117618630)",
                        "masterBinlogGtid": "",
                        "syncerBinlog": "(mysql-bin-changelog.058406, 117613841)",
                        "syncerBinlogGtid": "",
                        "blockingDDLs": [
                        ],
                        "unresolvedGroups": [
                        ],
                        "synced": false,
                        "binlogType": "remote",
                        "secondsBehindMaster": "0",
                        "blockDDLOwner": "",
                        "conflictMsg": ""
                    },
                    "validation": {
                        "task": "tidbmigration-sample-task",
                        "source": "tidbmigration-sample-src",
                        "mode": "full",
                        "stage": "Stopped",
                        "validatorBinlog": "(mysql-bin-changelog.058161, 36301019)",
                        "validatorBinlogGtid": "",
                        "result": {
                            "isCanceled": false,
                            "errors": [
                                {
                                    "ErrCode": 43003,
                                    "ErrClass": "validator",
                                    "ErrScope": "internal",
                                    "ErrLevel": "high",
                                    "Message": "failed to get event",
                                    "RawCause": "Header \u0026replication.EventHeader{Timestamp:0x63eecd70, EventType:0x20, ServerID:0x35a66d02, EventSize:0x47, LogPos:0x250bc62, Flags:0x0}, Data \"....\", Err: table id 140: invalid table id, no corresponding table map event",
                                    "Workaround": ""
                                }
                            ],
                            "detail": null
                        },
                        "processedRowsStatus": "insert/update/delete: 405548/181636/182125",
                        "pendingRowsStatus": "insert/update/delete: 3527/1545/1533",
                        "errorRowsStatus": "new/ignored/resolved: 3/0/0"
                    }
                }
            ]
        }
    ]
}```

right now there's auto-resume feature for continuous data validation, if it stopped by some resumable error, you can start it again by dmctl validation start <task-name>, it will resume from previous saved location.

closed, since 6.2.0 is a DMR version which don't have following fix version


Doesn't do run_query when compile

This is a:

[x] bug fix PR with no breaking changes
[ ] new functionality

Link to Issue

Closes #215

@b-per this looks good to be once we have an understanding of how we want the IDE to behave in this case (also is rpc going away in the newer iterations of the IDE?)

I believe that WHICH shows as rpc only when clicking on preview/compile.
I'd rather not alter the behavior if people want to see the query being run (and want to see the true results taking in account their exceptions). They will have an error if they try to compile/preview without having loaded the seed but I'd actually be ok with that.


Added solutions 12. & 13., Int to Roman & Roman to Int

Pull Request Template
Description
Please include a summary of the problem and about the approach to solve the solution. Please also include relevant motivation and context.
List any dependencies that are required for this change.
Put check marks:
Have you made changes in README file ?

[x] Added problem & solution under correct topic.
[x] Specified Space & Time complexity.
[x] Specified difficulty level, tag & Note(if any).

How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Please also note any relevant details for your test configuration.

[x] Input: 123 //for numberToRoman()
[x] Input: "VI" //for romanToInt()

Make sure all below guidelines are followed else PR will get Reject:

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] I have commented my code so that it is easy to understand
[x] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[x] Any dependent changes have been merged and published in downstream modules

Looks good @Kingal1337
Can you remove main method from both the solutions ?

I have removed the main methods


Release everything into Maven Central, instead of JCenter/Bintray

JFrog will be sunsetting Bintray and JCenter. New package versions submittion will close on March 31st, 2021. Serving packages from JCenter will terminate on February 1st, 2022.
https://jfrog.com/blog/into-the-sunset-bintray-jcenter-gocenter-and-chartcenter/
Embulk has been migrating its distribution repository to Maven Central gradually, but it has not completed yet. embulk-api and embulk-spi have been released into Maven Central from their beginning, v0.10.2 and v0.10.7, respectively.
Along with standard plugins, which start to be released into Maven Central from this version v0.10.28, it's time to drop JCenter/Bintray, adn start releasing embulk-core, embulk-deps, and embulk-junit4 into Maven Central!

Thanks!


Strange error related to 'device' variable

I was trying to follow the offical MNIST tutorial with PyTorch.
If the device variable is set as global, then autogluon would throw out a spawn error like this:

This is not intuitive and it took me a while to debug this issue.

Thanks for reporting the issue!
What was the change in code that fixed the error and what OS are you using?

Thank you for your response.
OS: Linux SMP (HPC cluster)
To fix this issue, the device variable needs to be removed before the train_fn and scheduler_fn. Just like the example, assign device inside train_fn should be fine.

HPO has been refactored in v0.4 and should no longer error.


az storage blob upload - support for standard base16 (hex) md5sum

As good as nobody in the world uses base64 encoded md5sums and most people would not even know how to generate it from a normal base16 encoded md5sum.
Please support both. If overhead is of concern consider compression. JSON is a large overhead format so the extra "compression" of base64 should be irrelevant here vis. user workflows.
trainer:/workdir/eee# az storage blob upload -c models --file model.onnx --name p11808/model.onnx --overwrite=true --content-md5 aba1a2322a80eee3b400679c8a50986b
Argument '--overwrite' is in preview and under development. Reference and support levels: https://aka.ms/CLI_refstatus
Finished[#############################################################]  100.0000%
The MD5 value specified in the request is invalid. MD5 value must be 128 bits and base64 encoded.
RequestId:208740f5-301e-008b-07b2-1e6451000000
Time:2023-01-02T13:57:18.5449066Z
ErrorCode:InvalidMd5
trainer:/workdir/eee#

In case anyone attempts to do this, here is a Python snippet:
>>> base64.b64encode(int("aba1a2322a80eee3b400679c8a50986b",16).to_bytes(16,'big'))
b'q6GiMiqA7uO0AGecilCYaw=='
>>>

Also, from a user workflow perspective, it is very unclear if this option even works when it is accepted.
The output hints on that the md5 is not even used:
trainer:/workdir/eee# az storage blob upload -c models --file model.onnx --name p11808/model.onnx --overwrite=true --content-md5 q6GiMiqA7uO0AGecilCYaw==
Argument '--overwrite' is in preview and under development. Reference and support levels: https://aka.ms/CLI_refstatus
Finished[#############################################################]  100.0000%
{
  "client_request_id": "d64a453c-8aa7-11ed-b97a-3a3f0cb41999",
  "content_crc64": "BqP5S4LU38E=",
  "content_md5": null,
  "date": "2023-01-02T14:14:56+00:00",
  "encryption_key_sha256": null,
  "encryption_scope": null,
  "etag": "\"0x8DAECCBBA844E98\"",
  "lastModified": "2023-01-02T14:14:57+00:00",
  "request_id": "c3746311-301e-0040-4ab4-1e6704000000",
  "request_server_encrypted": true,
  "version": "2021-06-08",
  "version_id": null
}

@evelyn-ys for awareness

The situation is not less obscure in Windows PowerShell:
https://stackoverflow.com/questions/62086677/azure-blob-upload-with-content-md5-set


WIP - C data interface implmentation

Closing for now since we're far away from this. We can always reopen it or start a new one when the time comes


Disk name in ${workspaceRoot} is lowercase may result in a bug related to node6, webpack and babel

VSCode Version: v1.1
OS Version: windows 10
nodejs Version: v6

Steps to Reproduce:
( a little bit complicate)

mkdir try-bugs && cd try-bugs
2.npm install -g vue-cli
2.vue init webpack
3.npm install
4.set up a task in task.json, whose command is npm, args is ["run", "build"]
press contrl + shift + b to build the project
6.then babel of webpack does not work in the right way

Further description and guess:
I have install a extension of vscode called new-cmd , which can enable you to open a new terminal from current work space directory by typing command cmd after pressing f1 in vscode.
If I open a terminal using this extension and then run npm run build in this terminal, it will show me the same bug as run the build task from vscode.

However, if I open a terminal manually by right click and run the same command, everything goes well.

I notice that there is one difference between the two terminal is that the disk name. The disk name in former terminal is d:\ while the later one is D:\.
In the project, from one hand, there are some code, the config of webpack specifically, related to path.join(__dirname, ...), which will generate an absolute path to files begin with D:\. From the other hand, there are some other code use relative path to locate file, which will result in path to file begin with d:\.
I wonder whether this caused my problem or not.
By the way, if I repeat the process with node5, the bug disappear.

@unhealthy in node v6 the case of drive letters has changed.
This is a duplicate of https://github.com/Microsoft/vscode/issues/6530


Fixes default path to work in mono

(original was getting the path location of mono, rather than AuroraPatch).
Please double check this still works as expected in windows! (I have no reason to think it shouldn't but haven't tested).

Thanks, it should work in windows too.


Added grunt seed command

broke users and projects out into separate json files for easy additions. Also made it so adding a generator later wouldn't be too much additional work

looks like mocha can't find the 'promise' module that you are trying to use. Should probably fix that test before we merge

added promise to the dependencies. should work now.

@jfucci any other concerns now that the tests are passing?

Looks good!


Resize transform

Resize Image Transform

Looks fine, just not sure what the use case for that would be...?

Well, i just needed it because i'm trying to reproduce reported issue, and don't have properly preprocessed dataset. So with this transform i'm at least sure all images are equal sized :)


Add MTU to network.ClusterNetwork

This is a cluster-wide value but we currently configure it per-node (in the "node-config" passed to openshift-sdn) for historical reasons.
(There are no compatibility concerns with respect to adding the new field; the object is used only for communication between cluster-network-operator, openshift-sdn, and openshift-network-controller, and the versions of those will always be in sync.)
/cc @squeed @dcbw

/lgtm

/lgtm
@knobunc can you give this an approve?

/approve


eosio-cpp silently fails with error code 255

When compiling my contract eosio-cpp silently fails with error code 255. No error is logged. No wasm-file is created. My contract is quite long (650 lines). This the version I am using:
$ eosio-cpp -v
clang version 7.0.0 (https://github.com/eosio/clang.git     6b886302a11a8419b76e469794ff9d0c531a4b4b) (https://github.com/eosio/llvm 3c026f8b7813ad693749d3551353a554c5ca33e7)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/opt/eosio.cdt/1.7.0/bin
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.4.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/8
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.4.0
Candidate multilib: .;@m64
Selected multilib: .;@m64

The behaviour suddenly appeared while I added more and more features to my contract. Any ideas what could be the reason for this?
I am not using a virtual machine. Compiler is running on my natively installed Ubuntu 18.04 on my laptop.

I'm having this problem, too.


feat: thorchain LP remove "Approx. Wait Time" row

Description

Pull Request Type

[ ] :bug: Bug fix (Non-breaking Change: Fixes an issue)
[ ] :hammer_and_wrench: Chore (Non-breaking Change: Doc updates, pkg upgrades, typos, etc..)
[ ] :nail_care: New Feature (Breaking/Non-breaking Change)

Issue (if applicable)

closes #
Risk

High Risk PRs Require 2 approvals

What protocols, transaction types or contract interactions might be affected by this PR?

Testing

Engineering

Operations

Screenshots (if applicable)

Current dependencies on/for this PR:

develop

PR #6125   👈

This stack of pull requests is managed by Graphite.


New method request: startsWithAny()

I would like to add the method startsWithAny to this library.

Looks good, thanks! :)


fix: add support for importing index files from subpaths

Fixes #107.

:tada: This PR is included in version 1.3.4 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


[Backup/Restore cStor] Verify the case of triggering backup when cStor is unhealthy.

This issue was created in response to Originally posted by @mynktl in https://github.com/openebs/velero-plugin/pull/79#issuecomment-625185814
There were some panics observed when backup was triggered in case of cstor volume being in not-ready state and then subsequent cleanup resulted in panic.
If CVR are not healthy then snapshot will fail.
If CVR are healthy then we can inject this error while restarting the cstor pool pod or killing the cstor-pool-mgmt container

Looking at the issue, e2e flow should be like;

Create backup
Get the pool name where backup is scheduled.
Inject chaos on pool pod when backup is in progress.
Backup will be failed (expected).
Try deleting failed backup (It should get deleted).


Replace CTZN.config with params.config

At every point after the configuration is extended by the controller config, server.js should reference params.config instead of the global CTZN.config.

Upon review, all instances of CTZN.config within server.js look fine.


Adding to existing model with data and methods don't work

When I add acts_as_list to a model retroactively the position is set to NULL and the move_higher and lower methods etc don't work. I have to add something like this to the migration.
TeamMember.reset_column_information
TeamMember.all.each_with_index do |tm, i|
  tm.update_columns(position: i)
end

It would be good if there was something in the documentation to highlight this as I seem to have to figure it out every time I use acts_as_list

Hi @tinderfields, yes that's a good idea. Would you mind forking the project, updating the README and  doing a pull request? Try to make you example as generic as possible to ensure it makes sense to everyone. You'll also want to set position to i + 1 since each_with_index is zero-based, and acts_as_list generally is configured one-based.
Remember also that scopes come into play here. So some model's might have positions scoped to some parent value.
@swanandp, is it worth looking into making all the methods work with an uninitialised table? We can't really auto-populate the table because we can't predict the scope values, but we can make the methods cope with NULL values.

Done

@brendon That does seem slightly out of scope for us, but we should certainly add the documentation. FWIW, in my experience, acts_as_list is almost exclusively used with a scope, than without.

@swanandp, yes that's been my experience also. If @tinderfields can adjust the methods so that they cope with nil values or values with gaps between adjacent items that'd be a bonus :)

👍 Agreed

@tinderfields, I can't find your Pull Request for this change. Can you make one or link it into here if it already exists?
If you'd also like to tweak the public methods to cope with nil values that would be a bonus (with tests of course). Let me know if you need help getting the test suite running etc...

Closing this for now. Let me know if you want to pursue it again @tinderfields.


Auto generate forms by backend model?

Would be really nice for prototyping...
How can i retrieve a loopback backend model schema through angular?
I want to build automatic forms based on the backend models... i think it is possible

It would indeed be really nice to have that.
Last week I've add a couple of methods to a model called Meta that can be used for this purpose.
The methods are:
/Meta/getModelAcls
/Meta/getModelProperties
/Meta/getModelRelations
/Meta/getModelRemotes
/Meta/getModelSettings

I'm not sure if it gives all the information that is needed, but I guess it will be a start.
Another thing to not is that I'm most likely moving towards using schema-form, so it might be good to base it on that. Or at least abstract it in a way that it can support both angular-formly and schema-form.
I know @drmikecrowe and @dot-louis have been working on something similar.
It's probably good to discuss the ideas in this issue or in the gitter room. I'm happy to look at the code if you submit a PR!

Hi @portokallidis ,
I'm indeed working on a solution to complete the Loopback explorer: https://github.com/dot-louis/loopback-browser (not ready yet)
If you want to get the model schema, you can enable loopback explorer and query the following api from your app:
// To get the api paths of your models
YOUR_HOST/explorer/resources
// To get the model schema
YOUR_HOST/explorer/resources/some_model_name_(plural)

For example you could have a function to request the available api endpoints,
and then get the related operations, and model details

var resources = YOUR_HOST+'/explorer/resources';

function getResources(){
  return $http.get(resources)
  .then(function(res){
    // res looks something like this
    /*{
         "swaggerVersion": "1.2",
         "apiVersion": "1.0.0",
         "apis": [
           {
             "path": "/SomeModels"
           }
         ]
      }*/

     // Note that querying a single model will fetch the details for all models (it seems the only difference is the order of the apis in the JSON response)
     // So you only need to get the first one
     return $http.get(resources + res.apis[0].path);
  })
  .then(function(details){
  // details looks something like this:
  /*
  {
  "apiVersion": "1.0.0",
  "swaggerVersion": "1.2",
  "basePath": "YOUR_HOST",
  "resourcePath": "/SomeModels",
  "apis": [
    {
      "path": "/SomeModels/{id}/orignal",
      "operations": [
        {
          "method": "GET",
          "nickname": "prototype.__get__orignal",
          "parameters": [
            {
              "paramType": "query",
              "name": "refresh",
              "required": false,
              "allowMultiple": false,
              "type": "boolean"
            },
            {
              "paramType": "path",
              "name": "id",
              "description": "PersistedModel id",
              "required": true,
              "allowMultiple": false,
              "type": "any"
            }
          ],
          "responseMessages": [
            {
              "code": 200,
              "message": "Request was successful"
            }
          ],
          "summary": "Fetches belongsTo relation orignal.",
          "type": "SomeModel"
        }
      ]
    }
   ...
  */
  });
}

You should have all the data you need to build your forms based on your loopback models.
However be careful as loopback explorer is probably not meant to be used in production (because security).
The other method would be as @beeman suggested which is creating a Meta model that will return other models' data for you.

Hi,
@dot-louis this was my first approach,then i explored the Meta model @beeman  has created and that was very helpful although i couldn't retrieve somehow the type(string,number,etc) of properties...
Thank you for the help!

@dot-louis thanks for your input :)
@portokallidis where would you expect these details to appear? In one of the existing methods or in a new one? It would be quite straightforward to add them

Perhaps nested like they are in common models
     prop_name: {
          type:"string",
          required:true
     }

I've just added a basic data browser. I've not yet implemented #121 in the updated Meta model as it seemed to crashed the server.
So it seems that the property definition is stored as a function instead of a string?

yes it does, the first commit crashes the server and the second does not. I think the server crashes because i tried to manipulate a function object and make it string.
What i did next is that i left "type" as it is and created a new type "stringType" and now it doesnt crash although is not clean

It looks like this does it: https://github.com/beeman/loopback-angular-admin/blob/9845ed2e8166d92da7a9e8a11b1aab545b863c32/common/models/meta.js#L9

Data browser is in place, closing this issue.


Click google account to log in nth happens

My friend can't even log in with her google account. It's like it's a dead button.

@bonedriven
Thanks for the report!  Just to get a bit more information, does a tab open in the web browser after clicking on the button?  If not, is there a way you can submit feedback (there is a link on the login page below the Google and Facebook buttons)?  If it does, can you give a bit more information about what button is dead?  Thanks again.

You can click the uproxy addon button. Then it brings a small tab with Google or facebook option. When you click the facebook option, it will bring you to facebook tab. Now if you click google, nth happens, like it's a dead button.
However, it opened a few times, but it failed eventually as when you click your google account then it closes automatically and then nothing happens and you find you wasn't logged in. Then when you try again, the google button (above facebook) is already dead too.
My friend is behind the great wall.

If there is any way you could get your friend to submit logs (again, from the submit feedback page) that would be really helpful.
We expect to run into problems in areas where access to the social networks is blocked and this could very well be one of those cases, but that's not the exact way I would expect things to fail.  It would be helpful to be able to look at the logs and get a better idea of what's going on.

It was submitted.

I have the same problem, I've tried multiple times, one lucky time it worked, and I got logged, after that and now click the 'Google' button just does not work.

@jpevarnek
I did a little digger,  after open a tab to login with facebook or google account, next time when you click 'FACBOOK' or 'GOOGLE', here is my log
Click 'FACBOOOK', it always do LOGIN + SEND_CREDENTIALS

Click 'GOOGLE', it only do LOGIN, no SEND_CREDENTIALS, I think that's why click 'GOOGLE' multiple-times does nothing.


Automated cherry pick of #7076

Cherry pick of #7076 on cloud.
/cc  @hahmadia

Will try to auto merge this PR once all tests and checks are passing. This might take up to an hour.

Trying to auto merge this PR.

Pull Request successfully merged
SHA: 78f19c0c74f56e9b93ec6f9c0cdfa6dd06942a73


iOS cancelTechnologyRequest -> requestTechnology -> Duplicate registration

In iOS, NfcManager.cancelTechnologyRequest() does not immediately cancel the request, and has no feedback event about when the request has been canceled. If you execute  NfcManager.requestTechnology() in the meantime, it will return with an error: Oops! [Error: Duplicated registration]
How to reproduce:

Activate the scan with NfcManager.requestTechnology()
Scan the tag
Immediately swipe down on the iOS's scan prompt screen to hide it.
Activate the scan again with NfcManager.requestTechnology()

+1

+1

Any update on this? or how to handle error?

:+1

The only solution that I've found to this so far is delaying the read requestTechnology call (2 seconds). Seems not like an ideal solution.

Has anyone found a solution to this? I believe it may help me solve my issue... I experienced this duplicate registration problem, so I tried to call requestTechnology() once, then loop through calling getTag() multiple times, and finally cancelTechnology() when the user is done but I'm getting the issue outline in #645.


ltrim issue

https://github.com/tikiatua/internal-assets-plugin/blob/craft3/src/controllers/DefaultController.php#L123
This is happening:
https://stackoverflow.com/questions/50174181/why-does-ltrim-remove-one-character-when-the-second-argument-contains-an-operato
Whatever character is present in $volumeUrl gets removed from $path as well as the full $volumeUrl string

Hi @kevadamson,
Thank your for your support. I have just created a new version of the plugin to support Craft v4 and was able to incorporate your feedback to fix this issue. Great catch.


Invoke-GlobalMailSearch is searching/exporting every email twice

Invoke-GlobalMailSearch -ImpersonationAccount<EMAIL_ADDRESS>-ExchHostname "outlook.office365.com" -AdminUserName<EMAIL_ADDRESS>-AdminPassword "password" -Terms * -MailsPerUser 500 -OutputCsv searchedmatches.csv
^^^ Here is the code that I am running ^^^
Specifically, my issue is that Invoke-GlobalMailSearch is searching/exporting every single email twice. When I run (Get-Mailbox).count it returns 37, aka 37 users. However when I run the above code it will give a display of [1/76] mailboxes, [2/76], [3/76]... [76/76].
Basically how, if I only have 37 users, does MailSniper search 76 total mailboxes? And how can I solve this?
Huge thanks for any responses!

That issue is likely due to there being multiple email addresses associated with each user. Someone else reported a similar issue before.
Try modifying the following line in the script by replacing ‘-ExpandProperty EmailAddresses’ with ‘-ExpandProperty primarySmtpAddress' and run it again.
$SMTPAddresses = Get-Mailbox -ResultSize unlimited | Select Name -ExpandProperty EmailAddresses
Let me know if that helps at all!

Yay! It seems to be working now, thank you very much Beau!

Awesome. I'll test out modifying that in the master script and push it some time soon.


Delete fails on Flutter web

I do delete, close the app, open the app, and the value is back again when I read it
I do the following
main() {
await secureStorage.delete(key: 'aKey');
value = await secureStorage.read(key: 'aKey');
print(value); // Here I get 'something', despite the read returned nothing after doing delete before closing the app
String value = '';
final secureStorage = FlutterSecureStorage();
await secureStorage.write(key: 'aKey', value: 'something');
value = await secureStorage.read(key: 'aKey');
print(value); // Here I get 'something' as expected
await secureStorage.delete(key: 'aKey');
value = await secureStorage.read(key: 'aKey');
print(value); // Here I get '' as expected
}

I am closing all older issues. If this issue still exists in the latest version, please let me know.


Shadow definitions

Does anyone know how to set "Shadow position" to "Inside" within a json script? No matter what I declare it always turns to "Outside"

I am using the below and it seems to work fine:
"dropShadow": [{ "position": "Inner" }]

Yes, just tested my self and it works, thanks!

Also, do remember that this is case sensitive so inner would not work. Outer is also the default so a typo here would trigger it to be applied.

Do you by any chance have you manage to declare "Display Units" value in any visual?

Do you by any chance have you manage to declare "Display Units" value in any visual?

This is an example (millions) that seems to work on my end:
"labels": [	{ 	"labelDisplayUnits": 1000000	}	]


prerequisites

Pre-requisites has been on the backlog for IE for some time. I am consolidating the ideas with how prereqs can be solved in the short, medium, and long-term - each involving a more nuanced but much needed feature update on IE.
Note: This is for the CLI. Contract changes between IE and Portal would come after that.
Short Term
Ask on IE: Have the ability to transfer variables from one environment (this could be a doc) to another

Setup: parent doc references prereq doc 1, which reference prereq doc 2
We include ie execute <remote URL to the raw markdown file for doc 1> as a code block within the prerequisites section of the parent doc. And we include ie execute <remote URL to the raw markdown file for doc 2> as a code block within the prerequisites section of doc 1.
During runtime, Innovation Engine will execute the parent doc, encounter the execution of doc 1 and go to that doc, encounter the execution of doc 2 and go to that doc, run doc 2 E2E, then run doc 1 E2E, and finally run the parent doc E2E
Whenever IE executes an ie execute command inside any of these docs, its output would be shown in the CLI without any formatting. Furthermore, the variable names would need to be inferred from that IE output so that they can be carry forwarded into the parent doc.

Medium Term
Ask on IE (in addition to short term ask): Have the ability to execute the bulleted list in the Prerequisites section in the back-end and provide a custom output with information from that run

Setup is the same as the short-term scenario
We include a designated section that should be consistent across all exec docs and call it, say, Prerequisites. That section would (optionally) contain a description and (mandatorily) contain a bulleted list of pre-reqs docs (with their names and URLs).
IE would look for this section in the doc and run the prereq docs in sequence from it
IE would provide a custom output in the CLI showing the progress of running the docs, the variables they output, the state of those variables, etc.
During runtime, Innovation Engine will execute the parent doc, encounter the execution of doc 1 and go to that doc, encounter the execution of doc 2 and go to that doc, run doc 2 E2E, then run doc 1 E2E, and finally run the parent doc E2E

Long Tem
Ask on IE (in addition to short and medium term asks): Have the ability to validate if a prereq doc has already been run and transfer the necessary information from that to the parent doc if so

Setup is the same as the short-term scenario
The designated section and its functioning is the same as the medium-term scenario
There would be a validation section at the end of every doc that wants to be a prerequisite. This section should contain commands for IE to run to check if the infra promised in the doc's execution was actually deployed
In all such docs, IE would first check the presence of the validation section. If it exists, IE would check that first i.e. check if the doc has already run and the resources deployed. If so, it would store the details of the infra in environment variables and export them to the parent doc. Only if the validation section fails for some reason, IE will run the prereq doc E2E.
IE will convey the information of the variables to the user such that they can use them in the parent doc

Given prerequisites being high on IE's roadmap and multi-part exec docs needing prerequisites to fully work, I would love to get the ball rolling for this one and implement some working solution while we scope out an ideal one. What does the group think?

**From @vmarcella **
I agree with most of the high-level structure, but I think there are a lot of gaps that aren't addressed which need to be for the PoC. Let's imagine how the process should go for a doc that has any arbitrary number of pre-requisites and those pre-reqs also have any arbitrary number of nested pre-reqs:

IE checks for a pre-requisite section in the document.
IE finds pre-requisite documents and loads them in the order that they're specified in the bullet list.
IE checks each pre-requisite doc for a Validation section that contains code blocks (Also by header)

If no validation section exists and there are no further pre-reqs in the pre-req doc we're currently checking, we just execute the pre-req doc as is.
If no validation section exists and there are further pre-reqs in the pre-req doc we're currently checking, we load those pre-reqs and go back to step 2
If validation section exists and there are no further pre-reqs in the pre-req doc we're currently checking, we run the validation section.

If validation fails, we execute the whole document.

If validation succeeds, we can skip executing the pre-req document.

If validation section exists and there are further pre-reqs in the pre-req doc we're currently checking, we run the validation section

If validation fails, we start the process over at step 2 for this pre-requisite doc.

If validation succeeds, we can skip executing the pre-req document.

IE finishes running all of the pre-requisites

If pre-reqs are satisfied, we begin the execution of the current document as normal.
If pre-reqs are not satisfied, i.e., validation steps constantly fail or the pre-req doc steps constantly fail, we need to communicate the error

This logic makes the following assumptions:

Validation is responsible for exporting variables that would be needed by other documents which serve as the dependencies for other documents.
Validation is somewhat fast, taking no longer than 30-60 seconds per validation section on each doc.
There are no cyclic pre-requisites (I.E. Parent doc has pre-req doc which specifies the parent doc as a pre-req, creating an infinite loop. IE will catch this in a production ready version of the feature)

With this in mind, here are my questions:

If a pre-requisite doc was run multiple times, how should we choose which resources or values to use for the current document? Or if it's up to the user, how do we let them choose?
Following up on the last question, how should validation optimally find resources from previous executions of a document? What guidance should we provide to doc authors writing validation sections?
How do we prevent breakage that can occur from pre-req documents being updated? If a pre-req doc gets updated, and let's say no longer exports a variable in the validation section which was depended upon by the parent doc, how should this be handled? Can we prevent it?
If we have to execute multiple pre-requisite docs before executing the current document, that can potentially take 30+ minutes. What do we communicate to the user while that is happening? Would it be better to just have them execute those docs first and then come back to the current document if there are too many unsatisfied pre-requisites?
What should be communicated in the CLI while executing pre-requisite documents? If we include the entire output from pre-req runs, that will result in a ton of output.

From @rgardler-msft
For a first iteration it may make sense to say no nested pre-reqs. Not saying we should, just saying that taking an iterative approach may make it easier to get something out the door. Similarly, things like changes in the pre-req causing problems "upstream" is (probably) best left until it is an actual problem. I want to see all docs tested on a regular cadence; this means that such breakages would be automatically caught by the test framework and thus IE need only report the break, it shouldn't worry about detecting it.
Remember we want to move forward at a pace, even if that means needing to accept that sometimes we will stumble. Of course, I'm not saying we don't need to consider all possibilities, only that we should feel comfortable saying some things are currently out of scope but need to be considered in a future iteration. It should be SWE that have final say on what can safely be left out of scope.

I went through all the points mentioned below. Given that, I agree with @rgardler-msft and would love to get on with a first iteration of this. TL;DR we pursue what you outlined @vmarcella  with one change - assume there are no nested pre-reqs.
here are my answers to your questions @vmarcella  and my take on the path moving forward:
If a pre-requisite doc was run multiple times, how should we choose which resources or values to use for the current document? Or if it's up to the user, how do we let them choose?
If the prereq doc has a validation section that passes, then the resource values from running that validation section will be transferred. If the validation section fails, the values from that run of the prereq doc will be transferred. Allowing users to choose values (in the CLI experience) should happen via a parameter or equivalent in IE that allows you to filter for resource values or pass them as parameters for the prereq doc if it needs any. However, allowing users to choose parameters in the Portal experience would happen through the configurability parameters effort i.e. in the prerequisites section, for every doc requiring parameters, they would be displayed in Portal and parsed accordingly along with that doc.
Following up on the last question, how should validation optimally find resources from previous executions of a document? What guidance should we provide to doc authors writing validation sections?
How can we implement this from a dev standpoint? This was one of my asks on IE. I thought of this implementation from my end and here is one way we could do it:

This uses the command to query the RG to check if the list of resources match the expected result. Maybe we increase the expected similarity match to more closely match it or introduce something in IE that would also check if the number of elements in the expected similarity results list are the same as in the actual list. How would you solve it as an MVP?
How do we prevent breakage that can occur from pre-req documents being updated? If a pre-req doc gets updated, and let's say no longer exports a variable in the validation section which was depended upon by the parent doc, how should this be handled? Can we prevent it?
This would just be an error while trying to execute the updated prereq doc and should be caught by the testing process and flagged to the author for further remediation. That is the closest we can go to prevent it in the short term. However, why would the prereq doc no long export a variable in the validation section without it being caught in testing? Also, is there any more efficient ways of doing this? Is this even an issue to worry about right now? I don't know, let's experiment and find out.
If we have to execute multiple pre-requisite docs before executing the current document, that can potentially take 30+ minutes. What do we communicate to the user while that is happening? Would it be better to just have them execute those docs first and then come back to the current document if there are too many unsatisfied pre-requisites?
We would need the content folks to give their $0.02 on the verbiage since long wait times are not ideal. If the prerequisite docs are exec docs that have been deeplinked into Portal, we can prompt the users to run those docs first. But then how would state (the data at the end of the doc) be carried over to the parent doc at the end of its execution?
What should be communicated in the CLI while executing pre-requisite documents? If we include the entire output from pre-req runs, that will result in a ton of output.
This was captured in my ask for the medium run: "IE would provide a custom output in the CLI showing the progress of running the docs, the variables they output, the state of those variables, etc." Can IE detect its running a prereq doc and based on that flag, modify the display in the shell. On the Portal side, we can mock up something quickly for the same.

From @mbifeld

I agree that the first iteration does not need to support a pre-req in a pre-req for simplicity purposes.
In regards to what IE displays when executing a pre-req, something like:

When it finds a pre-req, it outputs "Checking pre-requisites..."

If validation steps pass, continue to step c.

If validation fails, it outputs "A pre-requisite Exec Doc  needs to be executed.  Starting execution..."  A later experiment can determine if its better to ask the user if it should execute the pre-req doc first or just do it.

During execution of the pre-req, IE outputs the same as if it were a regular Exec Doc.  If we're not doing pre-reqs in a pre-req, there shouldn't be too much output.

After all pre-reqs have been met, we output "Pre-requisites have been met"

In regard to choosing the resources to validate against (such as in the case where the pre-req was run multiple times), we should allow for the top-level Exec Doc to have environment variables that are initialized prior to the pre-req validation being ran.  Essentially a "do this first no matter what".  The author should ensure the variable names line up with those in the pre-req.  In the screenshot you shared @Naman, $RESOURCE_GROUP_NAME would have to be defined before the validation step happens.  Something like:

RESOURCE_GROUP_NAME=abc
We could alternatively have this initial declaration section occur in the pre-req doc.  In this case, we execute 'initial' and then test 'validation' for the pre-req.  But I feel that putting the variable declaration in the top-level doc allows for more flexibility for the author.
- If a pre-req gets updated and breaks, the top-level doc will also break.  It's up to the authors to fix, and us to report.


Select brushX or brushY based on mouse direction ?

In v4, I am trying to implement brush (to zoom selected area) for a line chart. I want the brush in X or Y direction to be selected based on the direction the mouse moves first.
If the mouse moves to left or right, brushX needs to be invoked and if mouse moves first in top or bottom direction, brushY needs to be invoked.
Is there a way to implement this?

This is essentially what happens when you hold down Shift; the brush sets the internal lockX or lockY flag based on the subsequent movement of the mouse.
https://github.com/d3/d3-brush/blob/c8fe9fa8e3d88c22f1527a833279102522fd65db/src/brush.js#L361-L364
I can’t think of an obvious way of triggering this behavior programmatically (meaning without requiring Shift to be held down), but, maybe it’s possible? I think the ideal would be some way of overriding the logic that determines which mode the brush is in during interaction. But there are a lot of different modes, so I’m not sure how to do that elegantly. The quickest path to implementing this is probably to fork the code and modify the internal logic.

@mbostock Thank you for getting back to me. I implemented single directional zoom based on mouse direction. This works perfect for my requirement, Here is the Gist https://gist.github.com/Shravya-Siluveru/d958edfcbd6333e1a07054c15060ebd9


Improve social auth user-facing error handling

Our social auth error handling used to completely not account for SOCIAL_AUTH_SUBDOMAIN, leading to the user getting stuck on the auth subdomain, which could be confusing. I talked more about it in https://chat.zulip.org/#narrow/stream/3-backend/topic/SOCIAL_AUTH_SUBDOMAIN
We fix error-handling by redirecting users to appropriate endpoints on their realm's URL, and then give the subdomain an error page when accessed directly  to inform the user they shouldn't be there:

Then, building on top of those changes with an altered commit from https://github.com/zulip/zulip/pull/13844 (adjusting for the feedback received too), fixing #13126.

This looks generally great.  A few requests:

We should change "is no longer active" to "has been deactivated" -- that seems a lot more clear as to what's going on.
We should make the inactive_realm check before the inactive_user check in the social auth code path; it seems like if the realm is deactivated, we shouldn't get as far as to check whether the user is. (Just a quick if statement swap I noticed we should do).
Can we set SOCIAL_AUTH_SUBDOMAIN in dev_settings.py so that one can test the new page in the development environment without modifying settings?
For the ROOT_DOMAIN_ALIASES change, that's probably a good idea.  Two questions: (1) If we forget to update /etc/zulip/settings.py to remove auth from ROOT_DOMAIN_ALIASES, does something bad happen?   If so we'll want to be careful when deploying this and mention the change in our "Upgrade notes".  And (2) We should make sure you can't register an organization with SOCIAL_AUTH_SUBDOMAIN as your subdomain when making a new organization, including having a unit test for that failure mode.

Pushed commits with each requested change.

We should make the inactive_realm check before the inactive_user check in the social auth code path; it seems like if the realm is deactivated, we shouldn't get as far as to check whether the user is. (Just a quick if statement swap I noticed we should do).

Good catch! I think the same should be done in is_user_active so I swapped the order there too in the commit.

If we forget to update /etc/zulip/settings.py to remove auth from ROOT_DOMAIN_ALIASES, does something bad happen?

Nothing awful, get_subdomain(request) will simply return '' for it - so the new error page won't show up. Probably worth adding an entry in Upgrade notes?

Fixed a conflict.

I don't understand why CodeQL is complaining about logging a username :thinking:

I don't understand why CodeQL is complaining about logging a username 🤔

Apparently it's some issue on GitHub's side. It's failing for all other PRs(on master) too.

To what extent does this PR have unmerged work?  We might want to rebase past the black migration if it does.

@timabbott I think all these commits should be relevant, so rebase. Also added a fix for the thing from https://chat.zulip.org/#narrow/stream/31-production-help/topic/lots.20of.20emails.20w.2F.20error.20messages/near/1212636 at the end
I think the CodeQL error can be dismissed becuase we need to log the email there?

For the CodeQL error, I think you could reasonably just log the user ID rather than the email, and that'd be in line with how we try to log user details elsewhere.

This is looking good; sorry for the delay in trying to integrate it.  I posted a batch of comments that I think is reasonably complete, and also merged the first commit as 86c330b7520714e5e78ae7751d18fbc928096eb5.

@timabbott Ready for another round of review. Replied with some elaboration on the special auth subdomain page in https://github.com/zulip/zulip/pull/13924#discussion_r694124822
Regarding CodeQL and https://github.com/zulip/zulip/pull/13924#discussion_r676051716

This isn't new in this PR, but I kinda feel like this "wrong subdomain" error category should be removed; it feels like we should just tell the user it was a failed login rather than leaking their credentials were correct but for the wrong domain. (At least on the web; I could see e.g. emailing the user).

CodeQL error and this comment are about the same block of code:
            if return_data.get("invalid_subdomain"):
                logging.warning(
                    "User %s attempted password login to wrong subdomain %s", username, subdomain
                )
                error_message = WRONG_SUBDOMAIN_ERROR.format(username=username)
                raise ValidationError(mark_safe(error_message))

I think we should get rid of the special error in favor of the generic one as you mentioned, and also get rid of the logging.warning? I don't know if someone trying to auth with the credentials on the wrong subdomain is interesting enough to log? And it only generates the CodeQL error

Logging the user ID rather than the username would fix the logging issue.
I found this class of logging statements to be useful when we had the caching incident a few months ago (though I think it was a slightly different version), so I think it's better to keep them (maybe at INFO level), just adjusted to only contain user IDs, not emails.

@timabbott Made changes to the logging and removed the user-facing "wrong subdomain" error. Is there anything remaining we want to do here?

https://github.com/zulip/zulip/pull/13924#discussion_r704800500 still needs a resolution -- can we just do a redirect rather than adding that page?

I wanted to merge the first half of this branch, which I feel relatively good about , so I did that as the series ending with f064e3ebac202e415de00b4a47bd439b0c0de954.  I think it's likely still worth trying to replace fb3864ea3cb2aaa27b10506cb4618f28a95c74d4 with a redirect for clarity.
I have some concerns about the remaining commits (or just don't understand them), will post a few comments.

@timabbott

I don't understand the set of conditionals here. It might be better to reorder this logic so that the existing dev_auth_enabled conditional is just above this block, for example, to make it all easier to understand?

I've extracted the overcomplicated if to a should_redirect_away_from_login_page function which can have a much clearer conditional structure, does that help?

https://github.com/zulip/zulip/pull/13924#discussion_r704800500 still needs a resolution -- can we just do a redirect rather than adding that page?

I'm not sure what we should redirect to though? Is the idea still to redirect to /accounts/go?


Update Composer dependencies (2024-02-17-00-10)

Visual regression test passed!
View the visual regression test report


add unittest for SVM Light

This pr is about to add unit test for SVMLight module :)
@vigsterkr

@vigsterkr looks better like time?

oh, miss 'this' from above comment :/ I mean 'this time' actually. Sorry

NOTE: You can edit your comments :)

@vigsterkr ， I write some code on gist by gtest https://gist.github.com/MikeLing/50c96b402b0f8a42a5355ae962fb4fd0. Is that looks good to you? I haven't test it locally. Just want to make sure that's what we need. (I don't want to push the pr every time and make everyone on the irc get a notification ;)
Thank you!

Don't review this PR for now, I'm writing it on osx but I want to verify it's valgrind output. So I just synchronize this and test it on Linux (Valgrind doesn't work on osx)


refactor(EnumPropertyParser): rename to EnumMemberParser

Commit Body
BREAKING CHANGE: `EnumPropertyParser` has been renamed to `EnumMemberParser`
BREAKING CHANGE: `EnumMemberParser#properties` has been renamed to `EnumMemberParser#members`

Codecov Report
Base: 60.11% // Head: 60.11% // No change to project coverage :thumbsup:

Coverage data is based on head (dadaed0) compared to base (4ef3f9a).
Patch coverage: 46.66% of modified lines in pull request are covered.

Additional details and impacted files
@@           Coverage Diff           @@
##             main      #74   +/-   ##
=======================================
  Coverage   60.11%   60.11%
=======================================
  Files          50       50
  Lines        6599     6599
  Branches       53       53
=======================================
  Hits         3967     3967
  Misses       2592     2592
  Partials       40       40

Impacted Files
Coverage Δ

src/lib/structures/NamespaceParser.ts
35.89% <0.00%> (ø)

src/lib/structures/ProjectParser.ts
33.12% <0.00%> (ø)

src/lib/structures/enum-parser/EnumParser.ts
54.16% <25.00%> (ø)

src/lib/structures/enum-parser/EnumMemberParser.ts
58.74% <72.72%> (ø)

src/lib/structures/enum-parser/index.ts
100.00% <100.00%> (ø)

src/lib/types/SearchResult.ts
100.00% <100.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


potential for scipy.optimize.mip

scipy.optimize now offers mixed integer programming solution methods through a HiGHS interface. This is currently in the main branch and will be part of the v1.9.0 release, which should be cut soon. We may want to see about incorporating this new functionality due to the COIN-OR funding situation.

It seems a good tool. Maybe we should do an example for a simple locate model like LSCP? Then we can discuss about API changes and other enhancements to adopt that API. What do you think?

Seems like a very good open-source project from Edinburgh! I think we can test the speed, compare these 2 methods, and see what we want to do.

pulp now supports HiGHS. So now we can easily implement that solver in a demo/example. And if we decide to support our MIPs through scipy.optimize with HiGHS later, it will provide an easier transition for testing and ensuring equivalent solutions are obtained.

I have have successfully installed HiGHS and used from the pulp interface. The demo runs will be in the facloc_real-world_* notebooks and added in #300.


This entirely breaksNeorg

Describe the bug
It doesn't do anything to markdown files and Norg files aren't set to ft=norg for some odd reason?
Are you using a distro?
Idk if this counts?

[!NOTE]
Distros can sometimes cause unusual behavior due to changing various options.

To Reproduce
Steps to reproduce the behavior:

Install markview.nvim.
Open a markdown document.
Open a Norg file.
Whoop-de-doo it doesn't work.

Expected behavior
Both work in harmony.
Actual behavior
They actually don't work and have caused a markup war where they both lose and have no highlighting?
Screenshots

Neovim version
0.10.0
Additional context
I also have Neorg.

wait a sec there's something else wrong