Hi, Robert
A NAMELIST of variables is a list of (previously-) declared variable
names to each of the members of which one can assign values. The type of
each variable determines what kind of data may be assigned to each variable
and how these values are to be assigned. For example, in object-oriented
languages, which might allow such assignments, assigning values to the data
fields of an object whose data field might be "included in a NAMELIST" via
the object's setter methods again depending on data type. Conversely,
reading, displaying, and subsequently writing to a file the
currently-assigned value(s) of a variable in a NAMELIST can also include
reading values of object data fields via that object's getter method for a
given field. In this way, a NAMELIST of variables aggregates variables of
various data types both simple and abstract (in the OO sense) into a single
structure which facilitates reading and writing for large data volume. Key
to implementing all of this functionality is the ability in a language to
refer to the source code name and value of a declared variable and put it in
a list, i.e., a structure that accepts such names and the values to which
they refer as elements in a form of generalized array.
In the case of the output of a NAMELIST being written to a
human-readable textfile, called INSTANCE_NAME.NML, the file might look
something like this:
-----------------------------SNIP-------------------------------------------------------------------
&NAMELIST_INSTANCE_NAME
VAR1 = val1;
VAR2 = val2;
ArrayVar3 = ArrayVar3_11 ArrayVar3_12 ArrayVar3_13...
ArrayVar3_21 ArrayVar3_22 ArrayVar3_23...
ArrayVar3_31 ArrayVar3_32 ArrayVar3_33...
. .
.
. .
.
. .
.
&NAMELIST_INSTANCE_NAME
-------------------------------SNIP-----------------------------------------------------------------
Paule
----- Original Message -----
From: "Robert Meek" <[EMAIL PROTECTED]>
To: "'Borland's Delphi Discussion List'" <[email protected]>
Sent: Saturday, March 11, 2006 2:23 PM
Subject: RE: A Delphi Component that enables namelist-directed I/O
> Your description seems now a little different than what you first
> proposed, where you asked simply for a component, ( which I read to have
> meant visual ), that could display simple name=value pairs. Such things
> can
> be done quite well even with a simple listbox or edit and with or without
> an
> underlying TStringList, objectlist, array, whatever, providing you with
> the
> abilities to manipulate and/or parse these pairs from data whether it be
> represented textually or in binary form.
> Now suddenly you have upped the Ante to include the full parsing of
> un-structured data into some other form. Are we still talking about
> simple
> Name=Value pairs as the final output? Or are we talking about structured
> data streams of human-readable text? These are two entirely different
> concepts.
> My problem with using xml for the latter, IF you do NOT need the
> output to be human-readable, is all the overhead involved with taking the
> parsed data and formatting into an xml representation...and then possibly
> back again? If it doesn't need to be human-readable in it's final form OR
> if simple Name=Value pairs is all you need, xml would not seem to me to be
> the way to go!
> You'll find many varied examples of parsing various forms of data
> into various states for use on the net, but I don't know that you're going
> to find one that can be universally applied to any type of data no matter
> what its form is. The parsing needs to be designed to digest the
> available
> data down into a particular form and/or type that you need. After that
> you
> can do almost anything you want with the result set depending on what it
> is
> and what form its in itself!
>
> from Robert Meek dba Tangentals Design CCopyright 2006
>
> "When I examine myself and my methods of thought, I come to the conclusion
> that the gift of Fantasy has meant more to me then my talent for absorbing
> positive knowledge!"
> Albert Einstein
>
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf
> Of Cosmin Prund
> Sent: Friday, March 10, 2006 4:12 AM
> To: 'Borland's Delphi Discussion List'
> 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
