06:29 < blakjak888> @zoq A while back I mentioned a problem compiling the StockPriceLSTM with Visual Studio 2019. It was running out of heap space during compilation and I traced the problem to the data::Load() calls. Today I tried to compile the same example using GCC/G++ and I faced what I guess is a similar error. This time it generated an object file that was too big and aborted with "file too big" error.

06:29 < blakjak888> Did you try to run this example like you mentioned? It seems to be more than a compiler problem.

13:36 < shrit[m]> @blakjack888 can you paste the error you have faced in GCC ?

14:29 < blakjak888> 1> /usr/lib/gcc/x86_64-pc-msys/9.3.0/../../../../x86_64-pc-msys/bin/as: StockPriceLSTM.o: section .text$_ZN5boost6detail7variant22visitation_impl_invokeINS1_14invoke_visitorIKN6mlpack3ann13DeleteVisitorELb0EEEPvPNS5_9LayerNormIN4arma3MatIdEESD_EENS_7variantIPNS5_18AdaptiveMaxPoolingISD_SD_EEJPNS5_19AdaptiveMeanPoolingISD_SD_EEPNS5_3AddISD_SD_EEPNS5_8AddMergeISD_SD_JEEEPNS5_12AlphaDropoutISD_SD_EEPNS5_17AtrousConvolutionINS5_16NaiveCon

14:29 < blakjak888> volutionINS5_16ValidConvolutionEEENSX_INS5_15FullConvolutionEEESZ_SD_SD_EEPNS5_9BaseLayerINS5_16LogisticFunctionESD_SD_EEPNS14_INS5_16IdentityFunctionESD_SD_EEPNS14_INS5_12TanhFunctionESD_SD_EEPNS14_INS5_16SoftplusFunctionESD_SD_EEPNS14_INS5_17RectifierFunctionESD_SD_EEPNS5_9BatchNormISD_SD_EEPNS5_21BilinearInterpolationISD_SD_EEPNS5_4CELUISD_SD_EEPNS5_6ConcatISD_SD_JEEEPNS5_11ConcatenateISD_SD_EEPNS5_17ConcatPerformanceINS5_21NegativeLo

14:29 < blakjak888> gLikelihoodISD_SD_EESD_SD_EEPNS5_8ConstantISD_SD_EEPNS5_11ConvolutionISZ_S11_SZ_SD_SD_EEPNS5_5CReLUISD_SD_EEPNS5_11DropConnectISD_SD_EEPNS5_7DropoutISD_SD_EEPNS5_3ELUISD_SD_EEPNS5_8FastLSTMISD_SD_EEPNS5_12FlexibleReLUISD_SD_EEPNS5_3GRUISD_SD_EEPNS5_8HardTanHISD_SD_EEPNS5_4JoinISD_SD_EESF_PNS5_9LeakyReLUISD_SD_EEPNS5_6LinearISD_SD_NS5_13NoRegularizerEEEPNS5_12LinearNoBiasISD_SD_S35_EEPNS5_10LogSoftMaxISD_SD_EEPNS5_6LookupISD_SD_EEPNS5_4LS

14:29 < blakjak888> TMISD_SD_EEPNS5_10MaxPoolingISD_SD_EEPNS5_11MeanPoolingISD_SD_EEPNS5_23MiniBatchDiscriminationISD_SD_EEPNS5_16MultiplyConstantISD_SD_EEPNS5_13MultiplyMergeISD_SD_JEEEPS21_PNS5_11NoisyLinearISD_SD_EEPNS5_7PaddingISD_SD_EEPNS5_5PReLUISD_SD_EEPNS5_7SoftmaxISD_SD_EEPNS5_14SpatialDropoutISD_SD_EEPNS5_21TransposedConvolutionISZ_SZ_SZ_SD_SD_EEPNS5_10WeightNormISD_SD_JEEENSG_IPNS5_8Linear3DISD_SD_S35_EEJPNS5_7GlimpseISD_SD_EEPNS5_7HighwayISD_SD_

