Re: getting help (staring at screenshot)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Re: getting help (staring at screenshot)

Paul Sheldon-2
I notice that you enlarged your playing field so you could get a view
of the croquet world (which didn't appear) and have room to see
the error message. I must do this, too.

My eye caught on several focuses.

I noticed a bunch of "ins" which suggested the last was where in there
was the trouble . I had wondered at this being a callback chain where
the most relevant stuff was last.

I started in the dark ages of programming when there were core dumps
proudly read by folks I feared as one might fear a raptor
while clubbing off neandrathals (got my timing way off, mind you).

Even in 1982 rerun of graduate school, after some dark ages work
in the so called real world, one threw out the followup error messages
because only the first one's were relevant before the parser went crazy.

What I think is going on when you get past dark ages is not parser errors
but rather runtime or execution errors.
The parser errors you throw out the later as irrelevant.
The execution errors you must track through callbacks to find cause
and relevance in what is written down later.

The next thing that caught my eye was that, after all the ins,
the word context came up again and again.
I believe this has something to do with something like dynamic scoping
found in oop. I understood "context" in an intuitive and nonpedagogic
sort of way programming newtonscript on a newton message pad.
Whatever I did, I sadly can't write in textbook form, but
it was very meaningful to the newton message pad and made my program
work.

Ordinarily, in oop there are two streams of thought,
the one that writes textbooks and the other intuitive and getting networks
to work!

Croquet, the baby of or at least funded by Alan Kay, the father of oop,
may "integrate" these streams of thought into one "political party".

I am sorry to not be able to "parse" context,
the parsing and runtime worlds aren't yet together for me.

Signal sounds hot as it may have the entendre semaphor,
an obscure thing known with multicore or parallel computing
with threads and such. Semaphore is a difficult concept.
Jumping to pessimistic conclusions, these callbacks may be difficult
and not written for normal human consumption.
However, someone in a movie I like said it is always darkest before the
light.

I wonder what a external call is. I've seen these when you put together
different compiled codes. I believe I see these at link time.
But I think croquet or rather squeak is only one time, run time.
What could external mean? I think that may be seminal, that meaning.

OGLUnixX11LE sounds interesting.

I think I recall X11 as something I put on my system
to go to strange conferences. I had the impression it was some
sort of windowing thing. I recall unix external calls being mentioned
on this list.

I think openGL calls are detailed on man pages in unix and
somehow "belong" to the unix operating system.
Maya and computer algebra maple has unix system calls cost big bucks ;
In the case of Maya $1000's in the case of Maple, expensive upgrades.

OK here's a guess from mac xcode programming.

Alan Kay's prescription (for the oop he fathered) has whereabouts
(platforms)
of objects unimportant. One object tried to signal (send a message to)
another object's (external) code . This failed somewhere in the neatherworld
between intuition and textbook in opp that is croquet.

Can I dig up something better?

I never saw a yellow x .

Syntax of runtime !

LHS is object . after >> is method and arguments (if any)! Looked at this
and found it not quite true.

openGL, as I have experienced it from unix isn't oop with objects,
so when I see OGLUnixX11LE(OpenGL) seems to indicate X11 is oop!

The colons mean before is attribute and after is value
an abstract way of thinking of arguments for a procedure
without making a religion on how they are put onto a stack
(order of arguments unimportant).
Think, for example, initFrustum: as an abstract place that receives
an argument for this X11 argument.

Somehow, the values of arguments are unimportant in an error message. Why?
I suppose their values were not at fault, rather only the interface of the
external
call was known and the error was its implementation or callout mechanism
remained unknown to the "shared brain network".

Everything I said above might be hogwarts hogwash,
but, with the wave of someone's wand,
it might lead to correction and inspiration.

;-)