Java compiler cannot find "write"

[seal58]

Hello,

during coding and debugging I use Log(), because it is not possible to execute the code step by step when GUI actions are required at same time. Within debugger environment this lets crash the debugger often, because these text outputs need too much time.

So now I wanna write a kind of log messages into my own log file. Hereby I ended with a compiler message "cannot find symbol" for the method write( byte[] ).
This method is part of class RandomAccessFile within package java.io.
In the header of my module code I added

Code: Select all

import java.nio.*;
import java.lang.Object;
import java.io.*;

Nevertheless compiling failes. Do I have to import further java sources?

Roland

[terrymcg]

Hi Roland...

during coding and debugging I use Log(), because it is not possible to execute the code step by step when GUI actions are required at same time. Within debugger environment this lets crash the debugger often, because these text outputs need too much time.

I haven't managed to crash the VDM with Log output, but did recently get VM to crash that way

Nevertheless compiling failes. Do I have to import further java sources?

In one case where I needed to do in-module file i/o, I wound up with a more explicit import list than you're using. Try replacing/supplementing some of the wild-card imports with direct imports of the classes you need/want:

Code: Select all

import java.io.FileOutputStream

Other more Java-savvy people may have better suggestions but I don't think importing too much can really hurt at the debugging stage.

Cheers,
--
Terry McG

[ChR_is]

if log overloads your system, writing to a file probably will as well. string operations and printing are expensive. mostly too expensive to be carried out 48k times per second.

i suggest to buffer events and log them with a timer event (StartNamedTimer or GUI timer). e.g. if x happens you set a flag and save some debug info alongside and then have the timer thread detect/evaluate the flag.

as for the actual problem: what are you calling write on? which object does the write belong to?

[seal58]

Hi Terry and Chris(?)

thanks for your hints.
Until now I did not handle files with Java. When I tryed to create a file, compiler wanted me to manage a TRY/CATCH/TROW block, what I'm also not familiar with. When I did so, compiler even did not know exception enumerals. Extending "import" list was not successful.

So I gave up and searched the web for examples. Fortunately I found a very simple solution:

Code: Select all

private void writeByteArrayToFile( byte[] byteArray, String fileName, boolean append )
{
    try( FileOutputStream fos = new FileOutputStream( fileName, append )) 
    {
      fos.write( byteArray );
    } 
    catch(IOException e) {
        Log("writeByteArrayToFile  error IOException, could not write to output stream" );
    }
}

Therefore I needed to import only java.io.*
This little method works fine. It's parameter append makes it usable to write preset data as well as to continue an existing log file.

I'm very happy with this solution. It makes it even possible for me to log events in real time in VM background. (of course not within ProcessSample().

Roland

[poetix]

It may be worth keeping the FileOutputStream around, rather than reopening it every time you want to write something to it. Create it in the module's Initialize method, and clean it up in the Destroy method.

As far as buffering goes, I think FileOutputStream does some behind the scenes anyway (IIRC you sometimes have to call flush() on it to get everything that's buffered written out to disk), but it's still worth considering keeping a queue of messages you want to write and pushing them out to disk on a dedicated thread. If the purpose is just to observe events as they happen, you might consider writing to a socket and having a separate application connect to it and listen for events - no point in doing disk I/O if you don't have to...

[ColinP]

My guess is that poetix is referring to UNIX style IPC (inter process communication) sockets - java.net.Socket.

But I use actual VM sockets. Yeah, I know everyone else calls them jacks, but I grew up with different terminology.

Anyway, rather than using logging I do almost all my dynamic (non-breakpoint) debugging using what I call stomata. That's sending data out of ProcessSample() to one or more sockets. Then I use CV Watcher to examine the signals. Weevil's Multi Oscilloscope is another option if you have it. For DC outputs I use Monkey Business Audio's Volt Meter.

There's simply no way that you can get the same insight into what's going on by wading through vast amounts of logging data.

[poetix]

It struck me in an evil moment that one could actually stream characters to a text console (implemented as a debug display module) over an audio connection...

[ColinP]

If you wanted to destroy the planet you could send the stream to an industrial scale printer (with a very large buffer)...

[seal58]

Hi poetix,

good try, but sorry, until now I have no clue what a socket is. I've been programming with TurboPascal a long time ago. And now I try to use Java, what is totally different from old school programming. Java is a huge language. As in a spoken language I have to learn grammar and word by word.

I don't plan to output mass of data. In first line I wanted to use GetStateInformation() and SetStateInformation() and to get some logs during development. This part is done now.

Second thing was an idea of using similiar methods to log actions. The module I'm working on does not process CV or audio data. But it contains a tricky sequential GUI processing, depending on user actions. To get information within VM I sent some messages to module's label objects first. Some outputs disappeared, because a few things are done in ProcessSample() and most things in Notify() using GUI update timer.

I assume that I can write some text messages to my debugging log file without interferring with VM.
Nevertheless I thank both of you for having an eye on my newbee questions.

Roland

[UrbanCyborg]

I wrote a log class using Java log methods instead of VM's method, because I didn't know about it at the time. It writes to a text file, which I keep open in my editor alongside the code. Works a charm, but, of course, not in ProcessSample(). If anyone really cared, I'd post it. It's as lightweight as I could keep it.

Reid