AltME groups: search

My first attempt with extensions failed quickly.  I tried:
>> secure [extension allow]
>> import %libwmp3.dll

and got this error:

** access error: cannot open: %libwmp3.dll reason: none


libwmp3.dll is available at http://www.inet.hr/~zcindori/libwmp3/index.html
, an
d I've gotten it working in REBOL2

Any suggestions?


PS - that fact that we need to include "secure [extension allow]" 
should really

be included at http://rebol.com/r3/docs/concepts/extensions-using.html
!

(http://rebol.com/r3/docs/concepts/extensions-making.html)

(http://www.ogre3d.org/docs/api/html/hierarchy.html)  but extremely 
well documented...

I have coded a simple Text To Speech Extension, using SAPI5:
http://colineau.societeg.com/rebol/R3_extensions.html

I would be interested to know any other experience in R3 extensions

Are there Matlab users ? Going on in my investigation of the extensions, 
I have created an extension for executing Matlab instructions from 
R3, by calling the Matlab engine. Exe and source are here : http://colineau.societeg.com/rebol/R3_extensions.html
.

Rebolek, about documentation, feel free to use NicomDoc: http://www.fys.ku.dk/~niclasen/nicomdoc/

It can easily produce HTML output as (MakeDoc), but also PDF output 
by first producing LaTeX.

rebolek, I will definitely check this out.  if you have any docs 
converted to html, I will read them, so know it will not have been 
done in vain ;-)

because of web site availability problems, i have changed my site 
: you will find here the three  "experimental" extensions that I 
have done to learn the extension mechanism : a text to speech extension, 
a matlab engine extension, a simple windows api extension with some 
useful calls : http://www.colineau.fr/rebol/R3_extensions.html

http://www.rebol.com/r3/notes/command-blocks.html

http://bolka.at/2010/rebol3/CMakeLists.txt.html

There are a number of bad links in the extensions-embedded.html document 
... are they just docs yet to written? Or has the doc been moved 
destroying the links?

So this http://doc.trolltech.com/3.3/sql.html#4should work for 
DB access for R3

Note that while my sample.c it may _look_ just like the example given 
in http://www.rebol.com/r3/docs/concepts/extensions-making.html#section-2, 
it differs in that `RX_Call` takes three arguments instead of two.

http://www.rebol.com/r3/docs/concepts/extensions-making.html#section-17
says it's out of date and I'm really having trouble including words 
as symbols in a result block of an extension command. 

It works fine with an *INIT_BLOCK defined as


 const char *init_block = "REBOL [\nTitle: {Power Management}\nName: 
 power\nType: extension\nExports: [power-status]\n]\n"

     "lib-boot:           does [map-words words] ;-- Is that a good idea?\n"

     "words:             [ac-line battery remains of high low critical 
     charging]\n"
	    "map-words:    command [words [block!]]\n"
	    "power-status: command []\n"
;

if after IMPORT %power.dll I call SYSTEM/MODULES/POWER/LIB-BOOT.


Is there a way to have IMPORT automatically execute the LIB-BOOT 
code with a simple extension not included into the host code with 
host-kit?

Where to start when I would like to learn how to write own extension? 
This page is out -of-date:/
http://www.rebol.com/r3/docs/concepts/extensions-examples.html

I did several extensions for windows, and you can find the source 
code and the dlls here: http://www.colineau.fr/rebol/R3_extensions.html
. This code may not be up to date, but recently I have compiled new 
versions. If necessary, I can upload them.

pages updated with the new versions (binaries and sources) compatibles 
a110 :
http://www.colineau.fr/rebol/R3_extensions.html

Updated my ImageMagick extension and doc. It is now possible to exchange 
image data between Rebol and ImageMagick without using disk files, 
thanks to the "mpr:" (memory program register) format which allows 
in-memory save and recover.

http://www.colineau.fr/rebol/R3_extensions.html(refresh the page 
in your web navigator)

