AltME groups: search

Great news! thanks for upgrade. What about promissed file storage, 
i.e. is ti possible to operate the DB and index binary directly to/from 
file?

Anyway I'like to ask again about direct file storage of dat/index 
parts (file based database)  is it possible?

Yes. It's fairly easy to access the dat file on disk via a port! 
... as long as some port! bugs are corrected. Once ports are working 
correctly I'll add file support.

and the spool file... which is suggested to be called session.log 
but then it will be replayed by the commit * in login.sql if it's 
in the data directory..

if i say set spool session.txt, then it works.. pretty confusing 
default. and i would expect the file created in the current directory, 
not where the db.r file is stored

SQL> select * asd
asd has an open log file

For Chrome users, you might need to SHIFT-reload on CC's first shown 
page to get the lastest CSS file version.

Webapp's root-dir must point to the folder where CureCode application 
is located. The install script doesn't move anything nor creates 
any file, it just builds the bugs database and prints out a webapp 
definiton based on the location of the CureCode folder, and answers 
you give.

Guys, thanks for your input. I did log off, thinking that perhaps 
not doing so might be causing the issue. This morning, the same "page 
unavailable" occured. I checked the log and there is an RSP script 
 error in the head.rsp file:

 ** Script Error : say expected data argument of type: string none 
	** Where: rsp-script 
	** Near:  [projects/2: say projects/2 

Then a separate entry 

Request = make object! [ ...
 referring to the index.rsp file.


I can in fact run my test page which has a mysql test  that reads 
the curecode tables within it without any issues.


I have that work-around of restarting the service so I'm cool. I 
was just wondering if anyone else had that same behavior.

I'm also going to test it from another machine today.


Interesting. Reaching the server from another machine worked. Then 
when I went back to the server machine and tried curecode, it also 
worked.  

I'll do some more tests and let you know. Thanks.

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.

All of them (including chey-<pid>.log file if you have it). Just 
zip them and send them to me by email. Thanks for taking the time 
to help me investiguate this issue.

Yeah, I haven't seen the chey file. Where do you want me to send 
them to? The nr address?

The chey-<pid> file is produced when Cheyenne is run in verbose mode 
(-v... command line option) with no window (-w or encapped).

Hmm. I thought I was running it in verbose mode but maybe not. I 
do not see that file. I sent the files a little earlier.

CureCode application upgraded to 0.9.11. Changelog :

	o FEAT: Custom captcha system replaced by ReCaptcha.

 o FEAT: Auto-adjusting scale for bar charts in stats (more accurate 
 and readable).
	o FEAT: Category selector added in tickets list detailed view

 o FEAT: Empty attached file section not shown anymore in tickets 
 read-only view.
	

 o FIX: When clicked, attached files will now show up in browser's 
 window by default.

 o FIX: When attaching file in a new ticket, the returned attached 
 filename was 'none'.

Yeah, already tried with IE8. I got the same behavior, plus layout 
bugs in the file upload submit button.

Each day I get an rsp error in the head.rsp file:
** Script Error : Invalid argument: 2 
	** Where: rsp-script 
	** Near:  [foreach [id prj] head sort/skip/compare skip]

I am running Cheyenne and Curecode on a server at home and then have 
another PC as my normal workstation. So each day when I go to Curecode, 
it throws this error. All I have to do to fix it is to go to the 
server, refresh the curecode page from there and it works on the 
remote machine again. 
Anyone else seen this and have a fix?

Thanks Doc.    P.S. I re-ran an install of CureCode today and it 
is failing on the sql file (build-db.sql)  used to define the data 
base and tables.  I found it and moved it but now I am failing on 
webapp setup.

Doc, a little thing: the title.inc file for 0.9.12 needs to be updated. 
Or perhaps, the zip file is really .11. In any case, still a great 
app.

The ZIP file is 0.9.12, I left an older file version when I built 
the 0.9.12 archive. Issue fixed and 0.9.12 archive re-published. 
Thanks for reporting this issue.

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.

trying 0.9.12 and getting this crash:


        URL  = /bugs/
        File = /home/henrikmk/serve/www/bugs/head.rsp

        ** Script Error : Invalid path value: locals 
        ** Where: repend 
        ** Near:  [request/config/locals/instance 
%title.inc

Ah probably, now CureCode expects that the %mysql-protocol.r be loaded 
externally. The best way to do that is to instruct Cheyenne to load 
it directly by declaring it in the GLOBALS section of the config 
file, like this:

	worker-libs [
		%<path-to-mysql-protocol-folder>/mysql-protocol.r
	]

actually no, I already read through the install.r file and there 
is no reference to anything but SQL queries and a message which contains 
a description of the webapp, but not worker-libs.

You should stop Cheyenne completly, remove the %.rsp-sessions file 
found in Cheyenne working folder, then restart it.

ls -lR | grep sessions

reveals no such file

It's a file starting with a dot (= hidden file), so -lR is not enough 
to list it. Also, it exists only when Cheyenne is not running.

Way back when I reported that I was getting an error with the head.rsp 
file. Well, after being on a fix it binge, I decided to take a look 
at what was going on. It turns out that there were multiple instances 
of Cheyenne running. I am not referring to the multiple instances 
on normally sees but from another build altogether. I still don't 
know where that is getting launched from (I checked the startup and 
all the services etc in msconfig) but by kludging it and renaming 
the build I didn't want, it fixed the issue.

Hi all, I adjusted the  http://www.fm.tul.cz/~ladislav/rebol/timblk.r
file to reflect Steeve's measurement, but would like to obtain more 
results (results for other operating systems). If you have the results 
that are not already in the file, please, let me know.

sorry, it's already in the file., And it's XP SP3

This is the result of speed.r on my machine under Rebol 2.7.5

Console:   0:00:00.150098 - 3372 KC/S

Processor: 0:00:00.249708 - 3460 RHz (REBOL-Hertz)

Memory:    0:00:00.468639 - 101 MB/S
Disk/File: 0:00:00.37127 - 82 MB/S

Rebol [
    file: %prot-rif.r
    title: "RIF protocol"
    author: "Pavel"
    rights: 'PD
    date: 13-Aug-2010
    ]

;; Local functions

Append-RIF: func [port [port!] record [binary!] ][


 write/append port/locals/2 to-binary length? head port/locals/1		;index 
 port the end of data file will be beginning of new record

 write/append port/locals/1 record							        ;data port new record 
 into data file


 return shift length? head port/locals/2 -3					        ;number of 
 records 8 bytes per record
]


Get-RIF: func [ port [port!] i [integer!] /local numentry indexpos 
recpos recend value ][


    numentry: shift length? head port/locals/2 -3                    
       ;number of records 8 bytes per record


 if any [i = 0 i > numentry] [return none]                        
    ;numbering starts at 1 ends at file end


 indexpos: multiply subtract i 1 8					                ;compute index 
 offset
	recpos: to-integer read/seek/part port/locals/2 indexpos 8

  either ( (8 * i) = length? head port/locals/2 ) [				;last record 
  special case
		recend: length? head port/locals/1
		][

  recend: to-integer read/seek/part port/locals/2 add indexpos 8 8		;internal 
  record
		]

 return read/seek/part port/locals/1 recpos subtract recend recpos
]

;; Scheme definition
make-scheme [
	name: 'rif
	title: "RIF Protocol"
	spec: make system/standard/port-spec-head []
    awake: none

	actor: [
		open: func [port [port!] /local path ] [
            parse port/spec/ref [thru #":" 0 2 #"/" path:]
            append port/spec compose [path: (to-file path)]
            port/locals: copy []
            either (0 = length? port/locals) [

                append port/locals open/seek rejoin [port/spec/path ".dat"]

                append port/locals open/seek rejoin [port/spec/path ".idx"]
                ][

                port/locals/1 open/seek rejoin [port/spec/path ".dat"]

                port/locals/2 open/seek rejoin [port/spec/path ".idx"]
            ]
        return port
        ]

        close: func [port [port!]] [
            foreach  port port/locals [close port]
        ]

        read: func [port [port!] /seek number [integer!] ] [
            Get-RIF port number
        ]

        write: func [port [port!] record [binary!]] [
            Append-RIF port record
        ]

    ]
]

It would be interesting to see if there would be a way to make an 
async file scheme using the async or non-blocking file APIs of various 
operating systems. This would be needed to support WinRT-based applications 
for Windows 8, for instance.

It makes sense when dealing with network connections but not with 
the file system IMHO

File I/O can be pretty slow in some cases nowadays, particularly 
for accessing SD cards. I get freezes with AltME pretty often because 
of it waiting for blocking calls.

And If I send a 20MB file it bombs... but you know that ;-). But 
that's not a critism. IMO one just needs to know when a DB can be 
of value to allow small-footprint scaling.

If you're not using innodb, you should switch it off by uncommenting 
skip-innodb in /etc/mysql/my.cnf (default place for the config file). 
This will save you ~70MB. For the remaining 49MB, I don't know, I 
guess that a good part of that is used by caches.

By that I mean it was untolerable slow on some VPS where I assume 
same disc was used for streaming media, update was taking seconds 
while I could on the same system open a 1M rebol data file change 
it and save it back in almost no time. I couldn't get it why this 
is happening, and this was at neglegibly small database. I moved 
whole app that uses sqlite to some vps where it's almost alone on 
whole server because of this. And at Site Assistant where I used 
sqlite only for "mailbox" for bots (to send them work) I had to switch 
to mysql for this (it was the same server that blocked this heavily)

call {"C:\Program Files\Textpad\textpad.exe" file-to-open}

>> length? read http://idisk.me.com/dobeash/Public/rebdb.r
== 12771
>> size? http://idisk.me.com/dobeash/Public/rebdb.r
== none
>> help size?
USAGE:
	SIZE? target

DESCRIPTION:
	Returns the size of a file.
	SIZE? is a function value.

ARGUMENTS:
	target (file! url!)

File extensions: Can we all agree to use .r3 for R3 related scripts? 
IMO a lot of people will use R2 and R3 in parallel for some time. 
Hence, it's necessary to seperate the two to select the correct interpreter 
etc.

but as for me, generally, I don't mind. But as Amigans we always 
hated Windows for making decisions upon stupid file extension :-) 
OTOH if you would like to set associations, it is really better to 
use r3 for R3. That way you can have .r associated with R2 version 
....

You can use .r3 if you like. Aside from file extensions that are 
used by codecs or R3 extensions, the file extension is considered 
irrelevant if you specify it explicitly. One gotcha: If you import 
by module name and the module isn't loaded yet, the process of searching 
the library paths currently only looks for .r files. That can be 
worked around by including a module or script in your project that 
imports those modules explicity by filename - after that the import 
by name method will use the loaded module.

File associations only affect the main script though, not the modules 
it uses. You can't use an Explorer to load a module.

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

rebol[
	file: %carte-joueur.r
]

joueur: make object! [
	id: none
	nom: none
	prenom: none
	date-naissance: none
	adresse: none
	code-postal: none
	commune: none
	pays: none
]

rebol[
	file: %carte-db-joueur.r
]


db-joueur: make object! [
	table: 't_joueurs
	oo: make joueur []
	
	
	list: func[
		o[object!]
		/local
		fields-in-file
		where
		test-nom
		test-prenom
	][
		fields-in-file: select my-db/tables :table
		where: copy []

  if all[(not o/id = 0) (not none? o/id) (not empty? o/id)]  [append 
  where compose [id = (o/id)]]

  if all[(not none? o/nom) (not empty? o/nom)] [append where compose 
  [find nom (o/nom)]]

  if all[(not none? o/prenom) (not empty? o/prenom)] [append where 
  compose [find prenom (o/prenom)]]

   return self/find-where fields-in-file compose/deep [all [(where)]]
	]
	
	find-obj: func[
		o[object!]
		/local
		fields-in-file
		where
	][
		fields-in-file: select my-db/tables :table
		obj: none
		where: copy []
		
		foreach field fields-in-file [
			if not none? o/:field [
				append where compose/deep [(field) = (o/:field)]
			]
		]

  return self/find-where fields-in-file compose/deep [all [(where)]]
	]
	
	find-where: func [
		fields-in-file [block!]
		where[block!]
		/local
		return-list
		data
		obj
	][
		return-list: copy []
		data: copy []	
		obj: none
		either not empty? where [
			data: (db-select/where * :table :where)
		][
			data: (db-select * :table )
		]
		do compose/deep [
			foreach [(fields-in-file)]  [(data)] [
				obj: make oo []
				set obj reduce [(fields-in-file)]
				append return-list obj
			]
		]
		return return-list

	]
	
	insert: func[
		o[object!]
	][
		db-insert :table compose [next (skip get o 1)]
	]
	
	update: func[
		o[object!]
	][
		do compose/deep [db-update/where (table) 
			[(skip select my-db/tables :table 1)]
			[(skip get o 1)]
			compose[id = (o/id)]
		]
	]
	
	delete: func[
		o[object!]
	][
		db-delete/where :table compose[id = (o/id)]
	]

	commit: func[
	][
		db-commit :table
	]
]

Another method of importing modules is supported. If you use do on 
a module file, it will also be imported. This is provided as a convenience, 
because do has been used in REBOL for years as a way to load and 
initialize additional functions and values.

I guess I'm saying that it would be a bug if it were only supposed 
to return the size of the file.  But  if it is to return the size 
of the remainder from the index position then I would say it is buggy. 
 Either way there is a problem with it. I just we keep so that it 
is returning from the index position.

If you ask me it is that head seems to be a problem with the file 
port.

in other words head and next operate on file ports much differently 
then I would have expected.  I would have expected to have to do 
this:

port: head port

but this works:

head port

Next is the same way.

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

6993 wasn't a message, it was a move of 2 of Paul's messages to the 
right heading. Not every number is a message - everything gets a 
number, including headers, moves, deletes, file operations, etc.

Only messages show with n. Some file operations show with nf. Other 
operations don't show at all, except in effect.

IIRC originally we had following specs: read file /part size /skip 
len

because of some complaints with file operations

if file: request-file [
	append files file
]

append/found files request-file

In that case, I usually do 
>> append files [request file []]
no temp var

maybe i wasn't clear. Sorry i readed my post and some things appears 
not to be clear anough... 


1) Rebol runtime environement already exists that's the VM you install 
on your computer when you want to run scripts 

But a) it's not called a runtime environement  b) it's need disappears 
when you use REBO/SDK to "hide" your industrial secrets or when you 
don't want on purpose the client to install or know that  it's rebol 
behind.


