AltME groups: search

All new RebDB v3 released for REBOL3. To take it for a spin, try 
this:

import http://idisk.me.com/dobeash/Public/rebdb.r
help db-
test: db-load http://idisk.me.com/dobeash/Public/test.bin
help test
sql select test


Extensive documentation in the works (within a week) ... actually 
a large part of the doc deals with db design [from my POV] covering 
off on the trade-offs with fixed vs variable length records/fields, 
typed vs untyped columns and RAM vs speed optimization. Needless 
to say, I think I've got the balance about as good as is possible 
with pure REBOL mezz code. This has been a long time in the making 
...

(From Ashley on 5-Feb-10:)

All new RebDB v3 released for REBOL3. To take it for a spin, try 
this:

import http://idisk.me.com/dobeash/Public/rebdb.r


when I try this I get an access error - reason: "not found or not 
valid"


Has RebDB v3 moved to a new location ?  Thanks!  Cannot wait to try 
it out.

if i do a commit *, then the replay.bak won't exist, but the server 
will still try to execute the session.log, which results in fractional 
changes:

Point of information;  Due to some confusion with Bob's fuzzy Rules 
of Order and to try and keep in the spirit, Brian Hawley will also 
be included in the list of nomincations, unless someone announces 
dissent before Dec 15th.

Can't see anything wrong with your prefs data nor in the prefs saving 
code. Your current default project is "All Projects", selecting R3 
project in the droplist, then going to Profile and hitting "Set default..." 
button should work, can you try it again?

I'll try logging out and seeing if that makes a difference. Maybe 
the session expires and then on this local machine (also runs the 
services), it needs the service restart.

After a few attempts playing with expired sessions, I can't reproduce 
your issue with the latest SVN revision. Try to run Cheyenne in verbose 
mode using : -vvv as command line argument and send me the log chey-* 
log file once the error happens.

Can you try with a different browser?

Sunanda: you can use tabs now to indent your code, they will be rendered 
as 4 spaces. Inserting <pre> tags is possible, I'm making a quick 
try at adding it right now.

did you try in A108 ?

if you give me an A108, then i'll try

so how should i try A108 then :) ?

James: could you try to delete all the cookies on your remote browser 
when you see that error, then try accessing CureCode server again.

nope.  good point... I try that...

I try to not do this all the time as it gets tiresome, and at some 
point the UI problem will be fixed.

That is exactly what I'm telling you. I'm merely asking you to try 
to think for a moment from the perspective of the users you're asking 
to report issues, instead of your own perspective

:-) Good to know... let's try if I remember my password.

Doc, I still have issues with the cookies created from Curecode. 
Essentially, when I leave the browser open and the session expires, 
the next time I try to use curecode, it loads up the error page. 
I just manually delete the cookie and I'm good and I have extended 
the timeout as well which helps. I was wondering in the httpd.cfg 
file if there is any value for curecode's timeout that will make 
it endless (perhaps "none" ? ). Thanks. It is a very usefule app.

the next time I try to use curecode, it loads up the error page.

 Could you be more specific? On what page do you let the browser open? 
 What do you do when you resume your work after the session expires 
 (on what link/button do you click)?

I see, will try.

Try with ls -laR | grep sessions while Cheyenne is fully stopped.

I guess the first thing is to try and get them to the level of the 
r2 schemes in terms of user use

Graham, instead of
    write imap-port [ dialect stuff ]
    wait [ imap-port timeout ]
could you try:
    write imap-port [ dialect stuff ]
    read imap-port
    wait imap-port
I think that should work.

If I find anymore I'll update the wiki 
Andreas, going to try that now.

Maybe I did something wrong ... perhaps someone else can try it

Gabriele, thanks for the clarification. I'll give it a try over the 
weekend.

in prot-http.r, in http-awake function, there is a switch statement

res: switch state/state


try adding a switch/default instead

and use 'none for the default to see what happens

I guess I should try that ... sending a length

I'm missing what is the point?  the network schemes are written to 
try and emulate file io ...

OK thanks I'll try my own, anyway is there any distinction if fileport 
is open/closed? after close the information is still open

For RIF more suitable names would be PUT/GET as in basic key-value 
stores (memcache f.e.) I can try this convention

OK I'll try to finish simple rif:// scheme and update rif.r in rebol.org 
thanks guys for hepl! Documentation should be improved in file schemes, 
there is almost nothink.

ok i'll try to understand :-(
my scheme works used port: open rif:// ... read/seek port 1

but don't work the easy way: read rif://data/file 1, cant access 
locales

OK I'll try it

try to open the port at first
and then call your read function with it

OK lets try it better, thanks guys for lesson learned!

