1. Memory
Hi all,
Just few a questions. How much memory can Euphoria use? Is there an upper
limit? I have 128 megs can I use all of it?
Thanks
Paul Martin
2. Re: Memory
- Posted by Ralf Nieuwenhuijsen <nieuwen at XS4ALL.NL>
Jan 01, 1999
-
Last edited Jan 02, 1999
>Just few a questions. How much memory can Euphoria use? Is there an upper
>limit? I have 128 megs can I use all of it?
You can use as much as you let windows use it.
As to virtual memory.. it never worked for me.
I constantly get 'Program ran out of memory' errors with a bad constructued
loop (where every cycle data is allocated)
ANd I know it never tried virtual memory, for the simple fact that I have 2
gb free.. I would notice it using 2 gb from my HD and then removing it
again..
Ralf
3. Re: Memory
Ralf writes:
> ANd I know it never tried virtual memory, for the simple fact that I
> have 2 gb free.. I would notice it using 2 gb from my HD and
> then removing it again..
Under Windows, Euphoria is limited to the size of the
Windows swap area on your disk (you can adjust this
size, but don't bother). Euphoria can't use your
entire free space on disk.
Under pure DOS, Causeway seems to
give up after using several megs
of disk space. I'm not sure what the algorithm is there.
Regards,
Rob Craig
Rapid Deployment Software
http://members.aol.com/FilesEu/
4. Re: Memory
Hello i just wanted to say that if you have any problems
allocating memory while using Euphoria you might try
using actual explicit allocation techniques. Although this
requires setting up your own data structures in memory, i have
allocated over 100 megs of memory using this technique.
If you can't allocate enough memory from Euphoria you can using
a very simple .DLL (Win95+ platforms). If you need one let me
know.
If you want to use the data structures built into Euphoria then
i can't help, sorry. If Euphoria would supply us with some info
about the storage allocation techniques used by the language
it would sure help.
Good luck...
XAXO at AOL.COM
5. Re: Memory
On Fri, 1 Jan 1999 17:13:06 -0500, Robert Craig <rds at EMAIL.MSN.COM> wrote:
>Ralf writes:
>> ANd I know it never tried virtual memory, for the simple fact that I
>> have 2 gb free.. I would notice it using 2 gb from my HD and
>> then removing it again..
>
>Under Windows, Euphoria is limited to the size of the
>Windows swap area on your disk (you can adjust this
>size, but don't bother). Euphoria can't use your
>entire free space on disk.
>
>Under pure DOS, Causeway seems to
>give up after using several megs
>of disk space. I'm not sure what the algorithm is there.
>
Rob:
Has Causeway changed? When I first got Euphoria 1.5,
I set up a sequence of 300,000,000 characters with no problem
(except for considerable delay while reading or writing
the disk, obviously).
Irv
6. Re: Memory
- Posted by Robert Craig <rds at EMAIL.MSN.COM>
Jan 02, 1999
-
Last edited Jan 03, 1999
Irv Mullins writes:
> Has Causeway changed? When I first got Euphoria 1.5,
> I set up a sequence of 300,000,000 characters with no problem
> (except for considerable delay while reading or writing
> the disk, obviously).
Euphoria 2.0 uses the same version of CauseWay as
Euphoria 1.5. It seems to me that Causeway
will often report "out of memory", before the available
swap space (under DOS or Windows) is actually used up.
Regards,
Rob Craig
Rapid Deployment Software
http://members.aol.com/FilesEu/
7. Re: Memory
>Euphoria 2.0 uses the same version of CauseWay as
>Euphoria 1.5. It seems to me that Causeway
>will often report "out of memory", before the available
>swap space (under DOS or Windows) is actually used up.
Robert, I swear to you, when I set my swapfile to a minimum of 400 mb, of
which Im sure only 87 is used by Windows, it still does *not* use my
swapfile at all.
Within in a full screen dos-box (setup as Hawke once suggested) I do a mem,
and the available memory: around 30 mb (my internal memory is 32 mb) and
that is also around the available memory I can allocate using blocks of 1
mb.
You may accidently turned off some constant or switch or something, its
simply not working under windows, I havent tried it in pure dos.
Ralf
8. Re: Memory
Hei Euphoria Programming for MS-DOS, I'm replying your e-mail!!!
> Robert, I swear to you, when I set my swapfile to a minimum of 400 mb, of
> which Im sure only 87 is used by Windows, it still does *not* use my
OUCH! What system is this? (just little bit impressed)
Hey, I wanna tell you guys about my system. I have 16 megs of RAM with
64 mb of swapfile, mostly 24 used by Windows at boot-up.
Sorry for being so rude. Don't comment on this message.
Please don't forget replying,
Hendy Irawan > http://ceefour.cybermart.net
IBM: Inertia Breeds Mediocrity
According to the National Enquirer, case tools will no longer support Windows.
Don't forget, Search Mailing Lists
http://www.liszt.com
9. Re: Memory
On Fri, 1 Jan 1999, Robert Craig wrote:
> Ralf writes:
> > ANd I know it never tried virtual memory, for the simple fact that I
> > have 2 gb free.. I would notice it using 2 gb from my HD and
> > then removing it again..
>
> Under Windows, Euphoria is limited to the size of the
> Windows swap area on your disk (you can adjust this
> size, but don't bother). Euphoria can't use your
> entire free space on disk.
>
> Under pure DOS, Causeway seems to
> give up after using several megs
> of disk space. I'm not sure what the algorithm is there.
I seem to remember you saying a while back that Euphoria uses 31-bit
integers. The missing bit being used to indicate whether the data at a
location is an address or an integer. Surely this means Euphoria can only
address 2^31 (~2Gig).
Cheeky Request: Any chance of adding 64-bit integers and double length
floats in the near future? Or auto-promotion if things get
too big?
--
Carl R White -- Final Year Computer Science at the University of Bradford
E-mail...: cyrek- at -bigfoot.com -- Remove the hyphens before mailing. Ta :)
URL......: http://www.bigfoot.com/~cyrek/
Ykk rnyllaqur rgiokc cea nyemdok ymc giququezka caysgr -- B.Q.Vgesa
10. Re: Memory
Carl R White writes:
> I seem to remember you saying a while back that Euphoria
> uses 31-bit integers. The missing bit being used to indicate
> whether the data at a location is an address or an integer.
> Surely this means Euphoria can only address 2^31 (~2Gig).
Euphoria *can* use the full 4Gig. (I don't want to go into all the
implementation details.)
> Cheeky Request: Any chance of adding 64-bit integers and double length
> floats in the near future? Or auto-promotion if things get
> too big?
An implementor of Euphoria has a lot of freedom.
He can store atoms and sequences in any memory layout
that he wants - the Euphoria programmer can't tell whether an
atom is stored in one bit, one byte, 4 bytes, a double, a 64-bit integer
etc. Since there are no pointers in Euphoria,
people can't go picking through the memory layout of a
data object. This lets implementers of Euphoria
change the layout without breaking any existing code.
Euphoria currently uses 64-bit double-precision floating-point
internally. If 128-bit were available, at the same speed, then
Euphoria might start to use it. Euphoria could also use
64-bit machine integers to store integer values.
The "integer" type in Euphoria has been defined as 31-bits,
and some rare code might break if that were changed.
We could instead add a new type for 64-bit integers. But
keep in mind that, unlike other languages, Euphoria does not *have* to
define a new type, in order to utilize a new machine storage format.
In fact, Euphoria doesn't really care what type you declare for a variable
-- Euphoria will store and manipulate data *values* in whatever
form is convenient. In Euphoria types are optional - they
are there to catch errors and provide some documentation. They
do not dictate the format of data in memory.
Regards,
Rob Craig
Rapid Deployment Software
http://members.aol.com/FilesEu/
11. Re: Memory
Date sent: Fri, 8 Jan 1999 16:18:52 -0500
Send reply to: Euphoria Programming for MS-DOS
<EUPHORIA at LISTSERV.MUOHIO.EDU>
From: Robert Craig <rds at EMAIL.MSN.COM>
Subject: Re: Memory
To: EUPHORIA at LISTSERV.MUOHIO.EDU
Robert Craig writes:
> The Euphoria programmer can't tell whether an
> atom is stored in one bit, one byte, 4 bytes, a
> double, a 64-bit integer etc.
Perhaps this is a silly question, but I just want to be certain...
Does this mean that if I fill up a sequence with say 1.000 atoms
containing only zeros and ones (each atom holding the value 0 OR
the value 1), then the sequence will take up only about 125 bytes ?
I mean, THAT would be (or perhaps it _IS_) great!
The reason why I ask is that I somehow got the impression that
each atom required a minimum of 4 bytes, which sounds like a
terrible waste...
What's right and what's wrong?
BTW, Has anyone created a neural network in euphoria yet? I'm
attempting to make one myself, but I'm a lousy programmer, I have
no experience with NN, and I'm sort of low on IQ. I still want to try,
however, because I firmly believe that even people with a 2-digit IQ
should be able to work wonders in this programming language...
And while I'm at it, can anyone tell me specifically what the term
'structure' means ? Example; is it related to code or data? Please
convert your answear to my 2-digit IQ format 
Thanks to all of you for contributing to this nice list.
Tor Bernhard Gausen
12. Re: Memory
- Posted by Irv Mullins <irv at ELLIJAY.COM>
Jan 09, 1999
-
Last edited Jan 10, 1999
On Sun, 10 Jan 1999 01:15:06 +0000, Tor Bernhard Gausen <tor.gausen at C2I.NET>
wrote:
>Robert Craig writes:
>
>> The Euphoria programmer can't tell whether an
>> atom is stored in one bit, one byte, 4 bytes, a
>> double, a 64-bit integer etc.
>
>Perhaps this is a silly question, but I just want to be certain...
>
>Does this mean that if I fill up a sequence with say 1.000 atoms
>containing only zeros and ones (each atom holding the value 0 OR
>the value 1), then the sequence will take up only about 125 bytes ?
>I mean, THAT would be (or perhaps it _IS_) great!
>
>The reason why I ask is that I somehow got the impression that
>each atom required a minimum of 4 bytes, which sounds like a
>terrible waste...
>
>What's right and what's wrong?
I think he means the _programmer_ doesn't need to know.
The person who writes Euphoria does - and can change that
in the future as long as no one depends on it being any
certain fixed size.
>
<snip>
>
>And while I'm at it, can anyone tell me specifically what the term
>'structure' means ? Example; is it related to code or data? Please
>convert your answear to my 2-digit IQ format
Both. A structure is a way to "package" variables so they can be
handled more conveniently.
Example in unEuphoria code:
structure customer
sequence name, addr, city, state, zip, phone
integer age
end structure
You could make assignments as follows:
customer.name = "John Smith"
customer.phone = "555-1212"
customer.age = 23
and write to disk as puts(fn, customer)
or assign the whole thing in one swell foop: thiscustomer = customer
which does the same as:
thiscustomer.name = customer.name
thiscustomer.addr = customer.addr
thiscustomer.city = customer.city...and so on.
There's also the term "structured code" which is another thing
altogether.
Irv
13. Re: Memory
Tor Bernhard Gausen writes:
> Does this mean that if I fill up a sequence with say 1.000 atoms
> containing only zeros and ones (each atom holding the value 0 OR
> the value 1), then the sequence will take up only about 125 bytes ?
> I mean, THAT would be (or perhaps it _IS_) great!
It would be possible for an implementor of Euphoria to do that,
but the current implementation of Euphoria will use 4 bytes per
element for an array of 1's and 0's. More sizes could be supported
but there would be drawbacks. It would make the
interpreter bigger, more complicated, and in some cases
slower. I wouldn't rule out having a 1 byte per element format
for sequences of small integers, but so far I haven't been
able to convince myself that it's worth the trouble.
Changes like this can be made to the implementation of Euphoria
without breaking any code. If Microsoft decided in the next release
of their C++ compiler that the "int" type would now use 2 bytes,
or 8 bytes, or whatever, they would cause *massive*
breakage.
Regards,
Rob Craig
Rapid Deployment Software
http://members.aol.com/FilesEu/
14. Re: Memory
Rob... What about creating a "PACKED SEQUENCE" option in Euphoria similar to
the "PACKED ARRAY" or "PACKED RECORD" used in old Pascal compilers? This
would create complexities (processing delays) but only at the request of the
coder. You might also need an UNPACK() function depending on how you
implement it.
-----Original Message-----
From: Rob Craig <rds at EMAIL.MSN.COM>
To: EUPHORIA at LISTSERV.MUOHIO.EDU <EUPHORIA at LISTSERV.MUOHIO.EDU>
Date: Sunday, January 10, 1999 11:09 AM
Subject: Re: Memory
>Tor Bernhard Gausen writes:
>
>> Does this mean that if I fill up a sequence with say 1.000 atoms
>> containing only zeros and ones (each atom holding the value 0 OR
>> the value 1), then the sequence will take up only about 125 bytes ?
>> I mean, THAT would be (or perhaps it _IS_) great!
>
>It would be possible for an implementor of Euphoria to do that,
>but the current implementation of Euphoria will use 4 bytes per
>element for an array of 1's and 0's. More sizes could be supported
>but there would be drawbacks. It would make the
>interpreter bigger, more complicated, and in some cases
>slower. I wouldn't rule out having a 1 byte per element format
>for sequences of small integers, but so far I haven't been
>able to convince myself that it's worth the trouble.
>
>Changes like this can be made to the implementation of Euphoria
>without breaking any code. If Microsoft decided in the next release
>of their C++ compiler that the "int" type would now use 2 bytes,
>or 8 bytes, or whatever, they would cause *massive*
>breakage.
>
>Regards,
> Rob Craig
> Rapid Deployment Software
> http://members.aol.com/FilesEu/
15. Re: Memory
- Posted by Robert Craig <rds at EMAIL.MSN.COM>
Jan 10, 1999
-
Last edited Jan 11, 1999
Quality writes:
> Rob... What about creating a "PACKED SEQUENCE" option in
> Euphoria similar to the "PACKED ARRAY" or "PACKED RECORD"
> used in old Pascal compilers? This would create complexities
> (processing delays) but only at the request of the coder. You might
> also need an UNPACK() function depending on how you
> implement it.
Thanks for the suggestions.
I've kicked around the idea of providing some sort of
compression/decompression, either automatic or manual.
I haven't found anything really compelling yet.
Regards,
Rob Craig
Rapid Deployment Software
http://members.aol.com/FilesEu/
16. Re: Memory
On Fri, 1 Jan 1999 17:13:06 -0500, Robert Craig <rds at EMAIL.MSN.COM> wrote:
>Ralf writes:
>> ANd I know it never tried virtual memory, for the simple fact that I
>> have 2 gb free.. I would notice it using 2 gb from my HD and
>> then removing it again..
>
>Under Windows, Euphoria is limited to the size of the
>Windows swap area on your disk (you can adjust this
>size, but don't bother). Euphoria can't use your
>entire free space on disk.
>
>Under pure DOS, Causeway seems to
>give up after using several megs
>of disk space. I'm not sure what the algorithm is there.
I never run out of memory in pure ms-dos mode, but in windows 95,
it happends. Is it because windows 95 let your swapfile grow and shrink?
Under windows 3.11 this never happends. How is this possible?
Regards
Bert Belder <bbelder at hotmail.com>
17. Re: Memory
Bert Belder writes:
> I never run out of memory in pure ms-dos mode, but in
> windows 95, it happends. Is it because windows 95 let
> your swapfile grow and shrink? Under windows 3.11 this
> never happends. How is this possible?
I'm really not sure how the various flavors of Windows manage
virtual memory and swap files. In general I don't think it's a good idea
to depend on swap space too much. Things tend to slow down
a lot, and you never know when you might run out of memory.
A better solution might be to use your own data files, and
only load a reasonable amount of data into memory at one time.
Regards,
Rob Craig
Rapid Deployment Software
http://members.aol.com/FilesEu/
18. Memory
- Posted by Eduardo Uemura Okada <cool at ART.COM.BR>
Aug 05, 1997
-
Last edited Aug 06, 1997
Hi, anyone can send me a list of memory adresses ?
More expecific, I want the starting and ending adresses of video display
memory, used to poke and peek in graphics mode 19.
I'll be already thankful if you can send another list of adresses of
something else.
Eduardo Uemura Okada
e-mail: cool at art.com.br
19. Re: Memory
- Posted by Daniel Berstein <danielberstein at USA.NET>
Aug 05, 1997
-
Last edited Aug 06, 1997
> Hi, anyone can send me a list of memory adresses ?
> More expecific, I want the starting and ending adresses of video display
> memory, used to poke and peek in graphics mode 19.
Eduardo, video memory starts at offset #A000 (in hexadecimal), for
text modes it'a at #B800. You'll have some problems poking directly
to videomem, mostly related with VGA and SVGA modes... you just can't
access all the video mem at once, you must swith banks and do some
other weirds stuff that's better Michael Packard (or Jiri, or
Jacques, or Ralf) explain.
Regards,
Daniel Berstein
danielberstein at usa.net
http://www.geocities.com/SiliconValley/Heights/9316
20. Re: Memory
Daniel Berstein wrote:
>
> > Hi, anyone can send me a list of memory adresses ?
> > More expecific, I want the starting and ending adresses of video display
> > memory, used to poke and peek in graphics mode 19.
>
> Eduardo, video memory starts at offset #A000 (in hexadecimal), for
> text modes it'a at #B800. You'll have some problems poking directly
> to videomem, mostly related with VGA and SVGA modes... you just can't
> access all the video mem at once, you must swith banks and do some
> other weirds stuff that's better Michael Packard (or Jiri, or
> Jacques, or Ralf) explain.
Careful!!! Euphoria is running in protected mode so offsets must be
32-bit. The video memory for graphics modes is at #A0000, text modes
#B8000. Converting 16-bit segments and offsets to 32-bit ones must be
done by multiplying the segment by 16 then adding the offset.
Mode 19 is the easiest for writing to the screen using pokes. Other
modes require bank-switching as Daniel said and others (16-color) are
set up in bit planes so writes require changing video registers.
Has anyone else noticed that in SVGA modes, graphics operations below a
certain point on the screen are much slower that closer to the top? I'm
guessing that this is from the bank-switching going on. If the software
could detect if each operation would take place in the same bank as was
used last, it could save the time spent calling the bank-switch routine.
--
_____ _____ _____
________ /\ \ /\ \ /\ \
/ \ \ / \____\ / \____\ / \____\
/ _ \____\ / / ___/_ / /____/ / / ___/_
/ / \ |____|/ / /\____\ / \ \ / / /\____\
\ \_/ / / \ \/ / ___/_\ \ \ \ \/ / ___/_
\ /____/ \ / /\ \\/\ \ \ \ / /\ \
\ \ \ \ \/ \____\ \ \ \ \ \/ \____\
\ \ \ \ / / \ \____\ \ / /
\ \____\ \ / / \ / / \ / /
\ / / \ / / \/____/ \ / /
\/____/ \/____/ \/____/
21. Memory
Could someone tell me if there is a way to set aside memory in one
Euphoria program, use it for certain perposes, quit the program and
return to Dos. Then load another Euphoria program and be able to use hte
exact same memory area without the fear of the contents being overwrote
be another prevously run program?
I am working on a password program that ask for id when the computer
is started, then saves the necessary info to memory in incoded form. I
have done this in basic and it seems to work well, but often the
information is written over.
Any help would be greatly appreciated.
22. Re: Memory
> Could someone tell me if there is a way to set aside memory in one
> Euphoria program, use it for certain perposes, quit the program and
> return to Dos. Then load another Euphoria program and be able to use hte
> exact same memory area without the fear of the contents being overwrote
> be another prevously run program?
> I am working on a password program that ask for id when the computer
> is started, then saves the necessary info to memory in incoded form. I
> have done this in basic and it seems to work well, but often the
> information is written over.
why don't you just save the encripted form of the password to a
binary file and then retrieve it later... pour exemple:
-- this is the .ex file that saves the password
integer fn
sequence password
password = encrypt("blah") -- supposing you have a function called
-- 'encrypt' that encrypts it
fn = open("password.dat","wb")
for i = 1 to length(password) -- there's probably an easier way
-- to do this
puts(fn,password[i])
end for
close(fn)
-- this is the .ex file that reads the password
integer fn
object tempi,tempj
sequence password
tempj = {}
fn = open("password.dat","rb")
while tempi != -1 do -- think -1 is the code for eof... not
-- sure, tho
tempi = getc(fn)
tempj = tempj & fn
end while
close(fn)
password = decrypt(tempj) -- supposing you have a function called
-- decrypt
23. Re: Memory
> Could someone tell me if there is a way to set aside memory in one
>Euphoria program, use it for certain perposes, quit the program and
>return to Dos. Then load another Euphoria program and be able to use hte
>exact same memory area without the fear of the contents being overwrote
>be another prevously run program?
I previously experimented with memory passing between two Euphoria programs
during the design of "A Beginner's Guide To Euphoria", with little success.
You could find an area not used by the program through experimentation, but
you risk annoying the hell out of EMM386 if you do.
I suggest two approaches that I currently use now:
1) Write the password data to a temp file, use the system() command to
attrib +h it so it is invisible, exit program, run the second program
to receive the data by reading the temp file, and then have the second
program IMMEDIATELY erase the temp file. A variation of this is to make a
RAM disk and write the data there in the RAM disk.
2) Store the data in an environment variable, exit program, run the
second program to receive the data by reading the environment variable and
then have the second program set the environment variable to blanks. This is
a more preferable way because if you forget to reset the variable, it gets
done so on the next reboot and does not risk leaving confidential data on
your hard drive in the form of a forgotten temp file.
Hope this helps
David Gay
http://www.interlog.com/~moggie/euphoria.htm
24. Re: Memory
Hi Sam,
There are 16 bytes reserved in the BIOS data area at address #4F0 to #4FF. This
is for "Inter Application Communication" but I don't think any one uses it, you
might store your password data there.
Regards - Peter
25. Re: Memory
- Posted by Jacques Deschenes <desja at QUEBECTEL.COM>
Jan 05, 1997
-
Last edited Jan 06, 1997
>
>Hi Sam,
>
>There are 16 bytes reserved in the BIOS data area at address #4F0 to #4FF. This
>is for "Inter Application Communication" but I don't think any one uses
it, you
>might store your password data there.
>
>Regards - Peter
>
I tested it. It works if it's done in pure dos environment.
But under windows 95, it work only if the 2 dos programs are run in the same dos
virtual machine. That mean if you launch the first program from windows and
come back
to windows closing this dos box. then the second program is launch. It wouldn't
find the password. The reason is that windows create a virtual dos machine
different
for each dos session (for both program it seem to be the same address, but
in fact
it is not.)
Someone mention the idea of writing to the environment. If so you have to
write
to the parent process environment. As each program has its own copy of the
environment which is destroyed when then program end. To preserve the
information you have to write to master environment. Under windows the same
limitations as above apply.
Jacques Deschenes
Baie-Comeau, Quebec
Canada
desja at quebectel.com
26. Re: Memory
- Posted by "Sam L. Garrett" <samlgarrett at JUNO.COM>
Jan 06, 1997
-
Last edited Jan 07, 1997
> I tested it. It works if it's done in pure dos environment.
>But under windows 95, it work only if the 2 dos programs are run in
>the same dos
>virtual machine.
Thanks for the warning. I doubt that I will ever run it under
Windows 95 though, my computer is only 25Mhz and I am currently using a
monochrome screen to compute with.
> Someone mention the idea of writing to the environment. If so you
>have to
>write
>to the parent process environment. As each program has its own copy
>of the
>environment which is destroyed when then program end. To preserve the
>information you have to write to master environment. Under windows
>the same
>limitations as above apply.
Hmmm... You lost me there, I don't recall reading about 'parent' and
'master' environments. I run back over the manual and reread that
section. I'm sure that would have givin me a lot trougble you hadn't
brought up that point, thanks!
Thanks to all else who have written me a reply as well!!
Later!
