AltME groups: search

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 ;-)

show why it is important to do something like this and not like that 
(performance, re-use of code,maintenance of code, etc...)

Henrik are you saying that Carl will not bring back the R2 console? 
 - trying to sort out yours and Grahams responses.

And I'm saying that Carl agreed to bring back the R2 console for 
the Windows version of R3

Henrik and Graham, thanks for the update.

Datatype differences between R2 and R3:

Removed
	any-block!
	any-function!
	any-string!
	any-type!
	any-word!
	context!
	hash!
	list!
	number!
	routine!
	series!
	symbol!

Added
	closure!
	command!
	frame!
	get-path!
	gob!
	handle!
	map!
	module!
	percent!
	rebcode!
	task!
	typeset!
	utype!
	vector!

and routine! will be probably removed too,no?

frame! is used in extensions as well. There It's a linked/cascaded 
data-structure to get access to call parameters and construct return 
values like block!

Pekr, routine! was already removed, replaced with command!. The library!, 
rebcode!, and struct! types are just placeholders that haven't been 
removed or replaced yet. Don't count on them being there in the future.

Using DOS (tested with VISTA and XP) I can launch my editor with:
>>start textpad

But how can I do that with the Rebol CALL function. It's doesn"t 
seems to work...

Jeez i wasted my time to develop a script to launch remote commands 
from an AS400 on my PC using FTP.

And I fail on the finish line because CALL don't do the last easy 
part of the job.
T_T

Yes it does, you just need to look at cmd /? and start /? instructions 
if you are going to use those rather than calling Textpad directly.

I think I'm going to refer to them from now on as, chat and wiki 
...!

I only make the distinction between chat and DevBase for technical 
reasons.

I think we should factor them .. and remove the redundant 'Base ...

As you can see the TRETBASE group has really been picking up - this 
is because I'm busy porting the older Tretbase DBMS to R3 and finding 
problems along the way so I'm going to post some of the problem here 
to see if anyone else is seeing the same.

Are modules working correctly?

>> system/version
== 2.100.96.2.5
>> import http://www.rebol.it/power-mezz/mezz/form-error.r
>> source form-error
form-error undefined


Also, are the Imports and Globals fields (as used in Gab's Power 
Mezz) supported? ... http://www.rebol.com/r3/docs/concepts/modules-defining.html#section-3

Gabriele's modules aren't compatible with R3 modules, and the Power 
Mezz package is for R2 (so far).

What's the easiest way (under R3) to write code like this:

f: make function! [[][
	cols: [c1 c2]
	data: [2 4]
	cmd: [c1 + c2]
	set cols data
	do cmd
]


without adding words to the global context? (and not predefining 
c1, c2, etc).

Use FUNCT to define the function and use cols: [c1: c2:].

FUNC in R3 does a COPY/deep of its spec and code blocks, so it's 
safe to use here.

Max - it is just a structure, which was reshapen, and the page was 
also de-stylled. The layout, styling and gfx of the new site is not 
done yet, as well as front page segmentation for particular target 
groups interests ...

but already looks and feels better.

he did post on the blogs about what he's been doing and that he is 
now back to R3 coding.

Hi James.   There's actually an outline mode in the new wiki... so 
it's very easy to maintain and update this list.

BTW, the website looks nice and it's fast. I miss the link to the 
 script library though.

My regards to Cindy and your kids. I'll get out of the way for the 
"real" rebol troops. Thanks for all your effort. See you at the Devcon 
:-)

With the progress Graham, Andreas, and Steeve (and maybe others I've 
missed) have made on schemes, I would like to see their momentum 
and work leveraged. 


The host kit is probably also very important, so others can pursue 
that. Redirection, for writing pipe and filter apps. If the GUI console 
for Windows isn't too hard, that would be great IMO.

Working on compressed modules this week, inline export already done, 
protected header fields waiting on PROTECT fixes. It would be really 
helpful for there to be a discussion about the design requirements 
for embedded deferred init modules.


Really looking forward to host kit changes. Waiting on READ/as and 
WRITE/as before I start improving the clipboard:// scheme.