Pavel, you were right the first time in trying to implement GET/PUT 
actors, but you got the names wrong. Try again with PICK and POKE.

when I try to evt: make event! [type: 'custom code: 1] I got: 
== make event! [
    type: 'custom
    offset: 1x0
]

ie code dissappears and the value is merged into offset curiously 
is it intended?

Try core ...

you might try with con: open console://, but dunno how to proceed. 
Nor insert nor write works on that port ...

I'm just saying this to try and explain what I mean

I was wanting to try R3 again, but the download link isn't working....

If you agree with me, what about writing a small letter to Carl explaining 
our desire ? If many developers sign this letter we could try to 
convince him to make this step once R3 will go to beta.

try clicking the red box on the upper right corner

but i am not a guru in Rebol. and for me it is important to try to 
do this application to learn & to show the best practicies in R3, 
with the help of some guru ;-)

Start is a cmd.exe builtin command on Win2k+ (not Win9x). Try call 
"cmd.exe start textpad" or calling Textpad directly.

try a rejoin using two binary values.

Ah, special mode parsing ... you try to get block of lines, correct? 
I wonder if using some parse rules instead would show so much of 
a difference between R2 and R3?

just try my example

let's try to compare following for R2 vs R3: 


 parse "abc^/def^/ghi^/" [start: any [end: newline (print copy/part 
 start end) start: | skip]]

try running following code:

c: ""
 for i 0 255 1 [append c to-char i]

I get a beep here ....

ie. try print "^(07)"

OK, I will try ...

hi, would like to know why have this error want i try to import a 
file in R3.

i try to use rebDB3.r from Ashley

Ashley try using length? head p

It is not for us to say how severe an error is, short of a system 
crash; that is up to the programmer. The SECURE system can declare 
some things as being allowed or not. For the rest, use TRY/except 
and check the error code in the exception block, and retrigger the 
error if it isn't something you can handle.

bug#1437 was more likely, but try making the suggestion of an additional 
datatype in the other. Watch out though, since there are many tickets 
that are still current since we (mostly Carl) haven't gotten around 
to going over them yet.

As for your first question, try a lit-word parameter like this: my-funct: 
funct ['parameter]...

Try this:

join ["some string"] words-of ...

when i but new_word into a file new_word.r and test_mod into test_mod.r 
and i try to import them

I think i will change again some habits in the way I code.


It seems that the try/except idiom has better perfs than EITHER if 
you use it  that way:
>> try/except [...frequent case...][...rare case...]

Try this and give me your results...

f1: funct [v][either zero? v [0][1 / v]]
f2: func [v][try/except [1 / v][0]]

print dt [loop 100000 [f1 1]]
print dt [loop 100000 [f1 0]]

print dt [loop 100000 [f2 1]]
print dt [loop 100000 [f2 0]]

Wow, I never realized what overhead TRY/except has, but that overhead 
seems to be fixed. As long as you can safely run until an error without 
having to roll back changes, that could be a good strategy. Sticking 
to the R3 safety model (generating errors before it matters with 
functions like ASSERT) you can make code that runs faster in the 
default case, and safely always.

But we can't check anymore for the type of the last happend error 
with try/except.

>> try/except [1 / 0][error? probe system/state/last-error]
none
== false.

it's a problem, we can't have an accurate process error handler.

I think it's a missing feature (or the error is somewhere else in 
the system object).

>> f1: funct [v][either zero? v [0][1 / v]]
>> f2: func [v][try/except [1 / v][0]]
>> print dt [loop 100000 [f1 1]]
0:00:00.063264
>> print dt [loop 100000 [f1 0]]
0:00:00.044331
>>
>> print dt [loop 100000 [f2 1]]
0:00:00.050118
>> print dt [loop 100000 [f2 0]]
0:00:00.124219
>> print dt [loop 100000 [f2 0]]
0:00:00.121766