http://www.diefettenjahresindvorbei.de/odbc/odbc-docs.html

to me a lot of this discussion resembles HTML table box model discussion... 
maybe you should look into how they solved the various issues.


for example, cells can "span", which is an elegent way to solve the 
gaps in cell data.

Yes, I think tables are key here (tbl did spanning long before HTML 
I believe :-). Do H and V panels help that much, e.g. to reduce clutter? 
I imagine the team talked about that, and whether just a TABLE would 
be enough.

How do I easily turn docs into html, readable along with images?

Googledocs can turn a doc into html ...

there are lots of different paths ... doc -> pdf -> html is one

could it be included in the distro, or even maybe better, to provide 
html version directly?

well, you could run it via some automat script which makes your builds, 
to get us html, no?

do you guys have an html version of that?  I don't have mdp setup.

no html needed when you just need to copy a part of it and do

I vote for the MDP docs being added into the distro, if possible 
... or their generated html variant ...

HTML docs are online.

Now if I would think about comparing R3 GUI to html/css, then I am 
not able to compare it in my head, but doesn't inline CSS allow to 
override class setting?

Yes, CSS allows this using STYLE, and it gets painful, when you start 
doing that, riddling HTML with CSS code. The reasons are the same 
here by avoiding to apply proper meaning to the HTML code, when using 
STYLE.

Think of the layout dialect as HTML with no formatting, and all of 
the formatting in the CSS. Does that make sense?

In HTML you can also specify values that are not reflected in the 
resulting page so what?

Cyphre: "In HTML you can also specify values that are not reflected 
in the resulting page so what?" -- which one? What I know, if you 
use propper CSS, you have exactly what you want.

Oldes, there is lot of different quirks where the html definition 
doesn't work as it should, especialley between different browsers. 
Or do you want to argue about this? Just check all the html/css quirks 
related websites.

I think most of these quirks are gone with the new browsers. If I 
want clickable floating box of exact size, I will get it in HTML.

Pekr: looks, that you will get more examples from Cyphre, who promised 
to pack some and make them available. So, I am afraid, that at the 
time being, you only have the examples from the gui-panels.html text 
available.

Posted my evaluation on the compatibility of r3-gui (release v1993 
dated 2011-03-04) with the standard release (recompiled) of r3 : 
r3-a111. Result: very good. 
http://www.colineau.fr/rebol/r3-gui.html

cascadign: that's how CSS works with HTML

I have not intention right now to burry deep into CSS, as I think 
I know enough to understand consequences. Your "you are wrong here" 
does not work for me :-) Wrong in what aspect? I still think, that 
I do understand how you style html pages :-)

Cyphre - I can simply imagine, how we extend stylize to allow such 
definitions. But - in terms of html, you have IDs, CLASSes, and you 
have also the document tree, so you might know, where to apply which 
part of an CSS. What I can't imagine is - we have layout flow ... 
and no ID, CLASS definitions, we also don't keep tree information 
of the layout (faces), or do we? So how do you instruct, in your 
layout, that first button in the panel should use button-red definition? 
Just curious about what possibilities there are :-)

In R3 GUI, style names themselves act as classes, where in HTML you 
have a fixed set of tags that need to have classes. IDs are set-word!s, 
so there is no need to add any superfluous layer to identify specific 
faces.

Maxim, this is necessary in HTML, because of the fixed naming of 
HTML tags. set-words in the R3 GUI do this.

(in html)

yes, class in html is just an 'group-id'

classes in html/css really act as associative tags.  

in GLASS I am using #issue to simulate html class="label"

So your saying that in R3 GUI, classess are not usefull, is an incorrect 
statement, as we already do have classes? Or what you would call 
your 'my-button then?

 - A style is not a class in the HTML sense, where you can apply a 
 particular class to any tag.

the method I posted is exactly what you need to do in order to allow 
such a change

