Beginner's questions on REBOL/Core and REBOL/View
[1/12] from: a::rozek::gmx::de at: 11-Sep-2002 10:38
Good morning!
I downloaded REBOL/View for Win98 yesterday and try to become
familiar with that scripting language now.
Unfortunately, I run into numerous problems which take too
long to solve myself (although they might look really stupid
for a REBOL expert)
REBOL/Core
- error messages do not locate where the problem occurred
but present a very vage description of their orgin only
How can I retrieve the number of the faulty line?
REBOL/View
- how can I (horizontally) align, e.g., a text label within
a window. I tried "right", but the label was still left
aligned. I tried "font: [align: right]" but REBOL didn't
like the "right" in there (writing 'right or "right" did
not have any effect...(well, both together didn't help as
well)
- how can I "center" an image within the area, a layout has
provided?
Thanks in advance for any help!
Andreas Rozek Phone: ++49 (7031) 222305
Bunsenstraße 82 Fax: -
D-71032 Böblingen EMail: [Andreas--Rozek--T-Online--De]
Germany URL: http://www.Andreas-Rozek.de
[2/12] from: petr:krenzelok:trz:cz at: 11-Sep-2002 15:43
[A--Rozek--GMX--De] wrote:
>Good morning!
>I downloaded REBOL/View for Win98 yesterday and try to become
<<quoted lines omitted: 6>>
> but present a very vage description of their orgin only
> How can I retrieve the number of the faulty line?
I hope some more advanced reboller will comment here.
>REBOL/View
> - how can I (horizontally) align, e.g., a text label within
<<quoted lines omitted: 3>>
> not have any effect...(well, both together didn't help as
> well)
I noticed the same problem. In order to get right alignment working,
your face needs to be big enough. E.g. compare following two cases:
view layout [text right red blue "Right?"]
view layout [text 100 right red blue "Right?"]
> - how can I "center" an image within the area, a layout has
> provided?
>
hmm, dunno right now ... there's 'center-face function, but it just
seems to center the window:
view center-face layout [image %some-image.jpg]
maybe you coudl create any kind of sub-layout? Let's hope real View
gurus get in here quickly to help you :-)
Cheers and welcome to rebol-world :-)
-pekr-
[3/12] from: chris:ross-gill at: 11-Sep-2002 9:39
Hi Andreas,
> - how can I (horizontally) align, e.g., a text label within
> a window. I tried "right", but the label was still left
> aligned. I tried "font: [align: right]" but REBOL didn't
> like the "right" in there (writing 'right or "right" did
> not have any effect...(well, both together didn't help as
> well)
Unless you provide a specific width, the width of any style is based on the
width of the provided text. So simply choose an appropriate width:
view layout [
text 300 "Right Aligned" right
]
> - how can I "center" an image within the area, a layout has
> provided?
Not sure if this is what you're looking for:
lay: layout [size 300x300 img: image logo.gif]
img/offset: max 0x0 lay/size - img/size / 2
view lay
- Chris
[4/12] from: joel:neely:fedex at: 11-Sep-2002 9:09
Hi, Andreas,
Welcome to REBOL and the list!
----- Original Message -----
> REBOL/Core
> - error messages do not locate where the problem occurred
> but present a very vage description of their orgin only
> How can I retrieve the number of the faulty line?
>
The short answer is "you can't". One feature of REBOL this
differs from most other programming languages is that the
distinction between "code" and "data" is not relevant. REBOL
can evaluate anything, including blocks that were constructed
as the result of evaluating other expressions. So, in general,
the concept of "source line" simply isn't meaningful.
For example:
a: [b:]
c: [2 + 2]
d: append a c
insert d first [print]
do d
(I'm composing at the keyboard on a borrowed machine, so forgive
me if I make a typo...)
Evaluating the above expressions constructs a new block and then
evaluates that block. If an error had occurred during evaluating
the last expression (the last value of D), how would we have any
concept of "which line" was involved?
Let me emphasize that I'm not criticizing the question, just trying
to show how it depends on assumptions that may be true of other
programming languages, but not of REBOL.
Good luck with your learning, and please feel free to use this list
any time you have questions. I've found it very open and helpful
during my time with REBOL!
-jn-
[5/12] from: greggirwin:mindspring at: 11-Sep-2002 13:26
Sundanda, et al
<< But a longer answer should be "you can't, but Rebol should". >>
But is that feasible, and what would we have to give up in return?
My thinking is more in line with Joel's post on this, though we may be
talking along slightly different lines. I think the concept of a "source
line" isn't nearly as meaningful in REBOL as in most other languages, but
the more hints it can give us about the *context* in which an error
occurred, the better. That's tricky too, because of our ability to create
anonymous functions, rename, rebind, and, basically, create an entirely new
system, on the fly.
I think that REBOL gives us the tools (try, catch, disarm, error?, etc.) we
need to get the job done ourselves. They might be improved over time, but
adding "error handling" is up to us. How much we add, and how we add it,
will depend on the needs of each project. There are those that will add
handlers around every piece of code that could possibly trigger an error,
and there will be those that are happy to let things run until a errors pop
up and then put traps just around those sections. Some will build extensive
infrastructures based on exception handling models in other languages, or
Design by Contract idioms, and some will just say "if error? try [x] [print
{Error!}]".
In a distributed system, whether on the same machine or across the net, many
different models will be needed. How do we test and debug these systems, not
to mention simpler systems, effectively? Those are the problems I want Carl
and the team to think deeply about. I think REBOL allows, if not forces, us
to think in different terms at many different levels.
If it were trivial for RT to add more context information for errors, and no
other side effects came about because of it, I don't think anyone would
complain. We'd just wonder why they didn't do it already. :\
I have lots of "mental baggage" based on how I've done development in the
past, and occasional longings for familiar features and models, but I'm
learning (slowly) to step back and think about whether those things are
really important, or if they only seem that way because they're comfortable.
Carl has given us lots of familiar "road signs" to help us ease into REBOL
as a language, but what really excites me is what happens when I ignore
them. :)
--Gregg
[6/12] from: joel:neely:fedex at: 11-Sep-2002 22:43
Hi, Sunanda, and all,
The problem with small examples is that they're... small. This
sometimes makes things look trivial that really aren't, IMHO.
However, I'm interested in your opinions of the constructive
suggestions near the end...
[SunandaDH--aol--com] wrote:
> ... Rebol gives far too little away when there is an error --
> maybe Carl S doesn't make stupid coding errors like the rest
<<quoted lines omitted: 3>>
> ** Math Error: Attempt to divide by zero
> ** Near: print b: 2 / 0
...
> Better context information *is* in there somewhere -- try this:
> the same error in a VID action facet:
>
> unview/all
> view layout [
> button "click me"
> [
...
> ]
> ]
<<quoted lines omitted: 9>>
> ]
> ** Near: print b: 2 / 0
Note that this shows quite a bit of stuff that appears nowhere
in our source code: the
func [face value][
bit, as well as the block to which A is being set. This would
also be likely to confuse the typical beginner IMHO.
However...
Let's try that in Core (or at least the moral equivalent...)
>> crash: func [/local a c d] [
[ a: copy [b:]
[ c: [2 / 0]
[ d: append a c
[ insert d first [print]
[ do d
[ ]
>> crash
** Math Error: Attempt to divide by zero
** Where: crash
** Near: print b: 2 / 0
Notice that middle line
** Where: crash
which actually tells us where to look for the expression which
caused the math error. If we define and use reasonably small
functions, this narrows our scope quite a bit. Going further,
we can actually reproduce your more verbose case, as follows:
>> do func [/local a c d] [
[ a: copy [b:]
[ c: [2 / 0]
[ d: append a c
[ insert d first [print]
[ do d
[ ]
** Math Error: Attempt to divide by zero
** Where: func [/local a c d][
a: copy [b:]
c: [2 / 0]
d: append a c
insert d first [print]
do d
]
It appears that REBOL is trying (in all cases???) to show us the
exact structure/expression being evaluated when the math error
occurred. It's just that this second case involves a larger
expression, perhaps.
While I might agree that more detailed information would be
helpful, I still maintain that it doesn't relate to "source line"
in many cases. I haven't had time to play with the preprocessor,
but I suspect the concept of "source file" becomes even more
obscured when we #INCLUDE source from multiple places (especially
when nested...)
If we change the example just a bit more, we can get a case for
which source file concepts just don't apply at all.
crash-setup: func [i [integer!] j [integer!]] [
append copy [print] reduce [i to-word "/" j]
]
random-range: func [dn [integer!] up [integer!]] [
(random up - dn + 1) + dn - 1
]
crash-prep: func [
n [integer!] lo [integer!] hi [integer!]
/local result
][
result: make block! n
loop n [
append/only result
crash-setup
random-range lo hi
random-range lo hi
]
]
crash-wrapper: func [
n [integer!] bottom [integer!] top [integer!]
][
foreach item crash-prep n bottom top [
do item
]
]
crash-wrapper 20 0 5
Evaluating the above yields a nice puzzle:
...
>> crash-wrapper 20 0 5
1
4
0
0
3
1.5
0.333333333333333
1.66666666666667
5
1.5
0.5
2
2.5
1.25
0.333333333333333
** Math Error: Attempt to divide by zero
** Where: crash-wrapper
** Near: print 4 / 0
My first question is this: What more could REBOL tell us at
this point? We're told that the problem occurred during the
evaluation of CRASH-WRAPPER, but the body of that function
has little to do with the actual expression being evaluated
at the point of error.
My second question is: How much responsibility do I have as
the programmer for detecting and managing errors that may arise
during evaluation?
REBOL is a very powerful language, but with increased power must
come increased responsibility. For example, I could have done
some more work to handle errors myself:
crash-wrapper2: func [
n [integer!] bottom [integer!] top [integer!]
/local risky-blocks
][
foreach item risky-blocks: crash-prep n bottom top [
if error? try [
do item
][
print [
"Error DOing" mold item newline
"within" mold risky-blocks
]
halt
]
]
]
crash-wrapper2 20 0 5
which certainly gives me more context to think about:
>> crash-wrapper2 20 0 5
3
4
5
0
Error DOing [print 4 / 0]
within [[print 3 / 1] [print 4 / 1] [print 5 / 1] [print 0 / 1]
[print 4 / 0] [print 2 / 3] [print 1 / 0] [print 3 / 4]
[print 5 / 3] [print 2 / 2] [print 3 / 3] [print 1 / 2]
[print 4 / 2] [print 3 / 2] [print 4 / 5] [print 0 / 4]
[print 0 / 1] [print 4 / 3] [print 4 / 5] [print 1 / 5]]
Now let me suggest a couple of possibilities:
1) Could we (the list community) describe any additional context
information which RT might be able to add to error messages?
For example: I suspect that REBOL internally has some sort
of representation for all expressions pending evaluation (the
moral equivalent of a "stack", for example). Would it be
useful/feasible for an uncaught error to dump some portion
of that information to the console? Having a more thorough
view of what was going on might help the programmer locate
and diagnose an error, but we might want some way to control
the amount of information displayed (have you ever seen a Java
stack trace, for example... ;-) such as limiting the number of
levels to be displayed by setting a system variable.
2) Could we (the list community) define "safe" equivalents to some
of the more common error-prone operations (e.g. DO, FUNC, ...)
so that one could write and test code with the training wheels
on?
For example: A paranoid SAFE-DO accepting a block or function
as its argument could check for errors during evaluation and
dump the block or function to the console if something went
wrong. A SAFE-FUNC could wrap its argument in a try block to
dump the arguments to the console in case of an error.
I could even imagine a SET-SAFE and SET-UNSAFE word pair that
would redefine DO and FUNC and etc. to be the checked or un-
checked versions, so that the same source could admit both
checked (but slower) and unchecked (and faster) evaluations.
-jn-
--
; Joel Neely joeldotneelyatfedexdotcom
REBOL [] do [ do func [s] [ foreach [a b] s [prin b] ] sort/skip
do function [s] [t] [ t: "" foreach [a b] s [repend t [b a]] t ] {
| e s m!zauafBpcvekexEohthjJakwLrngohOqrlryRnsctdtiub} 2 ]
[7/12] from: jason:cunliffe:verizon at: 11-Sep-2002 23:03
What do you suppose RT use to debug?
./Jason
[8/12] from: al:bri:xtra at: 12-Sep-2002 17:49
Sunanda wrote:
> -- Much better context on the error. How about the last 50 words in the
near
statement.
Eeek! I don't want that! Some of my code when it blows up produces way more
than 50 words already! Sometimes full screens!! That's because it's deeply
nested in blocks and (usually) being constructed.
> -- I'd be happy for there to be a debug version of Rebol.
Actually, I'm almost sure that some people on this list could write a single
stepping and debugging version of Rebol, using 'do/next and 'load. I think I
could, but I've got no spare time and I'm getting enough debug information
at the moment, by using some XP techniques (like repeated code and test).
Andrew Martin
ICQ: 26227169 http://valley.150m.com/
[9/12] from: anton:lexicon at: 12-Sep-2002 20:23
Andrew, what does XP stand for?
Anton.
[10/12] from: petr:krenzelok:trz:cz at: 12-Sep-2002 12:32
Anton wrote:
>Andrew, what does XP stand for?
>
Extreme Programming? Kind of a special aproach to programming?
-pekr-
[11/12] from: atruter:hih:au at: 13-Sep-2002 10:02
> what does XP stand for?
eXperience (WindowsXP) ; I think they got the *experience* bit
down pat
eXtreme Processing (AthlonXP) ; how many degrees does *extreme* equate
to?
eXtremely Portable (RebolXP) ; just for fun, as everyone else is doing
the XP thing nowadays
Regards,
Ashley
[12/12] from: joel:neely:fedex at: 13-Sep-2002 6:46
Hi, Ashley,
XP = eXtreme Programming
Has been for years.
see http://www.extremeprogramming.org/
http://www.xprogramming.com/
[atruter--hih--com--au] wrote:
> > what does XP stand for?
>
> eXperience (WindowsXP)
>
Building on a well-established record of stealing ideas (and
even code), the behemoth of Redmond now stoops to stealing
and redefining acronyms.
;-)
--
; Joel Neely joeldotneelyatfedexdotcom
REBOL [] do [ do func [s] [ foreach [a b] s [prin b] ] sort/skip
do function [s] [t] [ t: "" foreach [a b] s [repend t [b a]] t ] {
| e s m!zauafBpcvekexEohthjJakwLrngohOqrlryRnsctdtiub} 2 ]
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted