I'm afraid it's not that easy because, as I recall, reads occur all over the place... but my memory may be vague.

Anyway, I'll look into it. I would much prefer it if Csound rendered by default from memory, with options to have temporary files on disk or named permanent files on disk.

Regards,
Mike

-----Original Message-----
>From: Jonatan Liljedahl 
>Sent: Jan 31, 2008 4:05 PM
>To: Developer discussions 
>Subject: Re: [Cs-dev] CppSound and CsoundPerformanceThread..
>
>Michael Gogins wrote:
>> They are not deleted afterwards. Personally, I want them around to
>> document the rendering so I can recreate it or modify it later. There
>> are number of pieces that I have lost because I did not do this, or
>> did not lose because I still had the temporary files around (I used
>> to do each rendering in its own directory, now I change the temp
>> filenames to match a master filename).
>
>Are you talking about the ones that the SetCSD() stuff is creating
>(because csound can only parse files, not strings) and not the
>/tmp/fileXXX.* files? (because these are deleted as they should, at
>least for me)
>
>> In addition to this personal philosophical preference for the
>> temporary files, there is a technical reason. The Csound orchestra
>> and score parsers need the orc and sco to be files on a disk. This
>> should probably be changed -- not everyone is like me. You would like
>> to create the orc and sco in memory and render from that, correct?
>...
>> It might also be possible to change the Csound internals to be able
>> to use pre-allocated memory buffers for this, or file handles that
>> belong to a memory stream. I will look at this latter idea again to
>> see if it is possible. It is easily possible in C++ but I do not know
>> about C.
>
>How does the parsers look? Do they use filedescriptors or FILE* streams?
>It should be "easy" to just allocate buffers and use these instead, and
>do stuff like c = *buf++ instead of c = fgetc(f), or sscanf() instead of
>scanf(), memcpy() instead of read(), etc...
>
>-- 
>/Jonatan         [ http://kymatica.com ]
>
>-------------------------------------------------------------------------
>This SF.net email is sponsored by: Microsoft
>Defy all challenges. Microsoft(R) Visual Studio 2008.
>http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>_______________________________________________
>Csound-devel mailing list
>Csound-devel@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/csound-devel




-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

When I write parsers I often load the whole file to memory first and
parse the string buffer, it's much easier to move around in a buffer
instead of needing to get/push chars and seek in the file, etc.
(So if this change is done the code might be a lot cleaner afterwards)

I don't know if you use scanf, but here's a tip of how one can keep
track of the position in the string buffer if you do:

  int read_chars=0;
  char *ptr = buf;
  ...
  sscanf(ptr, "....stuff...%n", ..., &read_chars);
  ptr += read_chars;

(perhaps you already knew this :)

Michael Gogins wrote:
> I'm afraid it's not that easy because, as I recall, reads occur all
> over the place... but my memory may be vague.
> 
> Anyway, I'll look into it. I would much prefer it if Csound rendered
> by default from memory, with options to have temporary files on disk
> or named permanent files on disk.
> 
> Regards, Mike
> 
> -----Original Message-----
>> From: Jonatan Liljedahl  Sent: Jan 31, 2008
>> 4:05 PM To: Developer discussions
>>  Subject: Re: [Cs-dev] CppSound
>> and CsoundPerformanceThread..
>> 
>> Michael Gogins wrote:
>>> They are not deleted afterwards. Personally, I want them around
>>> to document the rendering so I can recreate it or modify it
>>> later. There are number of pieces that I have lost because I did
>>> not do this, or did not lose because I still had the temporary
>>> files around (I used to do each rendering in its own directory,
>>> now I change the temp filenames to match a master filename).
>> Are you talking about the ones that the SetCSD() stuff is creating 
>> (because csound can only parse files, not strings) and not the 
>> /tmp/fileXXX.* files? (because these are deleted as they should, at
>>  least for me)
>> 
>>> In addition to this personal philosophical preference for the 
>>> temporary files, there is a technical reason. The Csound
>>> orchestra and score parsers need the orc and sco to be files on a
>>> disk. This should probably be changed -- not everyone is like me.
>>> You would like to create the orc and sco in memory and render
>>> from that, correct?
>> ...
>>> It might also be possible to change the Csound internals to be
>>> able to use pre-allocated memory buffers for this, or file
>>> handles that belong to a memory stream. I will look at this
>>> latter idea again to see if it is possible. It is easily possible
>>> in C++ but I do not know about C.
>> How does the parsers look? Do they use filedescriptors or FILE*
>> streams? It should be "easy" to just allocate buffers and use these
>> instead, and do stuff like c = *buf++ instead of c = fgetc(f), or
>> sscanf() instead of scanf(), memcpy() instead of read(), etc...
>> 
>> -- /Jonatan         [ http://kymatica.com ]
>> 


-- 
/Jonatan         [ http://kymatica.com ]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I think that otran does this, but the score parser does not.  One reason is
that the repeat opcodes in the score require looping on pre-macro-expanded
input.  (Not that it could not be done).  This area of the score parser is
very sensitive ...

Anthony

Jonatan Liljedahl wrote on 1/31/08 6:32 PM:

> When I write parsers I often load the whole file to memory first and
> parse the string buffer, it's much easier to move around in a buffer
> instead of needing to get/push chars and seek in the file, etc.
> (So if this change is done the code might be a lot cleaner afterwards)


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net