. Not sure - my idea was to use only "Button" name in the layout, 
not my-button, and diversify upon e.g. where the button is placed 
... but otoh even  in CSS/html, in most cases, you have to specify 
class or id, and hence my-button is kind of equivalent - you have 
to declare the special case. But - not sure all aspects of CSS are 
usefull to us.

ALIGN, VALIGN - this is same naming as in HTML, so you can expect 
most people be familiar with it.

as for alignment - from html I do remember align="left | right | 
center" .....

align and valign are pretty standard names if you've ever seen HTML, 
what's so confusing about them?

as I said - in html align = left | right | center ...

ok, my question towards the align, valign. I know we might want to 
be "compatible" to html, but to stay consistent - we have vpanel, 
and hpanel, not vpanel and panel. Wouldn't it be wise to use valign, 
halign too?

Some comments:

-the TEXT style in the release has incorrect resizing settings so 
it makes layouts that are being resized ugly. We'll fix that.


-regarding the introduced and discussed:  options [box-model: 'some-word] 

The defined word! symbol should specifiy box-model preset. By 'box-model 
preset' we mean group of facets attributes that affect the box-model 
settings of the specific face/style. So this option is IMO correctly 
named.

Currently the box-model option was added as temporary solution to 
the PANEL style only. But in the next release it will be possible 
to set it on any face in the layout or style definiton. Also we'll 
add basic set of such box-model presets that will be part of the 
system by default.


-ALIGN vs. HALIGN: yes, we borrowed the terms ALIGN/VALIGN from HTML(but 
note, it is used also in R2 font object and in R3 para object) . 
As people today are familliar with it and have it 'wired' in their 
heads using the same name could avoid silly bugs in their code.

I presonally don't think this must be consistent with names of styles 
but if majority people insist of such kind of consistency we would 
probably need to unify also the align word in the PARA object as 
well.

Cyphre:

box-model:
---------------


Few notes. Certain systems use FLAGs, which could be thought about 
as kind of switches, or representing certains states, etc., used 
in binary masks for e.g. Then we have TAGs. Even R3 GUI uses tagging 
- it is used mostly to mark particular face as behaving some way, 
belonging to some area, etc. And in that regard, I wonder if box-model 
type could be done just by using TAGs? 


What I think about TAGs in GUI in general is, that we don't use the 
concept to the max. I mean - if tags were not be flat block, but 
block of blocks, it could be used even more, e.g.:


tags: [box-model [tag1 tag2 tag3] style [internal] draw-mode [normal] 
resizing-mode [.....] ....]


Of course that might not work for us in all cases, because as you 
could see in above example, it would be difficult to distinguish, 
if something should be a facet, or a tag. E.g. if we would move DRAW-MODE 
into TAGS, then why not moving MATERIAL there too, etc. My question 
is - is there any rule for me to remember - what should be a facet, 
and what could be a TAG? (I expect the difference in how you work 
with them underneath)


My general problem is, that FACETS block is becoming long and messy, 
so what to do about it? There were following suggestions to think 
about:


1) close particular settings in subobjects/maps (whatever). There 
are settings belonging to the areas of resizing, colors, box-moderl, 
others, etc. The question is, if we want to refer to such values 
by face/color/bg-color for e.g.?


2) the simplest solution is to at least use some source code conventions. 
E.g. Carl introduced comments to particular ACTORS, desribing what 
arguments are supported for the function. So my idea is:

facets: [

   ; colors
   bg-color:
   other-color:

   ;resizing
    resizes: 
    init-hint:
...
]

ALIGNment:
----------------


It is probably not wise to change all subsequent areas to halign, 
valign. But anyway, we are a bit chaotic here, unless someone tells 
me, what's the rule here - to stay compatible to html/css, or to 
be consistent REBOL wise? I mean - if various areas use ALIGN/VALIGN, 
then my logical question is - why HPANEL/VPANEL, and not PANEL/VPANEL?


My comment is just food for thought, not a claim to change anything.

which is why in html we have align, and valign

Jocko, rgearding the: circle: [pair! | number! | number!] definition.

