1. Handling Structured Memory
13/11/2002 8:16:59 AM, Don Phillips <EuNexus at yahoo.com> wrote:
>
>
>Hey Derek, if you are looking for better handling of structures I might
>be able to help you out.
Its not that I'm looking for a "better way", but more that I'd like structured
memory handling to be
built into Euphoria. That way we could all use a standardised method rather than
the plethora of
struct libraries that currently exist.
Euphoria seems to not support structured memory because such a thing is not
abstract. The Euphoria
sequence can quite adequately do everything that a memory structure can do (and
more). It does this
by giving us an abstract memory model rather than having to force us to concern
ourselves with the
physical layout and interpretation of bits in RAM. And this is a good thing.
However, because we have to deal with programs and systems that are not using
the same memory model
as Euphoria (ie. every other programming language), we do actually need to deal
with the physical
structured memory model. Euphoria does provide all the low-level tools with
which to build code that
enables us to deal with structures, but because of that very thing, people have
built many different
(vastly different!) methods of doing the same thing. Thus it would be ever so
nice if the Euphoria
language could enter the real world and help us (in a consistent way) to deal
with these non-
Euphoria systems. And I'd prefer it if it was done at the syntax level rather
than RDS providing,
yet another, structure library.
Euphoria is a tool. Tools should be easy to use. (But maybe its not the right
tool for interfacing
with non-Euphoria programs).
For example...
struct Rect
INT32 a
UINT16 b
UBYTE c(2)
end struct
Rect d
d.a = 1
d.c(1) = 'a'
d.c(2) = #AC
integer i
i = d.b
atom m,n,o
m = allocate(length(Rect))
n = allocate(length(d))
Rect:m.a = 2
Rect:n = d -- Copies all of 'd' to where 'n' points to.
o = n -- Let's 'o' point to the same area as 'n'.
Rect:o = Rect:m -- Copies all of the Rect struct pointed to by 'm' to where 'o'
points to.
---------
Cheers,
Derek Parnell
2. Re: Handling Structured Memory
- Posted by irv at take.maxleft.com
Nov 13, 2002
On Tuesday 12 November 2002 06:37 pm, Derek wrote:
>
> 13/11/2002 8:16:59 AM, Don Phillips <EuNexus at yahoo.com> wrote:
> >Hey Derek, if you are looking for better handling of structures I might
> >be able to help you out.
>
> Its not that I'm looking for a "better way", but more that I'd like
> structured memory handling to be built into Euphoria. That way we could all
> use a standardised method rather than the plethora of struct libraries that
> currently exist.
Derek:
Structures (the lack thereof) are a major shortcoming of Euphoria. You have
described one very valid use of structures, now let me describe another:
I work with structured data, and need an efficient way to describe that data
and to access individual portions of that data. I am perfectly happy to work
with non-fixed length fields that Euphoria's sequences provide, in fact I
prefer to do so. However, the workaround (let's face facts, it is only a
workaround) that Rob has provided for accessing structured data is laughable.
It gets laughs from programmers who are accustomed to the simple, clear, and
usable structures in Pascal, C, and almost every other language ever invented.
The only ones who aren't laughing are us poor Euphoria programmers who have
to try to make this work.
If anyone does not understand what I am saying here, please let me know. I
can post a typical example.
Regards,
Irv
3. Re: Handling Structured Memory
On 13 Nov 2002, at 8:22, irv at take.maxleft.com wrote:
>
> On Tuesday 12 November 2002 06:37 pm, Derek wrote:
> >
> > 13/11/2002 8:16:59 AM, Don Phillips <EuNexus at yahoo.com> wrote:
> > >Hey Derek, if you are looking for better handling of structures I might
> > >be able to help you out.
> >
> > Its not that I'm looking for a "better way", but more that I'd like
> > structured memory handling to be built into Euphoria. That way we could all
> > use a standardised method rather than the plethora of struct libraries that
> > currently exist.
>
> Derek:
>
> Structures (the lack thereof) are a major shortcoming of Euphoria. You have
> described one very valid use of structures, now let me describe another:
>
> I work with structured data, and need an efficient way to describe that data
> and
> to access individual portions of that data. I am perfectly happy to work with
> non-fixed length fields that Euphoria's sequences provide, in fact I prefer to
> do so. However, the workaround (let's face facts, it is only a workaround)
> that
> Rob has provided for accessing structured data is laughable.
>
> It gets laughs from programmers who are accustomed to the simple, clear, and
> usable structures in Pascal, C, and almost every other language ever invented.
> The only ones who aren't laughing are us poor Euphoria programmers who have to
> try to make this work.
>
> If anyone does not understand what I am saying here, please let me know. I can
> post a typical example.
Please post it. I stopped using Pascal partly because i couldn't nest var
records at any place i wanted. If you want restrictions in a program, that's
*easy* to add. It's getting the language to *allow* things that is difficult!
Kat
4. Re: Handling Structured Memory
----- Original Message -----
From: <irv at take.maxleft.com>
To: "EUforum" <EUforum at topica.com>
Subject: Re: Handling Structured Memory
>
>On Tuesday 12 November 2002 06:37 pm, Derek wrote:
>>
>> 13/11/2002 8:16:59 AM, Don Phillips <EuNexus at yahoo.com> wrote:
>> >Hey Derek, if you are looking for better handling of structures I might
>> >be able to help you out.
>>
>> Its not that I'm looking for a "better way", but more that I'd like
>> structured memory handling to be built into Euphoria. That way we could
all
>> use a standardised method rather than the plethora of struct libraries
that
>> currently exist.
>
>Derek:
>
>Structures (the lack thereof) are a major shortcoming of Euphoria. You have
>described one very valid use of structures, now let me describe another:
>
>I work with structured data, and need an efficient way to describe that
data
>and to access individual portions of that data. I am perfectly happy to
work
>with non-fixed length fields that Euphoria's sequences provide, in fact I
>prefer to do so. However, the workaround (let's face facts, it is only a
>workaround) that Rob has provided for accessing structured data is
laughable.
>
>It gets laughs from programmers who are accustomed to the simple, clear,
and
>usable structures in Pascal, C, and almost every other language ever
invented.
>The only ones who aren't laughing are us poor Euphoria programmers who have
>to try to make this work.
>
>If anyone does not understand what I am saying here, please let me know. I
>can post a typical example.
>
>Regards,
>Irv
Yes Irv, I was only addressing the structed RAM issue and not the other
issue of strucured data. I agree that Euphoria would be enhanced if it
supported both concepts at the syntax level. The current method of assigning
sequence element indexes to constants and then using these is a little
kludgy.
constant Name = 1,
Address = 2,
Telephone = 3,
SIZEOF_CUSTOMER = 3,
NewCustomer = {"","",""}
type CustRecord (object x)
if sequence(x) and length(x) = SIZEOF_CUSTOMER and
sequence(x[Name]) and
sequence(x[Address]) and
sequence(x[Telephone]) then
return 1
else
return 0
end if
end type
CustRecord TempCust
TempCust = NewCustomer
TempCust[Name] = "Derek Parnell"
TempCust[Address] = "123 Main St"
TempCust[Telephone] = "555 5555"
------
instead of a simpler ...
struct sequence CustRecord
sequence Name
sequence Address
sequence Telephone
end struct
CustRecord TempCust
TempCust.Name = "Derek Parnell"
TempCust.Address = "123 Main St"
TempCust.Telephone = "555 5555"
----------------
cheers,
Derek Parnell
5. Re: Handling Structured Memory
- Posted by irv at take.maxleft.com
Nov 13, 2002
On Wednesday 13 November 2002 03:05 pm, Kat wrote:
> > If anyone does not understand what I am saying here, please let me know.
> > I can post a typical example.
>
> Please post it. I stopped using Pascal partly because i couldn't nest var
> records at any place i wanted. If you want restrictions in a program,
> that's *easy* to add. It's getting the language to *allow* things that is
> difficult!
Gladly. But this has nothing at all to do with restrictions that I want to
impose on Euphoria. It does illustrate some of features that should be
expected in any language, but which do not exist in Euphoria:
I have a client who sells items on a time-payment plan.
To keep track of who bought what, who owes how much, etc. he needs the
following data for each of a couple thousand customers:
for each customer, filed by ssn, the following fields:
customer
name, addr, city, state, zip, phone
customer's employer
name, addr, city, state, zip, phone, contact
Reference
name, addr, city, state, zip, phone
Purchases -- repeats n times
date, item, quantity, price
Payments -- repeats 24 times
date amount ck#
Adjustments -- repeats n times, for late fees, credits, etc.
date type amount ref#
(some more stuff)
Now, to describe the structure of this data as a Pascal record would be
pretty simple, except that you would have to establish a max value for n.
type address_rec = record
name : string;
addr : string;
city : string;
state : string[2];
zip : string[10[;
phone : string[10]
end;
customer_rec = record
ssn = string[[11];
info = address_rec
end;
reference_rec = address_rec;
employer_rec = record
info = address_rec;
contact = string
end;
purchase_rec = record
date : string;
item : string;
quantity : integer;
price : real
end;
..etc...
Then to make up my customer record:
CustomerRecord = record
customer : customer_rec;
employer : employer_rec;
reference : reference_rec;
purchase : array[1..n] of purchase_rec;
....etc...
end;
var this_rec : CustomerRecord;
Accessing members of the structure would be simple:
When customer #1002 changes her phone number, I can read record #1002, and
access it as:
this_rec.customer.info.phone := "555-1212";
if her employer changes, it's:
with this_rec.employer.info do
name := "Smith Co."
addr := "Whatever"
phone := "555-1234"
end;
This is simple. Compare it to trying to identify the fields in an equivalent
Euphoria sequence by using constants. Remember that the constants will
need to be global, because you may need to access this record from
other routines in different source files.
Add to that the fact that Pascal will type check the members of a field.
That saves a lot of headaches.
That's enough for now. Hope my Pascal isn't too wrong. And remember, this is
a simple one to convert to Euphoria, because it uses so many near-identical
structures. I'm usually not that lucky.
Regards,
Irv
6. Re: Handling Structured Memory
On 13 Nov 2002, at 16:38, irv at take.maxleft.com wrote:
>
> On Wednesday 13 November 2002 03:05 pm, Kat wrote:
>
> > > If anyone does not understand what I am saying here, please let me know. I
> > > can post a typical example.
> >
> > Please post it. I stopped using Pascal partly because i couldn't nest var
> > records at any place i wanted. If you want restrictions in a program, that's
> > *easy* to add. It's getting the language to *allow* things that is
> > difficult!
>
> Gladly. But this has nothing at all to do with restrictions that I want to
> impose on Euphoria. It does illustrate some of features that should be
> expected
> in any language, but which do not exist in Euphoria:
>
> I have a client who sells items on a time-payment plan.
> To keep track of who bought what, who owes how much, etc. he needs the
> following data for each of a couple thousand customers:
>
> for each customer, filed by ssn,
I recommend you do not use ssn, because in the early days, 1950's and
1960's, there were duplicate numbers issued, especially thru the military.
<snip>
> That's enough for now. Hope my Pascal isn't too wrong. And remember, this is a
> simple one to convert to Euphoria, because it uses so many near-identical
> structures. I'm usually not that lucky.
How about a structured example that Eu can't do in sequences or EDS?
Kat
7. Re: Handling Structured Memory
Kat wrote:
> On 13 Nov 2002, at 16:38, irv at take.maxleft.com wrote:
<snip>
>> I have a client who sells items on a time-payment plan.
>> To keep track of who bought what, who owes how much, etc. he needs the
>> following data for each of a couple thousand customers:
>>
>> for each customer, filed by ssn,
>
> I recommend you do not use ssn, because in the early days, 1950's and
> 1960's, there were duplicate numbers issued, especially thru the military.
> <snip>
What is "ssn", please?
TIA and regards,
Juergen
--
while not asleep do
sheep += 1
end while
8. Re: Handling Structured Memory
Social Security Number. An "American" thing. In Australia we do not have
anything like a ssn that
can be used. There is no National Identity numbering system in Austalia.
14/11/2002 9:38:17 AM, Juergen Luethje <jluethje at gmx.de> wrote:
>
>Kat wrote:
>
>> On 13 Nov 2002, at 16:38, irv at take.maxleft.com wrote:
>
><snip>
>>> I have a client who sells items on a time-payment plan.
>>> To keep track of who bought what, who owes how much, etc. he needs the
>>> following data for each of a couple thousand customers:
>>>
>>> for each customer, filed by ssn,
>>
>> I recommend you do not use ssn, because in the early days, 1950's and
>> 1960's, there were duplicate numbers issued, especially thru the military.
>> <snip>
>
>What is "ssn", please?
>
>TIA and regards,
> Juergen
>--
>while not asleep do
> sheep += 1
>end while
>
>
>
>
---------
Cheers,
Derek Parnell
ICQ# 7647806
9. Re: Handling Structured Memory
14/11/2002 9:04:59 AM, Kat <kat at kogeijin.com> wrote:
<<SNIP>>
>How about a structured example that Eu can't do in sequences or EDS?
constant NAME = 1,
PHONE = 2,
NewCust = {"",""}
constant KEYWORD = 1,
VALUE = 2,
NewPair = {"",""}
sequence TempCust, TempPair
-- This works in Euphoria but shouldn't be allowed.
TempCust = NewCust
TempCust[KEYWORD] = "Derek"
TempCust[VALUE] = "555-5555"
TempPair = NewPair
TempPair[NAME] = "filename"
TempPair[PHONE] = "C:\autoexec.bat"
If structures where built in at the syntax level, this sort of mis-information
could be detected by
the interpreter. The Eu type system won't help much here either.
---------
Cheers,
Derek Parnell
10. Re: Handling Structured Memory
- Posted by irv at take.maxleft.com
Nov 13, 2002
On Wednesday 13 November 2002 03:42 pm, Derek wrote:
> Yes Irv, I was only addressing the structed RAM issue and not the other
> issue of strucured data. I agree that Euphoria would be enhanced if it
> supported both concepts at the syntax level. The current method of
> assigning sequence element indexes to constants and then using these is a
> little kludgy.
>
> constant Name = 1,
> Address = 2,
> Telephone = 3,
> SIZEOF_CUSTOMER = 3,
> NewCustomer = {"","",""}
>
> type CustRecord (object x)
> if sequence(x) and length(x) = SIZEOF_CUSTOMER and
> sequence(x[Name]) and
> sequence(x[Address]) and
> sequence(x[Telephone]) then
> return 1
> else
> return 0
> end if
> end type
>
> CustRecord TempCust
>
> TempCust = NewCustomer
> TempCust[Name] = "Derek Parnell"
> TempCust[Address] = "123 Main St"
> TempCust[Telephone] = "555 5555"
>
> ------
> instead of a simpler ...
>
> struct sequence CustRecord
> sequence Name
> sequence Address
> sequence Telephone
> end struct
>
> CustRecord TempCust
>
> TempCust.Name = "Derek Parnell"
> TempCust.Address = "123 Main St"
> TempCust.Telephone = "555 5555"
I know you understand this, but in case someone else doesn't:
With the example given, even the first (standard Euphoria) method) doesn't
look too clumsy. However, most data I work with has not three fields, but
80 or 100.
Adding or removing a single item means renumbering as many as
99 out of 100 entries in the constant definitions. That would be easier if
Rob was willing to add enum, but enum would be only a partial solution to
this problem, because we'd still be stuck with having to use global
constants.
Meaning we could only
1. use NAME and ADDR once in the entire program, or
2. prefix everything, like customer[i][custName], customer[i][custADDR], or
3. use namespacing: customer[i][cust:NAME], customer[i][cust:ADDR].
(How many times do I have to type cust before Euphoria catches on?)
Compare that with the following:
with customer[i] do
printf(1,"%s\n%s\n",{NAME,ADDR})
Next, think of writing code to properly initialize those 80 or 100 fields, so
we don't get the "has not been assigned a value" error.
Worse, consider the effort required to write and debug a 100 line type
routine. Is it going to be fast? Doesn't seem likely, since every time an
assignment is made to ANY member of the structure, every single member
must be t;ype checked again.
Regards,
Irv
11. Re: Handling Structured Memory
Derek wrote:
> 14/11/2002 9:38:17 AM, Juergen Luethje <jluethje at gmx.de> wrote:
>
>> What is "ssn", please?
>
> Social Security Number. An "American" thing. In Australia we do not
> have anything like a ssn that can be used. There is no National
> Identity numbering system in Austalia.
Ahhhh. I had thought that it was something like md5 ...
But then I didn't understand Kat's comment.
Thanks Derek.
Regards,
Juergen
--
Q: How many Microsoft engineers does Bill need to change a light bulb?
A: None. He just declares darkness to be an industry standard.
12. Re: Handling Structured Memory
Chris wrote;
> Maybe soon, the author will release his wrapper set, or maybe he has
> already.. I'll find out..
I just uploaded all my api libs to my website at the url:
http://pages.prodigy.net/mirwalds/win32.zip .
For a link to the bookmark on the page, use:
http://pages.prodigy.net/mirwalds/#win32 .
I included two folders in the zip, that you should be able to drop in your
include folder, and use include names such as " include winapi/user32.ew ".
The kernel32.ew file is just a set of routines and constants that I
frequently use, or had wrapped in the past. I never completely converted it
because of all the thread/process/memory stuff that we really don't need.
All the others are designed for Win9x, IE V5.01. They are useable on XP and
2000, but lack the additional goodies that the newer platforms offer. The
structs.e file that Chris was referring to is included in the dev folder.
There are many structures in there that haven't been converted yet, but the
definitions that appears in the respective header is commented for each. I
have found that it's better to define them when I'm actually using them, due
to differances in alignment between C and Euphoria.
You are welcome to include it in the archives Robert. I also fixed the
annoying set_packet_size() thing in tcp.ew, so that if a user doesn't
specifically call it, it'll set packets to 1024 bytes automatically. Calling
set_packet_size() overrides this default regardless of when it's called.
<2-cents>
I spent ALOT of time trying to keep track of prefixes before I saw Chris'
ideas for structs.e. There's just such an overwhelming number of duplicated
names in these api libs, it was a constant battle (heh) to try and remember
them all, and look them up when my memory failed me. The ability to re-use
the names was a god-send for these libs. I can sure live with strings to be
able to copy/paste the structure names from the docs into my code (some are
pretty long).
</2-cents>
Jason
