AltME groups: search

ok, I'll try it out tomorrow.. its 5AM here... got to go get some 
sleep :-)

in the current stat of the host-kit and rebol architecture in general:
---------------------------

1) I cannot use data, since that is being used by r3_gui.r3 so it 
has in effect become a reserved word which we can't use.

2) if I use gob/draw, then I am in fact trying to hijack the meaning 
 of  draw gob... an AGG draw block.

3) the current gob! API is very limited because it was shrunk to 
handle a very specific use case.  I can't really play around with 
anything cause it just breaks up real quick (I tried).

4) the CGR API doesn't have a scene dialect yet, but that is just 
high-level use.  if you look at the code, its 4 lines of code to 
have an openGL high-rez model viewable in a window... I hardly consider 
that bloat.

5) using commands to manage a real life scene with several thousand 
animated, deforming objects and scene changes, is a nice dream. it 
doesn't work in practice since just managing the thousands of blocks 
this requires ends up eating a way a sizeable part of the CPU and 
ram.  

6) data marshalling is heavy, REBOL datatype access is heavy, datatypes 
use A LOT of ram, and the GC is extremely intrusive,  CGRs solve 
all of this while still making the high-level interface easy as pie.

7) primitives are more than just dead weight they allow direct access 
to/from rebol and the CGR itself.  they are the *low* level interface 
which can be used directly or directed by the use of a dialect later. 
  the difference from AGG is that these structures are persistent 
for many reasons, which will be much clearer in the future.

8) CGRs are not only for 3d graphics, but for any rendering.  primitives 
are a generic container to access/construct any rendering engine 
in the same way. ie. all CGR will use the same core cgr dialect.

9) the code does support multiple cgr gobs, but it might have bugs... 
I didn't even try it yet... I was busy getting this stable and released 
asap.

10) The opengl-cgr currently doesn't integrate into the view compositing, 
since that instantly *kills* rebol.  I mean... totally.  500x500 
a 30fps... = 100% cpu just blitting graphics (not even opengl rendering). 
 opengl-cgr uses the container mode, which actually uses up a sub-window 
(like every single construct in windows) and allows system double 
buffering in that area.

11) CGRs are compatible with all other gobs, though they must be 
built to support the internal gfx pipeline by using the compositor 
or image rendering modes.  That is how I started and it was quickly 
obvious how un feasible it was for opengl.

12) rendering performances ARE very implementation specific. using 
show instead of cgr-refresh on the display loop will show a performance 
penalty anywhere from 10-1000% (depending on nested gob depth & size). 
 If I didn't create internal data for the models, the large tree 
example would run much slower, if I used commands to call every opengl 
call in the large tree example, it would likely take several seconds 
a frame even with hw support.

in the future:
----------------------------

-there will be (hopefully) a small number of changes to the host-kit 
which will allow 1, 2, 3 to be resolved in a more natural REBOL feel... 
this current implementation actually highlights those needs and you 
where quick to point them out  :-)

-concurrency requires a bit more sophisticated structures to prevent 
locks, using the current design I solve some (though not all, yet) 
of the requirements for true concurrency, and this directly relates 
to issues and/or decisions in 5, 6, 7 & 8

-my goal is to have a high-performance rendering engine which isn't 
bound by any inherent design incompatibilities between REBOL and 
optimised native code, especially if the engine has access to hardware 
in parralel to the interpreter.  when i look at all the current games 
out there and they slow down even using only compiled code and sometimes 
not even really complex scenes, I don't want to fall into the trap 
of adding an additional layer of slowness which is to have the interpreter 
doing the renderer's job.

-I'm not trying to make a "cool" rebol plugin... I am trying to make 
an engine which is optimisized to run within REBOL.  the idea being 
not to help out rebolers per say, but to attract people with rendering 
needs TO REBOL because it has a high-perfomance engine *built-in* 
to which you can graph any actual renderer (DX, OpenGL, video frame 
buffers, etc).
-did I mention I want to make an AGG CGR ?  ;-)

did you try with the torus scene?

Adrian you are having a very strange problem.  the actual OS and 
opengl code being called is textbox 1.1 OpenGL  I will try to look 
into it, though with the little I've seen the 5xxx series ATI cards 
do come up often has being  "troublemakers" in OpenGL dev, though 
by all accounts the 10.10 drivers seem to cure problems for most 
users.


now I'm not downplaying that its something in my code, its possible 
there is a little something to add explicitely to make your card 
work which is done implicitely on other setups...

if you don't mind I'll use you to test anything I can find.  you 
are at the opposite end of my setup,  mobile nvidia card running 
on 32 bit xp.

I'll try whatever you want me to. As a point of note, it kind of 
looks like the animation is showing 1 in 10 to 30 frames or so. Also, 
I'm not sure that the colour rendering is OK - there seem to be too 
few colours used. Can you take a screen cap showing the torus on 
your end?

Max, I'm expierencing the same flickering as Adrian does, I'm running 
on a 3/4 year old Sony VAIO with Win7. I can't supply any further 
detail, I'm don't have access to the machine right now. I see a flickering 
torus , a flickering  simple tree and no complex tree at all. When 
I'm back at the machine, I'll try with the AA settings which Adrian 
seems to have identfied as the source of the confusion in just this 
moment.

ulimit -t 30 -m 20000 -v 10000 -u 10 -n 100 -f 200

/users/try-REBOL/program/r3 -q /users/try-REBOL/program/do-rebol.r 
$1

Jocko, I'll try TTS extension as soon as possible. It is really nice 
to have this on REBOL.

i can try :)

That's curious. If I try to unpack    2.4 MB glass-r003.zip, I get 
a folder with just 1.3 MB and only two files in glass/libs. I tried 
with 7zip and the WinExplorer.

Thanks to both Kaj and Andreas for taking up the 0mq task. Since 
Andreas made it so easy to try, with prebuilt binaries, I already 
played a bit, and it works fine here. Very exciting stuff guys.

And it will try to prevent you from creating a check-ins that are 
"earlier" than their parents.

OK, I'll try that

Used it once. Can you try again?

try "msntp -r ntp1.nl.net" instead (which, from the manual, should 
use settimeofday())

Graham -- please try an experiment:
-- Hop over to rebol-gate [id: guest password: guest]
-- Make a few posts in the Playpen group

rebol-gate is a tiny world, so it may help pinpoint if the problem 
is a world scaling issue.

Thanks. 

That's useful evidence that the problem is not network or server 
related [rebol3 and rebol-gate run on the same server]


Next step ---  is it better or worse in groups with many messages? 
(ie is the problem the world or the group):

--could you try a test post or two in a couple of groups that have 
less than 100 posts?
  list available here: http://www.rebol.org/aga-index.r

Also, technically, a given send box should be directly connected 
to the given group, so you can send, and even if it is in transit 
or waiting you can go on and work on other messages.

We do tag messages this way in Qtask, but we have seen this same 
bug, but don't have proof (as I do in AltME) that it is the program 
and not the operator.  But I'm always on the look out for it since 
it can be a very dangerous bug for some people.


This whole class of issue falls to a perceived form of latency, and 
a series of features are needed to suppress it.  For example, instead 
of graying the out going message area, just make it look like it 
was sent, but also instantly add a “message hour glass” in the “New 
message” bar when on that group, and, also create a new tinted empty 
box in the thread saying something like “Waiting for new message 
to post”.


This frees you up to go elsewhere.  If you come back to the same 
group it is clear what state it is in.  If you want to retrieve the 
sent message just click on the “Message hour glass” and it will bring 
it back into the input box.


Lastly, of course, if you try to leave AltME before it is done sending, 
need to offer people a dialog warning them , and giving them access 
to the messages waiting.

There is more, but yeah, it takes a lot to make this work.

I also have a fairly large private messages file.

Try with someone who does not -- say a Hello message to a new member.

You should give it a try. Whatever was done to this world, it was 
good :) Let's hope it stays that way for a while.

It rewrites your local file, right? It seems that Carl's concept 
of  - keep things simple - in fact turned into - constantly try to 
reinvent the wheel, never finish it properly, don't scale well, or 
at all.

I believe subsequent posts will be red ... try to send a ping to 
me ....

The Russian hacker I know is actually dying in St Petersburg -  of 
Marfan's Syndrome due to poor medical care - his brother has started 
med school to try to save him ...

I will try ....

(Did I never try that...?)

ok, if you have two machines, you can easily try it out.

me too, I am so used to having to try and export stuff and then import 
in a new install

Try these 
a acute ˆ
e grave Ž
c circumflex 

It seems to try to allocate a 3 GB file or area there. It's not surprising 
that fails, but it's surprising it would try that

Thats what I got going on. two worlds on same port. I will try again 
but close off the other ports first...let you know how it goes...thanks 
all

main problem is that  the fonts in R2 scale isn't accurate ... we 
discussed it or at least try to when we  writed area-tc and all we 
had as reply is don´t worry r3 is so much better and that was 2 years 
ago ...

Try: REBOL4, GiuseppeC, 1234

I've had recently the opportunity to dust off my experimental LDAP 
driver code, so I've decided to release it as-is, even if it's unfinished, 
at least querying the server and retrieving data is supported. Download 
at: http://softinnov.org/dl/ldap-protocol.r


The query dialect is probably not working 100%, but at least basic 
queries should do the job. I don't intend to implement more features 
now because I don't have any needs for a LDAP driver, but I'll try 
to fix the query dialect if required by users. I might accept to 
add the missing features and polish it under contracted work or bounty 
(if high enough).

Basic usage syntax and examples can be found in the file header.
Please use Ann-reply group for feedbacks.

New RMA release of R3GUI is available on:


http://www.rm-asset.com/code/downloads/files/r3-gui-src.zip- this 
is the full source version + docs


http://www.rm-asset.com/code/downloads/files/r3-gui.r3.zip- this 
is the 'classic' one file release


Feel free to try it and let us know in the R3GUI Altme group. Any 
feedback is appreciated.


NOTE: this version is compatible only with the RMA version of Rebol3. 
You can get it from: http://www.rm-asset.com/code/downloads/files/rma-r3-build.zip

New RMA release of R3GUI is available on:


http://www.rm-asset.com/code/downloads/files/r3-gui-src.zip- this 
is the full source version + docs


http://www.rm-asset.com/code/downloads/files/r3-gui.r3.zip- this 
is the 'classic' one file release


Feel free to try it and let us know in the R3GUI Altme group. Any 
feedback is appreciated.


NOTE: this version is compatible only with the RMA version of Rebol3. 
You can get it from: http://www.rm-asset.com/code/downloads/files/rma-r3-build.zip

Release change notes:

- added missing images to docs (thanks to Pekr)
- UNVIEW now works like in R2
- removed STYLE/FACED, now it is obsolete (use only STYLE/FACETS)
- improvements to facets creation
- fixed box-model border caclulation
- fixed binding of actors
- DO-STYLE code optimalization and fixes

- VIEW function cleanup, now it should work on block of faces as 
well
- fixed panel(container) names binding
- fixed 'load trigger calling
- fixed WHEN style
- misc smaller fixes
- old unused code cleanup

New RMA release of R3GUI is available on:


http://www.rm-asset.com/code/downloads/files/r3-gui-src.zip- this 
is the full source version + docs


http://www.rm-asset.com/code/downloads/files/r3-gui.r3.zip- this 
is the 'classic' one file release


Feel free to try it and let us know in the R3GUI Altme group. Any 
feedback is appreciated.


NOTE: this version is compatible only with the RMA version of Rebol3. 
You can get it from: http://www.rm-asset.com/code/downloads/files/rma-r3-build.zip

Release change notes:

- show-native recursive issue fixed
- enhancements to TEXT-LIST, TEXT-TABLE, TAB-BOX styles
- fixed DO reactor call
- fixed reactor actions handling
- optimized INIT-PANEL function
- added FOREACH-FACE function
- fixed internals of triggers subsystem
- optimized DRAW blocks handling
- optimized DO-STYLE and DO-TRIGGERS code
- added triggers handling to set/insert-panel-content
- lists.r3 code cleanup
- cleanup of unused/leaked variables

New RMA release of R3GUI is available on:


http://www.rm-asset.com/code/downloads/files/r3-gui-src.zip- this 
is the full source version + docs


http://www.rm-asset.com/code/downloads/files/r3-gui.r3.zip- this 
is the 'classic' one file release

or just simply type LOAD-GUI in the RMA version of R3.exe


Feel free to try it and let us know in the R3GUI Altme group. Any 
feedback is appreciated.


NOTE: this version is compatible only with the RMA version of Rebol3. 
You can get it from: http://www.rm-asset.com/code/downloads/files/rma-r3-build.zip

Release notes:

-updated documentation (though still incomplete)
-complete new set of examples
-new hint based autosizing