This is correct as the definition doesn't describe the exact syntax 
of the command but it works more like the rules used by DELECT.

So in this case the CIRCLE command can be used only in these combination:
circle pair! number!
circle pair! number! number! 


which corresponds to the syntax described here: http://www.rebol.com/r3/docs/view/draw-curves.html#section-3


Ofcourse, now when the float pair! has been implemented we could 
extend the syntax for another pair to:
circle: [pair! | pair! | number! | number!]
to allow also:
circle pair! pair!


but this change needs to be reflected also in the to-draw function 
and dialect-draw definition object used by DELECT in the R3GUI.


I'll add this enhancement so it will be available in the next RMA 
release for you.


Also note, the current DRAW dialect (implemented by the preprocessor 
mezzanines) is trying to reflect only  the R3 draw reference documentation 
(in the link above) syntax which has been designed at the time the 
float pair! was not available. The review of the syntax is planned 
in the future.

A R2 GUI document, I've used a lot over the years, is:
http://www.rebol.com/docs/view-guide.html


About everything is there in a small space. It's a very good document 
to get you going, almost perfect. Maybe just a little too long still.

It's time to decide about propagation of events using actors in R3GUI 
so we would like to know your opinion on that.

example:
Let's have face A and face B which is inside face A.

Currently, when you click mouse button on the face B and the face 
B has defined ON-CLICK actor the event is fired to that actor.

If the face B have no ON-CLICK actor the event is not catched anywhere.


We got a request to checnge this so there are few possible options 
we could use:


1. If face B doesn't have ON-CLICK actor defined then propagate the 
event up to its parent face (in our case face A) and up until any 
ON-CLICK is found. (If the face B have ON-CLICK defined then the 
actor is executed and propagation stops here.) In other words the 
event propagation stops in the closest found ON-CLICK actor during 
the 'bubbling' of the event upwards.


2. Propagate the event from face B thru its parent face (in our case 
face A) and up to the topmost(Window) face. The propagation/bubbling 
is done by default and can be stopped in any ON-CLICK actor on the 
way upwards by returning 'stop-event(or any other chosen) keyword. 
(this is simmilar to the model used in HTML)


3. (current behaviour) Don't propagate the event. Just execute the 
ON-CLICK actor in face B in case it is defined. Programmer have to 
manually add event propagation code to the actor if event bubbling 
is required.


4. Don't propagate the event by default. But introduce PROPAGATE/BUBBLE-ACTORS 
(or any other chosen word) option field that can be set for each 
face. The option could hold block of actor names that should propagate/bubble 
the events up.


Please, keep in mind that chosen behaviour affects not only actors 
that handle user input but also actors like ON-INIT, ON-MAKE and 
any other possible actors in general.


Please post either your favorite from the above options or even any 
other possible solution you think is better. Thanks for your help.

Just supppoting question - in R2 we were able to have "event filters" 
defined via insert-event-func. It allowed us to catch events going 
to subfaces. So my question is - if e.g. for #1, the event goes directly 
to face B, am I able to catch it, by inserting the filter into face 
A?

http://www.rebol.com/docs/view-face-events.html#section-14

That's true when you have to write the parser yourself, but I'm assuming 
the PowerMezz parsers handle all of HTML :-)

It's always easier to do:  parse html [thru "<title>" copy title 
to "<"]  than parse complete html to something like a block structure 
and dig title in it.

I've done quite a few html analysers and with a bit of experience 
I have found that going with a brute force parse on pages ends-up 
being very effective.  I did a font downloading script for www.acidfonts.com 
a few years ago and it took more time to actually download all the 
pages than build the script.  :-)

So if he can get by with an HTML parser, that would be great for 
him

About the HTML parser:


This started out because we had a need for a HTML filter. The mail 
client in Qtask allows users to view HTML emails, furthermore, the 
wiki editor submits HTML to Qtask. Whenever you are embedding HTML 
from an external (untrusted) source within your HTML, you have security 
problems. For this reason, we had to take the untrusted HTML and 
1) "filter" it so that it would be safe 2) make it embeddable (eg. 
only take what's inside <body>, and not the whole <html> etc.).

This *had* to work with *any* HTML (think about the stuff that comes 
out of Outlook, or the stuff you get as spam, or newsletters, and 
all that). You can't imagine how bad that can be. That had to be 
turned into something that would not break our own HTML pages.

My approach was, instead of doing what many others do (try to remove 
things from the HTML that are known to be "bad", eg. use regexps 
to remove anything that starts with "javascript:" or anything between 
<script>...</script> etc.), was to only pass what was known to be 
good, and ignore everything else. This is a bit more limiting but 
I consider it to be safer (you don't have to play a game with attacker 
where every time they find a new vector, you have to add it to the 
"bad" list).

So the first HTML filter was done. It parsed the HTML (any version), 
and going through two finite state machines in a pipeline, rebuilt 
it as XHTML 1.0 strict.

So, as our needs became more complex (esp. because of the initial, 
never released version of the wiki editor), I had to change approach. 
Also, at that time Maarten was doing the S3 stuff and needed a XML 
parser as well.


So, first, the Filter was split up into three modules. The first 
is the parser, that takes a HTML or XML string and just sends "events" 
to a callback function. This can be used basically for anything. 
(Maarten never used it in the end.) The second part was the first 
FSM, the HTML normalizer. You'll still find it within the Power Mezz, 
but it's deprecated. The third part was the actual filter and regenerator 
(second FSM). You can find it in the repository history.

Then, the latter two modules were replaced by a different approach 
that builds a tree of blocks from the HTML and rewrites it as it 
is being built (to avoid doing too many passes). This is done by 
LOAD-HTML, that allows passing a set of rules used for filtering 
(so the actual filter is now a bunch of rules for LOAD-HTML). LOAD-HTML 
handles a lot of HTML weird cases, it's probably not at the level 
of a web browser, but it comes close.

The HTML to text module has still not been rewritten to use LOAD-HTML 
instead of the older approach of the HTML normalizer followed by 
a FSM.

(i never got around to change wetan to show module dependencies. 
if you look at the script header though, you'll see that load-html.r 
depends on ml-parser.r)

Hi, first thanks for making and open sourcing power-mezz. 


I am trying to use load-html and am getting some strange results 
if sems it makes for example recursing [ html [ html [ html  ..... 
]]] on my simple html input (and on real one that I tried). I prepared 
two examples to make the point as clear as possible.


http://paste.factorcode.org/paste?id=2263(notice the stack owerflow 
error)

I added 2 more cases to the paste (2 annotaitons). load-html seems 
quite complex since it uses many other modules (that I don't understant 
either).. so I rather see if you find something obvious in my approach 
or the bug in power-mezz

First: you only need to import %mezz/load-html.r in your examples. 
You're not using the other modules; they will be loaded automatically 
by load-html.r - you never need to worry about dependencies.

there is a mold-tree function in %mezz/trees.r if you want to mold 
the tree. Or, you could simply use form-html to pretty print the 
tree for you.

Eg. for your first example:

t: load-html p
print mold-tree t


[root [] [html [] [head [] [title [] [text [value "t"]]]] [body [] 
[h2 [] [text [value "HEADING"]]] [p [] [text [value "first para"]]] 
[p [] [text [value "second para"]]]]]]

print form-html/with t [pretty?: yes]

<html>
    <head>
        <title>t</title>
        </head>
    <body>
        <h2>HEADING</h2>
        <p>first para</p>
        <p>second para</p>
        </body>
    </html>