2) by speudo compiling (byte code compilation) you allow people that 
need it to be a step closer to the hardware but keeping the portability 
effect so a rebol VM in my opinion should be able to  run both  a 
speudo binary file or a text script rebol file. Of course  like in 
java people would feel the need to share their software with embeded 
 Rebol Runtime Environement.


3) Having a runtime environement is the best modular way ...  core 
will be the base then you have View and lot of othe modules that 
wil clip to rebol. for example if i  put  import  "oracle" at the 
begining of my script then rebol runtime environement knows that 
he need the oracle package and goes to rebol.com to retrieve it and 
install it to the proper rebol runtime place in order for the vm 
to find it. Something close to what apt-get is to debian. REbol Environement 
doesn't comes with the whole thing but if the script tells it he 
can expend it selves in the fastest way. Well this runtime organisaton 
in  fact already exists but it's not pushed to it's extend, you know 
the point where the good idea become the best idea. the rebol/view 
2 implies a /desktop which implies a local scrit library (like a 
cache) to store the rebol script see the idea is there but once again 
it's not pushed to it's limits. Only rebgui used this system to store 
an extension to rebol.


4) by being closer to what people extend as an output you make them 
interessted in your input . To be more explicite by giving to peope 
what they are used to get in the end of their creation process then 
you allow them to be confident in your solution and to be more interressted 
on the way you propose to build your software.


