World: r3wp

Obviously that would need quite a bit of adjustment. If you are blowing 
stack limits you can roll your own. If you want the whole parent 
stack you can do that too.

This would probably be easier to do using block parsing.

Especially if you roll your own parent stack in embedded parens.

About the choice of the right internal data-keeping structure: because 
we are manipulating big XML files (> 2MB), we had to find the most 
performant way to retrieve our data into a nested structure. The 
choice was block! / hash! / list! / or object! . after a few tests, 
it appears that block! is the most suitable in terms of retrieval 
time. Note that this is true only for nested structures. In case 
of one-level structures, the hash! is the most performant (see http://www.rebol.net/article/0020.html).

When I say most perfomant, I mean the retrieval time is two times 
shorter.

Anyone having similar results ?

I agree.....

I tend to avoid hash! and use straight block! for values I'm reloaded 
from external storage.
Block! makes the loading much faster. 

Hash! may be faster once loaded, but I don't do enough processing 
to offset the loading disadvantage.

so what about loading it as a block, then hashing it? :-)

What's the advantage comparing to amke directly a hash! of it ? Did 
 mis the point ?

amke = make :-)

hash! is ok when staying at the level of an unary tree, not deeper. 
don't ask me why, it's just an observation. obviously it was wanted 
by the implementation... perhaps aiming to RIF ?

Carl has talked several times about a binary format for saving REBOL 
structures (can't find any references off-hand).

That would probably solve this problem as what is saved is, in effect. 
the internal in-memory format: useless for non-REBOL data exchange 
and perhaps dangerous for cross-REBOL releases data exchange, but 
much much faster as it'd avoid most of the parse and load that REBOL 
does now.

Very interested in ! Could u find the ref back ? Or was it about 
the new REBcode ?

It way predated rebcode -- may even be on the original REBOL Altme 
world....Which may be why i can't find it.

http://www.rebol.net/cgi-bin/blog.r?find=rebin<-- this?

Nice find!
http://www.rebol.net/article/0044.html

Thx ! Now I recall the article... As I thought, Carl is aiming to 
RIF: "RIF (index file) records will have the option of storing in 
REBin format". But you were right, RIF could be a solution for the 
data storage. Let's hope it will exists by Nov 14 :-)

yes, let's hope so, as then ashley can restart his work on otherwise 
excelent rebdb! :-)

FYI, I have set 2 ppl working on an implementation of XPath into 
our XML function lib (temporary called "EasyXML"). Basically, we'll 
have 5 functions encapsulated into a context: 'load-xml file!, 'save-xml 
file!, 'get-data path! or block!, 'set-attribute string!, 'set-content 
string!

so you use rebol oficially at your work? That is nice. So far I used 
it only for few small utils here ...

Since 2000, exclusively REBOL work! But I do not know how long I 
will be able to stand the position, because, despite the great results, 
we got a lot of opposition (not a standard, too cheap, no future, 
en so on...) :(

well, try to keep up your good work. What is standard anyway? Or 
just make some calculation, how using different technology makes 
process more complicated/expensive (unless your opponents don't use 
other open-source technology, e.g. python) ... the bad thing is, 
e.g. here in our company, that the price is not always deciding factor. 
RT does wery bad job here. Our managers want to read some success 
stories, want to see list of other customers who do use such technology 
.... some case studies etc. Maybe simply Europe uses different kind 
of logic than US.

it is simply about feeling safe, so that IT manager can be sure and 
tell himself - look, someone other uses it too ....

Yes, they want to be able to look forward. And REBOL stays "risky" 
in their critical eyes :-)

But we are Off topic here :-) Shouldn't we move to the "Chat" group 
?

Do what other people say - tell them you're using C :)

What happens if the ask for a code review?

C source for Rebol is closed.

But the cosomter may ask to see the code. If you say your code is 
C. Then you are trapped?

C++ is a domain specific language which is then converted to C.  
Is there a difference?

I can do a code review. And C++ is compilable by any standard compiler.

C++ is now a language that is directly compilable. It doesn't go 
thru a translation to C.

I guess you could then drag out dockimbels R# compiler

customers usually don't want to see a code ;-) And it is same like 
we coded with CA-VO ... we bought a library and did not care for 
its internals, if things worked ....:-)

Pekr. I agree. But  believe in the politics of truth instead of deception.

Better let the customer know what he is getting up front. Even if 
it is hards or sell the solution as closed-source.

With a support contract.

How hard would it be to write a C to Rebol translator ?

Do you want Rebol to run C code?

No... just thinking about an upcoming code review :)

BTW. When are you releasing your medical application? I guess is 
going to be open-source due to GPL licensing issues ;-)

It's being continually released all the time.

up to 0.0.70 now.

I mean the src code?

oh... well, I may have to backtrack on that .. it could be dangerous 
to release the source code while LNS doesn't have a way to restrict 
access to functions.

At present I fudge it by asking initiators to send a userid with 
each request so I can determine their rights.

But if someone had the source, they can pretend to be an administrator, 
and start to damage my data :(

So, when are you guys going to complete LNS ??

Nope. There is a way around this. Without your fudge.

Complete LNS when we have the final spec.