1. address of variable
- Posted by Bernie Ryan <bwryan at PCOM.NET> Dec 15, 1999
- 359 views
Rob: Why is it so difficult for Euphoria to return the address of a variable ? Since we can not pass a variable by reference; this would give the programmer a way to access a variable inside a procedure or function. It would not have to be any more than a simple function that returned a memory address of a given variable. If the variable is not available then it would return -1 If swapping out of memory is a problem then you could have the programmer declare them as special locked variables. Bernie
2. Re: address of variable
- Posted by Robert Craig <rds at ATTCANADA.NET> Dec 15, 1999
- 353 views
- Last edited Dec 16, 1999
Bernie Ryan writes: > Why is it so difficult for Euphoria to return the > address of a variable ? It isn't difficult. It's just a really bad idea for many other reasons. Here's my post on this subject from a few weeks ago... Nick Metcalfe writes: > It occured to me some time ago that a new function > for DOS/Win? Euphoria that returns pointers to variables in > memory like BASIC's VARPTR() would allow for some > serious performance improvements when using > embedded assembler or virtual screens in programs. This has been suggested before from time to time. On the surface it may sound like a good idea. However it will probably never be implemented because: - It would force me to freeze the current internal format for data. This format has changed many times, leading to enhanced performance, and change was only possible because no program depends on the format. - It would open a "Pandora's Box" of evil code that would access and alter variables in ugly and invisible ways. You'd see a lot of unexplained crashes and weird behavior, that would tend to be blamed on Euphoria itself. - It would reveal proprietary information that might help the competition to make faster interpreters (Rebol 44x slower?, Perl 34x slower? Python 34x slower?) - A variable's value is not always stored at the same place. A fixed varptr address is not that meaningful in the context of garbage collection etc. - You wouldn't get the full speed-up that you imagine. The machine code would have some of the same overheads as the interpreter when reading the internal format. Regards, Rob Craig Rapid Deployment Software http://www.RapidEuphoria.com
3. Re: address of variable
- Posted by Bernie Ryan <bwryan at PCOM.NET> Dec 16, 1999
- 360 views
Rob: I think that a programmer should be able to store data in a global variable inside a procedure or function. ( I don't need to know the variables address ) I also think a programmer should be able to use the free function to free memory that was allocated outside of a function or procedure from within a procedure or function. An example for it's need is: With in a procedure and I want to free a memory pointer's allocated memory. Reallocate a larger memory block and then reassign that memory block to that same memory pointer. This at present can not be done in Euphoria. Bernie
4. Re: address of variable
- Posted by Bernie Ryan <bwryan at PCOM.NET> Dec 16, 1999
- 349 views
Rob: Correction, memory can be freed from within a function or procedure. But, I want to be able to reassign a global pointer inside a procedure or function. Bernie
5. Re: address of variable
- Posted by "Boehme, Gabriel" <gboehme at POSTOFFICE.MUSICLAND.COM> Dec 16, 1999
- 358 views
Bernie Ryan wrote: >I think that a programmer should be able to store data in a >global variable inside a procedure or function. ( I don't need to >know the variables address ) Erm...you already *can* do this... global object var ... procedure or_function() ... var = some_value ... end procedure >I also think a programmer should be able to use the free function >to free memory that was allocated outside of a function or procedure >from within a procedure or function. atom addr ... procedure one_procedure() ... addr = allocate(number_of_bytes_needed) ... end procedure ... procedure another_procedure() ... if addr then ... free(addr) end if ... end procedure >An example for it's need is: > With in a procedure and I want to free a memory pointer's >allocated memory. Reallocate a larger memory block and then reassign >that memory block to that same memory pointer. This at present can not >be done in Euphoria. atom addr addr = 0 ... procedure resize_memory_block() ... free(addr) ... addr = allocate(new_length) ... end procedure >Correction, memory can be freed from within a function or procedure. >But, I want to be able to reassign a global pointer inside a procedure or >function. Okay, just put "global" in front of my "atom addr" in the example above. Hep yadda, Gabriel Boehme ---------- If we know what to look for, we may recognise it when it happens. Otherwise, we see what we expect to see. That is, what we know in ourselves. Robert Fripp ----------
6. Re: address of variable
- Posted by Bernie Ryan <bwryan at PCOM.NET> Dec 16, 1999
- 354 views
On Thu, 16 Dec 1999 10:11:08 -0600, Boehme, Gabriel <gboehme at POSTOFFICE.MUSICLAND.COM> wrote: >Erm...you already *can* do this... Gabriel: It's probably something I'am overlooking but try this program: include machine.e global object var var = allocate(4) poke(var,123) procedure foo() ? peek(var) poke(var,456) ? peek(var) end procedure foo() ? peek(var) Thanks Bernie
7. Re: address of variable
- Posted by Kat <KSMiTH at PELL.NET> Dec 16, 1999
- 354 views
----- Original Message ----- From: Bernie Ryan <bwryan at PCOM.NET> To: <EUPHORIA at LISTSERV.MUOHIO.EDU> Sent: Thursday, December 16, 1999 1:09 PM Subject: Re: address of variable > On Thu, 16 Dec 1999 10:11:08 -0600, Boehme, Gabriel > <gboehme at POSTOFFICE.MUSICLAND.COM> wrote: > >Erm...you already *can* do this... > > Gabriel: > It's probably something I'am overlooking but try this program: > > include machine.e > > global object var > > var = allocate(4) > poke(var,123) > > procedure foo() > ? peek(var) > poke(var,456) An 8 bit memory location can hold more than 256 (or 255, depending on how you call it, you know what i mean.) ? I know!, you are using one of those new-fangled trinary cpus, right? How are they? I am guessing they do math slower.... Kat
8. Re: address of variable
- Posted by "Boehme, Gabriel" <gboehme at POSTOFFICE.MUSICLAND.COM> Dec 16, 1999
- 369 views
Bernie, Your example returns the following output: 123 200 200 The reason for this is that 456 is outside a byte's 0-255 range, so you get and_bits(456, #FF) = 200. To store integers the way you seem to want to here (i.e., using 4 bytes), use the following code instead: include machine.e global atom var var = allocate(4) poke(var, int_to_bytes(123)) procedure foo() ? bytes_to_int(peek({var,4})) poke(var, int_to_bytes(456)) ? bytes_to_int(peek({var,4})) end procedure foo() ? bytes_to_int(peek({var,4})) This produces the following output: 123 456 456 Which is, I assume, what you wanted. Hep yadda, Gabriel Boehme ---------- The concern of the musician is music. The concern of the professional musician is business. Only become a professional musician if there is no other choice. Robert Fripp ----------
9. Re: address of variable
- Posted by Bernie Ryan <bwryan at PCOM.NET> Dec 16, 1999
- 386 views
On Thu, 16 Dec 1999 13:54:00 -0600, Kat <KSMiTH at PELL.NET> wrote: >An 8 bit memory location can hold more than 256 (or 255, depending on how >you call it, you know what i mean.) ? I know!, you are using one of those >new-fangled trinary cpus, right? How are they? I am guessing they do math >slower.... > Kat: DAHHH.. Should be poke4 PS. I know you are interested in scripting langauges. Have you ever looked at NETRXX ( ibm languauge ) at their web site. It allows you to write scripts in REXX for controlling java across the net. Thanks Kat Bernie
10. Re: address of variable
- Posted by Bernie Ryan <bwryan at PCOM.NET> Dec 16, 1999
- 355 views
On Thu, 16 Dec 1999 13:49:28 -0600, Boehme, Gabriel <gboehme at POSTOFFICE.MUSICLAND.COM> wrote: Gabriel: Thanks Gabriel I told you it was me, too many hours of programming :) Bernie
11. Re: address of variable
- Posted by Everett Williams <rett at GVTC.COM> Dec 16, 1999
- 355 views
Robert Craig wrote: >Bernie Ryan writes: >> Why is it so difficult for Euphoria to return the >> address of a variable ? > >It isn't difficult. It's just a really bad idea >for many other reasons. Here's my post on this >subject from a few weeks ago... > >it will probably never be implemented because: > > - It would force me to freeze the current internal format for data. > This format has changed many times, leading to enhanced > performance, and change was only possible because no > program depends on the format. Okay, I'll buy the internal format argument for the moment, but if we cannot know the internal format, then don't we really need some clear fixed structures and variables, if only for IO. At some point, we need something other than peek and poke as fixed interfaces to the outside world that use fixed forms of data with particular formats. I would be perfectly happy if these fixed structures were limited in scope to procedures in which the IO was done. It would be convenient if these structures could be included in some manner with prefixing to allow multiple occurrences. Peek and poke give us no names and actually do have some dependencies as evidenced by the atom/integer discussion that goes with their definition. > - It would open a "Pandora's Box" of evil code that would > access and alter variables in ugly and invisible ways. > You'd see a lot of unexplained crashes and weird behavior, > that would tend to be blamed on Euphoria itself. See above. There are ways to control this. > - It would reveal proprietary information that might > help the competition to make faster interpreters > (Rebol 44x slower?, Perl 34x slower? Python 34x slower?) I would have thought that the one thing that the Perl discussion would have given us is surcease from this pointless non-comparison. Who cares? Euphoria may or may not be faster than Perl/Rebol/Python/Visual whatever in any particular piece of code. It probably is somewhat faster, but it is most certainly overstated and of little significance to most of the community according to their comments. The ease of coding and reading appear to be uppermost in the minds of most of those who use Euphoria. As time goes on and faster machines take over, this will be less and less important. There will still be problems for which no interpretive or quasi- intepretive language can provide an answer purely because of performance. Proprietary paranoia appears to be solely your province. > - A variable's value is not always stored at the same place. > A fixed varptr address is not that meaningful in the context of > garbage collection etc. We're talking about "call" interfaces here, not internal work. While in a call, it is unlikely that a value will move around in memory because Euphoria won't have control. If all references must be by value then Euphoria should leave large things like screen IO completely alone because those things are just too large to pass by anything other than pointer. That leaves it as a script language that has only trivial ability to handle major tasks. All that type of thing is now being done through completely non-portable peek and poke rather than more easily modifiable call interfaces because of this little limitation. > - You wouldn't get the full speed-up that you imagine. > The machine code would have some of the same > overheads as the interpreter when reading the > internal format. > Sounds like an admission that Euphoria as it now stands is unable to deal cleanly with things such as I have described above. It might be noted that routine_id implements a pointer that is then passed as a value. So much for consistency. Must be terrible when the real world intrudes. Everett L.(Rett) Williams rett at gvtc.com
12. Re: address of variable
- Posted by "Boehme, Gabriel" <gboehme at POSTOFFICE.MUSICLAND.COM> Dec 16, 1999
- 349 views
Bernie Ryan wrote: > DAHHH.. Should be poke4 DOH -- I forgot about poke4! > I told you it was me, too many hours of programming :) You and me both! Going off to re-read LIBRARY.DOC on poke4, peek4s & peek4u... Hep yadda, Gabriel Boehme ---------- Music is the cup which holds the wine of silence; sound is that cup, but empty; noise is that cup, but broken. Robert Fripp ----------
13. Re: address of variable
- Posted by Kat <KSMiTH at PELL.NET> Dec 16, 1999
- 354 views
----- Original Message ----- From: Everett Williams <rett at GVTC.COM> To: <EUPHORIA at LISTSERV.MUOHIO.EDU> Sent: Thursday, December 16, 1999 2:22 PM Subject: Re: address of variable > Robert Craig wrote: > > >Bernie Ryan writes: > >> Why is it so difficult for Euphoria to return the > >> address of a variable ? > > > >It isn't difficult. It's just a really bad idea > >for many other reasons. Here's my post on this > >subject from a few weeks ago... > > > > >it will probably never be implemented because: > > > > - It would force me to freeze the current internal format for data. > > This format has changed many times, leading to enhanced > > performance, and change was only possible because no > > program depends on the format. > > Okay, I'll buy the internal format argument for the moment, but if we > cannot know the internal format, then don't we really need some > clear fixed structures and variables, if only for IO. Well three of us are using socks to talk to the outside world, and we send and recieve strings/sequences to do it. And somewhere i saw an assy language script that accepts sequences to send to serial/parallel ports. Then there is the interface to sound cards someone wrote, and an interface to a video card for different modes for games. And the on_mouse is done. David has interfaced with Win32lib and dos32lib(?). And Eu-managed screen buffering is done. What is missing that you want to do? Can you show us a Eu script that fails because of something Eu cannot do? > > > - It would reveal proprietary information that might > > help the competition to make faster interpreters > > (Rebol 44x slower?, Perl 34x slower? Python 34x slower?) > > I would have thought that the one thing that the Perl discussion would have > given us is surcease from this pointless non-comparison. Who cares? Me, for one. Mirc is even easier to code in, it has goto and string comparisons,, and heck, i can make strings that i don't know the names to and use them at runtime,, and it self modifies, etc,,, but it pours as slow as glass, and we all know glass is a liquid.... So i paid for a complete edition of Eu, to get that speed and ease of coding. It was that important to me,, as of the 10th of Dec, i had $19 to last me the month, i'm not rich. > > - A variable's value is not always stored at the same place. > > A fixed varptr address is not that meaningful in the context of > > garbage collection etc. > > We're talking about "call" interfaces here, not internal work. While in a > call, it is unlikely that a value will move around in memory because > Euphoria won't have control. You have something of a point here, but then there is windoze's nasty habit of paging things around, right out from under running applications. > > - You wouldn't get the full speed-up that you imagine. > > The machine code would have some of the same > > overheads as the interpreter when reading the > > internal format. > > > Sounds like an admission that Euphoria as it now stands is unable > to deal cleanly with things such as I have described above. It might be > noted that routine_id implements a pointer that is then passed as a value. > So much for consistency. Must be terrible when the real world intrudes. Everett, you gotta know that when an atom in a sequence takes up 4 bytes that 3 of those bytes have important data about the other byte's place in the world,,, and you shouldn't mess with those 3 bytes. Eu has more than one poke(), is there something besides that ( and the things i mentioned above ) that you wish to do? Kat
14. Re: address of variable
- Posted by "Boehme, Gabriel" <gboehme at POSTOFFICE.MUSICLAND.COM> Dec 16, 1999
- 356 views
Everett Williams wrote: [mega snippage] > Must be terrible when the real world intrudes. I'm sorry, but this statement of yours *really* made me angry. You, who only *ever* argue about what Euphoria should or shouldn't have based on your own *abstract* and *theoretical* ideas, are going to lecture *us* on the "real world"?!?! Here's my suggestion, for what it's worth. If you want these "problems" of yours addressed, post some "real world" code examples which actually demonstrate what you're talking about. You might be surprised by the helpful replies and "real world" solutions you'll receive in return. Yadda yadda, Gabriel Boehme ---------- When we have nothing to say, better to say nothing. When we have nothing to say, it is very hard to say nothing. Robert Fripp ----------
15. Re: address of variable
- Posted by Everett Williams <rett at GVTC.COM> Dec 16, 1999
- 362 views
Kat wrote: >> > >> Sounds like an admission that Euphoria as it now stands is unable >> to deal cleanly with things such as I have described above. It might be >> noted that routine_id implements a pointer that is then passed as a value. >> So much for consistency. Must be terrible when the real world intrudes. > >Everett, you gotta know that when an atom in a sequence takes up 4 bytes >that 3 of those bytes have important data about the other byte's place in >the world,,, and you shouldn't mess with those 3 bytes. Eu has more than one >poke(), is there something besides that ( and the things i mentioned above ) >that you wish to do? > >Kat Actually, I was following my license and not checking such things...not that I doubt what you are saying. But thanks for making my point. A quick look at the DBF-eng code from the archive will show you what absolute gyrations one must go to, to deal with externally formatted data. This only deals with DBF III files. A few simple structures could get rid of about 90% of that code. I'm not asking for access to those precious internal formats. I'm asking for some way to deal with structured external data without doing things that relate only to Euphoria's internal peculiarities. The problem is on the way out. Unless, the external data is dealt with entirely as meta-data within Euphoria, it becomes necessary to understand what you are not supposed to know about it to get it back into an external form. Actually, not even that will suffice unless one uses poke and it's variants. Every thing else violates that fact that you aren't supposed "know" about the internal format of anything. This gets into "the Emperor's new clothes" type of discussion. Wink, wink..nod, nod..we don't really know what those internal variables look like. Except the IO routines do "sort of" without really talking about it...or really documenting it for that matter. Since there is already a huge amount of nodding and winking going on in ASCII text handling for strings, I "bought" your argument on that one. Of course, double byte text will break the "unprintable" out of that. Structured data has no such equivalent and really can't have if we really believe the words of our esteemed author. Actually, if you follow his logic, you really can't have native "Euphoria IO". If variable form is subject to change, then who could ever know what was written out and how to read it back in. Everett L.(Rett) Williams rett at gvtc.com