davidakelley / cbd Goto Github PK

There are multiple functions in this repo that are taken from elsewhere (e.g legendflex and parse_json to name a few). We should provide licenses for all of them and shout them out in the readme however appropriate. We should make sure that all the licenses allow for including in other projects and distributing them in this manner.

We should at the same time think about what the right way to include these dependencies. The following questions arise:

1. Should the user have to include them on their path themselves?

   • This removes our need for including the licenses

   • I think this would be a burden for users

   • Packaging on matlab is not like R and Python (at least with respect to user written scripts that aren't packaged as toolboxes) so its not clear how we would make sure that the dependency exists and is the right version

2. Should they be in their own folder?

   • This would be useful if each file has a seperate license

   • For example, a dependencies or third_party folder would suffice for organizational purposes

   • We run into an issue if any of the dependencies have their own +. How does matlab treat these nested + folders when their is a folder inbetween that does not have the + prefix

3. Should they be submoduled?

   • Related to 2.

   • I think they should when we can. That is the cleanest, most robust solution available

   • For projects using git, this removes the need for us to include the license manually

   • This may lead to user confusion in both the proper way to clone this repo and how to edit these submodules. @ssordopalacios may have some thoughts on this.

I cleaned up the README to remove FRBC specific language.

I think there's 2 things left to handle:

• The path to the Haver folder.
• The default directory for chidatadir.

Ideally, they'd be empty and have some sort of prompt but I also don't want to change it since you guys are still going to use it.

Ideas?

You should be able to pass dates as either characters or datenums to all functions. This fails with cbd.plot right now, and maybe with others.

Hi David,

I encountered an issue with the latest versions of Matlab where when you try to use cbd to pull data from Haver with the fetch command and both a startDate and endDate option, fetch will get stuck in an infinite loop. It seems to be an issue with only a handful of quarterly data series with irregular start periods and can be easily fixed by not specifying at startDate or endDate.

As an example, try running the following: cbd.data('SRP15'). I think there may be an issue with the way that cbd.private.parseDates handles the dates for this series.

Scott

xlsfile fails in Matlab 2022a with the following error:

Error using cbd.xlsfile
Error:File: xlsfile.m Line: 92 Column: 51
Identifier 'workbook' is not a function or a shared variable. To share 'workbook' with a nested function,
initialize it in the current scope. For more information, see Sharing Variables Between Parent and Nested
Functions.

I'm not sure what the long-term fix is since the COM interface seems to have changed somewhat, but a temporary solution appears to be to replace lines 78-101 of xlsfile with the following:

if ~newWb
    obj.xlApp.DisplayAlerts = 0;
    obj.xlApp.workbooks.Open(obj.file, 0, readOnly);
    obj.wkBook = obj.xlApp.ActiveWorkbook;
end

wbProps = get(obj.wkBook);
if wbProps.ReadOnly && ~readOnly
    warning('xlsfile:readOnly', 'Excel file opened read only.');
end

I'll try to circle back on this soon, but this should let you at least use xlsfile in the meantime.