5) i took java and .net as main example but if you look closely this 
is an expending tendency. For example Adobe Flash do that.


6) the other interrest in the compiled way is to merge the source 
code and the related resourcies at the same place (1.exe  file for 
example) and then forbiding the people to change their contents ... 
and this leaded then to the skining my application modo. Wich is 
just the we don't merge in the resulting binary the resourcies . 
In rebol we can already easyly build a script merger with data to 
output a .r file containing both but then people can still extract 
the ressourcies and change them etc...

and since rebol script are  most of the time very tiny in size  i 
don't see the interest of having an updated scheme looking like what 
is done on the other laguages. I htink it should be a cool thing 
to be able somehow to substitute anytime the file on my computer 
and then  autoreload it in memory without having to restart the application 
and if i could trash out  from memory of the VM the previous script 
that wuld be even nicer ....

yeah in fact i could do this check the version then download the 
new version from server maning the file .TMP then create from my 
script a install-app.r  and call it then close the current app

and have that temporary script install-app.r to rename the .TMP file 
to my main script and then start the app. It could display popup 
message like "Configuring the new version please be patient..."

but it's lot of work for a thing i will be the only one to use ... 
and that's not the meaning of my ask ...

the function doing update could work as follows:

update: func [
    {updates the current application}
    application-file [file!] {the current application}
    tmp-file [file!] {a temporary file}
    source {updates from this source}
] [
    if exists? tmp-file [delete tmp-file]

    ; now we can rename the application-file, since the tmp-file does 
    not exist

    rename application-file tmp-file ; I guess, that this works, even 
    if the application is running?
    write/binary application-file read/binary source
    call application-file
    quit
]

