Added CustomExport functionality and updated Demo

Related Issue
Relate the Github issue
https://github.com/mbrn/material-table/pull/2089
Description
Added functionality to create customExport function. This is very helpful when exporting nested/complex objects . I also updated the demo to show customExport component in action.
Impacted Areas in Application
List general components of the application that this PR will affect:

Exporting data

Additional Notes
This is my first ever contribution to an open source project, please advise if I need to do anything differently.

Hey @hbermani thank you! Unfortunately, this has already been implemented =/

Hey @hbermani thank you! Unfortunately, this has already been implemented =/

Hey @hbermani thank you! Unfortunately, this has already been implemented =/

May be it's just me as my brain is fried after a full day, but what this allows you to do is specify the customExport function within exporting to .csv / pdf as it is changing the datas content.

Hey @hbermani thank you! Unfortunately, this has already been implemented =/

May be it's just me as my brain is fried after a full day, but what this allows you to do is specify the customExport function within exporting to .csv / pdf as it is changing the datas content.

Lol no worries. I've been known to misunderstand.
If I do understand this correctly, you are wanting to specify a custom function for exporting data, correct?
In the new model, the concept of exporting csv or exporting pdf no longer exists. You provide an array of objects with this shape:
exportMenu: [{
      label: 'Export PDF',
      exportFunc: (cols, datas) => ExportPdf(cols, datas, 'myPdfFileName')
    },
//....

And we add it to the menu. Notice the exportFunc - I believe that accomplishes the same thing as you described.
This way allows is to not hard code csv or pdf. Just give us an array of objects with the correct shape and we add it to the menu.
We separated the pdf and csv export defaults due to bundle bloat. That article shows how you can still use them though. You just have to import them.

Lol no worries. I've been known to misunderstand.
If I do understand this correctly, you are wanting to specify a custom function for exporting data, correct?
In the new model, the concept of exporting csv or exporting pdf no longer exists. You provide an array of objects with this shape:
exportMenu: [{
      label: 'Export PDF',
      exportFunc: (cols, datas) => ExportPdf(cols, datas, 'myPdfFileName')
    },
//....

And we add it to the menu. Notice the exportFunc - I believe that accomplishes the same thing as you described.
This way allows is to not hard code csv or pdf. Just give us an array of objects with the correct shape and we add it to the menu.
We separated the pdf and csv export defaults due to bundle bloat. That article shows how you can still use them though. You just have to import them.

@hbermani
To demonstrate, this is how you could use a custom export function to detect if the column header is not a string (if you're using JSX as the column title). This way you can replace it with a string so that the export doesn't show [object, Object] as the column header.
Or you could use the default import ExportCsv from '@material-table/core/exporters/csv';
const App = () => {
  return (
    <MaterialTable
      // ... other props
      options={{
        exportMenu: [
          {
            label: "Export CSV",
            exportFunc: (columns, data) => {
              // Turn headers into array of strings
              const headerRow = columns.map((col) => {
                if (typeof col.title === "object") {
                  // I am not sure what props the Translate component exposes
                  // but you would need to change `text` in `col.title.props.text`
                  // to whatever prop you need.
                  return col.title.props.text;
                }
                return col.title;
              });

              // Turn data into an array of string arrays, without the `tableData` prop
              const dataRows = data.map(({ tableData, ...row }) => Object.values(row));

              // Aggregate header data and 'body' data
              // Mirror default export behavior by joining data via
              // the delimiter specified within material table (by default comma delimited)
              const { exportDelimiter } = tableRef.current.props.options;
              const delimiter = exportDelimiter ? exportDelimiter : ",";
              const csvContent = [headerRow, ...dataRows].map((e) => e.join(delimiter)).join("\n");

              // This mirrors the default export behavior where the
              // exported file name is the table title.
              const csvFileName = tableRef.current.props.title;

              // Allow user to download file as .csv
              downloadCsv(csvContent, csvFileName);
            },
          },
        ],
      }}
    />
  );
};

@hbermani
To demonstrate, this is how you could use a custom export function to detect if the column header is not a string (if you're using JSX as the column title). This way you can replace it with a string so that the export doesn't show [object, Object] as the column header.
Or you could use the default import ExportCsv from '@material-table/core/exporters/csv';
const App = () => {
  return (
    <MaterialTable
      // ... other props
      options={{
        exportMenu: [
          {
            label: "Export CSV",
            exportFunc: (columns, data) => {
              // Turn headers into array of strings
              const headerRow = columns.map((col) => {
                if (typeof col.title === "object") {
                  // I am not sure what props the Translate component exposes
                  // but you would need to change `text` in `col.title.props.text`
                  // to whatever prop you need.
                  return col.title.props.text;
                }
                return col.title;
              });

              // Turn data into an array of string arrays, without the `tableData` prop
              const dataRows = data.map(({ tableData, ...row }) => Object.values(row));

              // Aggregate header data and 'body' data
              // Mirror default export behavior by joining data via
              // the delimiter specified within material table (by default comma delimited)
              const { exportDelimiter } = tableRef.current.props.options;
              const delimiter = exportDelimiter ? exportDelimiter : ",";
              const csvContent = [headerRow, ...dataRows].map((e) => e.join(delimiter)).join("\n");

              // This mirrors the default export behavior where the
              // exported file name is the table title.
              const csvFileName = tableRef.current.props.title;

              // Allow user to download file as .csv
              downloadCsv(csvContent, csvFileName);
            },
          },
        ],
      }}
    />
  );
};

Lol no worries. I've been known to misunderstand.
If I do understand this correctly, you are wanting to specify a custom function for exporting data, correct?
In the new model, the concept of exporting csv or exporting pdf no longer exists. You provide an array of objects with this shape:
exportMenu: [{
      label: 'Export PDF',
      exportFunc: (cols, datas) => ExportPdf(cols, datas, 'myPdfFileName')
    },
//....

And we add it to the menu. Notice the exportFunc - I believe that accomplishes the same thing as you described.
This way allows is to not hard code csv or pdf. Just give us an array of objects with the correct shape and we add it to the menu.
We separated the pdf and csv export defaults due to bundle bloat. That article shows how you can still use them though. You just have to import them.

I absolutely love how you guys separated the export menu like that, makes sense. Having said that the challenge here is that datas (referenced above) doesn't always hold the correct shape (i.e. all columns are not always flat data), that's why the customExport function at Column Definition level handles that then passes it to the exportToCSV / pdf etc.. This is particularly useful in scenarios where you might have complex user data or embedded arrays within a column, as show in updated demo file.

Lol no worries. I've been known to misunderstand.
If I do understand this correctly, you are wanting to specify a custom function for exporting data, correct?
In the new model, the concept of exporting csv or exporting pdf no longer exists. You provide an array of objects with this shape:
exportMenu: [{
      label: 'Export PDF',
      exportFunc: (cols, datas) => ExportPdf(cols, datas, 'myPdfFileName')
    },
//....

And we add it to the menu. Notice the exportFunc - I believe that accomplishes the same thing as you described.
This way allows is to not hard code csv or pdf. Just give us an array of objects with the correct shape and we add it to the menu.
We separated the pdf and csv export defaults due to bundle bloat. That article shows how you can still use them though. You just have to import them.

I absolutely love how you guys separated the export menu like that, makes sense. Having said that the challenge here is that datas (referenced above) doesn't always hold the correct shape (i.e. all columns are not always flat data), that's why the customExport function at Column Definition level handles that then passes it to the exportToCSV / pdf etc.. This is particularly useful in scenarios where you might have complex user data or embedded arrays within a column, as show in updated demo file.

@hbermani
To demonstrate, this is how you could use a custom export function to detect if the column header is not a string (if you're using JSX as the column title). This way you can replace it with a string so that the export doesn't show [object, Object] as the column header.
Or you could use the default import ExportCsv from '@material-table/core/exporters/csv';
const App = () => {
  return (
    <MaterialTable
      // ... other props
      options={{
        exportMenu: [
          {
            label: "Export CSV",
            exportFunc: (columns, data) => {
              // Turn headers into array of strings
              const headerRow = columns.map((col) => {
                if (typeof col.title === "object") {
                  // I am not sure what props the Translate component exposes
                  // but you would need to change `text` in `col.title.props.text`
                  // to whatever prop you need.
                  return col.title.props.text;
                }
                return col.title;
              });

              // Turn data into an array of string arrays, without the `tableData` prop
              const dataRows = data.map(({ tableData, ...row }) => Object.values(row));

              // Aggregate header data and 'body' data
              // Mirror default export behavior by joining data via
              // the delimiter specified within material table (by default comma delimited)
              const { exportDelimiter } = tableRef.current.props.options;
              const delimiter = exportDelimiter ? exportDelimiter : ",";
              const csvContent = [headerRow, ...dataRows].map((e) => e.join(delimiter)).join("\n");

              // This mirrors the default export behavior where the
              // exported file name is the table title.
              const csvFileName = tableRef.current.props.title;

              // Allow user to download file as .csv
              downloadCsv(csvContent, csvFileName);
            },
          },
        ],
      }}
    />
  );
};

That should do it, but imagine with the complexity of so many different data structures in an application how many exporter conditions you would have. I don't think it would scale nicely. The export to csv should do one thing only (export to csv), custom manipulation of underlying data is better managed IMHO at the column level.

@hbermani
To demonstrate, this is how you could use a custom export function to detect if the column header is not a string (if you're using JSX as the column title). This way you can replace it with a string so that the export doesn't show [object, Object] as the column header.
Or you could use the default import ExportCsv from '@material-table/core/exporters/csv';
const App = () => {
  return (
    <MaterialTable
      // ... other props
      options={{
        exportMenu: [
          {
            label: "Export CSV",
            exportFunc: (columns, data) => {
              // Turn headers into array of strings
              const headerRow = columns.map((col) => {
                if (typeof col.title === "object") {
                  // I am not sure what props the Translate component exposes
                  // but you would need to change `text` in `col.title.props.text`
                  // to whatever prop you need.
                  return col.title.props.text;
                }
                return col.title;
              });

              // Turn data into an array of string arrays, without the `tableData` prop
              const dataRows = data.map(({ tableData, ...row }) => Object.values(row));

              // Aggregate header data and 'body' data
              // Mirror default export behavior by joining data via
              // the delimiter specified within material table (by default comma delimited)
              const { exportDelimiter } = tableRef.current.props.options;
              const delimiter = exportDelimiter ? exportDelimiter : ",";
              const csvContent = [headerRow, ...dataRows].map((e) => e.join(delimiter)).join("\n");

              // This mirrors the default export behavior where the
              // exported file name is the table title.
              const csvFileName = tableRef.current.props.title;

              // Allow user to download file as .csv
              downloadCsv(csvContent, csvFileName);
            },
          },
        ],
      }}
    />
  );
};

That should do it, but imagine with the complexity of so many different data structures in an application how many exporter conditions you would have. I don't think it would scale nicely. The export to csv should do one thing only (export to csv), custom manipulation of underlying data is better managed IMHO at the column level.

@hbermani but thats the thing though. @material-table/core has no concept of "csv". It has no default way for you to export a CSV.
In fact, it doesn't matter what you're exporting. Let's say you need to export table data to a custom file format (for whatever reason), as well as to pdf...
We have abstracted the export process - exportCsv no longer exists. We give you a function and the data to do what you need to do, PLUS the freedom to add custom export menu items (before you had two options only exportCsv and exportPdf, now you are not limited to any of that).
Hope this makes sense.

@hbermani but thats the thing though. @material-table/core has no concept of "csv". It has no default way for you to export a CSV.
In fact, it doesn't matter what you're exporting. Let's say you need to export table data to a custom file format (for whatever reason), as well as to pdf...
We have abstracted the export process - exportCsv no longer exists. We give you a function and the data to do what you need to do, PLUS the freedom to add custom export menu items (before you had two options only exportCsv and exportPdf, now you are not limited to any of that).
Hope this makes sense.

@hbermani but thats the thing though. @material-table/core has no concept of "csv". It has no default way for you to export a CSV.
In fact, it doesn't matter what you're exporting. Let's say you need to export table data to a custom file format (for whatever reason), as well as to pdf...
We have abstracted the export process - exportCsv no longer exists. We give you a function and the data to do what you need to do, PLUS the freedom to add custom export menu items (before you had two options only exportCsv and exportPdf, now you are not limited to any of that).
Hope this makes sense.

It makes total sense, so picture the data structure below, if we wanted to export the field 'teams' into csv, pdf, txt etc alongside other columns, the current implementation means, we need to reimplement exportFunc for each exporter rather than the proposed addition which allows further flexibility as it handles data manipulation at Column Definition thus avoiding duplication, it's also more efficient as it doesn't have to map through the data again as it's handline the changes when it's getting the field value.
const global_data_CustomExport = [
  {
    name: 'Mehmet',
    surname: 'Baran',
    birthYear: 1987,
    birthCity: 63,
    teams: ['Team A', 'Team B']
  },
  {
    name: 'Zerya Betül',
    surname: 'Baran',
    birthYear: 2017,
    birthCity: 34,
    teams: ['Team C', 'Team D', 'Team E']
  }
]```

@hbermani but thats the thing though. @material-table/core has no concept of "csv". It has no default way for you to export a CSV.
In fact, it doesn't matter what you're exporting. Let's say you need to export table data to a custom file format (for whatever reason), as well as to pdf...
We have abstracted the export process - exportCsv no longer exists. We give you a function and the data to do what you need to do, PLUS the freedom to add custom export menu items (before you had two options only exportCsv and exportPdf, now you are not limited to any of that).
Hope this makes sense.

It makes total sense, so picture the data structure below, if we wanted to export the field 'teams' into csv, pdf, txt etc alongside other columns, the current implementation means, we need to reimplement exportFunc for each exporter rather than the proposed addition which allows further flexibility as it handles data manipulation at Column Definition thus avoiding duplication, it's also more efficient as it doesn't have to map through the data again as it's handline the changes when it's getting the field value.
const global_data_CustomExport = [
  {
    name: 'Mehmet',
    surname: 'Baran',
    birthYear: 1987,
    birthCity: 63,
    teams: ['Team A', 'Team B']
  },
  {
    name: 'Zerya Betül',
    surname: 'Baran',
    birthYear: 2017,
    birthCity: 34,
    teams: ['Team C', 'Team D', 'Team E']
  }
]```

I still don't see the difference. You are not 'reimplementing' the func for each menu item. Each menu item has to have it's own func.
Inside of said func, you can literally do whatever you need to do with data from anywhere you want to get it from. Literally. You can do whatever you want. You have complete control of the data that is being exported.

I still don't see the difference. You are not 'reimplementing' the func for each menu item. Each menu item has to have it's own func.
Inside of said func, you can literally do whatever you need to do with data from anywhere you want to get it from. Literally. You can do whatever you want. You have complete control of the data that is being exported.

You could just do:
I believe including that option as part of the column definition only confuses writing code for this library, as well as writing code using this library. It doesn't make sense to have it as part of the column definition.
exportMenu: [{
      label: 'Export PDF',
      exportFunc: (cols, datas) => {
        // You can do whatever you want here
        let dataToExport = [];
        cols.map(col => { col.teams.forEach(team => dataToExport.push(team) ) }) }
    },
//....

You could just do:
I believe including that option as part of the column definition only confuses writing code for this library, as well as writing code using this library. It doesn't make sense to have it as part of the column definition.
exportMenu: [{
      label: 'Export PDF',
      exportFunc: (cols, datas) => {
        // You can do whatever you want here
        let dataToExport = [];
        cols.map(col => { col.teams.forEach(team => dataToExport.push(team) ) }) }
    },
//....

I still don't see the difference. You are not 'reimplementing' the func for each menu item. Each menu item has to have it's own func.
Inside of said func, you can literally do whatever you need to do with data from anywhere you want to get it from. Literally. You can do whatever you want. You have complete control of the data that is being exported.

That's the thing, I am not proposing a change in how the export logic has been implemented, it's great as is. The change is mainly concerned with the underlying data before it gets to whatever custom Exporter. To be more specific this is the bit of code which handles it under  src/components/MTableToolbar/index.js
 const data = (props.exportAllData ? props.data : props.renderData).map(
      (rowData) =>
        columns.map((columnDef) => {
          if (typeof columnDef.customExport === 'function') {
            return columnDef.customExport(rowData);
          }
          return props.getFieldValue(rowData, columnDef);
        })

The type check for a "function" above allows users to pass a custom function at column definition level that handles the shaping of the data before it's passed to whatever exporter being used rather than looping data at each exporter to shape it.

I still don't see the difference. You are not 'reimplementing' the func for each menu item. Each menu item has to have it's own func.
Inside of said func, you can literally do whatever you need to do with data from anywhere you want to get it from. Literally. You can do whatever you want. You have complete control of the data that is being exported.

That's the thing, I am not proposing a change in how the export logic has been implemented, it's great as is. The change is mainly concerned with the underlying data before it gets to whatever custom Exporter. To be more specific this is the bit of code which handles it under  src/components/MTableToolbar/index.js
 const data = (props.exportAllData ? props.data : props.renderData).map(
      (rowData) =>
        columns.map((columnDef) => {
          if (typeof columnDef.customExport === 'function') {
            return columnDef.customExport(rowData);
          }
          return props.getFieldValue(rowData, columnDef);
        })

The type check for a "function" above allows users to pass a custom function at column definition level that handles the shaping of the data before it's passed to whatever exporter being used rather than looping data at each exporter to shape it.

You could just do:
I believe including that option as part of the column definition only confuses writing code for this library, as well as writing code using this library. It doesn't make sense to have it as part of the column definition.
exportMenu: [{
      label: 'Export PDF',
      exportFunc: (cols, datas) => {
        // You can do whatever you want here
        let dataToExport = [];
        cols.map(col => { col.teams.forEach(team => dataToExport.push(team) ) }) }
    },
//....

Now let's say you want to export this to a flat file or csv too.... you will have to re-write the same logic for each exporter.
         let dataToExport = [];
>         cols.map(col => { col.teams.forEach(team => dataToExport.push(team) ) }) }

You could just do:
I believe including that option as part of the column definition only confuses writing code for this library, as well as writing code using this library. It doesn't make sense to have it as part of the column definition.
exportMenu: [{
      label: 'Export PDF',
      exportFunc: (cols, datas) => {
        // You can do whatever you want here
        let dataToExport = [];
        cols.map(col => { col.teams.forEach(team => dataToExport.push(team) ) }) }
    },
//....

Now let's say you want to export this to a flat file or csv too.... you will have to re-write the same logic for each exporter.
         let dataToExport = [];
>         cols.map(col => { col.teams.forEach(team => dataToExport.push(team) ) }) }

That's exactly what exportFunc does. I just showed a demo that checks for the header to be an object (instead of a func) but its the exact same logic.
Then we have a property on a columns object for exporting data as well as properties to export data in options. Having to configure two separate settings to accomplish the same thing makes no sense to me.

That's exactly what exportFunc does. I just showed a demo that checks for the header to be an object (instead of a func) but its the exact same logic.
Then we have a property on a columns object for exporting data as well as properties to export data in options. Having to configure two separate settings to accomplish the same thing makes no sense to me.

Exactly that's what we want. It allows for freedom of exporting to whatever you want. Even a flat file with any extension you could possibly imagine.
That's exactly why we provide the default csv and pdf exports. To keep your code clean.
Outside of that, anything custom would need to have it's own method used to export.
Adding another prop only makes things a million times more confusing. It's just unnecessary. There are ways you can abstract your exporters to eliminate duplicate code, but all of that needs to be done in userland in the export func. This allows us to remain highly configurable, easy to understand, and efficient.

Exactly that's what we want. It allows for freedom of exporting to whatever you want. Even a flat file with any extension you could possibly imagine.
That's exactly why we provide the default csv and pdf exports. To keep your code clean.
Outside of that, anything custom would need to have it's own method used to export.
Adding another prop only makes things a million times more confusing. It's just unnecessary. There are ways you can abstract your exporters to eliminate duplicate code, but all of that needs to be done in userland in the export func. This allows us to remain highly configurable, easy to understand, and efficient.

That's exactly what exportFunc does. I just showed a demo that checks for the header to be an object (instead of a func) but its the exact same logic.
Then we have a property on a columns object for exporting data as well as properties to export data in options. Having to configure two separate settings to accomplish the same thing makes no sense to me.

Our brains are clearly wired differently :-D . I can see it's the same logic, it's just that extra bit of flexibility so the logic is handled at the data layer (column) rather than the exporter, otherwise with many export functions you will end up repeating the same logic and in turn have less consistency between exporters (Which in all fairness may be desirable by some), but in other scenarios isn't.
I feel we are going in circles here lol!

That's exactly what exportFunc does. I just showed a demo that checks for the header to be an object (instead of a func) but its the exact same logic.
Then we have a property on a columns object for exporting data as well as properties to export data in options. Having to configure two separate settings to accomplish the same thing makes no sense to me.

Our brains are clearly wired differently :-D . I can see it's the same logic, it's just that extra bit of flexibility so the logic is handled at the data layer (column) rather than the exporter, otherwise with many export functions you will end up repeating the same logic and in turn have less consistency between exporters (Which in all fairness may be desirable by some), but in other scenarios isn't.
I feel we are going in circles here lol!

I've been refactoring this code and one of the biggest problems is unnecessary props like that. Which, are not easy to troubleshoot. I can only imagine the pain of trying to troubleshoot the fact there are 2 properties in diff places that help serve a single feature. Its one of those things that if it isn't documented or commented - have fun reading that code.
One of the major benefits of material-table is how we expose so much of our internals, allowing you to be extremely modular.

I've been refactoring this code and one of the biggest problems is unnecessary props like that. Which, are not easy to troubleshoot. I can only imagine the pain of trying to troubleshoot the fact there are 2 properties in diff places that help serve a single feature. Its one of those things that if it isn't documented or commented - have fun reading that code.
One of the major benefits of material-table is how we expose so much of our internals, allowing you to be extremely modular.

The reason I proposed it at the column level is because custom render is handled there as well and the two are very interlinked in terms of what they serve, so to render a complex object using the "render" prop under Columns to me is no different to using "customExport" or it can be named whatever to handle the same object in the exporter. One is prepping it for HTML the other for whatever format the exporter likes.
And the best part is, it doesn't change any of the existing implementation, it just adds additional flexibility, as an option, for scenarios where it makes sense and consistency is desired across exporters.

The reason I proposed it at the column level is because custom render is handled there as well and the two are very interlinked in terms of what they serve, so to render a complex object using the "render" prop under Columns to me is no different to using "customExport" or it can be named whatever to handle the same object in the exporter. One is prepping it for HTML the other for whatever format the exporter likes.
And the best part is, it doesn't change any of the existing implementation, it just adds additional flexibility, as an option, for scenarios where it makes sense and consistency is desired across exporters.

I would agree that we are wired differently lol.. To me, custom render and custom export are not, and should not be, reliant on each other whatsoever. Coupling them is only asking for trouble.
The custom render function for columns makes sense to have on each column object, in my opinion. That is because it has to deal directly with the column itself. Exporting does not deal with a specific column (although, it could now) - it deals with exporting data.
Ultimately, using exportMenu gives you access to the exact same columns object/data anyway. If one of our concerns is duplicate code, why handle the same feature (exporting) in two different (duplicate) places? That should be concerning to us. (again, especially when the exportFunc provides you access to that exact same data anyway. handling this in the columns object feels convoluted).

I would agree that we are wired differently lol.. To me, custom render and custom export are not, and should not be, reliant on each other whatsoever. Coupling them is only asking for trouble.
The custom render function for columns makes sense to have on each column object, in my opinion. That is because it has to deal directly with the column itself. Exporting does not deal with a specific column (although, it could now) - it deals with exporting data.
Ultimately, using exportMenu gives you access to the exact same columns object/data anyway. If one of our concerns is duplicate code, why handle the same feature (exporting) in two different (duplicate) places? That should be concerning to us. (again, especially when the exportFunc provides you access to that exact same data anyway. handling this in the columns object feels convoluted).

I would agree that we are wired differently lol.. To me, custom render and custom export are not, and should not be, reliant on each other whatsoever. Coupling them is only asking for trouble.
The custom render function for columns makes sense to have on each column object, in my opinion. That is because it has to deal directly with the column itself. Exporting does not deal with a specific column (although, it could now) - it deals with exporting data.
Ultimately, using exportMenu gives you access to the exact same columns object/data anyway. If one of our concerns is duplicate code, why handle the same feature (exporting) in two different (duplicate) places? That should be concerning to us. (again, especially when the exportFunc provides you access to that exact same data anyway. handling this in the columns object feels convoluted).

I certainly don't want them to be coupled... blimey that would be a nightmare indeed lol... I am saying they are similar in terms of where they are placed in the code. And to the same point you raised about handling specific column, this is exactly what we want to do here, handle a specific column that does not hold flat data and to me the data logic shouldn't be handled in the exporter.
So using my not so great skills of trying to illustrate it (haha) here is how I picture it.
Rendering:

data  ==> Column render prop (Changes content to suit HTML) => Displays on table

Exporting (current implementation) :

data ==> Displays on Exporter (Handles data change there)

Export (Proposed add-on)
In addition to the above

data ==> Column export prop (Changes content to suit export) => Displays on Exporter

May be the use of the term customExport is not the best, what we are trying to do here is essentially ETL for export purposes.

I would agree that we are wired differently lol.. To me, custom render and custom export are not, and should not be, reliant on each other whatsoever. Coupling them is only asking for trouble.
The custom render function for columns makes sense to have on each column object, in my opinion. That is because it has to deal directly with the column itself. Exporting does not deal with a specific column (although, it could now) - it deals with exporting data.
Ultimately, using exportMenu gives you access to the exact same columns object/data anyway. If one of our concerns is duplicate code, why handle the same feature (exporting) in two different (duplicate) places? That should be concerning to us. (again, especially when the exportFunc provides you access to that exact same data anyway. handling this in the columns object feels convoluted).

I certainly don't want them to be coupled... blimey that would be a nightmare indeed lol... I am saying they are similar in terms of where they are placed in the code. And to the same point you raised about handling specific column, this is exactly what we want to do here, handle a specific column that does not hold flat data and to me the data logic shouldn't be handled in the exporter.
So using my not so great skills of trying to illustrate it (haha) here is how I picture it.
Rendering:

data  ==> Column render prop (Changes content to suit HTML) => Displays on table

Exporting (current implementation) :

data ==> Displays on Exporter (Handles data change there)

Export (Proposed add-on)
In addition to the above

data ==> Column export prop (Changes content to suit export) => Displays on Exporter

May be the use of the term customExport is not the best, what we are trying to do here is essentially ETL for export purposes.

I completely understand what you're saying but to me it would be so much easier to read with everything in one spot. The exporting is what takes the raw data, manipulates it, then exports it.
Your way would 100% work, I just don't like it lol (much like you don't like mine haha)...
With that being said I'm open to changing it, if that is what everyone agrees upon. I think taking a poll of some sort would help. Perhaps, I am the odd man out?

I completely understand what you're saying but to me it would be so much easier to read with everything in one spot. The exporting is what takes the raw data, manipulates it, then exports it.
Your way would 100% work, I just don't like it lol (much like you don't like mine haha)...
With that being said I'm open to changing it, if that is what everyone agrees upon. I think taking a poll of some sort would help. Perhaps, I am the odd man out?

I completely understand what you're saying but to me it would be so much easier to read with everything in one spot. The exporting is what takes the raw data, manipulates it, then exports it.
Your way would 100% work, I just don't like it lol (much like you don't like mine haha)...
With that being said I'm open to changing it, if that is what everyone agrees upon. I think taking a poll of some sort would help. Perhaps, I am the odd man out?

Haha, I honestly don't see it as either or, as it an addition rather than a replacement to existing implementation. I'll post on the original PR for people to add their thoughts and link to here. :-)

I completely understand what you're saying but to me it would be so much easier to read with everything in one spot. The exporting is what takes the raw data, manipulates it, then exports it.
Your way would 100% work, I just don't like it lol (much like you don't like mine haha)...
With that being said I'm open to changing it, if that is what everyone agrees upon. I think taking a poll of some sort would help. Perhaps, I am the odd man out?

Haha, I honestly don't see it as either or, as it an addition rather than a replacement to existing implementation. I'll post on the original PR for people to add their thoughts and link to here. :-)

Another benefit that the freedom of exportMenu allows is exporting remote data. Otherwise, there would have to be some hard coded prop for exporting remote data.
Overall, to me, it's just easier to understand as a consumer as well as a contributor. It's just more obvious and the abstraction helps other aspects and features of the app.

Another benefit that the freedom of exportMenu allows is exporting remote data. Otherwise, there would have to be some hard coded prop for exporting remote data.
Overall, to me, it's just easier to understand as a consumer as well as a contributor. It's just more obvious and the abstraction helps other aspects and features of the app.

I think we could change the prop name exportFunc to onExport though lol. I hate myself for not thinking of that sooner.

I think we could change the prop name exportFunc to onExport though lol. I hate myself for not thinking of that sooner.

I think we could change the prop name exportFunc to onExport though lol. I hate myself for not thinking of that sooner.

Oooo... though that would cause breaking changes...how about if the new customExport is called onExport ... I know I am blowing your mind now haha!!

I think we could change the prop name exportFunc to onExport though lol. I hate myself for not thinking of that sooner.

Oooo... though that would cause breaking changes...how about if the new customExport is called onExport ... I know I am blowing your mind now haha!!

lol @Domino987 what do you think about this? I know it's a long read but whatever you decide is where we will go. You are the deciding vote, my friend!
My vote is to not introduce this property as I believe it confuses things, both internally and externally, and it is unnecessary.
Thoughts?

lol @Domino987 what do you think about this? I know it's a long read but whatever you decide is where we will go. You are the deciding vote, my friend!
My vote is to not introduce this property as I believe it confuses things, both internally and externally, and it is unnecessary.
Thoughts?

lol @Domino987 what do you think about this? I know it's a long read but whatever you decide is where we will go. You are the deciding vote, my friend!
My vote is to not introduce this property as I believe it confuses things, both internally and externally, and it is unnecessary.
Thoughts?

@Domino987 Summary of my thoughts here https://github.com/mbrn/material-table/pull/2089#issuecomment-767100416

lol @Domino987 what do you think about this? I know it's a long read but whatever you decide is where we will go. You are the deciding vote, my friend!
My vote is to not introduce this property as I believe it confuses things, both internally and externally, and it is unnecessary.
Thoughts?

@Domino987 Summary of my thoughts here https://github.com/mbrn/material-table/pull/2089#issuecomment-767100416

Ok, people ;) That's a long thread and I see both sides. You have both great arguments and I have a difficulty to decide, but I think I would go with @hbermani 's way I think.
Material table is not only offering great customization, which is totally does, but I think the main reason is it easy use.
In my estimation, 99% of the use cases will be I want to export to csv/pdf and I only have this one header that needs to change (at least that was the one use case I had a while back).
That should not lead to writing one or more whole data manipulation and export functions, IMO.
IF somebody wants a custom export in addition, they could just use a free action and handle the onClick themselves right?. At least that's how I fixed it. And this will probably not be the use case,  I think.
SO while I see both sides, I think the majority of use cases will be single column header changes, or flattening of one column, so my vote would go to single column.

Ok, people ;) That's a long thread and I see both sides. You have both great arguments and I have a difficulty to decide, but I think I would go with @hbermani 's way I think.
Material table is not only offering great customization, which is totally does, but I think the main reason is it easy use.
In my estimation, 99% of the use cases will be I want to export to csv/pdf and I only have this one header that needs to change (at least that was the one use case I had a while back).
That should not lead to writing one or more whole data manipulation and export functions, IMO.
IF somebody wants a custom export in addition, they could just use a free action and handle the onClick themselves right?. At least that's how I fixed it. And this will probably not be the use case,  I think.
SO while I see both sides, I think the majority of use cases will be single column header changes, or flattening of one column, so my vote would go to single column.

Right on, if you all think it is beneficial then lets add it.  I still think it is unnecessary.
Whether one column or 100 columns - simplicity matters over all, and this way is not very simple (yes, it is simple for a very specific use case, which again, we should have no opinion on).
Another example of how this can be harmful - sometimes it is hard to tell at face value what the purpose of a property is.. I feel like this solution is how we wind up with things like this:
https://github.com/material-table-core/core/blob/881a48a9d19d10b28fb3522a7f39e9a70fb7e5b7/src/utils/data-manager.js#L960
and
https://github.com/material-table-core/core/blob/881a48a9d19d10b28fb3522a7f39e9a70fb7e5b7/src/utils/data-manager.js#L539
What is the difference (at face value)?
Which one should I use for what and why?
Now I have to not only read code, but try and understand the context that code is being used in, all to simply understand the difference between those two. (Yes, this is a simple example, but the idea remains the same.)
Separating functionality like this is the definition of spaghetti code, and it's how we wound up with so many confusing props strewn about everywhere to begin with... This code base is extremely difficult to read because of things like this, imo..
You're right, adding a prop is quick and easy for a single column, but it's a bandaid solution for a specific use case, and no easier than adding a single object to exportMenu.
Just my 2c tho, feel free to make any changes!

Right on, if you all think it is beneficial then lets add it.  I still think it is unnecessary.
Whether one column or 100 columns - simplicity matters over all, and this way is not very simple (yes, it is simple for a very specific use case, which again, we should have no opinion on).
Another example of how this can be harmful - sometimes it is hard to tell at face value what the purpose of a property is.. I feel like this solution is how we wind up with things like this:
https://github.com/material-table-core/core/blob/881a48a9d19d10b28fb3522a7f39e9a70fb7e5b7/src/utils/data-manager.js#L960
and
https://github.com/material-table-core/core/blob/881a48a9d19d10b28fb3522a7f39e9a70fb7e5b7/src/utils/data-manager.js#L539
What is the difference (at face value)?
Which one should I use for what and why?
Now I have to not only read code, but try and understand the context that code is being used in, all to simply understand the difference between those two. (Yes, this is a simple example, but the idea remains the same.)
Separating functionality like this is the definition of spaghetti code, and it's how we wound up with so many confusing props strewn about everywhere to begin with... This code base is extremely difficult to read because of things like this, imo..
You're right, adding a prop is quick and easy for a single column, but it's a bandaid solution for a specific use case, and no easier than adding a single object to exportMenu.
Just my 2c tho, feel free to make any changes!

Let me know if you publish a new version with these changes - I'll update the docs.

Let me know if you publish a new version with these changes - I'll update the docs.

Good morning folks, from the UK, please let me know if I need to do anything my end to get this past the finish line.
@oze4 , thank you for your patience in considering this PR, replacing the term customExport with onExport might be more intuitive, whichever you feel makes more sense to add further clarity.

Good morning folks, from the UK, please let me know if I need to do anything my end to get this past the finish line.
@oze4 , thank you for your patience in considering this PR, replacing the term customExport with onExport might be more intuitive, whichever you feel makes more sense to add further clarity.

My use case was exactly as @Domino987 above. One or two columns for display, not wholesale manipulation. Exporting was handled at the back end as the formatting and manipulation of the exported document required a additional processing (logo's formatting, watermarks etc)
Thanks for the consideration.

My use case was exactly as @Domino987 above. One or two columns for display, not wholesale manipulation. Exporting was handled at the back end as the formatting and manipulation of the exported document required a additional processing (logo's formatting, watermarks etc)
Thanks for the consideration.

Good morning folks, from the UK, please let me know if I need to do anything my end to get this past the finish line.
@oze4 , thank you for your patience in considering this PR, replacing the term customExport with onExport might be more intuitive, whichever you feel makes more sense to add further clarity.

I added one change request.

Good morning folks, from the UK, please let me know if I need to do anything my end to get this past the finish line.
@oze4 , thank you for your patience in considering this PR, replacing the term customExport with onExport might be more intuitive, whichever you feel makes more sense to add further clarity.

I added one change request.

One or two columns, not wholesale manipulation

@mogilvie it isn't "wholesale manipulation" and is very very simple to make necessary changes (and not as confusing imo). Keeps everything in one place!
Have you read the codebase by any chance @mogilvie ?

One or two columns, not wholesale manipulation

@mogilvie it isn't "wholesale manipulation" and is very very simple to make necessary changes (and not as confusing imo). Keeps everything in one place!
Have you read the codebase by any chance @mogilvie ?

If you search through mbrn/material-table issues you will see people wanting more than csv or pdf exports. Exporting should not be assumed or handled by material-table (or the "back end").

If you search through mbrn/material-table issues you will see people wanting more than csv or pdf exports. Exporting should not be assumed or handled by material-table (or the "back end").

If you search through mbrn/material-table issues you will see people wanting more than csv or pdf exports. exportMenu allows you to export however you want and now you're not limited. Exporting should not be assumed or handled by material-table (or the "back end"). Boggles my mind you all cant see that!!

I can certainly see your point Oze4, but it comes down to ease of use to manipulate the data in one place, just like we handle custom render for complex columns.  Besides, it doesn't stop someone from applying changes at an exporter level, so it's the best of both worlds.

If you search through mbrn/material-table issues you will see people wanting more than csv or pdf exports. exportMenu allows you to export however you want and now you're not limited. Exporting should not be assumed or handled by material-table (or the "back end"). Boggles my mind you all cant see that!!

I can certainly see your point Oze4, but it comes down to ease of use to manipulate the data in one place, just like we handle custom render for complex columns.  Besides, it doesn't stop someone from applying changes at an exporter level, so it's the best of both worlds.

Good morning folks, from the UK, please let me know if I need to do anything my end to get this past the finish line.
@oze4 , thank you for your patience in considering this PR, replacing the term customExport with onExport might be more intuitive, whichever you feel makes more sense to add further clarity.

I added one change request.

I have updated prop return type.

Good morning folks, from the UK, please let me know if I need to do anything my end to get this past the finish line.
@oze4 , thank you for your patience in considering this PR, replacing the term customExport with onExport might be more intuitive, whichever you feel makes more sense to add further clarity.

I added one change request.

I have updated prop return type.

@hbermani I completely understand the intent. It just doesn't make much sense to me. Render !== export so they should be treated differently, but as you say this doesn't prevent someone from doing anything it just gives them more options.
But again, if you read through the codebase you'll quickly discover props spread out across components like this (that serve a single feature) make things extremely difficult to keep track of and digest. So now when someone is using this codebase it isn't as straight forward. They will see an onExport in columns and an onExport in exportMenu. See what I'm saying? Two props. Named the exact same. Serving the exact same purpose. Yet they are in two completely different places, it's just confusing and unnecessary.
Above everything else, that is my biggest concern. Not use case, not ease-of-use (both of these solutions are easy), but the fact that it makes the codebase feel like spaghetti, hard to read, and creates duplicate props..

@hbermani I completely understand the intent. It just doesn't make much sense to me. Render !== export so they should be treated differently, but as you say this doesn't prevent someone from doing anything it just gives them more options.
But again, if you read through the codebase you'll quickly discover props spread out across components like this (that serve a single feature) make things extremely difficult to keep track of and digest. So now when someone is using this codebase it isn't as straight forward. They will see an onExport in columns and an onExport in exportMenu. See what I'm saying? Two props. Named the exact same. Serving the exact same purpose. Yet they are in two completely different places, it's just confusing and unnecessary.
Above everything else, that is my biggest concern. Not use case, not ease-of-use (both of these solutions are easy), but the fact that it makes the codebase feel like spaghetti, hard to read, and creates duplicate props..

@oze4 Isn't that what docs are for though, personally I just refer to docs like the ones here (https://material-table.com/#/docs/all-props) and read what it does under each section as things change all the time. I kept the naming as customExport for now.
There isn't more I can say about this, if you are the gatekeeper and you don't want it in then it's your decision and nothing more I can say or do will change that. I appreciate the time you took to review this.

@oze4 Isn't that what docs are for though, personally I just refer to docs like the ones here (https://material-table.com/#/docs/all-props) and read what it does under each section as things change all the time. I kept the naming as customExport for now.
There isn't more I can say about this, if you are the gatekeeper and you don't want it in then it's your decision and nothing more I can say or do will change that. I appreciate the time you took to review this.

Docs can help in any situation but relying on them isn't a good idea. Your code should be "self documenting" and easy to understand why a certain prop/func/etc.. is being used based off of context and naming. The ONLY way to know the column.onExport and the exportMenu.onExport are related is via the docs. That's a huge problem.
Not to mention the extra worked that has now been created. Someone has to update the docs. What if that prop changes name? Now you have to edit 2 files, updates the docs, etc.. etc.. etc...
Now lets say we are relying on the docs to explain 20 props. This gets out of hand very quickly (just read the current codebase for yourself to see).

Docs can help in any situation but relying on them isn't a good idea. Your code should be "self documenting" and easy to understand why a certain prop/func/etc.. is being used based off of context and naming. The ONLY way to know the column.onExport and the exportMenu.onExport are related is via the docs. That's a huge problem.
Not to mention the extra worked that has now been created. Someone has to update the docs. What if that prop changes name? Now you have to edit 2 files, updates the docs, etc.. etc.. etc...
Now lets say we are relying on the docs to explain 20 props. This gets out of hand very quickly (just read the current codebase for yourself to see).

Do you want me to add comments on each new line I added to explain what it does for future code reviews?
Ps. it's still called customExport and not onExport in column.

Do you want me to add comments on each new line I added to explain what it does for future code reviews?
Ps. it's still called customExport and not onExport in column.

I think it wouldn't hurt but it's up to you.
The prop names haven't been changed yet (just imagine how much more confusing it is to relate columns.customExport to exportMenu.exportFunc. At least naming them the other way is a little more obvious. That's why I used those names in my examples.

I think it wouldn't hurt but it's up to you.
The prop names haven't been changed yet (just imagine how much more confusing it is to relate columns.customExport to exportMenu.exportFunc. At least naming them the other way is a little more obvious. That's why I used those names in my examples.

Added the comments, would you like me to amend anything else or is it still a no go?

Added the comments, would you like me to amend anything else or is it still a no go?

I think its a for sure go (I am the odd one out here).
I have no other requests. Unless @Domino987 has any suggestions I think we are good to merge this one.

I think its a for sure go (I am the odd one out here).
I have no other requests. Unless @Domino987 has any suggestions I think we are good to merge this one.

I think its a for sure go (I am the odd one out here).
I have no other requests. Unless @Domino987 has any suggestions I think we are good to merge this one.

Thank you, appreciate your patience with it.

I think its a for sure go (I am the odd one out here).
I have no other requests. Unless @Domino987 has any suggestions I think we are good to merge this one.

Thank you, appreciate your patience with it.

I may have strong opinions but let's be honest I should be thanking you all for your patience lol
Thanks for the contribution!

I may have strong opinions but let's be honest I should be thanking you all for your patience lol
Thanks for the contribution!

I may have strong opinions but let's be honest I should be thanking you all for your patience lol
Thanks for the contribution!

No thank you for keeping this much needed library alive!!

I may have strong opinions but let's be honest I should be thanking you all for your patience lol
Thanks for the contribution!

No thank you for keeping this much needed library alive!!

I appreciate the gesture but it's not just me. I'm like 1/1000th lol it's really bc of all of us, including you, that are keeping it alive. @Domino987 deserves all the kudos.

I appreciate the gesture but it's not just me. I'm like 1/1000th lol it's really bc of all of us, including you, that are keeping it alive. @Domino987 deserves all the kudos.

@Domino987 are we good to merge this?

@Domino987 are we good to merge this?

Yes looks good to me. Thank you for your contribution. It is much appreciated. Sorry for being afk a few days.

This has been published with v2.3.25!
Thanks @Domino987 appreciate it!


match comparator terms with PSDO

Revise pipeline to use input message column names for comparator terms that match PSDO
For example, replace "Top_10_Average" with "peer 90th percentile benchmark"

Use underscores instead of spaces for all labels, like "peer_90th_percentile_benchmark"

The changes to column names are made with commit


Data processing script is not working

Hi there!
I am getting the following error in MaSIF data processing. I followed the demo example
root@dc2aa58b2fb5:/masif/data/masif_site# ./data_prepare_one.sh 4ZQK_A
Downloading PDB structure '4ZQK'...
Desired structure doesn't exists
Empty
pdb filename
/tmp/4ZQK.pdb
Traceback (most recent call last):
  File "/masif/source//data_preparation/01-pdb_extract_and_triangulate_test.py", line 55, in <module>
    extractPDB(pdb_filename, out_filename1+".pdb", chain_ids1)
  File "/masif/source/input_output/extractPDB.py", line 38, in extractPDB
    model = Selection.unfold_entities(struct, "M")[0]
IndexError: list index out of range
4ZQK_A
Reading data from input ply surface files.
Traceback (most recent call last):
  File "/masif/source//data_preparation/04-masif_precompute.py", line 74, in <module>
    input_feat[pid], rho[pid], theta[pid], mask[pid], neigh_indices[pid], iface_labels[pid], verts[pid] = read_data_from_surface(ply_file[pid], params)
  File "/masif/source/masif_modules/read_data_from_surface.py", line 23, in read_data_from_surface
    mesh = pymesh.load_mesh(ply_fn)
  File "/usr/local/lib/python3.6/site-packages/pymesh/meshio.py", line 21, in load_mesh
    raise IOError("File not found: {}".format(filename));
OSError: File not found: data_preparation/01-benchmark_surfaces//4ZQK_A.ply

Can someone please help?
Thank you!

I am getting the following error in MaSIF data processing. I followed the demo example

hello，How did you download reduce? Can you tell me?

hello, I encountered same error with you by just following the instruction on Docker tutorial page, have you solve the issue?

Hi there!
I am getting the following error in MaSIF data processing. I followed the demo example
root@dc2aa58b2fb5:/masif/data/masif_site# ./data_prepare_one.sh 4ZQK_A
Downloading PDB structure '4ZQK'...
Desired structure doesn't exists
Empty
pdb filename
/tmp/4ZQK.pdb
Traceback (most recent call last):
  File "/masif/source//data_preparation/01-pdb_extract_and_triangulate_test.py", line 55, in <module>
    extractPDB(pdb_filename, out_filename1+".pdb", chain_ids1)
  File "/masif/source/input_output/extractPDB.py", line 38, in extractPDB
    model = Selection.unfold_entities(struct, "M")[0]
IndexError: list index out of range
4ZQK_A
Reading data from input ply surface files.
Traceback (most recent call last):
  File "/masif/source//data_preparation/04-masif_precompute.py", line 74, in <module>
    input_feat[pid], rho[pid], theta[pid], mask[pid], neigh_indices[pid], iface_labels[pid], verts[pid] = read_data_from_surface(ply_file[pid], params)
  File "/masif/source/masif_modules/read_data_from_surface.py", line 23, in read_data_from_surface
    mesh = pymesh.load_mesh(ply_fn)
  File "/usr/local/lib/python3.6/site-packages/pymesh/meshio.py", line 21, in load_mesh
    raise IOError("File not found: {}".format(filename));
OSError: File not found: data_preparation/01-benchmark_surfaces//4ZQK_A.ply

Can someone please help?
Thank you!

it seems PDB file can not be downloaded but IDK why

Hi all,
I am also hitting the same issue.
Did anyone find a solution for this?
Thanks!


⚠ Bofrost.lu has degraded performance

In f5a3e9c, Bofrost.lu (https://www.bofrost.lu) experienced degraded performance:

HTTP code: 200
Response time: 1914 ms

Resolved: Bofrost.lu performance has improved in 150b534 after 15 minutes.


Gulp.dest fails to move files between filesystems in v5

Before you open this issue, please complete the following tasks:

[x] use the search bar at the top of the page to search this repository for similar issues or discussions that have already been opened.
[x] if you are looking for help from the gulp team or community, open a discussion.
[x] if you think there is a problem with the plugin you're using, open a discussion.
[x] if you think there is a bug in our code, open this issue.

What were you expecting to happen?
Gulp.dest copies files between filesystems as it happened in v4.
What actually happened?
No files are copied, but they are present in intermediate directory.
Please give us a sample of your gulpfile
import path from 'path';
import os from 'os';

// Gulp specific
import Gulp from 'gulp';

const dirs = {
  tmp: path.join(os.tmpdir(), 'gulp-build-cache'),
  out: 'public/static',
};

// ---

function hash() {
  return Gulp.src(`${dirs.tmp}/**/*.*`)
    .pipe(Gulp.dest(dirs.out))
}

// ---

function css() {
  return Gulp.src('assets/public/**/*.css')
    .pipe(Gulp.dest(dirs.tmp));
}

// ---

export const build = Gulp.series(css, hash);

Terminal output / screenshots
vagrant@debian11:/code$ yarn gulp build
yarn run v1.22.22
$ node ./node_modules/gulp/bin/gulp.js build
[16:12:23] Using gulpfile /code/gulpfile.mjs
[16:12:23] Starting 'build'...
[16:12:23] Starting 'css'...
[16:12:30] Finished 'css' after 7.14 s
[16:12:30] Starting 'hash'...
[16:12:39] Finished 'hash' after 8.38 s
[16:12:39] Finished 'build' after 16 s
Done in 16.90s.
vagrant@debian11:/code$ ls -l /tmp/gulp-build-cache/
total 4
drwxr-xr-x 6 vagrant vagrant 4096 Apr  6 16:11 css
vagrant@debian11:/code$ ls -l public/static
total 0

Please provide the following information:

OS & version [e.g. MacOS Catalina 10.15.4]: Debian GNU/Linux 11
node version (run node -v): v18.20.1
npm version (run npm -v): 10.5.0
gulp version (run gulp -v): 5.0.0 (CLI 3.0.0)

Additional information
Changing tmp: path.join(os.tmpdir(), 'gulp-build-cache'), to tmp: 'assets/build', results in working script and files are properly copied from intermediate directory to final one. /tmp and the /code (cwd in which gulp is executed) are on different filesystems.
vagrant@debian11:/code$ sed -i "s#path.join(os.tmpdir(), 'gulp-build-cache')#'assets/build'#g" gulpfile.mjs
vagrant@debian11:/code$ yarn gulp build
yarn run v1.22.22
$ node ./node_modules/gulp/bin/gulp.js build
[16:25:10] Using gulpfile /code/gulpfile.mjs
[16:25:10] Starting 'build'...
[16:25:10] Starting 'css'...
[16:25:14] Finished 'css' after 4.95 s
[16:25:14] Starting 'hash'...
[16:25:21] Finished 'hash' after 6.64 s
[16:25:21] Finished 'build' after 12 s
Done in 13.18s.
vagrant@debian11:/code$ ls -l assets/build
total 4
drwxrwxr-x 1 vagrant www-data 4096 Apr  6 16:25 css
vagrant@debian11:/code$ ls -l public/static
total 4
drwxrwxr-x 1 vagrant www-data 4096 Apr  6 16:24 css

This is due to an issue with glob-stream not resolving absolute paths that was just introduced, will transfer this issue over there.
As a workaround, you can avoid using absolute paths in gulp.src


Named slots

Hi, and thanks for your amazing work on this library. LiveView really needed a good component library and I feel Salad UI, is exactly what I was hoping for.
I am just curios why named slots was not used, but instead components inside components. Was it just because shadcn does it like that and it was copied without giving it much tought? Or are there other reasons?
Just curios since, since I am considering moving my copies of the components to use named slots, since I find that looks cleaner.
Example with the popover. I tried to convert that and I noticed that it got a bit easier to use, since I could hide the ID and target without having to pass them to both the trigger and the content. I myself used a bit of time to understand why it was not working, since it didn't pass the correct ID and target to the context and trigger the first time I tried using this component :sweat_smile:
<.popover side="left">
  <:trigger>
    <.button variant="link">
      @salad_ui
    </.button>
  </:trigger>

  <:content class="p-0">
    Hover card content
  </:content>
</.popover>

With this much work done, I guess it might be to late to rewrite it all to use names slots :sweat_smile:  But I am really curios on your opinon it.
And thanks again for your amazing work on this library :heart:

@torepettersen thanks for your opinion. I chose tag instead of slot because of some reasons:

there are many nested components and slot doesn't support that use case.
separating into multiple function component make maintenance easier
and it's easier to write unit test for each function component than slot
function component help to maximize customization capability: you can arrange order of components, custom class, attribute, ..

For example, with slot it's impossible to implement menu item like this:
       <.menu_group>
            <.menu_item>
              <.icon name="hero-user" class="mr-2 h-4 w-4" />
              Profile
              <.menu_shortcut>⌘P</.menu_shortcut>
            </.menu_item>
            <.menu_item>
              <.icon name="hero-banknotes" class="mr-2 h-4 w-4" />
              Billing
              <.menu_shortcut>⌘B</.menu_shortcut>
            </.menu_item>
            <.menu_item>
              <.icon name="hero-cog-6-tooth" class="mr-2 h-4 w-4" />
              Settings
              <.menu_shortcut>⌘S</.menu_shortcut>
            </.menu_item>
          </.menu_group>

Thank you for taking the time to give me such a detailed answer. Seems like you already put a lot of though into it 😊
Seems like named slots are a bit more limiting than I was aware of. Also noticed they don't support rest/global attributes.
So you have to give up a bit, for a slightly nicer API, in a few cases. Or maybe there are other ways around that without using named slots, to make a similar nice API? I will let you know if I can think of something.
And close the ticket since your answer more than answers my question 😊


GoogleTest + Sharpmake

Visual Studio propose an integration of the GoogleTest framework through "Google Test Adapter" extension.
Which allow us to use "Test Explorer Windows".
That give us a new project property group:

I tried to add a new dll project with all dependencies of gtest (googletest).
But the gtest project have packages.config file with references (from visual studio gtest template):

I wasn't able to find a hook in Sharpmake API to deal with those elements.
Do you have any advice how I could add GTest project with Sharpmake.

Heya!
Sharpmake doesn't have support for nuget packages in c++ projects yet, but will soon after this PR is accepted: https://github.com/ubisoft/Sharpmake/pull/81
It's in my TODO list, but maybe you could have a try and see if it helps with your issue.
Good luck!

Is it similar for vcpkg?
I have the same issue when vcpkg is installed on a computer.
I would like to disable vcpkg for a given solution/project:

To override the dependencies used internally vs the one installed by vcpkg (enabled when vcpkg is integrated with the computer of the user).

Hum, sharpmake is not aware of vcpkg at all. You can use the CustomProperties property in your project constructor, and add the tag + value that vs write when you set "Use Vcpkg" to false, so sharpmake will write them to the vcxproj, ex:
CustomProperties.Add("PropertyKey", "PropertyValue");

Hi Soufiane,
Long time, no see.
Yesterday I added a sharpmake sample showing a way of using vcpkg packages that I extracted from one of our internal tools. The sample is complete and the code compiles for msbuild + fastbuild targets.
Basically this takes advantage of [export] projects for implementing VCPKG packages support. The sample uses the vcpkg export feature as this is right now the fastest way for the CI to consume vcpkg packages as it doesn't need to compile anything. We just need to unzip the resulting vcpkg.zip and then we can generate the projects and compile.
Note that the update-vcpkg-packages.bat doesn't delete the tmp/vcpkg folder to be able to do source debugging easily,
Hopefully this can help you enough for your needs.
JS

Hi JS,
Thanks a will, thanks.
This will be really useful in the future.
What I try to achieves, is when in an dev environnement vcpkg is deployed and inside a project we installed a submodule with a specific branch.
I would like in the project A the module installed with vcpkg and in the project B use the project installed for exemple in a submodule in a folder extern/...
Unfortunately when vcpkg is deployed in the dev env, he have the priority of the path for includes.
I try to find a way to disable vcpkg like I can do with the UI:

I tried with:
CustomProperties.Add("Use Vcpkg", "False");
CustomProperties.Add("Use Vcpkg", "No");
But nothing works.
SK

That's probably because you wrote the description string instead of the proper tag :)
Try and set "Use Vcpkg" from visual studio to "No", then save all, and open the vcxproj in a text editor. Look for the property that was written, and it's value, it should be something like <UseVcpkg>No</UseVcpkg> and write those in CustomProperties, so taking my previous example, you would write CustomProperties.Add("UseVcpkg", "No");.
Good luck, let us know :)

For now I opened an issue on vcpkg:
https://github.com/microsoft/vcpkg/issues/15347

For now I opened an issue on vcpkg:
https://github.com/microsoft/vcpkg/issues/15347

Yeah I don't think you understood what I meant.
Look at this: https://github.com/microsoft/vcpkg/blob/50ea8c0ab7aca3bb9245bba7fc877ad2f2a4464c/scripts/buildsystems/msbuild/vcpkg-general.xml#L16
More specifically this line:
<BoolProperty Name="VcpkgEnabled" DisplayName="Use Vcpkg" Category="General" Default="true"
You can see that the Name and DisplayName are very different, so what you need to write in your sharpmake file is CustomProperties.Add("VcpkgEnabled", "false");

Yeah I don't think you understood what I meant.
Look at this: https://github.com/microsoft/vcpkg/blob/50ea8c0ab7aca3bb9245bba7fc877ad2f2a4464c/scripts/buildsystems/msbuild/vcpkg-general.xml#L16
More specifically this line:
<BoolProperty Name="VcpkgEnabled" DisplayName="Use Vcpkg" Category="General" Default="true"
You can see that the Name and DisplayName are very different, so what you need to write in your sharpmake file is CustomProperties.Add("VcpkgEnabled", "false");

[Fixed]
Indeed, my bad thanks!

[Fixed]
Indeed, my bad thanks!


Trait associated type bounds are stable

Looking at:
https://github.com/psychon/x11rb/blob/efece4d29b8d7d805033d596ea475e6263a90c80/src/utils.rs#L88-L98
However, the following code is allowed in rust 1.37 (https://godbolt.org/z/Xe9rG9):
pub trait MyTrait {
    type Buf: AsRef<[u8]>;
}

pub fn get<T: MyTrait>(v: &T::Buf) -> &[u8] {
    v.as_ref()
}

One problem that I came across: What to do with stuff like the following in the generated code?
impl TryFrom<&Buffer> for Point {
    type Error = ParseError;
    fn try_from(value: &Buffer) -> Result<Self, Self::Error> {
        Self::try_from(&**value)
    }
}
impl TryFrom<Buffer> for Point {
    type Error = ParseError;
    fn try_from(value: Buffer) -> Result<Self, Self::Error> {
        Self::try_from(&*value)
    }
}

The following is the "correct" replacement, I think:
impl<B: AsRef<[u8]>> TryFrom<B> for Point {
    type Error = ParseError;
    fn try_from(value: B) -> Result<Self, Self::Error> {
        Self::try_from(value.as_ref())
    }
}

However, coherence complains:
error[E0119]: conflicting implementations of trait `std::convert::TryFrom<_>` for type `generated::xproto::Char2b`:
  --> /[snip]/out/generated/xproto.rs:41:1
   |
41 | impl<B: AsRef<[u8]>> TryFrom<B> for Char2b {
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: conflicting implementation in crate `core`:
           - impl<T, U> std::convert::TryFrom<U> for T
             where U: std::convert::Into<T>;

You caught me looking at it also. As done in this PR, I propose to just use TryFrom<&[u8]>.

Looks like it's just not possible to have a generic TryFrom implementation: https://github.com/rust-lang/rust/issues/50133

Closing because https://github.com/psychon/x11rb/pull/259 has been merged.


Create 12-exchange-multi-asset-management-scenarios.mdx

Creating new file 'Exchange multi-asset management scenarios' in the 'Learn' section.

Closing PR


Support for targeting ephemeral workers

Each generated stub resource needs a new constructor that only takes a component ID, and just delegates the call to the existing constructor, but passing the component urn instead of a worker urn. The existing constructor, taking a worker URN, needs to be modified to detect if the passed URN is a component URN and generate a random worker name for it.
Needs a worker executor test proving that this works.

No change needed in the wasm-rpc repository because of https://github.com/golemcloud/golem/pull/976


Make sponsors optional

The new memberization procedure no longer requires two sponsors. Can you make those fields optional? People can still submit people if they want, but they don't have to anymore.

Pulled into prod, SQL executed.


AWS S3 object key format documentation

Hi,
this seems like a reasonable project to document that s3.object.key in https://github.com/michaelbrewer/aws-lambda-events/blob/main/docs/s3.md is a URI fragment that is URL-encoded.  One consequence is that in order to retrieve an object given this s3.object.key you have to urldecode the value to pass back into the S3 APIs as they will attempt to urlencode them.  This is very notable when dealing with filenames with pluses in them, like c++ linux packages or parens like you will see from (1) copy from files uploaded from end users computers.
I'm not sure the best way to document these kinds of exceptional embedded meanings though

Possibly via use cases. Let me have a deeper look

I did come across this when working on AWS Lambda Powertools for Python, so i have updated the docs to include a tip on this. I will still need to expand on the either fields too.
See the latest version: https://michaelbrewer.github.io/aws-lambda-events/s3/

Nice! That set of changes culminating in 7f681fb9cfb292b7f64026a67590e117c80a75af resolves this issue from my POV, so I'll close this.


Update Russian translation for use-display-flex-to-position-two-boxes.russian.md

[ x] I have read freeCodeCamp's contribution guidelines.
[ x] My pull request has a descriptive title (not a vague title like Update index.md)
[ x] My pull request targets the master branch of freeCodeCamp.
[ x] None of my changes are plagiarized from another source without proper attribution.
[ x] My article does not contain shortened URLs or affiliate links.

Closed and Reopened this PR to attempt to resolve a specific Travis build failure.

Congrats @ivangretsky on your first pull request (PR)! 🎉
Thank you for your contribution to the page! 👍
We're happy to accept these changes, and look forward to future contributions. 📝


Generate stub standalone sample files in NodeJS

This follows the pattern established in https://github.com/googleapis/gapic-generator/pull/1874

Codecov Report

Merging #1962 into master will increase coverage by 0.06%.
The diff coverage is 100%.

@@             Coverage Diff              @@
##             master    #1962      +/-   ##
============================================
+ Coverage     85.94%   86.01%   +0.06%
- Complexity     4918     4933      +15
============================================
  Files           451      452       +1
  Lines         19597    19655      +58
  Branches       2052     2055       +3
============================================
+ Hits          16843    16906      +63
+ Misses         2068     2065       -3
+ Partials        686      684       -2

Impacted Files
Coverage Δ
Complexity Δ

...codegen/transformer/nodejs/NodeJSSurfaceNamer.java
91.17% <100%> (+0.26%)
78 <2> (+2)
:arrow_up:

...le/api/codegen/gapic/MainGapicProviderFactory.java
93.75% <100%> (+0.16%)
13 <0> (+1)
:arrow_up:

...nsformer/nodejs/NodeJSGapicSamplesTransformer.java
100% <100%> (ø)
10 <10> (?)

...nsformer/nodejs/NodeJSGapicSurfaceTransformer.java
100% <100%> (ø)
27 <0> (-2)
:arrow_down:

...m/google/api/codegen/transformer/SurfaceNamer.java
74.93% <0%> (+0.25%)
199% <0%> (+1%)
:arrow_up:

...oogle/api/codegen/nodejs/NodeJSCodePathMapper.java
94.11% <0%> (+23.52%)
8% <0%> (+3%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update dfbbc45...249bb58. Read the comment docs.


Github actions fix

Made the following edits to make github actions work properly:

added a Project.toml file to the test directory for dependencies
formatted the tests in runtests.jl differently so that they work with the test runner (other tests will need to be reformatted still, these are just examples)
updated call to checkout v2 -> checkout v3 to silence deprecation warnings
removed testing on julia 1.0 since it doesn't support the way occursin is used in the code with regular expressions

Awesome, that was fast! Can't wait to take a look.


Add support for adding images to a library

We would like to autogenerate an Excalidraw library every time we create a release of our icon project.
Is this something that could be feasible?
Thanks :)

Hi @dwelle, we have an icon set - https://github.com/aquasecurity/cloudsec-icons
We'd like to automatically generate an Excalidraw library whenever we add/modify icons so we can easily share our icons with the Excalidraw community. We are already doing something similar for Draw.io - you can see info about this here.

I see. Yeah, that could be a cool use case!
Once we add support for SVGs/images in libraries, we might as well want to expose an SDK for easily making pull requests to create/update existing libraries.


Add go1.21.1

Closes: #523

Add go1.21.1
go1.21 defaults to go1.21.1

@joshwlewis  Is it possible to be reviewed or get an advice about this please?

kotarou1192:main

kotarou1192:main

$ sbin/sync-files.sh
Getting bucket credentials
Syncing contents of s3://heroku-golang-prod/ to /Users/josh.lewis/code/heroku-buildpack-go/file-cache.
Ensuring the correct versions of all files specified in files.json
All files verified, syncing to s3

upload: ./go1.21.1.linux-amd64.tar.gz to s3://heroku-golang-prod/go1.21.1.linux-amd64.tar.gz


revert: fix botched merge

#540 overrode #505.

Sorry buddy! I try never do it again

Don't worry, mistakes happen <3


Provide migration aid for breaking changes in 6x

Breaking changes in 6x: https://github.com/AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet/blob/dev/Tools/apiCompat/baseline/ApiCompatBaseline.netstandard2.0.txt

@GeoK @henrik-me we have had very little feedback that anyone has been broken. The number of breaking changes are small, I have closed this.
We can reopen or handle issues as they arise.


Memory optimization

The optimization is very simple: during the training we have as many decoders as maximal target words so that we can back-propagate in time. Also, with nngraph which is an abstract layer building the computation graph, each intermediate calculation node is an object for which we keep the full structure in memory – in particular the output field (the result of the operation), and gradInput (the gradient calculated on input). The last one is specially problematic when we do large operations – in the attn function for instance we are multiplying the context with the attention vector. The size of the context is batch_l x source_l x rnn_size. So is the same size of the gradInput on the context.
So for batch_l=64, rnn_size=600, max_sent_l=52, in memory – this takes up to 64 x 52 (50+2) x 600 x size_of float x number of decoders => 830Mb static memory usage for one single intermediate variable. This is significant on GPU.
There is already some optimization existing – the :reuseMem() method on some operations, but what it only does is pretty limited: it reuses the same tensor for output and gradInput – which saves 50% of the space but only works for the operators for which output and gradInput have the same dimension.
The patch is to pre-allocate the memory for these objects (gradInput or output can be specified) – so all the cloned decoders share the same tensor which gives us a max_sent_l_src reduction rate. This has no impact since all the intermediate variables in the nngraph do not have lifecycle beyond the :forward() or backward:() calculation they are involved in.
This preallocation on the two main MM operations of attention decoder gives a memory reduction of 1.6Gb – we can even do a little more by apply the same operator for other operations.
+-----------------------------------------------------------------------------+
| Processes:                                                       GPU Memory |
|  GPU       PID  Type  Process name                               Usage      |
|=============================================================================|
|    1     17141    C   /home/shared/lib/torch/f95379d/bin/luajit     5243MiB |
|    2     16830    C   /home/shared/lib/torch/f95379d/bin/luajit     6877MiB |
+-----------------------------------------------------------------------------+

this is really cool. merged!


Disable deletion of donations and purchases if they include an  inactive item

Summary
Disable the deletion of donations and purchases if they include an inactive item
Why?
We're going to error out on this anyway, better to be up front about it.
Also, on purchases, it's currently throwing an inventory error (which will be a 500 in production)
Details
This is in the view for the donations and purchase.
We already disable the "make a correction" button if there are inactive items
Do the same for the delete button
Change the  informational message regarding why the buttons are disabled  to:
You can only delete or correct [donations/purchases]  where all the items are active.
If you need to delete this [donation / purchase] or make a correction, please make the following items active: <%= @distribution.inactive_items.map(&:name).join(", ") %>
(replace distribution in the above with donation or purchase as appropriate)
Criteria for completion

[ ] on view for purchases and donations, delete button is disabled if and only if there are inactive items
[ ] appropriate informational message appears if and only there are inactive items.
[ ] tests to demonstrate this behaviour

May I take this one?

Go for it!


OCM-2646: Recreate IDP if it was deleted not from tf

This PR adds the ability to reconcile an IDP that was created by TF, but then was removed via a different method, Not via terraform.
In this case, And if the user still has the idp resource in his .tf (and state) files. Upon an apply the provider will re-create the idp.
Before this PR, the provider would have error out, since it could not find the idp defined in the state.
On the way, fixed indentation issues in the related subsystem

/lgtm
/approve

/test managed-oidc-config-e2e-presubmit


main: set GLIBC_TUNABLES=glibc.pthread.rseq=0

This patch sets the glibc.pthread.rseq tunable to disable rseq support in glibc as a temporary solution for the problem described in.
This would allow us to run CI tests until CRIU has rseq support.
https://github.com/containers/podman/issues/12949

Codecov Report

Merging #61 (301c0a6) into master (e305910) will increase coverage by 0.18%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master      #61      +/-   ##
==========================================
+ Coverage   26.30%   26.48%   +0.18%
==========================================
  Files          11       11
  Lines        2015     2020       +5
==========================================
+ Hits          530      535       +5
  Misses       1388     1388
  Partials       97       97

Impacted Files
Coverage Δ

main.go
58.65% <100.00%> (+1.18%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update e305910...301c0a6. Read the comment docs.


Player relative_move has some desync

after walking a bit, you can see that positions are wrong

fixed by #582


NoReverseMatch: u'<my_app>' is not a registered namespace in managment commands

Django==1.9.12
DjangoCMS==3.4.1
I've written apphook for application, the app hooks are correct and hooked to page, all work done. But in managment command (which call get_absolute_url method for model) raise NoReverseMatch exception.

Hello @seroy , please make sure to submit questions within the appropriate channels on either the User Mailing List, IRC (freenode#django-cms) or Stackoverflow.
You can find additional information on our support page.
In this case, I believe your question is best in the Users Mailing List.


fix: add global vulnerability ignore

Description
Please include a summary of the change, motivation and context.

Testing
Please describe the tests that you ran to verify your changes. Please summarize what did you test and what needs to be tested e.g. deployed and tested helm chart locally.
Checklist:

[ ] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] Any dependent changes have been merged and published in downstream modules

Documentation
Make sure that you have documented corresponding changes in this repository or hypertrace docs repo if required.

fixed here: https://github.com/hypertrace/document-store/pull/195


Skaven Race Mod Incompatibility

Above mentioned mod allows for an "Extract blood from left/right arm" operation.
Works fine without QEE.
With QEE it not only extracts the blood, but removes the entire arm.
This understandably kind of ticks of the blood donor quite a bit ;-)

Tracked this down to skaven mod overriding Recipe_Surgery.ApplyOnPawn, so changing load order fixes things


[NEW] Emoji keyboard

@RocketChat/android
There's much room for improvement that I'll be working on. Anyway this is the first version of our finally awaited emoji keyboard crafted by hand. :)

Closes #722

@rafaelks I'm putting the adjustments here so that we all can keep track of its progress.

[x] When you rotate the screen, it breaks the layout of the sections; Let's just adjust the spacing or fill the color until the end of the view;
[x] When I open the picker, if I have at least one recent emoji, the tab selected should be the recent emojis;
[ ] Pressing the Emoji button is very hard (at least for me on my physical device), needs o be easier. Maybe increase the touch area?
[ ] The emoji picker is opening on top of the keyboard? It should use the exactly same space and design as keyboard is using, also showing the text of the user on the top; (Look at this, maybe this is the way to go: a new input method for Emojis: https://developer.android.com/guide/topics/text/creating-input-method.html)
[ ] When you get to the end of the list, there are 0px between the bottom of the device and the bottom of the emojis. Let's add at least 16px of space;

@antgel Indeed, thanks for pointing out


TTS still speaks game messages that are supposed to be filtered

As the title says, I'm noticing that the TTS is working for game messages that aren't appearing in my chat box (one's I've filtered). E.g., "you've successfully cooked a fish" plays over and over and over... Any way around this? Is it possible to add a checkbox to enable filtering game messages?
For instance, I play RS in the background a lot while playing other games. Instead of hearing "you have chopped a log" over and over, it'd be nice if I only heard "you are idle".

Hmm back when I wrote on the issue board I had tried typing the exact
phrase that was being spoken and it didn't seem to work. I think it would
be really beneficial to have a list of checkboxes in the plugin options for
common annoying phrases (kind of like how Menu Entry Swapper gives quick
access to things people are likely to want to change [see image]). I don't
really have any accessibility needs, rather, I use this plugin to alert me
while I'm AFK skilling, as I've become kind of numb to the Runelite 'ping'
noise.
I'll try some stuff out and see if I can get it working with the
blacklisting in the meantime, thanks!
[image: wNNVs7TeoA.png]
On Mon, Mar 21, 2022 at 12:18 PM 0xDREAMS @.***> wrote:

Are you using the blacklist feature that already exists?
You could type "successfully cooked" into that box and it should filter it.
—
Reply to this email directly, view it on GitHub
https://github.com/Bullish53/TTS/issues/6#issuecomment-1074106683, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AKUVOSY6VE3HAXVKWXWGJ5LVBCOMJANCNFSM5QSARTLQ
.
You are receiving this because you authored the thread.Message ID:
@.***>

--
Kellen Evoy
CS Research Assistant, Sheridan College
@.***
Create your own email signature
https://www.wisestamp.com/create-own-signature/?utm_source=promotion&utm_medium=signature&utm_campaign=create_your_own&srcid=

@0xDREAMS I haven't really worked on this project myself lately but if you want to commit your changes i will merge them and update it to the pluginhub for sure!


webpack-defaults upgrade

Addition of webpack-defaults & associated refactoring as a part of the next Major release
Issue exists for status tracking across the organization.

Please do not close

Implemented in #11


Increase refresh rate

Increase refresh rate

Thanks for submitting this and the other pull requests. I'm not sure whether this one should be merged. I feel pulling every 30 seconds might be abusive use of the Mojio API.
When I developed the integration I thought about the refresh rate needed for my automation scenarios and concluded that 5 minutes is sufficient. My scenario was to detect when I start driving home from work (30 minutes drive) and the pre-heat/cool my flat. For the 30 minutes drive, the exact moment I leave isn't that important and also I don't need to precisely track my car. However, I'm aware that this might be different with other use cases.
I think what we could do is to have the refresh rate configurable (in reasonable ranges), so the user can decide what's best. IMHO it shouldn't be possible to refresh more frequently than every 30 seconds, but a sensible maximum might be 10 or even 30 minutes.
What do you think and why is it important that you need the higher refresh rate?

I am using the component to track the car and keep a local record where it was. I do not like to rely on cloud services and their retention periods.
I copied that code from the FleetGo integration.
It can be set a 1 per minute as I can remember that is the native refresh rate of the dongle and the App as well.
From previous experience I know that even 1 minute can be not enough as some maneuvers are not recorded correctly. I had a funny situation with a coworker years ago, when we both started from the same place, myself as second, and arrived before the coworker to the office.  Of course the coworker couldn't believe what has happened and looked at the tracking data of the cars and couldn't find it out where I did a different turn or have I done any over speeding (I didn't). Actually the distance what we did was about 1.5 km in a small town and the 1 minute logging was enough to hide the real route.
Anyhow, the 1 minute update should be enough for this...

This is now implemented in #15.
From my point of view this fulfills your requirement. Thus, I'll close this PR. Feel free to open a new one or an issue should you have further requirements.


[Bug] unable to open new phar "/home/forge/default/vendor/backpack/theme-coreuiv2/resources/assets/fonts/source-sans-3.052R.tar" for writing

Bug report
What I did
I've deployed a new version of my project into production.
What I expected to happen
To be able to login on Backack.
What happened
I've got the following error when trying to go the Backpack login screen :
unable to open new phar "/home/forge/default/vendor/backpack/theme-coreuiv2/resources/assets/fonts/source-sans-3.052R.tar" for writing
What I've already tried to fix it
Changing the chmod for boostrap/cache and storage.
Context to replicate the bug - Backpack, Laravel, PHP, DB version
When I run php artisan backpack:version the output is:
### LARAVEL VERSION:
<IP_ADDRESS>

### BACKPACK PACKAGE VERSIONS:
backpack/basset: 1.2.1
backpack/crud: 6.2.4
backpack/devtools: 2.0.3
backpack/generators: v4.0.2
backpack/permissionmanager: 7.1.0
backpack/pro: 2.0.16
backpack/theme-coreuiv2: 1.2.2
backpack/theme-coreuiv4: 1.1.1

Project is deployed on Laravel Forge, using PHP 8.2.

Hey @tjarrett @tibbsa @Astriel @vdomah
This was automatically closed by automation. Sorry guys.
So, I've just pushed some code that will move the file to the storage before attempting to extract it. Do you think this will be enough to solve the issues your reported with the .tar file ?
Can any of you pull basset 1.2.3 and test if it works now on your side ?
Cheers

I'm assuming it is solved and closing it Due to no activity.
Re-open if the issue persists.

Hello,
on fresh install i had this issues:
cURL error 28: Operation timed out after 10001 milliseconds with 0 out of 0 bytes received (see https://curl.haxx.se/libcurl/c/libcurl-errors.html) for https://github.com/jquery/jquery-ui/archive/refs/tags/1.13.2.tar.gz
cURL error 28: Operation timed out after 10001 milliseconds with 0 out of 0 bytes received (see https://curl.haxx.se/libcurl/c/libcurl-errors.html) for https://github.com/Studio-42/elFinder/archive/refs/tags/2.1.62.tar.gz
the solution given by @tjarrett  solved the problem


Cleanup left over temp directory.

See: https://github.com/GoogleCloudPlatform/google-cloud-python/pull/2847#discussion_r91715191
@tseaver LMK if there's a different way you would like to see this done.
I looked at tempfile.NamedTemporaryFile() since it cleans up on it's own but I'm not sure if there is a way to make that work with the {pid} formatting in the file name.

Ha! Just saw yours @tseaver.


Sustainability Tips

In place of really sad dark facts, add sustainability tips or reminders such as "Don't forget your water bottle," "Remember to bring your eco bag!"

@juliwithoutthee is it finished and fully implemented?
Maybe if improvements are needed, create new issues in the main mymizu repo.

@quesiu I didn't get a chance to start this one, so I think we can just create a new issue in the main mymizu repo


W-8033819 - GAU Allocations RD and Oppt in BDI

Adds the ability for GAU Allocation records to be created at the Recurring donation level and flow down to closed won opportunities that were created by BDI in the same transaction context.
Critical Changes
Changes
Issues Closed
Community Ideas Delivered
New Metadata
Deleted Metadata

Thanks for the contribution! It looks like @fparodi-salesforce @e-ferrando is an internal user so signing the CLA is not required. However, we need to confirm this.

@fparodi-salesforce and @e-ferrando can you both please click the link to complete the Google doc form to confirm you're part of the Salesforce.org org?

@callen-sfdo I noticed that the branch on this PR might be incorrect. It's merging from feature/W-8033819-GAUAllocationSupportForRDInBDI into feature/RDInBDI. However, both are these branches considered a child of master. That could create issues with the diff and might explain why there are 189 changed files in this PR. If this is actually a child branch of feature/RDInBDI, then the branch name for this should be something like feature/RDInBDI__W-8033819-GAUAllocationSupport.

Thanks for the contribution! It looks like @fparodi-salesforce @e-ferrando is an internal user so signing the CLA is not required. However, we need to confirm this.

@fparodi-salesforce and @e-ferrando can you both please click the link to complete the Google doc form to confirm you're part of the Salesforce.org org?

Please ignore this as I understand you are no longer working on this project with Salesforce.org.

Thanks for the contribution! It looks like @e-ferrando @fparodi-salesforce is an internal user so signing the CLA is not required. However, we need to confirm this.

Ignore. The user is no longer working with Salesforce and therefore no longer has perms to this org. Manually removed the cla:missing label as this is not considered an external contribution.


Expectation function

Possible implementations of the CuPyDense expectation function

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

8 of 20 (40.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-3.4%) to 81.784%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/qutip_cupy/dense_functions.py
8
20
40.0%

Totals

Change from base Build<PHONE_NUMBER>:
-3.4%

Covered Lines:
220

Relevant Lines:
269

💛  - Coveralls

This are the timings obtained for the different implementation for the operator ket expectation. The functions listed here where used with the caveat that I removed shape check for all as well as the call to item to speed up the trials.

And I bring good news on the kernel vs cupy for density matrices.

3 times speed-up 🎉

There may be more improvements if for example we are okey assuming the operator is hermitian  (I assume we are making a measurement here) .  And we could also use the hermitian property of density matrices.

Let's pick the best implementation, remove the others and clean up the code and uncomment the tests and then I can do a final review.