(the pretty? option to form-html is something i only use for debugging, 
so it's not as pretty as it should be i guess)

You can also do things like:

>> mold-tree get-node t/childs/html/childs/head/childs/title
== {[title [] [text [value "t"]]]}

get-node and set-node are also from %mezz/trees.r ; most likely you 
don't want to mess around with %mezz/macros/trees.r , that is deep 
vodoo i use to make the html filter fast.

other examples:


>> get-node t/childs/html/childs/head/childs/title/childs/text/prop/value 
== "t"


>> get-node t/childs/html/childs/body/childs/h2/childs/text/prop/value 
           
== "HEADING"

Also note that:


>> print form-html/with load-html "<p>A paragraph!" [pretty?: yes]
<html>
    <head>
        <title></title>
        </head>
    <body>
        <p>A paragraph!</p>
        </body>
    </html>

ie. load-html tries to cope with malformed input as much as possible.

very good that you cope with bad html .. I will need that functionality 
because no html is perfect.

It all works now according to your example.. and I tested and it 
handles improper html very well! Thanks!

I looked at html-rules in load-html and I am stunned by how well 
the code / dialect is

there are a few things that it still can't do (the dialect i mean), 
but it's very powerful on the things it can do :) The documentation 
is here: http://www.rebol.it/power-mezz/mezz/niwashi.html

general host-kit starter information:  http://www.rebol.com/r3/docs/concepts/host-kit.html


dowload link for the latest public host-kit:  http://www.rebol.com/r3/downloads/r3-host-kit-a107.zip


this includes both MS and linux distros, note that the linux one 
doesn't have the required files for enabling the graphics on linux 
(they have yet to be attempted by anyone AFAIK).

Indeed.. I tried to find them myself but didn't think to look in 
changes.html

I have published 'unofficial' proposal with improvements to the current 
RichText dialect in R3. If anyone is interested in this topic you 
can read the proposal here: http://www.rebol.cz/~cyphre/docs/rich-text.html
Any feedback is appreciated.

The document has been moved to http://www.rebol.cz/docs/rich-text.html

in HTML is not only margin, but also padding.

http://bolka.at/2010/rebol3/a102/hostkit.htmlhere's more documentation 
on the work I did for A102, along with the full patchset

Here is the problem with OS X host-kit release:
http://www.rebol.com/r3/docs/osx-linker-symbols.html

I found out, that Genesi is now sponsoring Linaro Linux, which tries 
to unify distros for ARM target. They gave away 50 smartbooks:

http://bbrv.blogspot.com/2010/12/momentum-is-building.html
http://www.genesi-usa.com/products/smartbook


From past month's discussion with BBRV, I believe they are able to 
send us a machine to port R3. And now again - this is not my port-it-for-me 
request, just a note, to eventually start a discussion, how do we 
get ourselves on ARMs. Carl could have one smartbook to port Core, 
and someone willing to play with the HostKit port could have another 
one. In the case someone is interested, I could try to negotiate 
it with BBRV.


Of course - ARM is a broad term. I never heard of Linaro. We have 
some TI hardware, and I know there are some embedded systems for 
such stuff, mostly commercial and expensive, and Linaro might be 
an answer here. Another HW option is BeagleBoard (cheaper, more OSes 
supported, even QNX, Android):

http://beagleboard.org/

Here are the official docs (so far):

Loading modules: http://www.rebol.com/r3/docs/concepts/modules-loading.html

Defining modules: http://www.rebol.com/r3/docs/concepts/modules-defining.html

Special notes: http://www.rebol.com/r3/docs/concepts/modules-special.html

Other script stuff: http://www.rebol.com/r3/docs/concepts/scripts.html

Delayed Modules - http://www.rebol.com/r3/notes/delayed-mods.html

Sorry, wrong link. Here:
http://www.kernel.org/pub/software/scm/git/docs/git-config.html

Not sure what you've mentioned, but here is my config output:

core.symlinks=false
core.autocrlf=true
color.diff=auto
pack.packsizelimit=2g
help.format=html
http.sslcainfo=/bin/curl-ca-bundle.crt
sendemail.smtpserver=/bin/msmtp.exe
user.name=
user.email=
core.autocrlf=true
core.safecrlf=false