The easiest way to do this is to maintain your source in an encrypted 
and signed compressed binary.  So, you have the stub which does the 
update and executes the source.  It checks for new source, overwrites 
the old one and then executes it.  Since it is not updating the exe, 
there are no file locking issues.

renaming won't work if there is a file lock on it

Ahh.. but it locks the tmp-file instead

so, to be sure you have to make sure that the tmp-file is not locked, 
or does not exist

Shadwolf, for scripts, there is no file locking. So the process is 
much easier if you are getting and writing the new script, saving 
your data, shutting down and starting up with the new script (similar 
to what Ladislav's function is doing for exes). If you just want 
to reload the script in place in the current interpreter instance, 
you have to do the live state migration I mentioned above.

I have a XML file and want to handle it by tags like a nested block. 
Are there are any tricks? Or do I need to use PARSE / FIND etc.

maybe the file you got from the link you posted is only core?

I was trying to make a build with r3-gui.r included, but when running 
the generation step of the build make-host-init.r outputs the error 
"Invalid tuple -- 2.147484e9x2.147484e9" when processing this file. 
Is there something wrong with this tuple?

strange load behaviour.....   it doesn't load a file as rebol data... 
its only a string... I just had to do:

load load %datafile.r

just like if I was doing:

load read %datafile.r

it seems to be related to the extension....  only a file with .r 
as extension is loaded as data... this insn't very cool.

the file name actually didn't have the .r in my script.

ok, your compile also crashes  on my system... strange!


we need others to test this.... please, if you have a running r3 
A107 try it out so I make as precise a ticket as I can.


if it doesn't crash, download the file and try to add a few (or many) 
draw commands to it so see if it fails at some point.

Otherwise, here is one, feel free to optimize:

delete-dir: func [dir /only criteria] [
	dir: clean-path dir
	foreach file read dir [
		if any [not only do func [file] criteria file] [
			file: dir/:file
			if dir? file [delete-dir file]
			delete file
		]
	]
]

Optimizing file deletes means first avoiding the standard DELETE 
func. It reads the dir each time which can kill you if you have a 
large dir or, heaven forbid, point it at an FTP location. You can 
build on CLEAR easily though.

    delete-all-files-in-dir: func [dir /local port] [
        port: open dir
        clear port
        close port
    ]


I think my tree deleters all rely on some of my other stuff, like 
FILE-LIST and DO-IN-DIR (now standard as IN-DIR). They generally 
have a callback option as well, so you can track progress.

Also not sure if it works the same way with R3 file ports.

Well, guess it's just the error message that is misleading, as CLEAR 
still works on file ports.

From a quick glance at the host kit, I think implementing it would 
be rather easy (basically another special case for RFM_TRUNCATE for 
RFM_DIR in Write_File in dev-file.c). But wiring it up to the directory 
port actor is beyond our freedoms with the hostkit, I think.

Now for the other binding stuff:


* SET is a low-level function that would be slowed down immensely 
by adding any refinements.

* SET does handle the unbound scenario: It triggers an error. You 
can then handle the error.

* R2 and R3 get their speed from the direct binding model. The core 
speedup of that model is that SET doesn't bind.


* LOAD in R3 is a high-level mezzanine function. It is meant to be 
as fast as possible given its purpose, but being fast is not its 
main goal; user-level flexibility is. Most of the overhead of LOAD 
is in handling all of its various options, as refinements, file extensions 
and script header settings. If you know what you are doing, you can 
always optimize your code by doing it directly instead of having 
LOAD try to figure out that is what you want to do. LOAD is not meant 
for use in tight loops.


* Henrik, ChristianE, the R3 standard answer to the question of how 
to make BIND TO-WORD "a" more efficient or friendly in R3 is this: 
You are encouraged to not program that way in R3. Converting strings 
to words is something you should do once, not all the time in tight 
loops. Your code will be much more efficient if you work in REBOL 
data rather than storing your code in strings and converting at runtime. 
Strings are for data, or script source, not for containing scripts 
at runtime. This is a good rule for all REBOL versions, but especially 
for R3 with its Unicode strings vs. shared UTF-8 words.


* I have recently refactored LOAD so that it is broken into smaller, 
more efficient functions. You might find that those functions would 
work better for you in lower-level code. But this was done to let 
us make LOAD *more* powerful, not less, so the same advice I gave 
above about not using LOAD in tight loops still applies. I don't 
yet know if the new LOAD is faster or slower, but it is safer and 
easier to understand and modify, and you can make your own LOAD replacement 
that calls the same low-level functions if you like. Plus, you get 
compressed scripts :)

