1. question
Another question. What are you using for daily backups of your stuff that
I could use at a customer's location for backing up the software and data.
I would like to include this as a menu option where all the stuff needed
is backed up to a cd/dvd w/o the customer having to think.
2. question
I have a question for how interpreter does its internal things.
Example:
function f ()
return {1, "large data"}
end function
procedure main ()
sequence tmp
sequence data
tmp = f ()
data = tmp [2]
data = append (data, "something")
-- If I assume correct previous line had to make
-- a copy fo "large data", which would slow things down,
-- and there are now two copies of "large data",
-- one in 'tmp' and one (modified) in 'data'.
--
-- Would it be better and faster if after line
-- data = tmp [2]
-- I would do this:
-- tmp = {}?
end procedure
3. Re: question
Tone Škoda wrote:
>
>
> I have a question for how interpreter does its internal things.
>
> Example:
>
> }}}
<eucode>
> function f ()
> return {1, "large data"}
> end function
>
> procedure main ()
> sequence tmp
> sequence data
> tmp = f ()
> data = tmp [2]
> data = append (data, "something")
> -- If I assume correct previous line had to make
> -- a copy fo "large data", which would slow things down,
> -- and there are now two copies of "large data",
> -- one in 'tmp' and one (modified) in 'data'.
> --
> -- Would it be better and faster if after line
> -- data = tmp [2]
> -- I would do this:
> -- tmp = {}?
> end procedure
>
>
> </eucode>
{{{
Yes, 'data' would have been copied when the append was done because
after the append, 'data' contains different values from 'tmp[2]'. But
til that point, there would have only been one copy of the data in RAM.
If you do 'tmp={}' I think that this will add the RAM that tmp was
using to the pool of RAM that Euphoria can reuse for this application.
If you are running this as a Windows app, I also think that the released
RAM may also be available for other apps too.
If you can arrange it, I suspect that you can preallocate space in some
situations...
function f ()
return {1, "large data" & 0}
end function
procedure main ()
sequence tmp
sequence data
tmp = f ()
data = tmp [2]
data[length(data)] = "something"
. . .
end procedure
But it would probably be a good idea to deallocate the 'tmp'
too. I don't know when Euphoria's garbage collector runs. It might
not sweep this until considerable some time after 'tmp' was deallocated.
--
Derek Parnell
Melbourne, Australia
4. Re: question
Derek Parnell wrote:
>
> Yes, 'data' would have been copied when the append was done because
> after the append, 'data' contains different values from 'tmp[2]'. But
> til that point, there would have only been one copy of the data in RAM.
>
> If you do 'tmp={}' I think that this will add the RAM that tmp was
> using to the pool of RAM that Euphoria can reuse for this application.
>
> If you are running this as a Windows app, I also think that the released
> RAM may also be available for other apps too.
What would happen when when I would do 'tmp={}' before I modify 'data'? Would
there be any copying going on? Because if yes, interpreter at would have to do
these two things: 1) delete memory of 'tmp' 2) allocate memory for 'data'. And
these two memories would contain same data.
This is one thing because of which I am thinking of switching to C, because
there you have pointers and things like this are crystal clear.
5. Re: question
> > ...
> > procedure main ()
> > sequence tmp
> > sequence data
> > tmp = f ()
> > data = tmp [2]
> > data = append (data, "something")
> > ...
> > end procedure
hello, I'm new here.
looking at the docs, this sequence should be faster and cost
less memory:
data = f()
data = data[2]
data = append(data,"something")
i'm guessing that there is actually no copying going on here at all.
(as far as gc, the docs don't refer to a traditional gc.
memory is reclaimed continuously rather than in a gc phase)
with all interpreters, the best you can do is time stuff.
regards, uboy (NZ)
6. Re: question
Tone Škoda wrote:
>
> Derek Parnell wrote:
> >
> > Yes, 'data' would have been copied when the append was done because
> > after the append, 'data' contains different values from 'tmp[2]'. But
> > til that point, there would have only been one copy of the data in RAM.
> >
> > If you do 'tmp={}' I think that this will add the RAM that tmp was
> > using to the pool of RAM that Euphoria can reuse for this application.
> >
> > If you are running this as a Windows app, I also think that the released
> > RAM may also be available for other apps too.
>
> What would happen when when I would do 'tmp={}' before I modify 'data'? Would
> there
> be any copying going on? Because if yes, interpreter at would have to do these
> two
> things: 1) delete memory of 'tmp' 2) allocate memory for 'data'. And these two
> memories
> would contain same data.
procedure main ()
sequence tmp
sequence data
tmp = f () -- tmp refers the sequence data returned by f(),
-- and this point that is the only reference to it.
data = tmp [2] -- data refers to tmp[2]
tmp = {} -- tmp drops reference to f() return sequence, but the
-- sequence's contents are not deleted 'cos of the
-- refers to the 2nd element.
-- There is some 'expansion' space defined at the end of a newly
-- created sequence. So this append would most likely not
-- cause a copy to happen but the expansion area would shrink.
data = append (data, "something")
-- So the original sequence returned by f() is still in RAM
-- and there probably hasn't been any copying done.
...
end procedure
If you don't do the "tmp = {}" then the append would have to make
a copy of the contents because 'tmp' would still be referring to
it.
> This is one thing because of which I am thinking of switching to C, because
> there you
> have pointers and things like this are crystal clear.
Yes, but the responsibility is on you and your perfect code
to always "get it right". That is why I stay away from C.
BTW, this is all speculation as to how Eu works because I haven't
actually examined the source code of the Interpreter.
--
Derek Parnell
Melbourne, Australia
7. Re: question
On Mon, 15 Nov 2004 19:48:46 -0800, Tone =8Akoda
<guest at RapidEuphoria.com> wrote:
>What would happen when when I would do 'tmp={}' before I modify 'data'?=
>Would there be any copying going on? Because if yes, interpreter at
>would have to do these two things: 1) delete memory of 'tmp' 2)
>allocate memory for 'data'. And these two memories would contain same
>data.
>
>This is one thing because of which I am thinking of switching to C,
>because there you have pointers and things like this are crystal clear.
LOL.
Just think of all Euphoria variables as pointers, and all data as
{refcount,data} pairs. The data can usually be modified "in situ" if
the refcount is one (some spare slack is left on sequences to allow
this), else a copy must be made.
I suppose there is a different mindset needed to think in refcounts,
but if you are claiming pointers are clear, then refcounts, once
understood, are even clearer. A refcount of zero means "deallocate
me", a refcount of 1 means "I'm all yours", and a refcount > 1 means
"make a copy and modify that". (Bet you're thinking "I knew that")
tmp={1,large}
tmp ->seq of length 2, refcount of 1. large now has a refcount + 1
data=tmp[2]
data ->large. large now has a refcount + 2
tmp={}
tmp ->seq of length 0. The previous length 2 thing now has a refcount
of zero, so it is deallocated and the refcounts of anything it
referred to are decremented. Hence large now has a refcount + 1
It is important to grasp that the refcount on large has dropped
because the {1,ptr} object's refcount dropped to zero, rather than
directly as a result of tmp becoming {}. Note that tmp never referred
to large, tmp referred to something which referred to large.
In contrast, tmp2=tmp tmp={} would not affect the refcount of large
in any way, /not even temporarily/.
data=append(data,some)
if large has enough "slack", and has a refcount of 1, and is not from
the constant pool, then it can be modified directly, otherwise create
a new (longer) top-level copy, copy the top level pointers, and
increase the reference counts accordingly.
In the above, I've used +1, +2 on the refcount of large, as obviously
it depends on where the original came from. If it was an item from the
constant pool, then reference counts are pretty much irrelevant.
The main point is to keep the refcount of anything large at 1, at the
point you want to modify it.
Regards,
Pete
8. question
In Eu, is there an easy way to split one large file
into dozens of smaller files?
For instance, if I have one giant source file, and I
want to create a new file everytime I read a line that
begins with "******", how is that done?
9. Re: question
This program has always done the trick for me. I modified it a bit in
the email to fit your needs, so a small typo or two may have crept in.
HTH,
Michael J. Sabal
---------- Program follows -----------------
without type_check
-- split file into separate parts
atom extctr, infid, outfid
extctr = 1
procedure main()
object options, temp, current_tp
options = command_line()
if length(options)<4 then
puts(1,"The correct syntax is SPLTFLAT BIGFILE
SMALLFILE'S_PREFIX.\n")
puts(1,"Ex: SPLTFLAT MYFLAT.850 TODAY\n\n")
puts(1,"Note: Do NOT use an extension with the second
argument.\n")
abort(1)
end if
infid = open(options[3],"r")
if infid < 1 then
puts(1,"Couldn\'t open "&options[3]&"\n")
abort(2)
end if
outfid = open(options[4]&sprintf(".%03d",extctr),"w")
if outfid < 1 then
puts(1,"Couldn\'t open "&options[4]&sprintf(".%03d",extctr)&"\n")
abort(2)
end if
temp = gets(infid)
while sequence(temp) do
puts(outfid,temp)
temp = gets(infid)
if sequence(temp) and length(temp)>=6 and
compare(temp[1..6],"******")=0 then
close(outfid)
extctr = extctr + 1
outfid = open(options[4]&sprintf(".%03d",extctr),"w")
if outfid < 1 then
puts(1,"Couldn\'t open
"&options[4]&sprintf(".%03d",extctr)&"\n")
abort(2)
end if
temp = gets(infid)
end if
end while
close(infid)
if outfid > 0 then
close(outfid)
end if
end procedure
main()
---------------- End program ----------------------
>>> csaik2002 at yahoo.com 12/31/02 02:36PM >>>
In Eu, is there an easy way to split one large file
into dozens of smaller files?
For instance, if I have one giant source file, and I
want to create a new file everytime I read a line that
begins with "******", how is that done?
10. Re: question
Thank you very much Mike!
Chris
--- Sabal.Mike at notations.com wrote:
>
> This program has always done the trick for me. I
> modified it a bit in
> the email to fit your needs, so a small typo or two
> may have crept in.
>
> HTH,
> Michael J. Sabal
>
> ---------- Program follows -----------------
>
> without type_check
> -- split file into separate parts
>
> atom extctr, infid, outfid
> extctr = 1
>
> procedure main()
>
> object options, temp, current_tp
> options = command_line()
>
> if length(options)<4 then
> puts(1,"The correct syntax is SPLTFLAT BIGFILE
> SMALLFILE'S_PREFIX.\n")
> puts(1,"Ex: SPLTFLAT MYFLAT.850 TODAY\n\n")
> puts(1,"Note: Do NOT use an extension with the
> second
> argument.\n")
> abort(1)
> end if
>
> infid = open(options[3],"r")
> if infid < 1 then
> puts(1,"Couldn\'t open "&options[3]&"\n")
> abort(2)
> end if
> outfid =
> open(options[4]&sprintf(".%03d",extctr),"w")
> if outfid < 1 then
> puts(1,"Couldn\'t open
> "&options[4]&sprintf(".%03d",extctr)&"\n")
> abort(2)
> end if
>
> temp = gets(infid)
> while sequence(temp) do
> puts(outfid,temp)
> temp = gets(infid)
> if sequence(temp) and length(temp)>=6 and
> compare(temp[1..6],"******")=0 then
> close(outfid)
> extctr = extctr + 1
> outfid =
> open(options[4]&sprintf(".%03d",extctr),"w")
> if outfid < 1 then
> puts(1,"Couldn\'t open
> "&options[4]&sprintf(".%03d",extctr)&"\n")
> abort(2)
> end if
> temp = gets(infid)
> end if
> end while
>
> close(infid)
> if outfid > 0 then
> close(outfid)
> end if
>
> end procedure
> main()
>
> ---------------- End program ----------------------
>
> >>> csaik2002 at yahoo.com 12/31/02 02:36PM >>>
>
> In Eu, is there an easy way to split one large file
> into dozens of smaller files?
>
> For instance, if I have one giant source file, and I
> want to create a new file everytime I read a line
> that
> begins with "******", how is that done?
>
>
>
>
> TOPICA - Start your own email discussion group.
> FREE!
>
>
>
11. Re: question
On 31 Dec 2002, at 11:36, Chris Saik wrote:
>
> In Eu, is there an easy way to split one large file
> into dozens of smaller files?
>
> For instance, if I have one giant source file, and I
> want to create a new file everytime I read a line that
> begins with "******", how is that done?
Easy. Close the file you were writing to, open a new one, and resume writing
to it. At the next *******, close that one, open a new one, and resume writing
to that one. You could pick names in numeric or alphabetic order, basicaly, if
you can open the filename to read it, then it exists, and pick a new name,
and try to read it.
Kat
12. question
I have the following sequence, as an example.
sequence a,b
a = {id1,id2,id3}
b = {
{id1,1,2},
{id2,2,4},
{id3,5,6}
}
Here's the question
if setEnable(a, False) -- works ok and disables all the id's
Why would not
setEnable(b[1],False) -- won't work but win32 blows up
I would think that setEnable would cycle over the 1st element of the table
for the length of the table. This is what I have to do
for i = 1 to length(b)
setEnable(b[i][1])
end for
Am I confused here? If so how could I solve the problem w/o a loop?
...george
14. Re: question
Hi George,
>
> I have the following sequence, as an example.
>
> sequence a,b
>
> a = {id1,id2,id3}
>
> b = {
> {id1,1,2},
> {id2,2,4},
> {id3,5,6}
> }
>
> Here's the question
>
> if setEnable(a, False) -- works ok and disables all the id's
>
> Why would not
>
> setEnable(b[1],False) -- won't work but win32 blows up
>
> I would think that setEnable would cycle over the 1st element of the table
> for the length of the table. This is what I have to do
>
> for i = 1 to length(b)
> setEnable(b[i][1])
> end for
>
> Am I confused here? If so how could I solve the problem w/o a loop?
The reason is that the first parameter to setEnable must either be a single
ID number or a sequence of ID numbers. In the example you have given, the
first parameter is a sequence of sequences - which is not something that I
catered for. The reason being that there is no way that Win32lib could know
which sub-element contains the ID. It would not be safe to assume that the
first sub-element always contained the ID.
However, now that you have pointed out this possibility, there is no reason
why I couldn't *document* this format for those routines that take an ID as
a parameter.
As Mike has pointed out, there is an argument for more rigorous parameter
checking in Win32lib to weed out ill formed parameters etc... The counter
argument is that this just slows down the library even more and the correct
parameters have been documented so it is the caller's responsibility. I do
not take any position in the argument. I would like to see some form of
optional parameter checking to be implemented and that is probably the way
I'll go in future.
However, to get around your current dilemma, try doing something like...
a = {id1,id2,id3}
b = {
a,
{1, 2, 5},
{2, 4, 6}
}
setEnable(b[1],False)
in other words, have each sequence element represent a field rather than a
record. To get the record data, you slice the sequence thus...
x = find (id, a)
if x != 0 then
fld1 = b[2][x]
fld2 = b[3][x]
end if
<off_topic>
Now if only Euphoria had some vertical slicing syntax that would make this
easier - oh well, just a pipe dream I suppose but it would be nice to do ...
sequence flds
flds = b[][find(id, b[1]]
where a zero index would result in an empty sequence (hint, hint Robert).
</off_topic>
----
Cheers,
Derek.
15. Re: question
Thanks Michael...my confusion. I have seen in other languages that the
unreferenced index is cycled over, so perhaps a better stated syntax could
be...
setEnable(b[ ][1],False)
notice the 1st argument is empty
...george
----- Original Message -----
From: <Sabal.Mike at notations.com>
To: "EUforum" <EUforum at topica.com>
Sent: Monday, August 20, 2001 2:25 PM
Subject: Re: question
This is the vertical slicing issue that many having been asking Rob to
include in a future version of Euphoria. Remember that b[1] = {id1,1,2},
not {{id1},{id2},{id3}}. Win32lib crashes because you're trying to set
something that can't be set. However <hint>this kind of error should be
trapped and gently handled by the win32lib designers</hint>.
HTH,
Michael J. Sabal
>>> gwalters at sc.rr.com 08/20/01 02:06PM >>>
b = {
{id1,1,2},
{id2,2,4},
{id3,5,6}
}
Here's the question
if setEnable(a, False) -- works ok and disables all the id's
Why would not
setEnable(b[1],False) -- won't work but win32 blows up
16. question
- Posted by gwalters at sc.rr.com
Mar 05, 2002
Derek, thanks for the list box example program. I have another question for
you or anyone who knows the answer.
How do you send a message to the list box to do things like page up, page
down, top, bottom....
constant mainWindow = create(Window,"Printout Viewer - "& rptName,
0,sx,sy,sw,sh,0),
idList = create(List,"",mainWindow,0,0,sw-7,sh-82,{WS_SCROLLBARS}),
sb = createEx(StatusBar, "", mainWindow, 0, 0, 0, 0, 0, 0)
thanks...
george
