World: r3wp

I swear, all I hiot was the 'enter' key.  And Kazaam ... there was 
my clipboard up in public.... at least it was that Rebol VID script 
... ; - )

LOL...

RobertS: try pastebin, it even lets you show diffs as you make new 
versions of a snippet!  http://pastebin.com/

These days on IRC people who post more than 5 lines of code in a 
chat channel get banned.  They're none too friendly about it.  :)

Ah, ok, was an accident.  Still, useful tool.  :)

Some Smalltalk have 'clipboards'  that stack CTRL-c so you can go 
through your last clips ... almost replaces the history in a REPL 
; - )

fork  ...  I offer rlwrap in return  http://utopia.knoware.nl/~hlub/rlwrap/man.html
  as a wrapper for readline which I call from Smalltalk when there 
are PTY issues with some cmd line tool.  Almost as useful as the 
unix screen cmd ; - )

rlwrap + pipes  can be used to wrap even Rebol core for those who 
refuse to use View while waiting for a DLL/so

Thanks Robert, I would have to see it in action to truly understand 
the usefulness.  And on that note, here's another good tool, Jing: 
http://jingproject.com

You can easily capture and share short videos of the demonstration 
of tools-in-action

Okay, new question, I will ask many... :)  I am trying to write a 
new version of an assert macro which is able to do "location-parameterized-assertions", 
similar to what I describe in this article:http://hostilefork.com/2005/05/01/location-parameterized-assertions/

I have gathered that I need to find a way for the caller to pass 
in the required information, e.g.

assert system/script/header length? array > 3

I'd like a shorthand for this which evaluates the expression in the 
calling context, and I'd also like to know the line #...

So I'm willing to write: assert FOO length? array > 3

I seek  FOO: f(system/script/header) which would help me do this, 
and also what it would take to get the line number of this specific 
instance of FOO

It would be nice if I could somehow do this without the FOO helper... 
so if REBOL has some magic to reflect the call stack and pick out 
the necessary information that would be nice.

REBOL is not so big on line numbers.  Even when you look at http://www.rebol.net/cookbook/recipes/0042.html
which is Carl's source parser, and added a line number tracker, it 
won't be accurate as a multiline comment (embedded newlines) counts 
as one source entity to LOAD.  I think the best you could really 
hope for is an offset into the sources at the start of a entity. 
 REBOL scripts do not require any newlines to function properly. 
 But aain, an index?  into the sources would work.   Brian;  Always 
take my squawking for what it is, someone that thinks he knows but 
knows he doesn't, yet still wants to help.  :)

R2 can't do much with the call stack.
R3 promises more, eg:
http://www.rebol.net/r3blogs/0011.html

and
http://www.rebol.net/r3blogs/0075.html

Stack looks useful... though as I mention in my article I sort of 
feel that it's dangerous to do it that way, and am ok with narrower 
contracts

Erm... I still can't quite figure out how to conveniently get my 
assert routine to access the system/script/header from the caller, 
without writing:

assert system/script/header 1 != 0

I'd like some shorthand FOO so I don't have to type system/script/header 
each time, so I'd settle for:

assert FOO 1 != 0

But if FOO is a function that lives in debug-functions.r then I'd 
need some parameter trick to access the calling context, the way 
bind uses a known-word for example.  Is that the case?

That won't work, even if you specify system/script/header at the 
call site, unless your assert statement is run during the execution 
of the script in question. Once a function is loaded, its source 
is gone - system/script/header refers to the currently running script. 
The only way to get your assert system working is with a preprocessor.

Ah, well, I was thinking of doing that anyway.

REBOL doesn't have declarations - it has expressions that build functions 
and assign them to variables at runtime.

You might consider extending prebol.r from the SDK - it has all of 
the preprocessing infrastructure built in. All you would have to 
do is add a #assert directive that would be replaced at preprocessing 
time with the info you want to log.

An option I considered was a refinement to assert, called /loc (for 
location) and let you pass in an identifying string for that assert. 
 Then, a tool which goes through all the asserts in the code and 
if it doesn't have a location, add the refinement and a parameter 
based on a GUID.  It will also make a database of file/lines for 
each location.  Thereafter programmers can move them around without 
much trouble.

Does R3 have guid! ??

You can make your own using binaries or strings, but nothing built 
in.

Yet - user-defined datatypes aren't done yet.

In your case, filename, line and position on the line would probably 
be sufficient.

Brian (fork); :)  Check out rebol.org - pager.r for an attempt I 
made at keeping track of source line numbers. Again, some REBOL scripts 
are built without newlines.  Best to keep index? values.  imho.  
It's what I use for the word cross referencer I'm working on  (forth 
style locate and tour)

As far as I can figure, the only things in REBOL that cares doodle 
about newline is; the semi-colon comment, that newlines are retained 
in multi-line braced strings (and kinda in blocks)  and  a newline 
breaks a quoted string.

You can just call me Fork, that's fine, no offense taken.  :)

Seems to keep things clearer... and I can feel all hacker elite to 
be one of the few on here with a handle.  :)

Only add fork that time as this is a three-way Brian chat.  :)

--[[  a Lua multi-line comment  --]]   but adding a hyphen   as in 
---[[  lets the commented block run and the --]] can remain in place 
as both bookends are now just -- single-line comments; really quite 
clever.  Rebol could use ;{  and ;}  where ;;{ opens up the 'commented' 
lines  to run (not a block comment  at that point) but leaves the 
'markers' in place until debugging or profiling or unit test or whatever 
is completed;

dumb question:

>> a: make object! [b: 'c]
>> mold a
== "make object! [^/    b: 'c^/]" ; c is lit
>> mold/all a
== "#[object! [^/    b: c^/]]" ; c is not lit


I guess the question is why c is not lit for MOLD. It means that 
when you probe an object , words in an object appear lit, when they 
are really not. (Are they?)

sorry, it should be "why is c lit for MOLD"

make evaluates the object spec block. Therefore, the lit-word is 
transformed into a word.

mold/all, on the other hand, does not evaluate the object spec block.

compare
	probe load mold a
	probe load mold/all a

They both load the same.

in your first reply, did you mean "mold evaluates the object spec 
block"?

no, I definitely meant make.

Try this:
	make object! [a: 1 + 2 print "hello"]