All I needed to know in the past is, that for CGI I need fast system, 
which will not load unnecessary code, e.g. help, etc. Hence I used 
/base executable. Now:


base - initialize only the lower levels. This option is for special 
purpose testing only because it provides no way to load external 
code. (No schemes, such as file access, nor load or do functions.) 
If your host-kit build is crashing on startup, you can use this option 
to confirm that the exe image is loadable and runable.


sys - initialize up to and including the basic runtime lib and sys 
contexts. This option allows you to run a very "lean" system (minimal 
memory and boot time) where your code will be supplying all other 
run-time functions and modules. Provides a basic load function but 
with very limited special options (no import, needs, versions, or 
related features.)


mods - initialize up to and including lower-level resident modules. 
In addition to boot-sys, this level adds high-priority resident modules, 
but not mezz plus (higher level mezzanines).

now whether PUT can stream a file off the filesystem

What are the registered filetypes in the more recent builds? What 
is the consequence of a file type being registered? Is there any 
documentation?

tried A108 from console, and got:

** Script error: clean-path word is not bound to a context
** Where: if -applier-

** Near: if slash <> first boot [boot: clean-path boot] home: file: 
f...

OK, then it wasclearly my wrong guess :-) btw - how do you list unnamed 
modules in the module list then? or we don't? I thought that unnamed 
modules are auto-named according the file-name, but that would not 
be suficient anyway, as 1) one filename can contain multiple modules 
2) it still does not solve the case, when you create module e.g. 
in console manually ...

