Contribute to Bedrocktm1 project

[Elessar]

Hi all,

I want to contribute to bedrocktm1, but the link on the main page is not working. The e-mail 'info@bedrockTM1.org' seems to be inactive too.
Does anybody have information about this? Is the project alive?

[Alan Kirk]

Hi all,

I want to contribute to bedrocktm1, but the link on the main page is not working. The e-mail 'info@bedrockTM1.org' seems to be inactive too.
Does anybody have information about this? Is the project alive?

I believe so; version 3 was released not all that long ago in the overall scheme of things. I sent a couple of e-mails to that address in the early days too (long before V3) about some issues that I'd picked up but they vanished without a trace. I know that some of the Bedrock people inhabit these halls; they may well be in touch about it.

[Elessar]

Alan,

Do this issues still exist in Bedrock v3? If no, could you please sent me their description?

[Alan Kirk]

Do this issues still exist in Bedrock v3? If no, could you please sent me their description?

I doubt it; this was a very long time ago, before even V2 came out. I can't find the e-mail(s?) now; I can't recall whether it was before or after we moved from Exchange to Gmail (urgh...), but before, I suspect. I no longer have access to my ancient Exchange e-mails, short of putting in a request to the Help Desk. And Gmail insists that it can't find the e-mail in question, which could be either because:
(a) It was sent before we moved to GMail and was not part of the then-current mail swept across to it (which is quite possible); or
(b) For a company that built its name on a search engine the Gmail search is really, really woeful, though usually it's woeful in the way of returning dozens to hundreds of false positives rather than not being able to find anything at all.

The reason that I suspect that they're no longer an issue is that over the last few weeks I've been doing a review of all of the Bedrock code, making sure that I have a standardised version (i.e., V3) across all servers. I've only come across a couple of minor code issues which are so obscure that it would be exceedingly unlikely for anyone to stumble on them and which are so long winded that I'm not even going to bother typing them here at the moment.

The bigger issue is with the documentation, which needs an overhaul. The documentation for a bunch of processes refer to, for instance, a non-existent parameter called pSkipConsols. (Eg Bedrock.Cube.Data.Export and Bedrock.Cube.View.Create. Note that this is not the same as the pSuppressConsol parameter, which serves a completely different purpose. ) That parameter does not seem to exist in any process at all. Obviously if someone includes it in a process call it will crash the call chain; calling a process with an unknown parameter drops it dead. Still, that's more an irritation than an error, and should be picked up in testing. In a similar vein the documentation keeps referring to a parameter named pDeleteTempObj whereas the real parameter name is pDestroyTempObj; again this is more than pedantry because if you use the wrong one, the call fails. A couple of the examples refer to incorrect process and/or parameter names, so copying and pasting them tends to result in a brief bout of mild swearing at runtime.

There are a couple of instances where the output does not work as advertised; for example Bedrock.Cube.Data.Export supposedly produces the following file: "If no file name is provided, a combination of the cube, dimension and element suffixed by 'export.csv' will be used." Yeah, no. That doesn't happen. It actually gets generated as CubeName_Export.csv. That will only be a problem if the user generates multiple files using different dim / element combinations out of a single cube. They may be expecting separate files on each call but will instead get just one file which is constantly being overwritten. There's nothing wrong with the code as such (and the obvious way around it is to specify the output file name)... but it's not doing what the documentation says it is.

But I haven't found any (substantial) issues with the actual code to date, so either I haven't reached the processes in question yet or, more likely, whatever it was was fixed in subsequent versions or just superseded by new processes.

[Alan Kirk]

Do this issues still exist in Bedrock v3? If no, could you please sent me their description?

But I haven't found any (substantial) issues with the actual code to date, so either I haven't reached the processes in question yet or, more likely, whatever it was was fixed in subsequent versions or just superseded by new processes.

This still isn't "substantial" but it's slightly annoying. I noticed it when I upgraded one of my servers to V3.0.

