1. Profiling Under Windows & String Size
Hi,
1) What was the reason time profiling was not implemented in Euphoria for
Windows? Is it because the timer could not be re-programmed as it could
under DOS? If so, why couldn't timeGetTime() or QueryPerformanceCounter()
be used?
2) In the documentation it states a "string" is simply a sequence of
numbers. Does this mean each character takes 4-bytes of memory, or does
Euphoria store them in single bytes until it has some compelling reason to
do otherwise?
Thanks in advance,
David Guy
2. Re: Profiling Under Windows & String Size
- Posted by Robert Craig <rds at ATTCANADA.NET>
Aug 04, 1999
-
Last edited Aug 05, 1999
David Guy writes:
> 1) What was the reason time profiling was not
> implemented in Euphoria for Windows? Is it
> because the timer could not be re-programmed as it
> could under DOS? If so, why couldn't timeGetTime() or
> QueryPerformanceCounter() be used?
In DOS, for profile_time, Euphoria takes control of
the clock interrupt. Every 1/100 (or whatever) of a second,
a routine in the interpreter gets control. It records the address
in your Euphoria program where you are currently executing.
At the end of execution, these machine addresses are
analysed, and related back to statement numbers in
your program. I have not figured out how to get regular
interrupts of this granularity under Windows. There is
probably a way to do it. If anyone knows how to do it please
let me know. The routines that you mention don't do what
I want.
> 2) In the documentation it states a "string" is simply a
> sequence of numbers. Does this mean each character
> takes 4-bytes of memory, or does Euphoria store them in
> single bytes until it has some compelling reason to do
> otherwise?
They take 4 bytes. This has been discussed before.
It would be nice if they could only take one byte, and
I've spent a good deal of time looking for a convenient
way to do this. Unfortunately, any 1-byte scheme
seems to have the following disadvantages:
* It makes the interpreter bigger, thereby wasting
some of the space you are trying to save.
* It makes the interpreter a few percent slower.
* It makes the interpreter more susceptible to bugs.
* It makes the interpreter harder to maintain
Regards,
Rob Craig
Rapid Deployment Software
http://members.aol.com/FilesEu/
3. Re: Profiling Under Windows & String Size
----- Original Message -----
From: Robert Craig <rds at ATTCANADA.NET>
To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Sent: Wednesday, August 04, 1999 7:11 PM
Subject: Re: Profiling Under Windows & String Size
<snip>
> > 2) In the documentation it states a "string" is simply a
> > sequence of numbers. Does this mean each character
> > takes 4-bytes of memory, or does Euphoria store them in
> > single bytes until it has some compelling reason to do
> > otherwise?
>
> They take 4 bytes. This has been discussed before.
> It would be nice if they could only take one byte, and
If they took one byte, they could not be upgraded to the upcoming 16bit
characters, which will do something the current ascii 8bit byte has no
allocations for: store all the Arabian, Japanese, Scandinavian, etc
characters. Maybe someday the extra 16bits of the Euphoria character word
can be used to store display info for that char such as font, underline,
bold, colors, etc. I would have taken Euphoria to task for this apparent
memory waste, if it weren't for the other benefits of the language, like
transparent memory management, including virtual memory paging to the hd,,,,
with a one gig hd, i won't worry about bytes wasted in string storage.
<pester mode on> I'd still like a private "goto" command tho...
Kat
4. Re: Profiling Under Windows & String Size
- Posted by "Lucius L. Hilley III" <lhilley at CDC.NET>
Aug 04, 1999
-
Last edited Aug 05, 1999
1st your 1 gig HD is puny by todays standards.
2nd it isn't th HD space we are trying to conserve.
It is the precious 32Meg DOS Memory limit imposed on DOS.
Granted the interpreter is relative large at 720 KB but, that
doesn't dent the 32,768 KB available and the Megs of RAM that
can be conserved if a better byte storage scheme existed.
Assume that this new byte scheme BLOATS Euphoria into the
800 KB realm. So now as Rob says, You are WASTING 80 KB more
than you where before. Assume you have written a program that
under the old scheme abused 16,000 KB of memory. But, using
the new byte scheme you could store the same amount of data
using only 4,000 KB. This frees up 12,000 KB of memory.
When you are freeing up 12,000 KB who cares about the 80 KB
wasted?
Now that I am off my high horse. Lets get back to our happy,
memory wasteful, Euphoria coding. 8^)
Lucius L. Hilley III
lhilley at cdc.net lucius at ComputerCafeUSA.com
+----------+--------------+--------------+----------+
| Hollow | ICQ: 9638898 | AIM: LLHIII | Computer |
| Horse +--------------+--------------+ Cafe' |
| Software | http://www.cdc.net/~lhilley | USA |
+----------+-------+---------------------+----------+
| http://www.ComputerCafeUSA.com |
+--------------------------------+
> ---------------------- Information from the mail
header -----------------------
> Sender: Euphoria Programming for MS-DOS
<EUPHORIA at LISTSERV.MUOHIO.EDU>
> Poster: Kat <KSMiTH at PELL.NET>
> Subject: Re: Profiling Under Windows & String Size
> --------------------------------------------------------------------------
-----
>
> ----- Original Message -----
> From: Robert Craig <rds at ATTCANADA.NET>
> To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
> Sent: Wednesday, August 04, 1999 7:11 PM
> Subject: Re: Profiling Under Windows & String Size
>
> <snip>
>
> > > 2) In the documentation it states a "string" is simply a
> > > sequence of numbers. Does this mean each character
> > > takes 4-bytes of memory, or does Euphoria store them in
> > > single bytes until it has some compelling reason to do
> > > otherwise?
> >
> > They take 4 bytes. This has been discussed before.
> > It would be nice if they could only take one byte, and
>
> If they took one byte, they could not be upgraded to the upcoming 16bit
> characters, which will do something the current ascii 8bit byte has no
> allocations for: store all the Arabian, Japanese, Scandinavian, etc
> characters. Maybe someday the extra 16bits of the Euphoria character word
> can be used to store display info for that char such as font, underline,
> bold, colors, etc. I would have taken Euphoria to task for this apparent
> memory waste, if it weren't for the other benefits of the language, like
> transparent memory management, including virtual memory paging to the
hd,,,,
> with a one gig hd, i won't worry about bytes wasted in string storage.
> <pester mode on> I'd still like a private "goto" command tho...
>
> Kat
>
5. Re: Profiling Under Windows & String Size
- Posted by Kat <KSMiTH at PELL.NET>
Aug 04, 1999
-
Last edited Aug 05, 1999
----- Original Message -----
From: Lucius L. Hilley III <lhilley at CDC.NET>
To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Sent: Wednesday, August 04, 1999 8:19 PM
Subject: Re: Profiling Under Windows & String Size
> 1st your 1 gig HD is puny by todays standards.
I picked the size at random, anyone's hd size wasn't the point of my email,
it's irrelevant, would you have been more biting if i had said i know
someone running linux on a 286 and a 20 meg hd?
> 2nd it isn't th HD space we are trying to conserve.
I know that, but Eu will virtualize all the memory you need on the hd, or am
i mistaken?
> Assume that this new byte scheme BLOATS Euphoria into the
> 800 KB realm. So now as Rob says, You are WASTING 80 KB more
> than you where before. Assume you have written a program that
> under the old scheme abused 16,000 KB of memory. But, using
> the new byte scheme you could store the same amount of data
> using only 4,000 KB. This frees up 12,000 KB of memory.
> When you are freeing up 12,000 KB who cares about the 80 KB
> wasted?
While you try to lock Euphoria into 8 bits per character, i'd like to refer
everyone else to http://www.unicode.org/ , where the standard is 16 bits,
for the reasons i gave earlier.
Kat.
6. Re: Profiling Under Windows & String Size
Kat wrote:
<snip>
>> Assume that this new byte scheme BLOATS Euphoria into the
>> 800 KB realm. So now as Rob says, You are WASTING 80 KB more
>> than you where before. Assume you have written a program that
>> under the old scheme abused 16,000 KB of memory. But, using
>> the new byte scheme you could store the same amount of data
>> using only 4,000 KB. This frees up 12,000 KB of memory.
>> When you are freeing up 12,000 KB who cares about the 80 KB
>> wasted?
>
>While you try to lock Euphoria into 8 bits per character, i'd like to refer
>everyone else to http://www.unicode.org/ , where the standard is 16 bits,
>for the reasons i gave earlier.
Hmmm... while the advantages of Rob's current scheme are very valid,
I think I'd like to state here that I'm not sure he would be better off
putting stock in the Unicode "standard".
According to other postings on this list, Unicode is tragically
insufficient for its most notable goal: handling global character sets.
Norm's Chinese characters alone (for his Eu project) number--what, around
45,000? And then Japanese takes the same number... already the 65,536
characters of Unicode are blown away, by only two languages. Apparently,
Unicode simply CANNOT do what it is trying to, at least not without severe
compromise. That being the case, why try to make use of it? If anything, a
3-byte scheme (or 4-byte) would make more sense (Super Unicode?), but then
those of us with languages that do just fine under ASCII might start to
balk. 
Rod
7. Re: Profiling Under Windows & String Size
The Unicode UTF-8 and UTF-16 encoding uses variable length characters
sizes. All the Roman characters and most of the special ASCII characters
take a single byte but other language character sets can have 2 to 6 bytes
per character. This comfortably takes care of the various Chinese,
Japanese, Korean, Etc... character sets. And for English text it is space
efficient. UTF-8 is supported by Windows and IE5 and XML and most
database systems (Oracle, Progress, Informix, etc)
To quote from the Unicode FAQ
"Q: What is UTF-16?
Unicode was originally designed as a pure 16-bit encoding, aimed at
representing all modern scripts. (Ancient scripts were to be represented
with private-use characters.) Over time, and especially after the addition
of over 14,500 composite characters for compatibility with legacy sets, it
became clear that 16-bits were not sufficient for the user community. Out
of this arose UTF-16.
UTF-16 allows access to 63K characters as single Unicode 16-bit units. It
can access an additional 1M characters by a mechanism known as surrogate
pairs.
"
see http://www.unicode.org for more details.
cheers,
Derek Parnell
dparnell at bigpond.net.au
Melbourne, Australia
-----Original Message-----
From: Roderick Jackson <rjackson at CSIWEB.COM>
To: EUPHORIA at LISTSERV.MUOHIO.EDU <EUPHORIA at LISTSERV.MUOHIO.EDU>
Date: Thursday, August 5 1999 23:41
Subject: Re: Profiling Under Windows & String Size
Kat wrote:
<snip>
>> Assume that this new byte scheme BLOATS Euphoria into the
>> 800 KB realm. So now as Rob says, You are WASTING 80 KB more
>> than you where before. Assume you have written a program that
>> under the old scheme abused 16,000 KB of memory. But, using
>> the new byte scheme you could store the same amount of data
>> using only 4,000 KB. This frees up 12,000 KB of memory.
>> When you are freeing up 12,000 KB who cares about the 80 KB
>> wasted?
>
>While you try to lock Euphoria into 8 bits per character, i'd like to
refer
>everyone else to http://www.unicode.org/ , where the standard is 16 bits,
>for the reasons i gave earlier.
Hmmm... while the advantages of Rob's current scheme are very valid,
I think I'd like to state here that I'm not sure he would be better off
putting stock in the Unicode "standard".
According to other postings on this list, Unicode is tragically
insufficient for its most notable goal: handling global character sets.
Norm's Chinese characters alone (for his Eu project) number--what, around
45,000? And then Japanese takes the same number... already the 65,536
characters of Unicode are blown away, by only two languages. Apparently,
Unicode simply CANNOT do what it is trying to, at least not without severe
compromise. That being the case, why try to make use of it? If anything, a
3-byte scheme (or 4-byte) would make more sense (Super Unicode?), but then
those of us with languages that do just fine under ASCII might start to
balk.
Rod
8. Re: Profiling Under Windows & String Size
----- Original Message -----
From: Roderick Jackson <rjackson at CSIWEB.COM>
To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Sent: Thursday, August 05, 1999 8:38 AM
Subject: Re: Profiling Under Windows & String Size
<snip>
> According to other postings on this list, Unicode is tragically
> insufficient for its most notable goal: handling global character sets.
> Norm's Chinese characters alone (for his Eu project) number--what, around
> 45,000? And then Japanese takes the same number... already the 65,536
> characters of Unicode are blown away, by only two languages. Apparently,
> Unicode simply CANNOT do what it is trying to, at least not without severe
> compromise. That being the case, why try to make use of it? If anything, a
> 3-byte scheme (or 4-byte) would make more sense (Super Unicode?), but then
> those of us with languages that do just fine under ASCII might start to
> balk.
And so.. Eu uses 4 bytes per char, and reducing to one byte per char doesn't
make a lot of sense if you want Eu used outside the usa in the future.
Anyways, it's just my opinion. Maybe the rest of the world will convert to
english.
Kat
9. Re: Profiling Under Windows & String Size
Kat wrote:
><snip>
>
>> According to other postings on this list, Unicode is tragically
>> insufficient for its most notable goal: handling global character sets.
>> Norm's Chinese characters alone (for his Eu project) number--what, around
>> 45,000? And then Japanese takes the same number... already the 65,536
>> characters of Unicode are blown away, by only two languages. Apparently,
>> Unicode simply CANNOT do what it is trying to, at least not without severe
>> compromise. That being the case, why try to make use of it? If anything, a
>> 3-byte scheme (or 4-byte) would make more sense (Super Unicode?), but then
>> those of us with languages that do just fine under ASCII might start to
>> balk.
>
>And so.. Eu uses 4 bytes per char, and reducing to one byte per char doesn't
>make a lot of sense if you want Eu used outside the usa in the future.
>Anyways, it's just my opinion. Maybe the rest of the world will convert to
>english.
!!!
Well, if you choose to look at it that way, I guess Euphoria is *already*
Unicode-compatible. All it needs are routines to output to screen (file,
etc.) using character sets besides ASCII--hence, Norm's work...
But just to clarify, I don't think the request was for turning ALL
sequences into lists of one-byte characters. Consider: if we're using
literals like
"Hello, you've encounter a Killer App error"
in our code, then I can understand the desire to reduce memory usage
by 75% (and increase I/O speed) by having them compacted, C-style. I'm
not sure it's a good idea, but considering you could still construct
your own sequences of 4-byte integers, it shouldn't affect Eu's ability
to handle routines based on any Unicode-derived setup.
Rod
10. Re: Profiling Under Windows & String Size
Thank you Rod,
This was exactly what I was pruposing.
Lucius L. Hilley III
lhilley at cdc.net lucius at ComputerCafeUSA.com
+----------+--------------+--------------+----------+
| Hollow | ICQ: 9638898 | AIM: LLHIII | Computer |
| Horse +--------------+--------------+ Cafe' |
| Software | http://www.cdc.net/~lhilley | USA |
+----------+-------+---------------------+----------+
| http://www.ComputerCafeUSA.com |
+--------------------------------+
----- Original Message -----
From: Roderick Jackson <rjackson at CSIWEB.COM>
To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Sent: Thursday, August 05, 1999 2:39 PM
Subject: Re: Profiling Under Windows & String Size
> ---------------------- Information from the mail
header -----------------------
> Sender: Euphoria Programming for MS-DOS
<EUPHORIA at LISTSERV.MUOHIO.EDU>
> Poster: Roderick Jackson <rjackson at CSIWEB.COM>
> Subject: Re: Profiling Under Windows & String Size
> --------------------------------------------------------------------------
-----
>
> Kat wrote:
> ><snip>
> >
> >> According to other postings on this list, Unicode is tragically
> >> insufficient for its most notable goal: handling global character sets.
> >> Norm's Chinese characters alone (for his Eu project) number--what,
around
> >> 45,000? And then Japanese takes the same number... already the 65,536
> >> characters of Unicode are blown away, by only two languages.
Apparently,
> >> Unicode simply CANNOT do what it is trying to, at least not without
severe
> >> compromise. That being the case, why try to make use of it? If
anything, a
> >> 3-byte scheme (or 4-byte) would make more sense (Super Unicode?), but
then
> >> those of us with languages that do just fine under ASCII might start to
> >> balk.
> >
> >And so.. Eu uses 4 bytes per char, and reducing to one byte per char
doesn't
> >make a lot of sense if you want Eu used outside the usa in the future.
> >Anyways, it's just my opinion. Maybe the rest of the world will convert
to
> >english.
>
> !!!
>
> Well, if you choose to look at it that way, I guess Euphoria is *already*
> Unicode-compatible. All it needs are routines to output to screen (file,
> etc.) using character sets besides ASCII--hence, Norm's work...
>
> But just to clarify, I don't think the request was for turning ALL
> sequences into lists of one-byte characters. Consider: if we're using
> literals like
>
> "Hello, you've encounter a Killer App error"
>
> in our code, then I can understand the desire to reduce memory usage
> by 75% (and increase I/O speed) by having them compacted, C-style. I'm
> not sure it's a good idea, but considering you could still construct
> your own sequences of 4-byte integers, it shouldn't affect Eu's ability
> to handle routines based on any Unicode-derived setup.
>
>
> Rod
>
11. Re: Profiling Under Windows & String Size
Kat wrote:
>
> ----- Original Message -----
> From: Robert Craig <rds at ATTCANADA.NET>
> To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
> Sent: Wednesday, August 04, 1999 7:11 PM
> Subject: Re: Profiling Under Windows & String Size
>
> <snip>
> If they took one byte, they could not be upgraded to the upcoming 16bit
> characters, which will do something the current ascii 8bit byte has no
> allocations for: store all the Arabian, Japanese, Scandinavian, etc
> characters. Maybe someday the extra 16bits of the Euphoria character word
> <snip>
> Kat
-----------------------------
I can hardly wait until I can fill memory (and HD) with Arabian,
Japanese,
Scandinavian, and more!
By the way, did you say why I would want to do that?
Jack
12. Re: Profiling Under Windows & String Size
> I can hardly wait until I can fill memory (and HD) with Arabian,
> Japanese,
> Scandinavian, and more!
>
> By the way, did you say why I would want to do that?
>
> Jack
And Scandinavian takes up so much memory too!
Let's see, a and o umlaut, plus the norwegian counterparts, and the swedish o.
That's a whopping 5 characters, plus Icelandic if you want it of course, which
adds about 5 or so more.
Oh my god, that's 10 characters. That'll fill up your RAM or HD.
And I admit that Japanese, Chinese and Arabic are a different case altogether,
but they won't fill up your memory either. Arabic is about 200kb depending on the
dialect, and Japanese and Chinese are ~1mb. If you don't intend to read any of
these languages you don't need to, of course. But there are the people who happen
to need dots above their letters, and some who need the radical for huo4 and so
forth.
If you need it, you use it. Simple.
Sorry about the sarcasm, just happen to be in a very irate mood for a change.
----
Get your free email at http://www.gnwmail.com
13. Re: Profiling Under Windows & String Size
- Posted by "Lucius L. Hilley III" <lhilley at CDC.NET>
Aug 06, 1999
-
Last edited Aug 07, 1999
We need to put that male/female symbol thing that the
Artist formerly known as Prince uses for his name into the
Unicode character set. We can't leave his name out. :)
What this really comes to is this.
Do we want the memory managing control that C programmers
have to deal with? Obviously, we don't want the pointers.
Yes they have their advantages but they also have large
drawbacks. If we want pointers we can just allocate chunks
of memory and manage it ourselves. Do we want Multiple
different memory types?
char = 8-bit
int = 16-bit
short int = 16-bit
long int = 32-bit
float = 32-bit
double = 64-bit
long double = 80-bit
signed char = 8-bit
signed int = 16-bit
signed short int = 16-bit
signed long int = 32-bit
And then for strings you have to use arrays. Apparently
you can use any of the above types for the arrays.
I do understand that we are really only asking for
the special memory conserving byte-string data type. But
what we really want is a more conservative data system?
Wouldn't it be nice if our integer valued atoms where
stored as 16-bit integers? Oops, Euphoria already does
that. Okay, maybe we would like Even smaller numbers
that would fit within 8-bit range to be stored that way.
And also euphoria to be smart enough to a set of 8-bit
values as an 8-bit arrayn until those values moved out
of the 8-bit range and then Dynamically be changed.
That's it. We want our objects to be even more dynamic
than they already are.
Lucius L. Hilley III
lhilley at cdc.net lucius at ComputerCafeUSA.com
+----------+--------------+--------------+----------+
| Hollow | ICQ: 9638898 | AIM: LLHIII | Computer |
| Horse +--------------+--------------+ Cafe' |
| Software | http://www.cdc.net/~lhilley | USA |
+----------+-------+---------------------+----------+
| http://www.ComputerCafeUSA.com |
+--------------------------------+
----- Original Message -----
From: Tom Eklöf <eu-list at GNWMAIL.COM>
To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Sent: Friday, August 06, 1999 4:30 PM
Subject: Re: Profiling Under Windows & String Size
> ---------------------- Information from the mail
header -----------------------
> Sender: Euphoria Programming for MS-DOS
<EUPHORIA at LISTSERV.MUOHIO.EDU>
> Poster: Tom Eklöf <eu-list at GNWMAIL.COM>
> Subject: Re: Profiling Under Windows & String Size
> --------------------------------------------------------------------------
-----
>
> > I can hardly wait until I can fill memory (and HD) with Arabian,
> > Japanese,
> > Scandinavian, and more!
> >
> > By the way, did you say why I would want to do that?
> >
> > Jack
>
> And Scandinavian takes up so much memory too!
> Let's see, a and o umlaut, plus the norwegian counterparts, and the
swedish o. That's a whopping 5 characters, plus Icelandic if you want it of
course, which adds about 5 or so more.
>
> Oh my god, that's 10 characters. That'll fill up your RAM or HD.
>
> And I admit that Japanese, Chinese and Arabic are a different case
altogether, but they won't fill up your memory either. Arabic is about 200kb
depending on the dialect, and Japanese and Chinese are ~1mb. If you don't
intend to read any of these languages you don't need to, of course. But
there are the people who happen to need dots above their letters, and some
who need the radical for huo4 and so forth.
>
> If you need it, you use it. Simple.
>
> Sorry about the sarcasm, just happen to be in a very irate mood for a
change.
>
>
> ----
> Get your free email at http://www.gnwmail.com
>
14. Re: Profiling Under Windows & String Size
- Posted by Kat <KSMiTH at PELL.NET>
Aug 06, 1999
-
Last edited Aug 07, 1999
----- Original Message -----
From: Lucius L. Hilley III <lhilley at CDC.NET>
To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Sent: Friday, August 06, 1999 7:08 PM
Subject: Re: Profiling Under Windows & String Size
> We need to put that male/female symbol thing that the
> Artist formerly known as Prince uses for his name into the
> Unicode character set. We can't leave his name out. :)
>
> What this really comes to is this.
> Do we want the memory managing control that C programmers
> have to deal with? Obviously, we don't want the pointers.
> Yes they have their advantages but they also have large
> drawbacks. If we want pointers we can just allocate chunks
> of memory and manage it ourselves. Do we want Multiple
> different memory types?
I stopped coding a big project in Pascal, and didn't move to Delphi, to
avoid all that. I wanted to write and run a *program* , not a memory
management unit. And i wanted fully dynamic arrays,, oops, sequences,
sorta... actually, i did make those, but there was still a large wish list
with pascal. <whine mode on > And i'd still like to have a Eu function like:
"DDE TargetName DataFieldType Where/Data". Or "Socket TargetName Write/Read
Data/Where".
> That's it. We want our objects to be even more dynamic
> than they already are.
Has anyone tried to use those "extra" 3 bytes for anything? Will Eu keep
them as you set them, or change them in some way? I suspect a gui would make
good use of them, for formating the character. What happens to those 3 bytes
if they get swapped the the hd and back into ram?
Kat
15. Re: Profiling Under Windows & String Size
- Posted by Roderick Jackson <rjackson at CSIWEB.COM>
Aug 08, 1999
-
Last edited Aug 09, 1999
Kat wrote:
>> That's it. We want our objects to be even more dynamic
>> than they already are.
>
>Has anyone tried to use those "extra" 3 bytes for anything? Will Eu keep
>them as you set them, or change them in some way? I suspect a gui would make
>good use of them, for formating the character. What happens to those 3 bytes
>if they get swapped the the hd and back into ram?
When you create a "string" in Euphoria, such as
"HELLO"
it is *literally* nothing more than a sequence, in this case the same as
{72, 69, 76, 76, 79}
When written out to disk with print(), which is for writing out any
object, each value gets written completely. If you added 51200 to each
"character" (making the second byte of each value equal to 200), and
wound up with
{51272, 51269, 51276, 51276, 51279}
you could still use print() to store each value without losing anything.
When using puts(), which treats sequences like C strings, only the lowest
of each value's 4 bytes is written... in this case, the two above
sequences would both be written out identically. You would lose the extra
bytes in the second sequence.
As far as I know, an integer sequence in Euphoria ALWAYS uses 4 bytes per
integer in RAM, so swapping to virtual memory shouldn't hurt anything.
And you don't have to worry about Euphoria making use of those "extra"
bytes either. That would be like you adding data to each "character", and
suddenly finding your altered string (really a sequence) of
{51272, 51269, 51276, 51276, 51279}
changed into
{72, 1000069, 7676, 33376, 790079}
Euphoria simply does not abuse your sequences that way (thank goodness!)
As for making use of the extra bytes? Might be a good idea; I don't know
for sure, but I would imagine someone has done something like that before.
(But then, I could be wrong....)
Rod