Pekr, Andreas is right. The problem is that the 'flag' if the app 
is of Console or GUI type is set at compile time. So when you execute 
file th Windows kernel just checks that flag and if set to 'Console' 
immediately creates console *before* the main() of your programm 
is called. So even if you put: ShowWindow(console, SW_HIDE); as the 
first command in your app you'll always see the console window for 
a while, which is not so nice ;)

I'm using hashes to cache directory contents. They need to be case 
sensitive to support Unix file systems. Now I have a problem with 
porting to R3

Binary is treated case-sensitively. Convert the file names to binary.

Say I have a huge file, there are some grabage bytes in its tail. 
How can I truncate it? Remove doesn't work on the file port.

BTW the file couldn't be truncated from R3 I think (no func option 
available for this) but similarly as udp truncation is mentioned 
in c sources of host kit.

If you look here: http://rebol-power-mez.hg.sourceforge.net/hgweb/rebol-power-mez/rebol-power-mez/file/68b9806fc1a1/mezz/html-to-text.rlp

Gabriele likes what is called "literate programing". RLP is his own 
processor that implements it. The .rpl files are the source of both 
the .r code files and the .html doc files, one .rlp generates both. 
If you want to understand his code, either read the .html or the 
.rlp file; the .r file is not formatted for human consumption.