here's a personal wishlist:


1. a license for the hostkit, which would allow us to publish and 
distribute patches and custom builds. this would be a necessary precondition 
to bootstrap a healthy hostkit ecosystem (if such a thing is desired).


2. documentation of more hostkit intricacies, such as "documenting 
the boot script build method" mentioned on the priorities page. another 
pet peeve of mine would be documentation on how to add new native 
port types (such as ssl). and fixes (if any) to enable creation of 
such native ports by only touching mezzanines and the host kit.

3. a libr3.dylib built for osx.

right now flushing out (finishing) the extensions is actually the 
most enabling.  so: 


1.  Releasing the view host-kit with improved extensions would be 
the first step into finishing WHAT the first R3 beta will be, in 
terms of architecture. Right now, there are a lot of datatypes missing, 
and a proper REBOL callback mechanism *** with return value***  is 
probably the most frustrating issue with R3 extensibility.  image 
and vector types are critical to extensions... please they have to 
be part of next extensions.


2. Schemes!!!   with a lot of work ALREADY done,  plus willing and 
able helpers, Carl, you should REALLY look into this and orient the 
spontaneous team that is dying to get your attention so they can 
proceed FOR YOU.


3. Documentation ... I'd say.. .TWO complete and final pages a day... 
no need to do more.   At that rate, the documentation will be much 
more helpfull within weeks.  But sections of it will start to be 
worthy of being called documentation... right now... I'd call it 
the "sprawled notes" part of the site.

Let's see:
- 1.6 depends on 1.2, and 1.3, 1.5 and 1.6 are related to these
- 2.1 and 4.3 depends on 1.1 (probably)
- 2.2 depends on 1.6 (probably)
- 3.3 depends on 2.1, 3.1 and 3.2
- 4.1 is written and submitted already
- 4.2 is in process
- 4.3 is waiting for discussion
- 4.4 depends on 7.1

- Clipboard support for other formats than text depends on 5.1 and 
5.2
- 7.3 and 7.4 will probably use the same code
- 8.2 depends on 5.7

- 8.5 (and secure use of R3) depends on 5.5, 5.8, 7.1, 7.2 and possibly 
6.2
Those are the dependencies I can see in the R3 priorities list.

now topo-sort it, break cycles and off you go :)

Priorities not in the priorities list:

- User-addable devices in the host, and device extensions (probably 
the same mechanism) in section 1
- SSL in section 8

but don't see why this is bad, its very confined... I mean... its 
not like we're going to start seeing this in code:

do [cd]

just so we can supply less arguments and slow down our code.

Most important from my perspective:

- finish Extension enhancements
- finish Host enhancements
- move View to the enhanced command! interface

both to the state, that ppl can fully exploit those features.

- multitasking


... for Doc starting to port Cheyenne as mostly the only one REBOL 
killer product

- support porting efforts, get us to the mobile devices (ARM)


... as for Console and some other items - yes it sucks to not have 
them available, but I think that having strong infrastructure in-place 
is really important. But overall we need all the priority list implemented 
for R3 being worth calling a beta ...

... and someone damned fix the useless 'call function :-)

.... some ppl also requested enhanced /library interface being done 
as an extension. I started by donating 100USD, and now we are at 
someting like 400 USD ppl would pay for such a feature. So, what 
do we sponsor next? :-)

Can't reach rebol.com and rebol.net ...

Well, that was odd ... and I couldn't see any r3 updates either!

those fixes started. Look at CC, first 6 bugs fixed, and I hope the 
list of fixes will be even bigger for next version ...

host kit will give a bit of parallel work done (Robert, Cyphre, BrianH 
and Maxim are all waiting), but I guess it's up to what motivates 
Carl currently.

If that is the case Henrik, then I'm all for hostkit to get built. 
 I just don't want to see us have to keep building hostkits for minor 
changes.  Better to make more changes to core and then less to hostkit 
unless the hostkit build will bring something new to the table as 
your implying.

host kit will fix remaining graphics issues, which Cyphre is already 
preparing. It will also help prepare for a better console for all 
platforms. Robert and Maxim has done various implementations (OpenGL, 
SQLite) and are doing general tests. BrianH, I can't remember what 
he's doing...

