World: r3wp

>> type? first reduce [a]
== hash!
>> type? first reduce [b]
== block!

>> c: mold/all reduce [a b]
== "[#[hash![]] []]"
>> load c
== [make hash! [] []]
>> first load c
== make hash! []
>> type? first load c
== hash!

No information loss.

I mean if you provide a reduce [...] to some parse rules and you 
have a "make hash!..." in the block you need to parse this. Hence, 
the parse rules change if you use block or hash.

I'm not sure I understand. If you have "make hash!..." as words, 
then your block is not properly serialized.

which would indeed make the parsing a bit more complex.

Hi Robert, can you give us a an example, where you have this problem? 
I can't see it.

>> h: make hash! [3 4 5]                                    
== make hash! [3 4 5]
>> b: [1 2 3]                                               
== [1 2 3]
>> parse reduce [b] [into [some [set i integer! (print i)]]]
1
2
3
== true
>> parse reduce [h] [into [some [set i integer! (print i)]]]
3
4
5
== true

'key-word set key-word [block! | word!] (...

So, not when parsing for the content but for the block as is.

Robert, what you see at the console is the output of MOLD. there 
is no 'make and no 'hash! there. if you are *saving* the hash in 
a file or sending thru tcp and so on, use MOLD/ALL (or SAVE/ALL) 
so that hash! can be loaded properly afterwards.

Is there a built-in function that returns the platform we're running 
on (Windows or Linux or Mac or whatever)?

it's encoded in system/version
this script decodes it for you:

http://www.rebol.org/cgi-bin/cgiwrap/rebol/view-script.r?script=environ.r

Thanks, Sunanda, much appreciated.

http://www.rebol.org/cgi-bin/cgiwrap/rebol/view-script.r?script=environ.r

arg !!! too slow

:) Thanks to you, Steeve.

Hi Robert, do you mean, this?

>> b: [a b c]                   
== [a b c]
>> h: make hash! [a b c]        
== make hash! [a b c]
>> parse reduce [b][block!]     
== true
>> parse reduce [h][block!]     
== false

because a hash!, is a hash! and not a block?

>> parse reduce [h][hash!]      
== true

Then you should use any-block!

>> parse reduce [h][any-block!]
== true
>> parse reduce [b][any-block!]
== true