of note, if you have the normal package, from windows you can go 
to tools/ and double click on wetan-test.r (assuming you have View 
associated with .r files), and it will just ask you for a file to 
process. select any of the .rlp file to process it and produce .html 
and .r files.


make is only required if you want everything to happen automatically. 
i'm not sure if it is obscure, as it is the tool used by basically 
every C programmer on this planet since 1980 or so...

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.

Oops -- Didn't see the malformed file path!!!

Where can I find  examples of how to use Power Mezz?

The particular script I am writing is called GET ADDRESS.  This script 
takes a CSV file called contacts which has first and last name, city 
and state of all of my friends that I'd like to get addresses for 
Christmas cards, but have forgotten or misplaced.


So far, the script takes each entry and sends it to SUPERPAGES.com 
where the HTML sent back contains the information.  Right now, I'm 
simply saving the HTML as a file for each entry in my CSV.


What I would like to do is somehow parse the HTML from it and extract 
out the address lines, zip code, phone number etc.  But I admit that 
parsing through HTML is daunting to me.  So after looking around 
on the internet, I discovered HTML-TO-TEXT in your Power Mezz.  


That is where I am now, trying to figure it out and see how it works. 
 I've read some of your documentation, but I admit, I am still in 
the dark as to how it works -- at least for my application.  Any 
advice you have is welcome.

Thanks in advance.

I agree as well... mostly peope would like to use /library instead 
of extensions to do simple things like:
kernel32.dll: load/library %kernel32.dll
set 'MoveFile make routine! [
		"Moves file using OS"
    lpExistingFileName  [string!]
    lpNewFileName [string!]
] kernel32.dll "MoveFileA"

We don't want to download MS sources from MSDN to parse headers and 
integrate everything what's in kernel32.dll. Of course it may be 
cool in some cases, but we should keep it simple where possible.

for example actually being lua ruby or python most of their "regular" 
use  are to be merge as plugin into a host application that shares 
data with them Allowing to set up a base that will not change and 
an extention that will be faster to create ... This point is still 
in my opinion a strutural problem in rebol since in rebol data structure 
are hum ... special  and cool. 


One thing you can't do in rebol and that will miss us alot is for 
example the hability to create a ready made structure  in memory 
and map a file content directly to it. (For example in case of  "memory 
dumped files" in C ...) I could provide a detailled example but i 
think most of you saw what was my point...

@ shadwolf, wrt memory dumping of structs... yes... easy.  they will 
be flat memory chunks in RAM, managed with malloc/free  so we could 
easily just dump the bits to a file.