Fixed tickets now at 14 and counting :-) A good sign R3 is back in 
development, although over time we do have few tens of tickets to 
implement :-)

That produces an error for higher values of 2.

This should produce an int when it can, and a dec when it can't, 
though only for positive values of 2:

   pow: func [a b /local res][attempt [res: to-integer res: power a 
   b] res]

is Android and the iPhone platforms under consideration?

yes, it is in priority plan, to get build for ARM and possibly other 
platforms ...

Ashley, scalar! means that the type can be operated on by *, /, + 
and -, not that it can be converted from integer.

Oh yeah, and it is much appreciated :)

He's still sing the queue-with-timeouts priority model. The hostkit 
got put on hold while some of the timed out items were handled: R2, 
the web site, and now bug fixes.

I got a big project I want to turn off of R3DBMS and need many of 
these core fixes.

A97 released for Windows and OS-X with over 40 fixes. Can't be reached 
by 'upgrade function though, probably due to website changes. You 
can find it here: http://www.rebol.com/r3/downloads.html

Here's the proposal for compressed scripts/modules: http://curecode.org/rebol3/ticket.rsp?id=1466

And the original blog (complete with comment flame war): http://www.rebol.net/r3blogs/0274.html

The previous build worked fine but this one gives me an error and 
I can't execute my functions.  Currently my script has a halt at 
the end and I just run it and execute the functions from the console.

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.

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.

FUNC does a COPY/deep of its spec and code block, for safety and 
recursion-safe use within functions (see the source of COLLECT for 
an example of this). However, the internal code uses a non-copying 
version to lower overhead. That non-copying version is assigned to 
FUNCO as the last thing, and the copying version assigned to FUNC. 
FUNCO is left defined for power users who can asses the safety of 
not copying their function specs and bodies.

And before you ask, I don't know what EVAL is used for either, just 
what it does: It does a DO on block! arguments, but returns the argument 
unevaluated otherwise. I've asked Carl what it's used for and haven't 
gotten an answer yet.

TO-TYPESET creates typeset! values. We don't have R2's pseudo-datatypes 
like series! anymore, we now have typeset!, sort-of an immediate 
bitset for datatypes. It speeds up function calling and allows all 
sorts of other things. I backported a fake version of typesets to 
R2 as well in the 2.7.7 release.

TYPES-OF function! returns a block of argument words and typesets.

Docs need more examples.  If someone just went thought the R3 Functions 
page and separted it into a seciton that says NEW in R3 and explained 
those and gave an example for each we would have awesome docs.

Brian, please add that .r3 scripts are searched for as well. And 
that .r3 takes priority over .r if filenames are the same.

The strategy that seems to work best is to have platform-specific 
scripts in different directories and set system/options/module-paths 
to pick the sets of files that are appropriate.

And since the module lookup process doesn't apply to scripts, this 
is a bit of a non-issue.

Recently I made some tests comparing the speed of  R3 to R2.

After getting results of R3  up to 100 times slowlier than R2 and 
more, I found that parse is now almost unusable for simple parsing 
under some circumstances.

I will later add a Curecode ticket.

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?

The data I parse, are oftly in the 10s of MB and more.
With R2 I had no problems

Hmm... tried to parse 4M chars a few times and r2 ran out of memory 
... r3 worked fine

I would curecode it, along with my example, and ask Carl about the 
possible cause ...

I did it already.

But your example does not show the real problem. just use my example 
and you will see why.

and this is the windows console

I tried that code in R2 and R3.....R3 took about twice the memory.

UNICODE strings plus unoptimised data structures may account for 
the difference.

Worth noting too perhaps: after trying the test three times, unsetting 
'c and 'm and recycling .... R3 got stuck trying to get into 'chat 

Possibly some screwed up garbage collection when recycling large 
elements? The failure is repeatable.

of note, you don't see that from the website, but the repository 
includes a test suite and benchmark suite as well. they are undocumented... 
but i guess they can be useful for other projects as well...