In Bedrock.Dim.Sub.Create.ByElement, on lines 192 and 197 there are output calls to the debug file such as:

Code: Select all

        If( pDebug <= 1 );
          AsciiOutput( sDebugFile, 'Element: ' | sElement | ' has been added to the subset.' );

This means that if you have debug off (value 0)... you get spammed with the debug file anyway.

I believe it was meant to be >=1, not <=1.

[Alan Kirk]

Do this issues still exist in Bedrock v3? If no, could you please sent me their description?

But I haven't found any (substantial) issues with the actual code to date, so either I haven't reached the processes in question yet or, more likely, whatever it was was fixed in subsequent versions or just superseded by new processes.

This still isn't "substantial" but it's slightly annoying. I noticed it when I upgraded one of my servers to V3.0.

In Bedrock.Dim.Sub.Create.ByElement, on lines 192 and 197 there are output calls to the debug file such as:

Code: Select all

        If( pDebug <= 1 );
          AsciiOutput( sDebugFile, 'Element: ' | sElement | ' has been added to the subset.' );

This means that if you have debug off (value 0)... you get spammed with the debug file anyway.

I believe it was meant to be >=1, not <=1.

And in a similar vein... Bedrock.Cube.Data.Copy. In the Epilog ( around line 74) we have:

Code: Select all

      IF( pDebug <= 1 );

reporting that temporary objects were destroyed. This one is slightly more annoying in two respects:
(a) The file in the logging folder incorrectly reports that the file is being generated by the Prolog. (The debug file name is (correctly) only changed to Epilog if the pDebug value is >=1.); and
(b) Because the source is a cube view of a cube that you pretty certainly won't have on your system until or unless you kludge it up[1] ( Bedrock Test->Temp)... you can't edit the process to fix that.

It's only annoying rather than critical.

[1] Edit: To save anyone else having to write the code...

Code: Select all

SC_NAME = 'Bedrock Test';

If ( CubeExists( SC_NAME ) = 1) ;
    ItemReject ( 'Cube already exists');
EndIf;

iDimIdx = 1;

While ( iDimIdx <= 27 );
    sDim = 'BedrockTestDim' | Trim ( Str ( iDimIdx, 2, 0 ) );

   If ( DimensionExists( sDim ) = 0 );

        DimensionCreate ( sDim );

        iEltIdx = 1;

        While ( iEltIdx <= 10 );

            sElt = 'Element ' | Trim ( Str ( iEltIdx, 2, 0 ) );

            DimensionElementInsert( sDim, '', sElt, 'N');

            iEltIdx =  iEltIdx + 1;

        End;

    EndIf;

    iDimIdx = iDimIdx + 1;

End;

CubeCreate( SC_NAME, 'BedrockTestDim1', 'BedrockTestDim2', 
 'BedrockTestDim3', 'BedrockTestDim4', 'BedrockTestDim5', 'BedrockTestDim6', 
 'BedrockTestDim7', 'BedrockTestDim8', 'BedrockTestDim9', 'BedrockTestDim10', 
 'BedrockTestDim11', 'BedrockTestDim12', 'BedrockTestDim13', 'BedrockTestDim14', 
 'BedrockTestDim15', 'BedrockTestDim16', 'BedrockTestDim17', 'BedrockTestDim18', 
 'BedrockTestDim19', 'BedrockTestDim20', 'BedrockTestDim21', 'BedrockTestDim22', 
 'BedrockTestDim23', 'BedrockTestDim24', 'BedrockTestDim25', 'BedrockTestDim26', 'BedrockTestDim27');

ViewCreate(SC_NAME, SC_NAME);
ViewCreate(SC_NAME, 'Temp');

[Elessar]

Hello all,
It's my last try to find bedrock community's contacts

Did somebody on the tm1forum contribute to bedrock project? Is the project alive, and will it be?