World: r3wp

There are other methods of debugging at runtime if you have the source. 
Heck, even good old print statement debugging would work.

it could be simulated with a special mezz. A function which executes 
an indirect DO on one code block instead of building a function.

So that the code block could still be inspected by a debuging tool.

hum... maybe a way to build a context when building a function, with 
the index of each member of the body block mapped out to its original 
source.

yep it should work

then the debugger could inspect the context instead.

Right, and that kind of thing works now. But allowing a debugger 
to get past the protections just isn't going to happen. We don't 
have a way to know at runtime which person needs to be asked for 
permission to break past a protection like that. Since it certainly 
isn't the user.

you will just have to furnish mezzs to replace the standard, func, 
funco and funct

we could be able to do this by switching to a "debug" version of 
the various func creating mezz

Yes, and replace those functions before the system is protected to 
support the reset.

we could even make those functions able to trigger events based on 
"break points"  then listen on those events in a normal event loop.

so the debugger actually adds a line of code where the break should 
happen... then rebuilds the body block it executes when its called.

They could even be trace events.

since the external function isn't replaced, its transparent .

Pekr - "if we can't have full fledged debugger, then we are crap 
:-)"

Agreed, though maybe not complete crap.


Brian - "Heck, even good old print statement debugging would work."

Agreed, to an extent.

Brian - "They could even be trace events."


Ahhh, joy. What can we learn from DTrace, and what should modern 
debugging look like? I have, at times, ached for the ability to step-trace 
and set break and watch points in REBOL. At the same time, I don't 
want to be myopic and focus on how we debugged in the past.


What are the best ways to debug the things we're supposed to build 
with REBOL? And can we hope for mechanisms to let us debug things 
outside what RT says REBOL is targeted at?

using replacement function builders we could, in theory, completely 
control how execution occurs.  this would be at some speed cost and 
possibly not 100% transparent.


but setting break points and real-time value watching is definitely 
in the realms of possibility.

I just don't want to preclude the use of R3 in the biggest industry: 
content delivery and presentation.

Or for that matter, any secure client systems. Most cryptographic 
security is based on secrets. If we can't keep secrets, we can't 
be used for those purposes.

Other secure systems are debuggable

As is R3, just using different methods. You might notice that DTrace 
doesn't allow you to read the iTunes process on OSX.

Not everyone is on the board of Disney

Secure systems can be debuggable. But security comes first.

Especially when there are other methods for debugging that don't 
require breaking security.

Are all the "^M"s below because of datatypes not implemented yet 
or is this a bug? I'd expected READ/STRING to not only TO STRING!, 
but to DELINE the data read.

>> sql: read/string clipboard://
== {create table scans (^M
               id     serial primary key,^M
               date   date not null,^M
               time   time(3) not null,^M
               job    integer not null, ^M
               branch integer, ^M
               ean    char(13) not null,^M
               box    integer^M
          )}

IIRC, READ at one point only returned the data read as a binary stream, 
forcing you to DELINE TO STRING! READ ... because of the transition 
to UTF-8, but /STRING was added back later. Found nothing in the 
change log, though.

How can I remove key form map! ?

set it to none

Hm, it's easier than I though :) Thanks

Any comment onto R3 now displaying security dialog each time it starts? 
Do we have some non-standard exe being generated by hostkit? This 
symptome is not happening with A99 IIRC ...

The clipboard:// type returns a string without line ending conversion, 
at the moment. It hasn't been updated since before the /string refinement 
was added. It's a platform-specific bug.

I've got this unexpected R3 behaviour (it's the core of the LDS issue 
mentioned in [Testing and Tools]

    f: func [] [error? try [return 1] return 2]
    f
    == 2   ;; r3 does this....despite no error
    == 1   ;; r2 does this...as expected

Any ideas, thanks!

Yes, this is CC #771

Carl intents to correct it, but it will not be in A108

Now you have to circumvent it, at the cost of having longer code. 
I suppose, that the not simplified code is more like:


f: func [] [error? try [do-something return 1] return 2], which can 
be transformed to:

f: func [] [return either error? try [do-something] [1] [2]]

Thanks...Glad to know there are work-arounds.

Sure, this is not that hard to circumvent, but it comes at the cost 
of needing to "reorganize" the code

Does R3 somewhere have the equivalent of
   READ/CUSTOM .... [POST...]
yet?
I'd like to read a URL as a POST rather than a GET.

Yes it does

looks like Carl will not only be attending Amiwest, but exhibiting 
as well.

Thanks Graham....Now, can I have a clue what the equivalent is!?

Henrik - what is he going to exhibit? R3 on Amiga? Or R3 in general?

Don't know. He is just listed as an exhibitor. Maybe he'll bring 
wine. :-)

I think he'll try to peddle is "rare" Amiga items...   ;-)

result: write http://yourhost.com/cgi-bin/myscript.cgi{Posted data}

See http://www.rebol.net/wiki/Scheme:_HTTP

Thanks Graham.
Initially, that sounds lllogical -- doing a write to read a URL.

But I guess it makes sense -- as POST is supposed to cause an update 
action of some sort at the server end.

I'm not sure of the logic .. I would think that 'write should be 
used for non idempotent actions but that's not how it is done.

Anyway, 'read is a straight 'GET and write allows custom headers

I always thought HTTP GET is incredibly anti-intuitive when used 
to send form data. Mapping write to POST feels a lot more logical

I haven't looked to see how it handles PUT, and DELETE with parameters

now whether PUT can stream a file off the filesystem