if i had the time, i would add everything to the power mezz. the 
detective stuff needs some work though before being added here. (convert 
to a module, change the format, add tests if possible, and so on)

Thankyou for that, I can particularly relate to "reduce the need 
of reinventing the wheel for each developer"! Documentation is first 
rate as well (both presentation and content). Congrats to all involved.

(HTML to Text needs to be rewritten as it's still using the old normalize-html 
function. load-html is much faster and much better...)

1) Download the built zip, or download the scripts individually from 
http://www.rebol.it/power-mezz/. (Of course it would be nice to 
get the whole repo and setup your system to be able to make changes 
as well. It currently requires GNU Make, however, those crazy people 
still using Windows could rewrite remake.r to do all the work.)

however, I recommend the former as I don't like making things global 
and I will remove that eventually

First of all.. thanks for making this and making it awailable. I 
am working with emails now for usrjoy and if I would have to manaually 
detect and decode (or write all this) various encodings in subject 
or content I would just shoot myself (like quoted printable / base64 
).

I can use decode-email-field to decode various encodings of subject. 
But I wasn't able to figure out how can I decode the content of an 
email which is in my case encoded with quoted-printable / utf8 . 


I found to-netmsg library on codeconscius.com code that loads the 
email text and parses it into structure. It doesn't decode the subject 
=?UTF-8?B...?= but it does the content. I could use that and power 
mezz to get the effect I want. If there is a way to encode content 
in power-mezz I would rather use it alone.

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.

So this: %./ wasted 2 hours of my precious Saturday! I hate dots 
and slashes.

Well, well. I thought I could just type and things heppen. I actually 
need to read code. Bummer. This guy, BrianH, is a heartless man.

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.

I am not an RLP advocate, for good reasons, but it has its fans and 
I respect that. It's a matter of taste.

Note, I mean that I am not a LP advocate. However, if you are a LP 
fan, I *definitely* recommend RLP, it's a great implementation of 
the LP concept and a great piece of code.

Florin, if you go here: http://sourceforge.net/projects/rebol-power-mez/files/


you'll find power-mezz-built-1.0.0.zip which contains pre-built .r 
scripts. Inside tools/ , there is a module-console.r which defines 
a IMPORT function so that you can just write "import %mezz/load-html.r" 
and have its exported words available in the console.

Otherwise, from your own code:

    do %<path to power-mezz>/mezz/module.r
    load-module/from %<path to power-mezz>

    module [
        Imports: [%mezz/load-html.r]
    ] [
        ; your code that uses load-html
    ]

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...

Gabriele, thank you so much. I realize that you don't like to litter 
the global namespace, yet I doubt that (poking) ~Humor should have 
it's own group on Altme. I barely get an hour every now and then 
for Rebol so I appreciate all the shortcuts that I can get. I need 
to change my name to Nonchalant. You guys are an awesome bunch.

And I did get it work to this point:
** Script Error: make-node has no value
** Where: context
** Near: root: current-node: make-node 'root

Gabriele, thanks, it worked. I downloaded the build provided from 
above and it worked. Thank you.

Here now, Anyone have ideas on how to use Power-Mezz for the beginner?

Also, what is the difference between power-mezz-1.0.0 and power-mezz-built-1.0.0?

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.

To be honest, if you just like to parse some HTML page to get some 
parts of it, you don't need to use Power Mezz at all.. I'm using 
Rebol more than 10 years and still consider PM as a too complex staff 
for me. If you are REBOL newbie, better to start reading REBOL doc. 
In your case something about parsing.

Yeah, there's some tipping point in parsing web pages and such. When 
the pages are consistent and the data you want to scrape is simple, 
I use PARSE, too, or even just string processing

But when the HTML and the data become more complex, there are so 
many exceptions you have to program, that a real HTML parser becomes 
more convenient

a good one would be to convert R3 rich text to HTML and vice versa.

Kaj, I think it's the other way around! I found when the HTML and 
the data become more complex, then a simpler "hack" parse job is 
more likely to survive changes to the source. This happened to me 
several times with a weather forecast and television guide scraper 
etc. that I made (and remade, and remade..).