1. implications, flames, etc.
1. I shouldn't free-associate on-line and then become irritated when others
complain that I responded to
something that they said (which is what triggered my tangent, but
which is not directed at them)
2. I shouldn't free-associate on topics like Java in which I've been
*hammering* out 2 problems for the past 2
weeks straight and still don't have the optimal solution.
I will try to keep points 1 and 2 in mind in the future.
Cheers!
--Warren
2. Re: implications, flames, etc.
- Posted by Everett Williams <rett at GVTC.COM>
Feb 01, 2000
-
Last edited Feb 02, 2000
On Tue, 1 Feb 2000 16:18:48 -0800, WCBaker at home <WCBaker at HOME.COM> wrote:
>1. I shouldn't free-associate on-line and then become irritated when others
>complain that I responded to
> something that they said (which is what triggered my tangent, but
>which is not directed at them)
>
>2. I shouldn't free-associate on topics like Java in which I've been
>*hammering* out 2 problems for the past 2
> weeks straight and still don't have the optimal solution.
>
>I will try to keep points 1 and 2 in mind in the future.
>
>Cheers!
>
>--Warren
You'd think I was immune by now. I have been flamed early and often by
many, and have mostly managed to stay on topic. I should have in this case.
I sympathize with your difficulties with JAVA. It is a far from ideal construct,
language, environment, whatever. I did not mean to "imply" that it was ideal
in any way. What I was pointing out was that many major players have
committed huge resources to it and I want access to the results of those
efforts, whatever they may be. I'll correct that. I may NEED to have access.
I'd also like for Nick to have access to ActiveX as long as he'll keep it
hidden in his closet and not in the language base 
In general, I'd like
to have straightforward access to anything that can be called in the most
general sense of that word. That requires two things the ability to reasonably
describe the data to be sent and received without peeking and poking
everything(structures) and a more generalized and flexible calling procedure.
Everett L.(Rett) Williams
rett at gvtc.com
3. Re: implications, flames, etc.
-----Original Message-----
From: Everett Williams <rett at GVTC.COM>
To: EUPHORIA at LISTSERV.MUOHIO.EDU <EUPHORIA at LISTSERV.MUOHIO.EDU>
Date: Wednesday, February 02, 2000 12:38 PM
Subject: Re: implications, flames, etc.
Hi Everett
> In general, I'd like
>to have straightforward access to anything that can be called in the most
>general sense of that word. That requires two things the ability to
reasonably
>describe the data to be sent and received without peeking and poking
>everything(structures) and a more generalized and flexible calling
procedure.
>
I'm a Euphoria newbie but have already found frustration in not being able
to get at the location of my variables. I wouldn't want to know for my own
code but so much of what I want to call expects me to know where that
variable is. I'm not even particularly concerned on performance grounds (EU
seems to hum along quite nicely). It just makes doing something simple so
untidy. I know Rob is opposed to this (I can understand that he does not
want the competition to get at his language) but as the language grows,
people (even incompetents like me) are going to want to do odd things.
Cheers.
Mark
4. Re: implications, flames, etc.
On Wed, 2 Feb 2000 18:51:23 +1030, Mark Brown wrote:
>I'm a Euphoria newbie but have already found frustration in not being able
>to get at the location of my variables. I wouldn't want to know for my own
>code but so much of what I want to call expects me to know where that
>variable is.
Forgive me if I'm stating something you've already considered but if you
need the pointer for a C variable/structure, why not use allocate/poke?
That is, after all, the reason these routines exist...
-- Brian
5. Re: implications, flames, etc.
- Posted by Mark Brown <mabrown at SENET.COM.AU>
Feb 02, 2000
-
Last edited Feb 03, 2000
-----Original Message-----
From: Brian Broker <bkb at CNW.COM>
To: EUPHORIA at LISTSERV.MUOHIO.EDU <EUPHORIA at LISTSERV.MUOHIO.EDU>
Date: Wednesday, February 02, 2000 7:25 PM
Subject: Re: implications, flames, etc.
Hi Brian.
This mailing list thing really does work quickly, doesn't it!
>On Wed, 2 Feb 2000 18:51:23 +1030, Mark Brown wrote:
>
>>I'm a Euphoria newbie but have already found frustration in not being able
>>to get at the location of my variables. I wouldn't want to know for my own
>>code but so much of what I want to call expects me to know where that
>>variable is.
>
>Forgive me if I'm stating something you've already considered but if you
>need the pointer for a C variable/structure, why not use allocate/poke?
>That is, after all, the reason these routines exist...
>
This is what I have been doing (following stuff I've learned from you guys
(and Todd Riggins) actually!). I guess what I mean is that I would like to
turn the following (for example) :-
atom view_direction,p1,p2,p3
view_direction = allocate(3*8)
p1 = allocate(3*8)
p2 = allocate(3*8)
p3 = allocate(3*8)
--
global function Morfit_math_is_clockwise_from_direction(sequence
my_view_direction, sequence my_p1, sequence my_p2, sequence my_p3)
-- rip the values from the sequence(s) and poke them into the array(s)
poke(view_direction, atom_to_float64(my_view_direction[1]))
poke(view_direction+8, atom_to_float64(my_view_direction[2]))
poke(view_direction+16, atom_to_float64(my_view_direction[3]))
--
poke(p1, atom_to_float64(my_p1[1]))
poke(p1+8, atom_to_float64(my_p1[2]))
poke(p1+16, atom_to_float64(my_p1[3]))
--
poke(p2, atom_to_float64(my_p2[1]))
poke(p2+8, atom_to_float64(my_p2[2]))
poke(p2+16, atom_to_float64(my_p2[3]))
--
poke(p3, atom_to_float64(my_p3[1]))
poke(p3+8, atom_to_float64(my_p3[2]))
poke(p3+16, atom_to_float64(my_p3[3]))
return c_func(xMorfit_math_is_clockwise_from_direction,{view_direction,
p1, p2, p3})
end function
into something more like :-
ret_val = c_func(Morfit_math_is_clockwise_from_direction,{&
view_direction, &p1, &p2, &p3)
where &view_direction etc.... are just the location in memory of my
sequence(s). This would mean I wouldn't have to poke into memory, everything
I've just put into my sequence(s) so that the c function I'm calling knows
where to get what it needs (and often I've found, where it needs to return
stuff, which results in a whole new round of grabing the values from the
memory locations and putting them in my sequences.
I suppose we can just deal with the memory without loading and unloading the
sequences but it seems to me to make doing anything else with the data a bit
of a chore.
The "atom_to_float" thing in the above also makes me wonder whether, just
for using stuff in the C world etc, it might be a good idea to have fixed
length types available in Euphoria (such as Double). From the flexible to
the totally inflexible!. I think Rob is going to hate me for that one.
Perhaps, something like :-
sequence p1[3*8]
I'm well out of my depth here so if any of this is junk, please just chuckle
and go on.
Mark.
6. Re: implications, flames, etc.
On Wed, 2 Feb 2000 03:49:29 -0500, Brian Broker <bkb at CNW.COM> wrote:
>On Wed, 2 Feb 2000 18:51:23 +1030, Mark Brown wrote:
>
>>I'm a Euphoria newbie but have already found frustration in not being able
>>to get at the location of my variables. I wouldn't want to know for my own
>>code but so much of what I want to call expects me to know where that
>>variable is.
>
>Forgive me if I'm stating something you've already considered but if you
>need the pointer for a C variable/structure, why not use allocate/poke?
>That is, after all, the reason these routines exist...
>
>-- Brian
And what nice naming conventions would you like to associate with these
allocated and poked structures? Even though I was the lead assembler
person on a team of ten assembler programmers, it didn't take me
long to figure out that assembler was not going to allow most people to
approach the programming area. Peek and poke don't even allow the
named structures that assembler allows. I can fill up a swimming pool
with a coffee cup, but I doubt that anybody will see the efficiency of that
approach.
Everett L.(Rett) Williams
rett at gvtc.com
7. Re: implications, flames, etc.
Mark Brown wrote:
>This is what I have been doing (following stuff I've learned from you guys
>(and Todd Riggins) actually!). I guess what I mean is that I would like to
>turn the following (for example) :-
>
>atom view_direction,p1,p2,p3
>view_direction = allocate(3*8)
>p1 = allocate(3*8)
>p2 = allocate(3*8)
>p3 = allocate(3*8)
>--
>global function Morfit_math_is_clockwise_from_direction(sequence
>my_view_direction, sequence my_p1, sequence my_p2, sequence my_p3)
>
> -- rip the values from the sequence(s) and poke them into the array(s)
> poke(view_direction, atom_to_float64(my_view_direction[1]))
> poke(view_direction+8, atom_to_float64(my_view_direction[2]))
> poke(view_direction+16, atom_to_float64(my_view_direction[3]))
> --
> poke(p1, atom_to_float64(my_p1[1]))
> poke(p1+8, atom_to_float64(my_p1[2]))
> poke(p1+16, atom_to_float64(my_p1[3]))
> --
> poke(p2, atom_to_float64(my_p2[1]))
> poke(p2+8, atom_to_float64(my_p2[2]))
> poke(p2+16, atom_to_float64(my_p2[3]))
> --
> poke(p3, atom_to_float64(my_p3[1]))
> poke(p3+8, atom_to_float64(my_p3[2]))
> poke(p3+16, atom_to_float64(my_p3[3]))
>
> return c_func(xMorfit_math_is_clockwise_from_direction,{view_direction,
>p1, p2, p3})
>end function
>
>into something more like :-
>
>
> ret_val = c_func(Morfit_math_is_clockwise_from_direction,{&
>view_direction, &p1, &p2, &p3)
>
>where &view_direction etc.... are just the location in memory of my
>sequence(s). This would mean I wouldn't have to poke into memory, everything
>I've just put into my sequence(s) so that the c function I'm calling knows
>where to get what it needs (and often I've found, where it needs to return
>stuff, which results in a whole new round of grabing the values from the
>memory locations and putting them in my sequences.
>
>I suppose we can just deal with the memory without loading and unloading the
>sequences but it seems to me to make doing anything else with the data a bit
>of a chore.
>
>The "atom_to_float" thing in the above also makes me wonder whether, just
>for using stuff in the C world etc, it might be a good idea to have fixed
>length types available in Euphoria (such as Double). From the flexible to
>the totally inflexible!. I think Rob is going to hate me for that one.
>Perhaps, something like :-
>
>sequence p1[3*8]
>
>I'm well out of my depth here so if any of this is junk, please just chuckle
>and go on.
>
>Mark.
Out of the mouths of babes...hey emperor, I really like those new clothes
you have there. Better said than I ever could. I realize that several of the
resident geniuses will come up with a dozen techniques to mask what you
have written, but the reality is that underneath it all is that loveliness that
you document so well...peek and poke.
Everett L.(Rett) Williams
rett at gvtc.com
8. Re: implications, flames, etc.
Everett Williams wrote:
> but the reality is that underneath it all is
> that loveliness that you document so well...
> peek and poke.
Gosh, using memory access routines to access memory! We certainly can't have
*that*.
-- David Cuny
