home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / sys / amiga / programm / 19179 < prev    next >
Encoding:
Internet Message Format  |  1993-01-25  |  5.1 KB
  1. Xref: sparky comp.sys.amiga.programmer:19179 comp.sys.amiga.misc:20468
  2. Path: sparky!uunet!gatech!usenet.ins.cwru.edu!magnus.acs.ohio-state.edu!bgsuvax!uoft02.utoledo.edu!jupiter!mneylon
  3. Newsgroups: comp.sys.amiga.programmer,comp.sys.amiga.misc
  4. Subject: Re: Strange wierdness in E-language!
  5. Message-ID: <1993Jan25.205721.1282@uoft02.utoledo.edu>
  6. From: mneylon@jupiter.cse.utoledo.edu (Michael Neylon)
  7. Date: 25 Jan 93 20:57:20 EST
  8. References: <1993Jan25.160550.9255@abo.fi>
  9. Nntp-Posting-Host: jupiter.cse.utoledo.edu
  10. Lines: 132
  11.  
  12. MSAASTAMOINE@FINABO.ABO.FI (Mika Saastamoinen Tkkk) writes:
  13. : 1st of all, there's something strange about the IF-THEN-ELSE statement: the
  14. : following statement is supposed to plot a pixel on screen if its coordinates
  15. : (sx,sy) are within given bounds (LFEDGE,RGEDGE,TOEDGE,BOEDGE) (ie. it's a sort
  16. : of primitive clipping thingy):
  17. : 
  18. : IF ((sx>LFEDGE AND sx<RGEDGE) AND (sy>TOEDGE AND sy<BOEDGE)) THEN Plot(sx,sy,2)
  19. : 
  20. : Now then, guess what that did? It plots the pixel no matter what the coordina-
  21. : tes are! And yes, I did check those boundary values, which were defined in 
  22. : CONST statements, and they were correct! The funny thing is that when I conver-
  23. : ted my test program to C, the above if-statement worked correctly, ie. clipped 
  24. : the pixels within the boundaries! Now is this strange or what?
  25.  
  26. I would say that the lack of precedence is screwing this up.  You need more
  27. parens (unfortunately)...try the following...
  28.  
  29. IF ((sx>LFEDGE) AND (sx<RGEDGE) AND (sy>TOEDGE) AND (sy<BOEDGe)) THEN blah...
  30.  
  31. (Note that I have removed a few parens as well ;).
  32.  
  33. : 
  34. : Another thing was this: 
  35. :     This statement works:               IF tz<0 THEN...
  36. :     This statement crashed my machine(!): IF (tz<0 AND tz>-300) THEN...
  37. : The 'tz' was used in a formula like this inside the IF-block: 'sx:=tx/tz' and
  38. : it caused the guru..ehm... software failure #80000005 (I think)... Wierd?
  39. : Again, the latter if-statement worked correctly in the C-version and did NOT
  40. : cause any gurus...
  41. : 
  42.  
  43. Again, lack of precedence screwed this up....The compile sees this as...
  44.  
  45. IF (tz<0 AND tz>-300) THEN ...
  46.     ^  ^  ^   ^   ^
  47.     1  2  3   4   5
  48.  
  49.     1. tz.  No prob.
  50.     2. tz is less than 0, fine no prob.  Let this return 1.
  51.     3. The result of (tz<0) AND the next value (bitwise op)
  52.     4. Now if tz is less than 0, then a bitwise operation will probably 
  53.     crash the computer.
  54.     5. It then takes the result of the bitwise op and tests it against  >-300.
  55.  
  56. A better arrangment will be
  57.  
  58. IF ((tz<0) AND (tz>-300)) THEN ...
  59.  
  60.  
  61. : A third thing concerns the SELECT-ENDSELECT-statement. Consider this:
  62. : 
  63. :     blablabla...
  64. :     ...class:=WaitIMessage(w)...
  65. :     SELECT class
  66. :         CASE IDCMP_RAWKEY
  67. :             code:=GetCode()
  68. :             SELECT code
  69. :                 CASE $45 /* esc */
  70. :                     blabla...
  71. :                 CASE $4d /* cursor down */
  72. :                     blabla...
  73. :                 CASE ...
  74. :                     etc...
  75. :             ENDSELECT
  76. :         CASE IDCMP_INTUITICKS
  77. :             blablabla
  78. :     ENDSELECT
  79. :     blablabla...
  80. : 
  81. : Now, the wierd thing about this is that the program's execution never got
  82. : to the IDCMP_INTUITICKS-part (yes, I did have the IDCMP_INTUITICKS-flag in
  83. : the OpenW()-function's parameters!)!!! Also, it never got to IDCMP_RAWKEY's
  84. : cases beyond the $4d (cursor down)!!! When I changed the order of the rawkey-
  85. : cases, it still didn't get past the first two! Ie. in the above example,
  86. : the program only reacted to the esc- and cursordown-keys (and yes, I did have
  87. : all the rawkey-codes correctly!) The above routine worked only when I dumped
  88. : the SELECTs and used IF-ELSEIF-ENDIF instead:
  89. : 
  90. :     ...
  91. :     IF class=IDCMP_RAWKEY
  92. :         ...
  93. :         IF code=$45 ...
  94. :         ELSEIF code=$4d...
  95. :         ELSEIF code...
  96. :         ENDIF
  97. :     ELSEIF class=IDCMP_INTUITICKS
  98. :     ELSEIF class...
  99. :     ENDIF
  100. :     ...
  101.  
  102. I have a feeling that E does not quite handle nested SELECT-CASE statements
  103. well.  Now it also seems that the above IF structure is very messy, so I
  104. would recommend the following....
  105.  
  106.     SELECT class
  107.         CASE IDCMP_RAWKEY
  108.             HandleRawKey()
  109.         CASE IDCMP_INTUITICKS
  110.             HandleTicks()
  111.     ENDSELECT
  112.  
  113.     ...
  114.  
  115.     PROC HandleRawKey()
  116.         ...
  117.     ENDPROC
  118.  
  119.     and etc..
  120.  
  121. This should inprove your performance, and can make editing much easier (
  122. ie, I can easily rewrite the Rawkey handlers).
  123.  
  124. : E looks like a promising language, but I think I'll still stick with C, since 
  125. : I can at least understand how it works... Also, as many others, I too don't 
  126. : like the one-source-file-philosophy of E, nor do I like the (upper)case-
  127. : sensitivity of it. Other than that, it's quite easy to program the Amiga with 
  128. : E, provided that the above mentioned wierdnesses are inside my head (and my 
  129. : Amiga)... ;)
  130.  
  131.  
  132. As I wrote someone else, the above faults in E are made up for speed in
  133. the compiler.  For someone just begining in Intuition programming, this
  134. is a great language to learn in, and to do a minor adjustment of the 
  135. interface, it only requires a small change in the code, and a few SECONDS
  136. of compile time (on a unaccel. 500!!!)
  137.  
  138.  
  139. -- 
  140. Michael Neylon   aka Masem the Great and Almighty Thermodynamics GOD!
  141.       //         | Senior, Chemical Engineering, Univ. of Toledo
  142.   \\ // Only the |   Summer Intern, NASA Lewis Research Center
  143. \  \X/   AMIGA!  |         mneylon@jupiter.cse.utoledo.edu           /
  144.