1. Handling Structured Memory
- Posted by Derek Parnell <ddparnell at bigpond.com> Nov 12, 2002
- 450 views
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
- 423 views
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
- Posted by Kat <kat at kogeijin.com> Nov 13, 2002
- 430 views
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
- Posted by Derek Parnell <ddparnell at bigpond.com> Nov 13, 2002
- 400 views
----- 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
- 411 views
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
- Posted by Kat <kat at kogeijin.com> Nov 13, 2002
- 423 views
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
- Posted by Juergen Luethje <jluethje at gmx.de> Nov 13, 2002
- 393 views
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
- Posted by Derek Parnell <ddparnell at bigpond.com> Nov 13, 2002
- 402 views
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
- Posted by Derek Parnell <ddparnell at bigpond.com> Nov 13, 2002
- 406 views
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
- 409 views
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
- Posted by Juergen Luethje <jluethje at gmx.de> Nov 14, 2002
- 411 views
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
- Posted by Jason Mirwald <mirwalds at prodigy.net> Nov 14, 2002
- 438 views
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