14:29 < blakjak888> JEEEPNS5_18MultiheadAttentionISD_SD_S35_EEPNS5_9RecurrentISD_SD_JEEEPNS5_18RecurrentAttentionISD_SD_EEPNS5_15ReinforceNormalISD_SD_EEPNS5_17ReparametrizationISD_SD_EEPNS5_6SelectISD_SD_EEPNS5_10SequentialISD_SD_Lb0EJEEEPNS5C_ISD_SD_Lb1EJEEEPNS5_7SubviewISD_SD_EEPNS5_13VRClassRewardISD_SD_EEPNS5_16VirtualBatchNormISD_SD_EEPNS5_3RBFISD_SD_NS5_16GaussianFunctionEEEPNS14_IS5R_SD_SD_EEPNS5_18PositionalEncodingISD_SD_EEEEEEE18has_fallback_type

14:29 < blakjak888> _EEENT_11result_typeEiRS62_T0_PT1_T2_i: string table overflow at offset 10001890

14:29 < blakjak888> 1> /d/Users/David/AppData/Local/Temp/cc0ly2VV.s: Assembler messages:

14:29 < blakjak888> 1> /d/Users/David/AppData/Local/Temp/cc0ly2VV.s : Fatal error : can't close StockPriceLSTM.o: file too big

14:30 < blakjak888> sorry, did not realise there was so much there!

14:50 < shrit[m]> @blakjack888 are you using mingw ?

16:45 < AakashkaushikGit> hey, can someone give a look to this, https://github.com/Aakash-kaushik/ann_exp as i have `Linear` layer class derived from the `Layer` base class and so the functions defined as virtual in the base class should be implicilty virtual in the `Linear` class but when i explicitly mention them as virtual they error out with `templates may not be ‘virtual’`, which is understanble but why only when i mention it and if i

16:45 < AakashkaushikGit> the parameter in the class then i have to edit a lot more code, is there any other way to do it ?

16:54 < rcurtin> AakashkaushikGit: templatize the base layer with `InputDataType` and `OutputDataType`, then use those parameters in the functions `Forward()`, `Backward()`, etc.

16:54 < rcurtin> so, there should be no need for `Forward()` to have template parameters of its own

17:02 < AakashkaushikGit> hey @rcurtin i have done something similar now, the base class has a template param `eT` which is by default a `double` and the functions such as `Forward()` use `arma::Mat<et>` which if i remember correctly is equivalent to `arma::mat`.

17:02 < rcurtin> yes, try templatizing the base layer with `InputDataType` and `OutputDataType` instead

17:02 < rcurtin> the issue is that you cannot have a templatized virtual member function

17:02 < rcurtin> however, you can have a virtual member function of a templatized class

17:03 < rcurtin> therefore, all template members need to be at the class level, not the method level, and you'll have to find some way to refactor the code to do that

17:03 < rcurtin> what I suggested is just one way to do it, but there are other ways too

17:03 < rcurtin> after all, this is just an experiment, so do whichever way you find the most convenient :)

17:06 < AakashkaushikGit> @rcurtin thanks for the guidance. :D

17:07 < rcurtin> sure, happy to help

22:04 < abernauer[m]> Ok draft of that cfmovielens notebook for the R bindings is done.

22:46 < shrit[m]> abernauer: great, thanks, it will be the first R example in mlpack I think

22:48 < abernauer[m]> It wasn't a ton of effort just adapted some Python code to R code and expanded on the quick start example.

23:06 < rcurtin> shrit[m]: cleaning up issues and PRs... you are my hero :-D

23:08 < shrit[m]> You are most welcome :-D

23:11 < shrit[m]> rcurtin: I was thinking, it would be great to have something like https://github.com/hill-a/stable-baselines in mlpack, what do you think?