-many internal and style related fixes and improvements, for details 
see: http://rm-asset.com/code/level1/r3-gui/#toc1

New RMA release of R3GUI version 2124 is available on:


http://www.rm-asset.com/code/downloads/files/r3-gui-src.zip- this 
is the full source version + docs


http://www.rm-asset.com/code/downloads/files/r3-gui.r3.zip- this 
is the 'classic' one file release

or just simply type LOAD-GUI in the RMA version of R3.exe


Feel free to try it and let us know in the R3GUI Altme group. Any 
feedback is appreciated.


NOTE: this version is compatible only with the RMA version of Rebol3. 
You can get it from: http://www.rm-asset.com/code/downloads/files/rma-r3-build.zip

Release notes:

-new set of examples
-many internal and style related fixes and improvements


for more details see r3-gui-changes.txt in the zip archive (the changelog 
will be updated on the RMA webpages soon as well)

New RMA release of R3GUI version 2182 is available on:


http://www.rm-asset.com/code/downloads/files/r3-gui-src.zip- this 
is the full source version + docs


http://www.rm-asset.com/code/downloads/files/r3-gui.r3.zip- this 
is the 'classic' one file release

or just simply type LOAD-GUI in the RMA version of R3.exe


Feel free to try it and let us know in the R3GUI Altme group. Any 
feedback is appreciated.


NOTE: this version is compatible only with the RMA version of Rebol3. 
You can get it from: http://www.rm-asset.com/code/downloads/files/rma-r3-build.zip

Release notes:

-generic box-model presets
-better text sizing
-improved keyboard navigation
-correct handlind of minimal window size
-cleaned up style tags
-many internal and style related fixes and improvements


for more details see r3-gui-changes.txt in the zip archive (the changelog 
will be updated on the RMA webpages soon as well)

New RMA release of R3GUI version 2338 is available on:


http://www.rm-asset.com/code/downloads/files/r3-gui-src.zip- this 
is the full source version + docs


http://www.rm-asset.com/code/downloads/files/r3-gui.r3.zip- this 
is the 'classic' one file release

or just simply type LOAD-GUI in the RMA version of R3.exe


Feel free to try it and let us know in the R3GUI Altme group. Any 
feedback is appreciated.


NOTE: this version is compatible only with the RMA version of Rebol3. 
You can get it from: http://www.rm-asset.com/code/downloads/files/rma-r3-build.zip

Release notes:

-new dividers subsystem

-support of application 'shortcut' and 'access' keys (see panels-15.r3 
for details)
-more stable resizing
-improved keyboard handling in some styles
-many internal and style related fixes and improvements


for more details see r3-gui-changes.txt in the zip archive (the changelog 
will be updated on the RMA webpages soon as well)

New RMA release of R3GUI version 2367 is available on:


http://www.rm-asset.com/code/downloads/files/r3-gui-src.zip- this 
is the full source version + docs


http://www.rm-asset.com/code/downloads/files/r3-gui.r3.zip- this 
is the 'classic' one file release

or just simply type LOAD-GUI in the RMA version of R3.exe


Feel free to try it and let us know in the R3GUI Altme group. Any 
feedback is appreciated.


NOTE: this version is compatible only with the RMA version of Rebol3. 
You can get it from: http://www.rm-asset.com/code/downloads/files/rma-r3-build.zip

Release notes:


this is just minor update(as previous one has been published only 
2 days ago) so we(RMA) get back up-to-sync with 'Friday release' 
frequency ;-)


for more details see r3-gui-changes.txt in the zip archive (the changelog 
will be updated on the RMA webpages soon as well)

(it's a windows build so far, maybe I could try to build it for Linux 
as well, or maybe someone else can provide it)

New RMA release of R3GUI version 3015 is available on:


http://www.rm-asset.com/code/downloads/files/r3-gui-src.zip- this 
is the full source version + docs


http://www.rm-asset.com/code/downloads/files/r3-gui.r3.zip- this 
is the 'classic' one file release

or just simply type LOAD-GUI in the RMA version of R3.exe


Feel free to try it and let us know in the R3GUI Altme group. Any 
feedback is appreciated.


NOTE: this version is compatible only with the RMA version of Rebol3. 
You can get it from: http://www.rm-asset.com/code/downloads/files/rma-r3-build.zip

Release notes(just the main changes):