There is a nice script that encodes strings to utf-8. It is by Romano 
Paolo & Oldes. I'd like the reverse:  decoding utf-8 strings. I found 
a script by Jan Skibinski proposing to do that, but the script doesn't 
load in rebol, exiting with an error ('map has no value). What's 
next?

Ok, I think I got what I need. Jan's script can be salvaged, if only 
part of it.

BTW, I noticed that rebol.org serves pages in utf-8 encoding, but 
the scripts themselves are latin-1. This is not a problem for the 
code, but it is a problem for the comments, which may contain accented 
characters. For example, names of authors (hint: Robert Müench), 
and they consequently appear garbled. I'm not saying pages should 
be served as latin-1, on the contrary, I am an utf-8 enthusiast, 
I think rebol scripts themselves should be encoded as utf-8, (it 
is possible with python, for example). I hope Rebol3 will be an all 
encompassing utf-8 system (am I dreaming?).

UTF-8 is being discussed as part of R3 Unicode support.  All encompassing? 
 Dunno.  Well thought out and robust?  I'd bet on that one.

Well, on that same note of optimism, allow me to declare in forthcoming 
R3 syntactic style, rebol: "vive la rébolution"

And why not even rébol: "rébolution"?

That is to say, not only should there be utf-8 string datatype, but 
words themselves should be utf-8 compliant.

It's on the discussion plate.  Gabriele mentioned that unicode will 
help REBOL open up in Asia, so it's a topic at the high levels.  
A couple of rebols have done some very nice work on fonts and character 
sets.  Jerry Tsai comes to mind ... check the Unicode group for some 
of his links.  Oldes has also pulled off some nice translators...again 
links in the Unicode group.  To name but two.  Even Bi-Di is being 
discussed.

Daniel, afaik, R2 words are already utf-8 compliant. (thanks to the 
way utf-8 is designed)

What is current R2 recursion limit? Bobik reports me, that he does 
some tree, and it hits the barrier with 2000 iterations ....

Daniel: just read Unicode group in this world.

2000 sounds about the limit for R2. There's a script here that tests 
various limits like that:

http://www.rebol.org/cgi-bin/cgiwrap/rebol/view-script.r?script=rebol-stress-test.r

Pekr, I think it depends how many local vars are used in the function. 
With one local var, I got 14263 recursions before stack overflow. 
Maybe he can optimize by moving some variables out into a shared 
context.

Thanks everybody, I'll follow your advice.

I'm tring to open a .pdf from rebol script using "call" function. 
It works but i get that MSwindows console window poping up too. I 
know if you call the application (acrobat reader) at the same time 
you do not get the console window. any otehr wat to suppress the 
console from popping up?

This works: call "C:\Program Files\Adobe\Acrobat 6.0\Acrobat\acrobat.exe 
C:\Program Files\PDFS\file.pdf"

What would be the rebol path notation of the above. I tried variations 
of this: call "/C/Program Files/Adobe/Acrobat 6.0/Acrobat/acrobat.exe 
/C/Program Files/PDFS/file.pdf", but I can not get it to work...

This will show the pdf with console: call %"/C/Program Files/ACI32/PDFS/X11070003.pdf"

This will start acrobat with no cosole: call %"/C/Program Files/Adobe/Acrobat 
6.0/Acrobat/acrobat.exe"

But I can not combine them as I did with using windows file path 
notation

AFAIK there is no way to supress the console window in R2.

>> to-rebol-file "C:\Program Files\Adobe\Acrobat 6.0\Acrobat\acrobat.exe"
== %/C/Program Files/Adobe/Acrobat 6.0/Acrobat/acrobat.exe

if you have PRO license, you should use ShellExecuteA routine from 
shell32.dll

amacleod, try this:

    call [%"/C/Program Files/Adobe/Acrobat 6.0/Acrobat/acrobat.exe"  
    %"/C/Program Files/PDFS/file.pdf"]

If the application starts and returns immediately, the console will 
close before you get a chance to see it. I think acrobat is one of 
those programs. If you are opening this pdf in the free reader, I 
would seriously suggest upgrading to reader 8.1.1 for security reasons, 
and because it's better.

CALL will do the to-local-file translation for any REBOL files it 
is passed (even in that block above, though not in nested blocks), 
and even wrap the filenames in quotes just in case they have spaces 
in them.

BrianH, Your suggestion above works. I had tried the same thing but 
without the block...stupid me. Thanks!

Any binary parse wizards ever tried to tackle the on disk file format 
that postgresql uses to store row data?


I'm looking through the docs trying to get a handle on how tough 
it is.

http://www.postgresql.org/docs/8.1/static/storage.html
and

http://www.postgresql.org/docs/8.1/static/storage-page-layout.html


give a fairly detailed starting place, plus the source of course 
but my C is so rusty I think reviewing the raw data is going to be 
easier.


We are trying to recover some data that was deleted (marked for) 
by accident.  We basically need to find the serial key value and 
associate it with a text value for each row so we can rebuild the 
table and not lose the relationships that key off that serial numeric 
value in other tables.


There are some good examples of binary parsing in the rebol.org script 
library so I know rebol can help write out a text version of the 
two values if we can get a handle on the structures involved.


I'm open to suggestions or advice, this is not critical but would 
be a nice win to recover the key data.

I'm quite interested and I may give it a try... but I don't know 
when

but I have only Postgresql 8.0 I'm not sure how much it's different

the header is same

here is a basic... http://box.lebeda.ws/~hmm/rebol/pgsql-db.rthis 
reads the postrge's file per pages... but I'm not sure what to do 
with the data inside and have to do something else now

Oldes, thanks for getting us started on the postgresql data parsing!

Thanks, Rod.

is it possible to get the name of the script that was run with 'do?