Thanks, Cosmin
I really appreciate the power of this Delphi List, which in the language
of transaction processing, might best be stated as eventually-convergent
interaction. It seems that you, Robert, and I are finally converging on the
same thing: modern Fortran, a compiled language optimized for data
throughput and manipulation, contains a facility from which other compiled
languages might profit greatly, although they weren't designed for it. Even
as late as Fortran 77 the NAMELIST structure wasn't completely nailed down.
So, I wonder is there a way to "transliterate" the C NAMELIST emulator (many
thanks for the search Cosmin) into pure Delphi? I appreciate the underlying
difficulties and the possible requirement for pushing the envelope of Delphi
language constraints, however a scientific computing oriented Delphi would
really do well to have a built-in or at least mostly-native NAMELIST
facility.
This facility should allow aggregation of already-declared variables
with the option to initialize them via a collective NAMELIST assignment,
e.g., in a loop or from a file. That together with whole array operations
and time-optimized memory management should make Delphi a R.A.D.,
fully-O.O. alternative Fortran 2003 and C++.
I realize that you can assign a value to a variable name, but rather to the
memory space already allocated or allocatable to that variable, whose name
is just part of its declaration and that the source code level variable name
is no longer present in the compiled and linked executable and that source
level debugging requires synchronization of executable machine code
instructions, their assemby mnemonics, and source code level variable names.
However, the Fortran implementation of NAMELISTs ought to be repeatable in
other languages that are sufficiently-complete. Can we find a way? It would
really be worth it.
Best regards,
Paule
----- Original Message -----
From: "Cosmin Prund" <[EMAIL PROTECTED]>
To: "'Borland's Delphi Discussion List'" <[email protected]>
Sent: Monday, March 13, 2006 2:21 PM
Subject: RE: A Delphi Component that enables namelist-directed I/O
> Here I go again!
>
> My curiosity led me to google and wikipedia - I really wanted to see some
> sample Fortran code working with NAMELISTS. And I found more then that - I
> found the documentation for a C library designed to make it possible for
> an
> C program to read/write Namelists.
>
> Here's the link:
> http://mmace.nrl.navy.mil:8080/mmace/mmace_docs/mm-tech-C-namelist.html#sec2
> 1
>
> I noticed this library creates a in-memory structure for associating
> variables with names for the purpose of reading/writing namelists. In
> other
> words, some other people had the same problem you're having, only they
> wore
> coding with C - not Delphi.
>
> I know understand the issue: FORTRAN has a specialized keyword NAMELIST
> for
> defining a group of variables for the purpose of saving them to a text
> file.
> I guess the program would generate all required RTTI on the base of that
> statement (ie: the Compiler offers support for such a thing).
>
> In it's Win32 form Delphi offers only limited support for RTTI. In order
> to
> properly simulate NAMELIST behavior for any kind of variable you'd require
> compiler support (so the compiler would generate some form of RTTI for
> local/stack variables as well as any other kind of variable). The only
> parts
> of the code that automatically get RTTI are the published members of
> TPersistent descendent classes. If you can work within those restrictions
> you might be able to get NAMELIST behavior working.
>
> You might also be able to get NAMELIST behavior by supplying all the
> required RTTI yourself.
>
> Code sample in pseudo-pascal:
>
> <snip>
> procedure NamespaceTest;
> var a:Integer;
> b:Double;
> c:string;
> Test1:TDelphiNameList;
> begin
> a := 1;
> b := 2.0;
> c := 'Test string';
> Test1 := TDelphiNameList.Create;
> try
> Test1.RegInteger(@a, 'a');
> Test1.RegDouble(@b, 'b');
> Test1.RegDouble(@c, 'c');
> Test1.SaveToFile('c:\test.txt');
> Test1.LoadFromFile('c:\test.txt');
> finally Test1.Free;
> end;
> end;
> </snip>
>
> I can elaborate on that if it looks like something that might help.
>
>> -----Original Message-----
>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
>> Behalf Of Paule Ecimovic
>> Sent: Saturday, March 11, 2006 6:40 PM
>> To: Borland's Delphi Discussion List
>> Subject: Re: A Delphi Component that enables namelist-directed I/O
>>
>> The first thing I'd need to know is how to refer, in a standard Pascal or
>> Delphi way, to the source-code-level name of a variable so as to put it
>> in
>> a
>> list. Then assemble a list of variables of various types. Then assign a
>> name
>> to the resulting list, which would also be a variable of (class) type
>> NAMELIST. This class would contain methods for inputing and outputing
>> values
>> of variable in an instantiated NAMELIST object at runtime.
>>
>> Paule
>> ----- Original Message -----
>> From: "Cosmin Prund" <[EMAIL PROTECTED]>
>> To: "'Borland's Delphi Discussion List'" <[email protected]>
>> Sent: Friday, March 10, 2006 10:11 AM
>> Subject: RE: A Delphi Component that enables namelist-directed I/O
>>
>>
>> > Can you post a short "demo" of what you're trying to accomplish, using
>> > Pascal/Delphi syntax? I insist on pascal syntax (as opposed to
>> pseudocode
>> > or
>> > fortran) because I think you want something that can't be accomplished
>> by
>> > a
>> > compiled language without using some odd trick.
>> >
>> >> -----Original Message-----
>> >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
>> >> Behalf Of Paule Ecimovic
>> >> Sent: Friday, March 10, 2006 1:24 AM
>> >> To: Borland's Delphi Discussion List
>> >> Subject: Re: A Delphi Component that enables namelist-directed I/O
>> >>
>> >> Thanks Cosmin,
>> >>
>> >> Firstly, thank you for both your thorough response and your
>> incisive
>> >> sense of humor, which even helps digestion of the solutions you offer
>> in
>> >> ways that make them even more useful. Secondly, the ordering of your
>> >> solutions from most encapsulated to most exposed build-your-own
>> >> meta-language with a parser culminating in the very advice I am trying
>> to
>> >> avoid shows and evaluates for me a spectrum of ready solutions. This
>> all
>> >> makes me see how high performance oriented Fortran 9x really is and
>> >> how
>> >> expensive a trade-off are built in graphics, RAD GUI development (even
>> >> the
>> >> best in the programming industry), and a very familiar, quite
>> >> complete,
>> >> and
>> >> powerful implementation of object-oriented programming for language
>> >> features
>> >> that are tuned to the decades old and still unchanging needs of
>> >> scientific
>> >> computing: high-volume, highly-structured data throughput in a
>> >> computationally-intensive environment.
>> >> Plug-and-play reusability is, pardon the expression, a gimmick,
>> which
>> >> I
>> >> have learning to sell myself on and have found very useful in not
>> >> re-inventing the computer science wheel every time I need to do
>> something
>> >> that involves creating and parsing little variable-centric languages
>> such
>> >> as
>> >> are instantly handled by Fortran 9x NAMELIST-directed I/O. I would
>> >> like
>> >> to
>> >> used Delphi as a transparent
>> >> Del-tran making the best use of the best parts of both languages. I
>> >> realize
>> >> that as the thread started by Robert Meek on the topic of deleting an
>> >> element from an array brings home once again that the tax of
>> >> encapsulating
>> >> programming language dynamics in high-level facilities is paid at
>> >> run-time
>> >> in seemingly unaccountable ways. For plug-and-play re-usability of
>> modern
>> >> computer science routines to be feasible, it must become such that the
>> >> solutions it encapsulates perform to between 60% and 80% of optimal
>> >> runtime
>> >> efficiency, i.e., the best hand-coding possible, in any conceivable
>> >> context
>> >> of application . I guess the over-head debate almost as old as Simula
>> 67
>> >> or
>> >> at least as old as C++, but I'm sure the promise of OO and of Delphi's
>> OO
>> >> successor, component orientation, can and will be realize in high
>> >> run-time
>> >> performance, plug-and-play re-usable components that are
>> >> mini-applications
>> >> in themselves that needn't be re-coded (almost) at all: functionality
>> >> pills
>> >> to boost the potency of modern applications.
>> >> Specifically, I envision the system to work according to (excuse
>> the
>> >> schematic and informal syntax):
>> >>
>> >> namelist_type_inst.write(varname,[var_type],varfile,[permissions]);
>> >>
>> >> and
>> >>
>> >> namelist_type_inst.write(varname,[var_type],varfile,[permissions]);
>> >>
>> >>
>> >> This way I have an instance of a NAMELIST class which encapsulates
>> write
>> >> and
>> >> read methods. The read method should read from a delimited plain text
>> >> file,
>> >> tokenize it, and parse it for regular expressions defined by the
>> >> variable(s)
>> >> and their types given as parameters. If there is a way to infer a
>> >> variable's
>> >> type from its instance properties, then the additional type parameter
>> is
>> >> unnecessary. If however, this problem turns out to be recursively
>> >> unsolvable, then additional type information must be included as a
>> >> parameter
>> >> to the read method.
>> >>
>> >> I could say more and I should provide an example, but that's for
>> another
>> >> note.
>> >>
>> >> Paule
>> >> ----- Original Message -----
>> >> From: "Cosmin Prund" <[EMAIL PROTECTED]>
>> >> To: "'Borland's Delphi Discussion List'" <[email protected]>
>> >> Sent: Thursday, March 09, 2006 4:16 PM
>> >> Subject: RE: A Delphi Component that enables namelist-directed I/O
>> >>
>> >>
>> >> > Delphi has a VERY re-usable, plug-and-play solution for handling
>> >> > object-to-text and text-to-object conversions. It's named "Delphi
>> >> > Streaming
>> >> > System" and it's the thing that produces the DFM's; And you will not
>> >> like
>> >> > it
>> >> > - it's not really human readable.
>> >> >
>> >> > Also there's Delphi's TStringList. It has a "Values" property that
>> can
>> >> be
>> >> > used to handle basic "key=value" pairs. Not very smart but can do
>> >> > the
>> >> job.
>> >> >
>> >> > If TStringList's basic "key=value" is not enough you may consider
>> >> > TIniFile.
>> >> > TIniFiles offers a bit more, specifically it offeres a way to read a
>> >> > "value"
>> >> > as a given native type. It also has support for grouping values into
>> >> > "sections".
>> >> >
>> >> > If you need more structure there's XML. It is text, it is cool and
>> >> > it
>> >> > is
>> >> > almost human readable.
>> >> >
>> >> > If you don't want DFM, you don't want TStringList, you don't like
>> good-
>> >> old
>> >> > TIniFile and you think XML is overkill, you can always roll your own
>> >> > :-)
>> >> >
>> >> > How exactly do you envision this plug-and-play system to work?
>> >> >
>> >> >> -----Original Message-----
>> >> >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
>> On
>> >> >> Behalf Of Paule Ecimovic
>> >> >> Sent: Thursday, March 09, 2006 11:57 AM
>> >> >> To: Borland's Delphi Discussion List
>> >> >> Subject: A Delphi Component that enables namelist-directed I/O
>> >> >>
>> >> >> Hi, All
>> >> >>
>> >> >> After coming across very useful threads in this list on writing
>> to
>> >> >> and
>> >> >> reading from human-readable text files in structured ways, such as
>> >> >> writing
>> >> >> the values of a list of variables of various types to a file
>> >> >> containing
>> >> a
>> >> >> string representing a given variable's name followed by a delimiter
>> >> >> followed by that variable's value along with the ability to extract
>> >> >> the
>> >> >> information back from the corresponding file, I came to wondering
>> >> whether
>> >> >> there is a Delphi component that does this. In the past when I have
>> >> >> posted
>> >> >> to this list about this I got very useful pointers outside of
>> Delphi,
>> >> >> i.e., a wrapper of a C routine for NAMELIST-like functionality, or
>> the
>> >> >> tried and true yet insufficiently re-useable maxim "For best
>> results,
>> >> >> advice roll-your-own". I am wondering about a plug-and-play
>> >> >> standard
>> >> >> Delphi solution to this problem that I can re-use at the drop of a
>> >> >> hat,
>> >> >> everywhere.
>> >> >>
>> >> >> Many thanks in advance,
>> >> >>
>> >> >> Paule
>> >> >> _______________________________________________
>> >> >> Delphi mailing list -> [email protected]
>> >> >> http://www.elists.org/mailman/listinfo/delphi
>> >> >
>> >> > _______________________________________________
>> >> > Delphi mailing list -> [email protected]
>> >> > http://www.elists.org/mailman/listinfo/delphi
>> >> >
>> >>
>> >>
>> >> _______________________________________________
>> >> Delphi mailing list -> [email protected]
>> >> http://www.elists.org/mailman/listinfo/delphi
>> >
>> > _______________________________________________
>> > Delphi mailing list -> [email protected]
>> > http://www.elists.org/mailman/listinfo/delphi
>> >
>>
>>
>> _______________________________________________
>> Delphi mailing list -> [email protected]
>> http://www.elists.org/mailman/listinfo/delphi
>
> _______________________________________________
> Delphi mailing list -> [email protected]
> http://www.elists.org/mailman/listinfo/delphi
>
_______________________________________________
Delphi mailing list -> [email protected]
http://www.elists.org/mailman/listinfo/delphi