As parse rules go, it wouldn't be difficult. Try this:
>> hex: charset [#"0" - #"9" #"a" - #"f" #"A" - #"F"]
== make bitset! #{000000000000FFC07E0000007E}

>> parse a: "paul%40tretbase.com" [any [to "%" [b: skip copy x 2 
hex (b: change/part b to-char first debase/base x 16 3) :b | skip]]] 
a
== "[paul-:-tretbase-:-com]"

Now that is a modifying method, but it should be easy to adapt that 
to a copying method.

I've given it some more thought and think I have combined two issues 
that could better be dealt with separately:

1. TRY and ATTEMPT as ways of protecting my code:

Generally, the current behavior is surprising but in most cases acceptable.

It is rare that something as stupid as attempt [exit] would make 
it to production status. So, in many cases  no problem. [perhaps 
an odd problem if my app is generating code (eg a genetic algorithm). 
But knowing the problem, that could be guarded against]. 

2. TRY and ATTEMPT for protecting arbitrary code

As Gregg suggests, that needs a careful, systems-level design to 
get right and to make robust. REBOL3 offers some help (SECURITY policies, 
ATTEMPT, TRY, CALL) but isolating code into a safe sandbox, and recovering 
from any possible error/lapse/attack is not something the language 
alone can provide.


Still, making TRY and ATTEMPT fully predictable [succeed or return 
an ERROR] would be most welcome!

The trick, Sunanda, is that the code that you want ATTEMPT to catch 
isn't actually erroneous. EXIT itself never generates an error - 
it basically is like a fancy goto that has to be caught by a handler. 
However, the handler can trigger an error (the one that you see) 
if the goto supposedly isn't handled; actually, all such goto functions 
are always handled and never cause an error directly, it is the handlers 
that cause the error.


The problem is really one of perception: Code that you think is erroneous 
(but isn't) is not triggering errors (and shouldn't), and the code 
that is triggering the error is not actually inside the code block 
that you are passing to TRY or ATTEMPT. Perceptual problems are tricky 
- either you have to change your perceptions, or rewrite the basic 
semantics of the language. Which is easier in this case?

I guess ATTEMPT is no longer an extension of error? try like in R2.

I think I can answer my own question about executing arbitary code.

Just tried the ancient error? try technique:

   error? try [break]  ;; I'm happy
   attempt [break]   ;;  still think this is a bug!

ATTEMPT and TRY push a handler for exceptions with codes over 100 
on the task-local handler stack. Those exceptions are generated by 
DO MAKE error! (or code called by natives with the same effect).

Brian, I agree with you.  I think if we make Try or Attempt handle 
these other exceptions then we are going to slow things down.  Again, 
we have  a way to handle this now.  No need to pursue the problem 
at this point.

Thanks for the repeated attempts to explain, Brian!

For me, the work around is:
    error? try [....]
That seems to work in all cases I have tried.


[Ironically, 99% of all the REBOL code I have ever written uses ERROR? 
TRY --  ATTEMPT did not exist when I started REBOL, and my fingers 
have learned to type the idiom. It's only with R3 that I'ved tried 
to update my error handling.....Seems I should stick with my older 
ways for a while...:)]

Sunanda, that error? try [....] code you keep mentioning doesn't 
work in all cases you mention. The problem is this:
>> error? break
== true