-removed reactors
-udpated documentation
-reworked text-list, text-table styles
-new testing tool + basic tests included 
-improved keyboard handling
-many internal and style related fixes and improvements


for more details see r3-gui-changes.txt in the zip archive (the changelog 
will be updated on the RMA webpages soon as well)

seriously, if you mean that you see funny stuff on the display, and 
you're using an analog connection to the monitor, try switching to 
DVI or HDMI (if that's one of the connectors on the computer). Just 
using an RGB to DVI convertor will might not do it since you still 
have part of the connection prone to interference

A possible complicating factor is that the shared wall between the 
radio and my computer has a power outlet on it, and an ethernet cable 
goes from my computer into it and down under the house, so those 
two things are both pretty close to the radio.
But I'll try lining my computer case first.
Thanks for the suggestions.

Try the radio on a different wall socket .. the RF being generated 
by the PC may be leaking into the power.  Also if that doesn't work, 
get some ferrite beads from Dick Smiths and wrap them around cables 
inside the PC.

There were imo better docs. I'll try to find my previous posts, I 
gathered some links ...

Bug #1825 "Crash in RESOLVE" (and/or #1865 "SIGSEGV when importing 
modules") are getting annoying really soon, once you try to seriously 
use R3 modules.s

(Just privmsg me and I can try it quickly.)

I rewrote http://issue.cc/r3/1865to match the real cause. Here's 
the code:

    resolve/extend/only context [] context [a1: a2: a3: a4: a5: a6: none] 
    [a]

If you all would try it on other platforms than Windows, that would 
help. On Windows you need 6 or more words in the source context to 
cause the bug. If that number is different for other platforms, it 
would be helpful to know.

Another disadvantage is that loading errors are currently harder 
to recover from with serialized constructors than they are with normal 
literal values like blocks. There's a ticket about this already. 
However, if you are loading the entire preference file in one go 
and just catching the error with TRY, there's no difference in the 
error handling.

The security issue is to not have a file that is done automatically 
be writeable using the same permissions that the scripts are run 
under.

sorry, i don't get that. could you try reformulate the problem?

OR AND etc, already return errors when you try to compare incompatible 
datatypes.  right now it seems very odd to me that #[none] is not 
comparable to logic values.


none is part of the logic! handling in conditionals and loops... 
IMHO it should be in logic ops and funcs too.

I'm tripped by it EVERYTIME I try to use them... none is a valid 
value for all logic control funcs.


so in over 10 years of reboling I've never been able to use them 
to control logic flow... I've used them only as bitwise ops...

Ah, I see Brian. I'll try to remember that.

Pretending that security doesn't matter is a worse policy. Here is 
what would resolve the security issue:

- Putting warnings in the docs for DO, in the same section where 
they talk about the special treatment of functions and blocks.

- Make parameters not work, and don't do blocks and parens through 
word values, same as R2's DO of path values.

- Make sute that we don't try to make set-words and set-paths do 
assignment when you DO them. Treat them like get-words and get-paths.


Together, those restrictions would make DO of word and path values 
no more insecure than DO of block and paren values. For functions, 
we have APPLY.

OK, I will try

I figured out a new way to express the equivalence that can safely 
be used for word! (http://issue.cc/r3/1882), path! (http://issue.cc/r3/1881), 
lit-word! and lit-path! (http://issue.cc/r3/1434), set-word! and 
set-path! (http://issue.cc/r3/1883), and get-word! and get-path! 
(current behavior), that matches the behavior of paren!. This code 
should work in all cases.

use [a b] [
    a: func [] ["blah"]

    foreach t compose [(paren!) (to-block any-word!) (to-block any-path!)] 
    [

        assert [any [all [error? try reduce [to t 'a] error? try [do to t 
        'a]] same? do reduce [to t 'a] do to t 'a]]
        assert [b: to t 'a strict-equal? to t 'a b]
    ]
]


Basically, the equivalence of an individual type would be this (using 
word! as an example):
    same? do [a] do 'a
    b: 'a same? 'a b


The important part of the equivalence would be that DO value would 
be equivalent to DO reduce [:value], that it be equivalent to evaluating 
that value inline *in a block all by itself*. That would deal with 
the parameter problem, with making sure that set-words and set-paths 
trigger errors properly, it even would work with refinements and 
issues.

If allowing get-words in spec blocks, then QUOTE is fine. I'm questioning 
allowing get-words in spec blocks. It can lead to uses as this:


I make a function, that can do a paren! (in lack of better example, 
but it makes the point, I think):
>> do-paren: [:p] [do p]
I can try it on a paren:
>> do-paren (1 + 2)
== 3
Works ok so far, so I try having a var holding a paren:
>> q: quote (1 + 2)
== (1 + 2)
>> do-paren q
== 3
I got the feeling, I know how do-paren works, until I write:
>> do-paren quote (1 + 2)
** Script Error: do is missing its value argument
Hm, what if I use the old method:
>> do-paren first [(1 + 2)]

** Script Error: p expected series argument of type: series pair 
event money date object port time tuple any-function library struct 
even...

That's confusing, as I see it. (Example done in R2.)

What if ... this is radical, but try go with me ... what if block's 
content wasn't bound to any context, when the block is made? And 
then the content is just bound to a context, when and if the block 
is being evaluated (or compiled if a language does that) the first 
time. Doing it this way, words are treated just like any other value 
within the block. They don't hold any other meaning than the words 
themselves. What would the consequences be?

R3 has system/contexts/user , which seem to work like R2's system/words. 
Try

? system/contexts/user


before and after making some random words, e.g. in a block like [some 
random words]

I did not try to categorize the votes futher to guru/non-guru, btw

We can still try to get the body of a native and action, like we 
can with functions. So we can use them exactly the same way.

Didn't try.

I understand, what happens, that it's a position in a series, I try 
to insert earlier in the same series. I just find it a bit confusing, 
it works as it does. Woldn't it be more logical, if it's the position 
+ 1, that is inserted in such cases? I think, this looks strange:

>> s: [a b c d e f g h]
== [a b c d e f g h]
>> insert/only s find s 'd
== [a b c d e f g h]
>> s/1
== [c d e f g h]

It seems more logical to me, if it does this:

>> s: [a b c d e f g h]
== [a b c d e f g h]
>> insert/only s next find s 'd
== [a b c d e f g h]
>> s/1
== [d e f g h]

Well, the only thing I can suggest you is to try it and see which 
incompatibilities you get.

John, remember our previous discussion, that indexes are not properties 
of series, but properties of series references. Therefore, it makes 
no sense to try to make a vector behave like a list, because any 
other references to the vector are unknown and thus it's impossible 
to make the behaviour for those references consistent

test: func [block expected-result /local res] [
    if error? try [
        print [mold/only :block newline tab mold res: do block]

        if res <> expected-result [print [tab 'FAILED! tab 'expected mold 
        expected-result]]
    ][
        print [mold/only :block newline tab "ERROR!"]
    ]
]

Yup. I'll try to mock something up later this week.

Short update, we received a R3 Core version for OSX / Linux with 
the WAIT bug (consuming 100% CPU time) fixed. I still need to give 
it a try but I expect it to work. With this we now can use R3 on 
the non-GUI server side with our event driven BEEP based communication 
layer.

Kaj  I don't think I make things worst I thing most of the people 
here just don't give a damn ...  but if you are at a state were you 
refuse any discution to try to find a solution  to our current problem 
... Can we set RMA R3GUI to have as main goal to propose a concrete 
thing like for example "a rebol console based on their library in 
octobre"

No, try this:

a: [#[false]]
either a/1 [true][false]

R3 probably runs on x86 MeeGo already. Someone interested in MeeGo 
should just try.

When I try to make three dot dir under Vista, it returns an error, 
and hence R3 hould return an error too imo. Ditto for invalid chars, 
not allowed being a part of the dir names ...

The particular error triggered in the Windows console when you try 
to make a directory with only periods in its name is that the directory 
already exists; this is probably a bad error. However, when you try 
to MAKE-DIR directories that already exist in REBOL, it's a noop, 
not an error. That is probably why it's not triggering an error here.

I should try it first, my mistake.

We have a Winter Syllable Conference there a month before, so we'll 
try to keep a tap on it

Try read (write etc) like this:

     read [ scheme: 'ftp host: domain.com user: user-domain.com pass: 
     "password" ]

Or see what other people have tried in the past:
    http://www.rebol.org/ml-topic-index.r?i=ftp

Thanks, I will try it.

Thanks Sunanda. I'll try that. Carl was just here looking at the 
code (How humiliating) and telling me why mine wouldn't work. OOPs.

Could you try a variant on....
    all [exists? uppercase what-dir exists? lowercase what-dir]

....At least it does not require reads/writes outside of the current 
folder.

I have redefine my probe so it uses mold/all instead... it also only 
dumps the first 500 chars when I try to probe something which is 
way to big (like a nested set of faces)

Try parse, it should be quick:


>> parse [["xxx"] ["yyy"] ["zzz"]] [(f: copy []) any [set b block! 
(append f first b)]]                                             
                           
== true

>> 
f
== ["xxx" "yyy" "zzz"]

Look at the #1520 proposal, with the clarifying comments. Combined 
with TRY it should catch everything short of an interpreter crash.

We want the separate TRY in order to distinguish between errors and 
unwinds.

more things to try :)

Good luck!

For raw speed, experiment with dropping the SORT -- and try DIFFERENCE 
- it may be faster for large strings.
    "" = difference "01"  join "10" string

Try here: http://www.movable-type.co.uk/scripts/aes.html

Hmm ... http://www.rebol.org/view-script.r?script=crypt.r


I changed the strength to 256, and algorithm to rijndael .. and encrypted 
a file, but get an out of memory when I try to decrypt it :(

Graham, you can do your own indices using hash!, but that might be 
pushing your complexity budget. Try it and see.

I try to swap [[a b 1 d  z 3]   [X 3 Y ]]
minus the sub blocks

Try by replacing SAVE/ALL by SAVE and LOAD FILE by DO LOAD FILE.

You might also try connecting with the FTP server with a command 
line client like NcFTP and looking at the listings directly.

Or try Gavin's code:
   http://www.rebol.org/view-script.r?script=xml-object.r

Graham, I'll try that. Thanks.

One idea....Try setting the user-agent to the same as your browser's
   system/schemes/http/user-agent

I made some notes here and there, but can't seem to make time to 
really think deeply about all this. Consider these thoughts lightly 
---


The FOREACH trick is clever, but it makes me wonder if things are 
a bit inverted. Should there be a core binding func that does that 
service *for* FOREACH and other funcs that need that behavior.

Even though it's temporary, should this:
    if set-word? first words
be this:
    if find words set-word!

(behavior alterations and 'values being modified ignored due to temp 
status of func)


TRY/EXCEPT doesn't read particularly well to me, because 'except 
sounds like you're leaving something out, rather than catching the 
error.

I have discussed a new page organization strategy for the Exceptions 
page with Ladislav. As time permits, I will try to reorganize. It 
will make these issues much more clear.

Please don't take my mentioning of downsides as being a statement 
of opinion or some kind of taking sides. I only mention them because 
they are real, and must be considered when picking a certain strategy. 
Both approaches have plusses and minuses. If you want to make a rational 
choice then you need to know the issues - otherwise you are just 
being a fanboy.


For instance, I picked the definitional side for returns, without 
the need for a fallback to dynamic, because of a rational evaluation 
of the algorithmic style of R3's functions. And it wasn't until I 
remembered that the tasking issues had already removed the advantages 
that dynamic scoping has over lexical scoping - we just can't do 
that stuff as much anymore, so it doesn't matter if we don't try. 
The same goes for loops, but to a lesser extent - loops aren't affected 
as much by tasking issues so we can still do code that would benefit 
from dynamic breaks, but it still might be a worthy tradeoff to avoid 
needing an option (since we have no such option). But for THROW, 
especially THROW/name, there are things that you can do with dynamic 
throw that you *can't* do with definitional, and those things would 
have great value, so it's a rational choice to make the tradeoff 
in favor of dynamic.

btw, for throw/catch, I agree 100%, even after I now, fully understanding 
the topic. 
   

If we lost dynamic throws, trying to make it work *as* a dynamic 
system is not pragmatic and AFAIK prone to many strange problems, 
especially if we try to create our own code patterns and would need 
to decipher cryptic mezzanine code which does some magic.


the way I see it, definitional throw/catch really doesn't scale well 
and doesn't work especially well in collaborative programming if 
there are multiple trap points with different catch setups.


I can see ways this can be a problem, especiallly when code IS NOT 
bound on purpose like in liquid which uses a class-based model, *specifically* 
because it allows me to scale a system by at least three orders of 
magnitude. 


liquid builds nodes on the fly and generally re-organizes processing 
on the fly.  one system might be building the setup, while another, 
later will execute it.  with definitional throw, this is impossible 
to make work.