1. Re[2]: Multitask Feedback
- Posted by akusaya at gmx.net
Sep 23, 2005
R> Maybe.
R> I'll give it some thought.
R> Thanks.
R> Currently when any task crashes you'll get a call stack
R> traceback in ex.err for *each* task, plus the global/local
R> variables as usual. The active (crashing) task info is listed first.
Again, and again, how about a feature to ignore return values after
calling a function? It's really annoying, almost every time I make a
little Eu program I need to do something like
PP = seek(fn, 100)
where PP is a global variable I defined in aku.e which is an include
file I always include when starting to write a new Eu program. (almost
never write a Eu program without an "include"!)
All languages I know allow ignoring function return values. Why not
Eu?
(BTW, I tried making a website with PHP, unexpectedly it's not a lot
harder than using Eu, but much easier since it has rich functions and
database access functions)
2. Re: Re[2]: Multitask Feedback
akusaya wrote:
> Again, and again, how about a feature to ignore return values after
> calling a function? It's really annoying, almost every time I make a
> little Eu program I need to do something like
>
> PP = seek(fn, 100)
>
> where PP is a global variable I defined in aku.e which is an include
> file I always include when starting to write a new Eu program. (almost
> never write a Eu program without an "include"!)
>
> All languages I know allow ignoring function return values. Why not
> Eu?
I might get around to it.
I don't have strong objections to it,
but I also don't see that it creates much hardship,
and occasionally it might catch an error.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
3. Re: Re[2]: Multitask Feedback
akusaya wrote:
>
> (BTW, I tried making a website with PHP, unexpectedly it's not a lot
> harder than using Eu, but much easier since it has rich functions and
> database access functions)
I actually manage a web site that uses PHP and MySQL, plus a variety of
web sites that are run with Euphoria and text files, and one site that is
Euphoria plus EuSQL (plus Kanarie, etc...). PHP might be easier than
vanilla Euphoria, but when you add EuSQL (and probably any other database
library) and Kanarie, your benefits for using PHP drop significantly.
-=ck
"Programming in a state of EUPHORIA."
http://www.cklester.com/euphoria/
4. Re: Re[2]: Multitask Feedback
Robert Craig wrote:
> akusaya wrote:
> > Again, and again, how about a feature to ignore return values after
> > calling a function? It's really annoying, almost every time I make a
> > little Eu program I need to do something like
> >
> > PP = seek(fn, 100)
> >
> > where PP is a global variable I defined in aku.e which is an include
> > file I always include when starting to write a new Eu program. (almost
> > never write a Eu program without an "include"!)
> >
> > All languages I know allow ignoring function return values. Why not
> > Eu?
>
> I might get around to it.
> I don't have strong objections to it,
> but I also don't see that it creates much hardship,
> and occasionally it might catch an error.
I don't see the benefits. Can somebody explain it to me?
-=ck
"Programming in a state of EUPHORIA."
http://www.cklester.com/euphoria/
5. Re: Re[2]: Multitask Feedback
akusaya wrote:
>
(snip)
>
> Again, and again, how about a feature to ignore return values after
> calling a function? It's really annoying, almost every time I make a
> little Eu program I need to do something like
>
> PP = seek(fn, 100)
>
> where PP is a global variable I defined in aku.e which is an include
> file I always include when starting to write a new Eu program. (almost
> never write a Eu program without an "include"!)
>
> All languages I know allow ignoring function return values. Why not
> Eu?
>
> (BTW, I tried making a website with PHP, unexpectedly it's not a lot
> harder than using Eu, but much easier since it has rich functions and
> database access functions)
>
Well, functions return values for a reason and it's not that hard to ignore a
return value. Is it annoying? At times, yes. Worth adding some language construct
to the langauge to remedy it? Definitely not.
Here, this is what I use:
procedure ignore(object x)
-- Do nothing, just ignore the object passed
end procedure -- ignore
ignore( seek(fn, 100) )
It's not that hard to implement and use, looks neat and clear, and most
importantly doesn't change Euphoria in any way.
The Euphoria Standard Library project :
http://esl.sourceforge.net/
The Euphoria Standard Library mailing list :
https://lists.sourceforge.net/lists/listinfo/esl-discussion
6. Re: Re[2]: Multitask Feedback
D. Newhall wrote:
>
> akusaya wrote:
> >
> (snip)
> >
> > Again, and again, how about a feature to ignore return values after
> > calling a function? It's really annoying, almost every time I make a
> > little Eu program I need to do something like
> >
> > PP = seek(fn, 100)
> >
> > where PP is a global variable I defined in aku.e which is an include
> > file I always include when starting to write a new Eu program. (almost
> > never write a Eu program without an "include"!)
> >
> > All languages I know allow ignoring function return values. Why not
> > Eu?
> >
> > (BTW, I tried making a website with PHP, unexpectedly it's not a lot
> > harder than using Eu, but much easier since it has rich functions and
> > database access functions)
> >
>
> Well, functions return values for a reason and it's not that hard to ignore a
> return
> value. Is it annoying? At times, yes. Worth adding some language construct to
> the langauge
> to remedy it? Definitely not.
>
> Here, this is what I use:
>
> }}}
<eucode>
> procedure ignore(object x)
> -- Do nothing, just ignore the object passed
> end procedure -- ignore
>
> ignore( seek(fn, 100) )
> </eucode>
{{{
>
> It's not that hard to implement and use, looks neat and clear, and most
> importantly
> doesn't change Euphoria in any way.
>
>
> The Euphoria Standard Library project :
> <a href="http://esl.sourceforge.net/">http://esl.sourceforge.net/</a>
> The Euphoria Standard Library mailing list :
> <a
> href="https://lists.sourceforge.net/lists/listinfo/esl-discussion">https://lists.sourceforge.net/lists/listinfo/esl-discussion</a>
>
Hi there,
That's a good idea. I can go either way with this though. After all,
it doesnt take too much to ignore a return value, yet it wouldnt take
any new keyword to modify the language either.
i=seek(fn,a) --i need the return value
seek(fn,a) --i dont need the return value
It's also hard to believe this would cause many problems, because
im wondering who could make an error like these:
seek(fn,a) --whoops! I really needed the return value here! :)
i=seek(fn,a) --Oh geeze! I didnt really need the return value here! :)
Would anyone make this kind of error if it worked both ways?
With my C compiler (not sure if this is typical for compilers) it
allows you to call Win API functions as either a function when you need
the return value:
c=SetColor(new)
or as a procedure when you dont:
SetColor(new)
I think most people do something like this in Euphoria...
object void --local or global
void=seek(fn,a)
void=SomethingElse()
etc.
although Rob seems to prefer:
if seek(fn,a) then end if
Take care,
Al
And, good luck with your Euphoria programming!
My bumper sticker: "I brake for LED's"
7. Re: Re[2]: Multitask Feedback
D. Newhall wrote:
>
> Here, this is what I use:
>
> }}}
<eucode>
> procedure ignore(object x)
> -- Do nothing, just ignore the object passed
> end procedure -- ignore
>
> ignore( seek(fn, 100) )
> </eucode>
{{{
>
> It's not that hard to implement and use, looks neat and clear, and most
> importantly
> doesn't change Euphoria in any way.
>
derek:
Why not just use this; your way has the overhead of an extra call ?
object ignore
ignore = seek(fn, 100)
Bernie
My files in archive:
w32engin.ew mixedlib.e eu_engin.e win32eru.exw
Can be downloaded here:
http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan
8. Re: Re[2]: Multitask Feedback
Al Getz wrote:
>
> Hi there,
>
> That's a good idea. I can go either way with this though. After all,
> it doesnt take too much to ignore a return value, yet it wouldnt take
> any new keyword to modify the language either.
>
> i=seek(fn,a) --i need the return value
> seek(fn,a) --i dont need the return value
>
> It's also hard to believe this would cause many problems, because
> im wondering who could make an error like these:
>
> seek(fn,a) --whoops! I really needed the return value here! :)
>
> i=seek(fn,a) --Oh geeze! I didnt really need the return value here! :)
>
> Would anyone make this kind of error if it worked both ways?
>
> With my C compiler (not sure if this is typical for compilers) it
> allows you to call Win API functions as either a function when you need
> the return value:
> c=SetColor(new)
> or as a procedure when you dont:
> SetColor(new)
>
>
> I think most people do something like this in Euphoria...
>
> object void --local or global
> void=seek(fn,a)
> void=SomethingElse()
> etc.
>
> although Rob seems to prefer:
>
> if seek(fn,a) then end if
>
>
> Take care,
> Al
>
> And, good luck with your Euphoria programming!
>
> My bumper sticker: "I brake for LED's"
>
The "problem" with simply ignoring the return value if no variable assignment is
before it is if you forget to put the assignment in when you meant to and your
code works but not correctly and I think that that could be a hard bug to find.
Especially if you're converting C code to Euphoria, for example, since C's open()
doesn't return a value so if you forget the assignment while translating and you
do a quick scan over your code and you forget to make the distinction between C
and Euphoria's open() it might take you a while to figure out where the bug is.
While that argument does seem a bit forced I can see simply ignoring the return
values of functions without an assignment causing a lot of problems for some
programmers because it's not a very apparent bug and if you didn't define the
routines you are using (ie. you're using another person's library) you might have
no idea while your code isn't working.
Bernie Ryan wrote:
>
> derek:
> Why not just use this; your way has the overhead of an extra call ?
>
>
> object ignore
>
> ignore = seek(fn, 100)
You can do that too (and many times I do as well) however in most cases the
extra procedure call doesn't add much and I think it's clearer because maybe the
variable is named ignore for some other reason? Also, with this method (and this
is simply me being a lazy programmer) I have a tendency to use the variable
ignore in tests and as a temporary variable rather than redeclare it so I've
beeen known to use an "ignored" variable for a good length of code :P, the
procedure version makes sure I can't do that.
The Euphoria Standard Library project :
http://esl.sourceforge.net/
The Euphoria Standard Library mailing list :
https://lists.sourceforge.net/lists/listinfo/esl-discussion
9. Re: Re[2]: Multitask Feedback
D. Newhall wrote:
>
> Al Getz wrote:
> >
> > Hi there,
> >
> > That's a good idea. I can go either way with this though. After all,
> > it doesnt take too much to ignore a return value, yet it wouldnt take
> > any new keyword to modify the language either.
> >
> > i=seek(fn,a) --i need the return value
> > seek(fn,a) --i dont need the return value
> >
> > It's also hard to believe this would cause many problems, because
> > im wondering who could make an error like these:
> >
> > seek(fn,a) --whoops! I really needed the return value here! :)
> >
> > i=seek(fn,a) --Oh geeze! I didnt really need the return value here! :)
> >
> > Would anyone make this kind of error if it worked both ways?
> >
> > With my C compiler (not sure if this is typical for compilers) it
> > allows you to call Win API functions as either a function when you need
> > the return value:
> > c=SetColor(new)
> > or as a procedure when you dont:
> > SetColor(new)
> >
> >
> > I think most people do something like this in Euphoria...
> >
> > object void --local or global
> > void=seek(fn,a)
> > void=SomethingElse()
> > etc.
> >
> > although Rob seems to prefer:
> >
> > if seek(fn,a) then end if
> >
> >
> > Take care,
> > Al
> >
> > And, good luck with your Euphoria programming!
> >
> > My bumper sticker: "I brake for LED's"
> >
>
> The "problem" with simply ignoring the return value if no variable assignment
> is before
> it is if you forget to put the assignment in when you meant to and your code
> works
> but not correctly and I think that that could be a hard bug to find.
> Especially if
> you're converting C code to Euphoria, for example, since C's open() doesn't
> return
> a value so if you forget the assignment while translating and you do a quick
> scan over
> your code and you forget to make the distinction between C and Euphoria's
> open() it
> might take you a while to figure out where the bug is. While that argument
> does seem
> a bit forced I can see simply ignoring the return values of functions without
> an assignment
> causing a lot of problems for some programmers because it's not a very
> apparent bug
> and if you didn't define the routines you are using (ie. you're using another
> person's
> library) you might have no idea while your code isn't working.
>
>
> Bernie Ryan wrote:
> >
> > derek:
> > Why not just use this; your way has the overhead of an extra call ?
> >
> >
> > object ignore
> >
> > ignore = seek(fn, 100)
>
> You can do that too (and many times I do as well) however in most cases the
> extra procedure
> call doesn't add much and I think it's clearer because maybe the variable is
> named
> ignore for some other reason? Also, with this method (and this is simply me
> being a
> lazy programmer) I have a tendency to use the variable ignore in tests and as
> a temporary
> variable rather than redeclare it so I've beeen known to use an "ignored"
> variable
> for a good length of code :P, the procedure version makes sure I can't do
> that.
>
>
> The Euphoria Standard Library project :
> <a href="http://esl.sourceforge.net/">http://esl.sourceforge.net/</a>
> The Euphoria Standard Library mailing list :
> <a
> href="https://lists.sourceforge.net/lists/listinfo/esl-discussion">https://lists.sourceforge.net/lists/listinfo/esl-discussion</a>
>
Hi again Derek,
Sure, i agree that if you 'forget' to type the return variable
it can be a harder bug to track down, but this can happen anyway
if you type
void=seek()
ignore=seek()
ignore(seek())
Same bug, same problem.
The reasoning here is that if you dont think you need the return value
when you really do then the language isnt going to help. Maybe this
is why my C compiler allows it for API calls...
This style is typical:
procedure DrawThis()
OldColor=SetColor(NewColor1) --do first color and save original color
DoSomething()
SetColor(NewColor2) --do second color
DoSomething()
SetColor(NewColor3) --do third color
DoSomething()
SetColor(OldColor) --restore original color
end procedure
The idea is to save the value of OldColor until the very last call,
where the old color is restored before exiting the function call.
In some cases, you might have to call SetColor() 20 times without
needing the return value simply because it isnt used until the
end. Without this functionality, you'd have to do this:
procedure DrawThis()
OldColor=SetColor(NewColor1) --do first color and save original color
DoSomething()
void=SetColor(NewColor2) --do second color
DoSomething()
void=SetColor(NewColor3) --do third color
DoSomething()
SetColor(OldColor) --restore original color
end procedure
and here you'd have to be very careful NOT to do this:
procedure DrawThis()
OldColor=SetColor(NewColor1) --do first color and save original color
DoSomething()
OldColor=SetColor(NewColor2) --do second color
DoSomething()
OldColor=SetColor(NewColor3) --do third color
DoSomething()
SetColor(OldColor) --restore original color
end procedure
because then the original color would not be restored!
So it looks to me that it's just the burden of responsibility shifts
from possibly creating an error one way, or another.
When we look at:
seek()
we know any possible variable isnt getting updated, but when we look at:
void=seek()
we also assume the same, and as someone said, if you arent true to
your own chosen style you may be using 'void' for some other purpose too :)
I really dont mind the way it is now though, i just use 'void' or
something like that. I like the function call idea too though.
Hey, maybe 'void' should be declared in misc.e :) that way everyone
would be using the same var for an ignored return value.
Or this (he he)
--file: Void.e
global object void
You could put your procedure there too...
global procedure ignore(object x)
end procedure
Take care,
Al
And, good luck with your Euphoria programming!
My bumper sticker: "I brake for LED's"
10. Re: Re[2]: Multitask Feedback
D. Newhall wrote:
>
> Al Getz wrote:
> >
> > Hi there,
> >
> > That's a good idea. I can go either way with this though. After all,
> > it doesnt take too much to ignore a return value, yet it wouldnt take
> > any new keyword to modify the language either.
> >
> > i=seek(fn,a) --i need the return value
> > seek(fn,a) --i dont need the return value
> >
> > It's also hard to believe this would cause many problems, because
> > im wondering who could make an error like these:
> >
> > seek(fn,a) --whoops! I really needed the return value here! :)
> >
> > i=seek(fn,a) --Oh geeze! I didnt really need the return value here! :)
> >
> > Would anyone make this kind of error if it worked both ways?
> >
> > With my C compiler (not sure if this is typical for compilers) it
> > allows you to call Win API functions as either a function when you need
> > the return value:
> > c=SetColor(new)
> > or as a procedure when you dont:
> > SetColor(new)
> >
> >
> > I think most people do something like this in Euphoria...
> >
> > object void --local or global
> > void=seek(fn,a)
> > void=SomethingElse()
> > etc.
> >
> > although Rob seems to prefer:
> >
> > if seek(fn,a) then end if
> >
> >
> > Take care,
> > Al
> >
> > And, good luck with your Euphoria programming!
> >
> > My bumper sticker: "I brake for LED's"
> >
>
> The "problem" with simply ignoring the return value if no variable assignment
> is before
> it is if you forget to put the assignment in when you meant to and your code
> works
> but not correctly and I think that that could be a hard bug to find.
> Especially if
> you're converting C code to Euphoria, for example, since C's open() doesn't
> return
> a value so if you forget the assignment while translating and you do a quick
> scan over
> your code and you forget to make the distinction between C and Euphoria's
> open() it
> might take you a while to figure out where the bug is. While that argument
> does seem
> a bit forced I can see simply ignoring the return values of functions without
> an assignment
> causing a lot of problems for some programmers because it's not a very
> apparent bug
> and if you didn't define the routines you are using (ie. you're using another
> person's
> library) you might have no idea while your code isn't working.
>
>
> Bernie Ryan wrote:
> >
> > derek:
> > Why not just use this; your way has the overhead of an extra call ?
> >
> >
> > object ignore
> >
> > ignore = seek(fn, 100)
>
> You can do that too (and many times I do as well) however in most cases the
> extra procedure
> call doesn't add much and I think it's clearer because maybe the variable is
> named
> ignore for some other reason? Also, with this method (and this is simply me
> being a
> lazy programmer) I have a tendency to use the variable ignore in tests and as
> a temporary
> variable rather than redeclare it so I've beeen known to use an "ignored"
> variable
> for a good length of code :P, the procedure version makes sure I can't do
> that.
>
>
> The Euphoria Standard Library project :
> <a href="http://esl.sourceforge.net/">http://esl.sourceforge.net/</a>
> The Euphoria Standard Library mailing list :
> <a
> href="https://lists.sourceforge.net/lists/listinfo/esl-discussion">https://lists.sourceforge.net/lists/listinfo/esl-discussion</a>
>
I just use a dummy IF statement to ignore function return values. It doesnt
cause any overhead that I'm aware of. Graphics_mode() is a good example of a
function that I rarely need the return value for.
-- Example (DOS-32)
without type_check
without warning
constant GRAPHICS_MODE = 5,
TEXT_COLOR = 9,
VIDEO_CONFIG = 13,
WAIT_KEY = 26
sequence vConfig
if machine_func(GRAPHICS_MODE, 13) then end if
vConfig = machine_func(VIDEO_CONFIG, 0)
position(vConfig[3]/2, vConfig[4]/2.6)
machine_proc(TEXT_COLOR, 12)
puts(1, "Hello There!")
machine_proc(WAIT_KEY, 0)
if machine_func(GRAPHICS_MODE, -1) then end if
Regards,
Vincent
----------------------------------------------
___ __________ ___
/__/\ /__________\ |\ _\
\::\'\ //::::::::::\\ |'|::|
\::\'\ //:::_::::_:::\\ |'|::|
\::\'\ //::/ |::| \::\\ |'|::|
\::\'\ //::/ |::| \::\\|'|::|
\::\'\__//::/ |::| \::\|'|::|
\::\','/::/ |::| \::\\|::|
\::\_/::/ |::| \::\|::|
\::,::/ |::| \:::::|
\___/ |__| \____|
.``.
',,'
11. Re: Re[2]: Multitask Feedback
- Posted by Pete Lomax <petelomax at blueyonder.co.uk>
Sep 24, 2005
-
Last edited Sep 25, 2005
>D. Newhall wrote:
>> While that argument does seem a bit forced
Yes, it does. The original argument, imo, was also flawed in that ALL
calls to seek() should be of the form:
if seek(..blah..) != 0 then
Error(...)
end if
>Al Getz wrote:
>Hey, maybe 'void' should be declared in misc.e :)
Seconded. Maybe 'ignore' on the sole basis it does not (tmk) clash
with any existing libs.
Regards,
Pete
12. Re: Re[2]: Multitask Feedback
D. Newhall wrote:
>
> akusaya wrote:
> >
> (snip)
> >
> > Again, and again, how about a feature to ignore return values after
> > calling a function? It's really annoying, almost every time I make a
> > little Eu program I need to do something like
> >
> > PP = seek(fn, 100)
> >
> > where PP is a global variable I defined in aku.e which is an include
> > file I always include when starting to write a new Eu program. (almost
> > never write a Eu program without an "include"!)
> >
> > All languages I know allow ignoring function return values. Why not
> > Eu?
> >
> > (BTW, I tried making a website with PHP, unexpectedly it's not a lot
> > harder than using Eu, but much easier since it has rich functions and
> > database access functions)
> >
>
> Well, functions return values for a reason and it's not that hard to ignore a
> return
> value. Is it annoying? At times, yes. Worth adding some language construct to
> the langauge
> to remedy it? Definitely not.
>
> Here, this is what I use:
>
> }}}
<eucode>
> procedure ignore(object x)
> -- Do nothing, just ignore the object passed
> end procedure -- ignore
>
> ignore( seek(fn, 100) )
> </eucode>
{{{
>
> It's not that hard to implement and use, looks neat and clear, and most
> importantly
> doesn't change Euphoria in any way.
>
>
> The Euphoria Standard Library project :
> <a href="http://esl.sourceforge.net/">http://esl.sourceforge.net/</a>
> The Euphoria Standard Library mailing list :
> <a
> href="https://lists.sourceforge.net/lists/listinfo/esl-discussion">https://lists.sourceforge.net/lists/listinfo/esl-discussion</a>
>
Why not just
global object ignore
ignore = seek(fn,100)
that way you save procedure call overhead.
regards,
Jacques Deschênes
