Announcement

Collapse
No announcement yet.

Arrghh. File reading

Collapse
This topic is closed.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Arrghh. File reading

    Folks,

    It's quite possible this topic has been done to death already but here goes.

    I want to be able to read in data and plot it from a source file that contains data that is not available from eSignal. In this case it is Committments of Traders data.

    There are two obstacles here. One, I am pretty much a complete idiot when it comes to jscript. So just the syntax for opening, reading, and parsing a file is going to be a challenge.

    The next though is that I have no idea what format the data should be in for eSignal to be able to handle it. For example the data is weekly, but how can I "tell" the eSignal app that it is in this format instead of daily so that it does the right thing? Secondly, the data is dated specifically (the Tuesday of every week) so it is important not to lose that information.


    I am sure there are plenty of other instances where people have data that has the price format, date issues discussed. And I suppose in the worst case doing a file export from eSignal so that the data here can be plotted in Excel is one workaround.

    It would however be very handy to be able to do this inside eSignal directly.

    Thoughts?

  • #2
    Using Sample

    OK, tried this stub which was provided in the file object thread and nothing happens at all. No errors, just nothing at all. Like I said, I'm not good at jscript but I thougt it odd that nothing showed up at all in the output window. The file in question is just CR delimited Fibonacci numbers (did this just in case I was only getting the line number back...). Anyway, no go.

    function testRead() {
    debugPrintln("Testing Read");
    var f = new File("./testReadWrite.txt");

    debugPrintln("Exists: " + f.exists());
    debugPrintln("Is File Open: " + f.isOpen());
    debugPrintln("Is EOF: " + f.eof());
    debugPrintln("Length: " + f.getLength());
    debugPrintln("Position: " + f.getPosition());

    f.open("rt");

    var line;

    while(!f.eof()) {
    line = f.readln();
    debugPrintln("Line: [" + line + "]");
    }

    f.close();
    }

    Comment


    • #3
      - What build # of eSignal are you using (in help/about).

      - Any file that the EFS engine reads must exist in the Formula Output Root (on tools->EFS Settings). Default is something like c:/program files/esignal/formulaoutputroot

      m.
      Matt Gundersen

      Comment


      • #4
        FileRead

        Matt,

        Using 7.2 build 544

        Okay, so I just drop the texfile into that folder and it should work without having to provide the explicit path? I just tried it and still nothing. It should have thrown an error or something though no? That's what is puzzling me, nothing is happening.

        If that works, problem one solved. Then we can move on to the other issues.

        Comment


        • #5
          I think there was an issue with build 544 and file i/o. You might try updgrading to the beta.

          m.
          Matt Gundersen

          Comment


          • #6
            Thanks Matt

            Probably will hold off then. But to the more general parts of the question (expected format, date preservation of external data, etc) can you help with that?

            No point in me even trying if there are going to be issues in not being able to use that data properly. Might punt back to MetaStock for this analysis if it's going be be problematic in eSig (much as I would hate that).

            Comment


            • #7
              Not sure what you are asking - but if you want to do file i/o you should upgrade. It's been in beta for a while now and prettys table.

              m.
              Matt Gundersen

              Comment


              • #8
                I did the same and also reads nothing.
                I created a file with notepad and put 3 lines in it.
                The result I get:
                debugPrintln("Exists: " + f.exists()); TRUE
                debugPrintln("Is File Open: " + f.isOpen()); FALSE
                debugPrintln("Is EOF: " + f.eof()); TRUE
                debugPrintln("Length: " + f.getLength()); -1
                debugPrintln("Position: " + f.getPosition()); -1

                I know f.exits() is true is correct because when i remove the file from the directory, it show false.

                Some of you must be doing this successfully with 7.2 build 544, what could be wrong?

                Comment


                • #9
                  I also created a file with 3 lines from EFS (successfully) but was NOT able to read from it either (same result).

                  Comment


                  • #10
                    Exists?

                    I had a problem with f.exists() when opening a file in the default directory (FormulaOutput). It kept returning False even thought I knew it existed. In the end I just used f.open() and f.IsOpen(), they work fine. You don't really need f.exists() in that situation, it won't open if it doesn't exist...

                    Here's an exaple of how I output to text files, this code works:

                    var f = new File("Out.txt");
                    f.open("at+");
                    if(f.isOpen()) {
                    f.writeln("Text");
                    f.close();
                    }

                    Not sure if this is relevant, but it might be helpful to someone.

                    Katrina.
                    Last edited by katnap; 04-12-2003, 08:35 PM.

                    Comment


                    • #11
                      I was successful in writing also. I have UNsuccessful in reading. Katrina, have you tried reading the file you wrote?

                      Comment


                      • #12
                        I've done a fair amount of file I/O efs's...(or whatever the plural of efs is).

                        If you want, post up your entire code (or at least enough of a standalone that shows the exmplae of the problem and runs) and I will take a look.
                        Garth

                        Comment


                        • #13
                          Couple of things

                          The code stub I think was one that Matt posted ages ago, at least that is the one that I have been using. And I know there are issues with 7.2 and risked death by installing 7.3B

                          But before we get all twisted in our knickers, for me at least here is the problem. Am I going to be able to use external data or not to create a non-price study? For example, making a plot of the weekly Specialist Short Ratio data against the SPX, or the daily new highs/lows list, what have you.

                          If the answer to that is "no" or if it is going to require extensive hand tweaks for every data set then for me it's likely a non-starter anyway.

                          As I think I pointed out elsewhere, there is tons of data floating around out there from various services already in ASCII or Metastock format.


                          Other packages make import pretty simple so for this I may have to stick with the old platform. I think it would be worth having a look at how hard/easy it would be to have some sort of parser that could handle files of this type.

                          Comment


                          • #14
                            Its very possible to do what you want, BUT (isn't there always a but), it may not be trivial. File I/O isn't too bad, but you will have to figure out how to sych up the dates and times. It's not hard, but it isn't trivial either.

                            Remember also, that you are pretty well restricted in drawing you own information to bars that exist on the eSignal chart. Doing something like drawing many years worth of 60 minute data therefore will not work.
                            Garth

                            Comment


                            • #15
                              A-Ha

                              Well, isn't there always good and not so good news!

                              OK, the probable good news is that most of the data in question is weekly or daily in frequency.

                              I had posted a question elsewhere about showing weekly data in an efs posted on a daily chart, so i guess your response answers that question (no).

                              But this gets to the format issue.These files will likely come with the data separared by commas with the date either at the end or beginning of the line.

                              It would be nice not to have to parse each and every one of those dates by brute force. Like if there was a library or module that could handle this stuff so people would not have to waste gobs of time redoing it each time.

                              Maybe that's something the team can work on.

                              Comment

                              Working...
                              X