This is an error (bug#771 and bug#862): It should not return true, 
it should break and then later on trigger an error for an unhandled 
break. To illustrate why:
>> loop 1 [error? break 'buggy]
== buggy

That should have returned unset, not continued. The BREAK is supposed 
to halt execution and resume it somewhere else, either after the 
enclosing loop or at the top level. The same error is affecting your 
error? try [....] code, which is not behaving correctly. 


Your problem, Sunanda, is that you are thinking that ATTEMPT is not 
catching bad code (bugs) that it is supposed to catch - this is not 
strictly true. ATTEMPT isn't supposed to catch bugs, it is supposed 
to catch triggered errors. And a lot of logic bugs don't trigger 
errors, because the code itself is technically correct (what REBOL 
can check for), but not in accordance with the programmer's intentions 
(which REBOL can't know).


Now in this case the logic bug is that you have forgotten that the 
purpose of the BREAK, CONTINUE, THROW, EXIT and RETURN functions 
is escape from the normal flow of the code ("structured" gotos, aka 
non-local returns, exceptions, ...) - you remembered this about HALT 
and QUIT - and didn't realize that the error you are trying to catch 
with ATTEMPT is not in the code that you have wrapped in the ATTEMPT: 
It is not bad code. The error is triggered by the code on the other 
end, the handler, which is not wrapped in the ATTEMPT at all.

So you need to realize that this code is technically correct:
>> attempt [break]
** Throw error: no loop to break
but doesn't do what you thought it should.

And this code is absolutely incorrect:
>> error? try [break]
== true

but doesn't trigger an error because of a weird design quirk in R3 
that is arguably a bug, but not necessarily fixable (see bug#771 
and bug#862).

Paul, creating your own func is the way to go for that. And emails 
can be very complex. REBOL doesn't try to validate against the true 
grammar, it just looks for @.

Paul, I usually test email entry using simmilar code to this:
if any [
    not email? try [email: first load/next cgi/email]
    all [
		not read join dns:// email/host
		not read rejoin [dns:// "smtp." email/host]
		not read rejoin [dns:// "pop." email/host]
		not read rejoin [dns:// "mail." email/host]
		not read rejoin [dns:// "www." email/host]
		...
	] 
][
	print "email is not valid or your email server is unavailable"
]


Worked well in most cases for me but I bet others might have more 
sophisticated solutions.

I don't have the time now to provide examples, I'm afraid, must run 
an errand. Try it yourself and see what you find out :)

(and, you omitted Try)

try/handle is one char shorter than try/recover :-)

alternatively:

try [block]

handle [block][error handler]

try/do
try/on-error

Or it should be an refinement to DO?

do/on-error


But then it's a question, if TRY should be there in the first place.

try/else

I see, TRY already has a refinement called /except.

handle: :try/except

would be cool, but maybe that's taking refinements too far. :-)

Note to the "Should we catch unwinds?" question in the http://www.rebol.com/r3/notes/errors.html
article - the subject of the CureCode #1506 is, that it is (or should 
be) possible for the interpreter to find out, whether the unwind 
would cause a "No catch for throw" type error, and, that Try should 
catch such an "unhandled" unwind.

(Continuing from "Rebol School".)


I've thought about TRY/EXCEPT too, since it popped up a few days 
ago. My thoughts are more about design. Why do we have TRY? Why not 
make /EXCEPT a refinement of DO? DO can do any type, TRY only works 
on blocks. If you wanna do a script on the net, and it can go wrong, 
we have to write:

try/except [do <url>] [<handle error>]

With /EXCEPT on DO, it could be:

do/except <url> [<handle error>]


My point is: is it good to have all these words in the language? 
It may add depth, but it also add confusion and complexity. Maybe 
the depth could still be there with fewer words, and the language 
would be easier?

I don't miss a simplification of DO/TRY as much as structures for 
sequential tests that may or may not fail. REBOL doesn't have anything 
here, so you have to roll your own. Say you're trying to connect 
somewhere in a protocol and one of 50 things can go wrong, so you 
have to state 50 tests, 50 error messages, 50 exit routes. That's 
a lot of lines of almost identical code.

There may be another concern with this. How do we get the error in 
the except block, so we can handle it? A common way is:

if error? result: try [1 / 0] [probe result]

This doesn't work:
(Remember to clear result, if you did the above first.)

result: try/except [1 / 0] [probe result]

And having /EXCEPT on DO is the same problem.

Henrik, yes, what you explain is a common problem. The best way to 
handle it, as I see it, is with a foreach loop, like this:

foreach [code handle-error] [
	[do something] [handle-error-1]
	[do something-else] [handle-error-2]
	...
] [
	if error? err: try code handle-error
]

A better example of the foreach loop:

foreach [code handle] [
	[1 / 0] [print "error 1"]
	[2 / 0] [print "error 2"]
] [
	if error? try code [do handle break]
]

Geomol, maybe you're missing that /except accepts a function, ie. 
try/except [...] func [error] [probe error]

Brian, no, it works here (version 2.100.95.3.1). Do this:

if error? result: try [1 / 0] [probe result]

It's unset!, SET can't set, not error!.

Sunanda, whoops, you meant the TRY [CATCH/QUIT [...]] bug. It's already 
been reported.

Is there any documentation on how to use these modules? I've had 
a couple of hours this beautiful weekend and all I did was try to 
find a way to load load-html.r with no results. Dependent modules 
change the current directory in the console and as a result one module 
cannot find another another. Yes, I am a poor soul on windows. Heck, 
I got to take the kids to the Fall Festival and am late already.

I'll try this: http://www.rebol.org/view-script.r?script=xpath.r

Patrick, e:/Projects/... is not a valid rebol file path.

try with something like:


    power-mezz-path: %/E/Projects/PT/Rebol/power-mezz-built-1.0.0/
    do power-mezz-path/mezz/module.r
    load-modules/from power-mezz-path
    ; etc.

Buuu, virtual.. We should try hard and meet!

if you can separate them as:
must have:
nice to have:


and provide them in the order which you can test them on their own, 
then I'll have a good feel for what I should try to tackle first 
wrt the /library API.

I want to mention this openly:


The name of this altme group is intentionally meant to look RT official. 
 The end goal is for this extension to become THE standard for mapping 
libraries dynamically to REBOL 3.


I want to work WITH the whole community AND with Carl, so that it 
becomes part of the official "sanctified" R3 toolset. 


It will be an ongoing project and will probably, eventually,  be 
maintained by several people.  So its best to start with a name which 
implies this, if only so that the group doesn't get renamed later.


Please understand that as the extension and host kit capabilities 
are improved and changed, this extension will try to keep up.  Its 
even possible that noteworthy efforts in this project might ultimately 
alter REBOL3 itself, so please feel free to participate, even if 
you aren't intent on testing/using the extension right away!


I resisted in giving this project any special name... its as plain 
and obvious as can be... so it should be obvious that ITS AS MUCH 
YOUR PROJECT THAN MINE.