AltME groups: search

it gives me an access denied error, from the mysql server, yet I 
am right in the midst of a heavy bunch of requests...

I was thinking there might be a timeout value which is set a little 
too short, but I am such a neophyte when it comes to tweaking ports 
and with mySql in general...

did you find a solution?

I tried a manual "wait" between requests, but would still choke.

I've also noticed some "access error" messages from the server under 
heavy loads. A possible solution is to make connections persistent 
to avoid the open/close overhead for each request. This should solve 
most of these kind of issues.

CGI are slow, I'm not sure that you can easily overload a MySQL server 
that way. Did anyone experienced such issues (access deny errors) 
from CGI ?

why not post this on REBOLTalk.com forum as a poll?

have AltMe, ML user participate in this poll

i'm just trying to get some ideas. not a real poll. but maybe we 
can post this on reboltalk too.

well, if you can write a stylesheet that outputs a layout.  Not at 
all impossible, <xsl:output method="text" />

basically, you have a tree, and you have a set of rules for rewriting; 
a rule is a pattern and a replacement for the matched node

Tree rewriting is a model of computation which is used in a variety 
of contexts within computer science, for example in semantic specification 
and compiler implementation

no, you specify a pattern that can match a subtree, and replace that 
subtree with something else.

xslt does something very similar; it matches a number of nodes (via 
xpath), then creates a new tree based on those nodes. rules are applied 
recursively so that you end up with a new tree starting from the 
initial tree.

there are only two votes so far, howeverr both voted for 3. maybe, 
we could introduce a new concept to CS, "dialect rewriting". :) it's 
the same as tree rewriting but without a tree. ;)

dialect rewriting is basically what my rewriting engine for rebcode 
does; it's rewriting where instead of using a regexp you use a parse 
rule; and instead of compiling a tree to another tree you compile 
a dialect to another dialect.

so it can be considered a superset of tree rewriting (since you can 
think of a dialect to represent trees)

But by avoiding the AST aren't you throwing the possibility for optimizations, 
a direct rewrite engine is more like a literal translator. The cool 
think of having an AST is all the tricks that you can play to produce 
more efficient code at the cost of pre-processing time.

maybe noone votes for 3 because a) we have little understanding what 
xpath can do for us b) once we say "dialect" or rebol in general, 
we sometimess think it is cure for all proglems

the lack of vote for xpath and xslt..


maybe its because there is this thought of adding yet another layer 
just to manipulate the data etc (remember Carl's slide in DevCon 
2004 ?... with REBOL on one side against a stack of others on the 
other side)

Actually I don't care what directly is available (as a user), if 
just some things can be done:

e.g. people need to process XML - thus people already knowing XSLT 
and XPATH would like to leverage their knowledge (I asume) - so if 
we get a dialect for this (2.) this is nice, but even nicer if there 
is some mechanism (a generalization) which allows to import an XSLT 
(ast?) or some XPATH query and return the (more rebolesque) according 
Rebol dialect

3. three has always this kind of attitude of being able to do everything 
better in Rebol itself - even if true (?), that's one of the problems 
with Rebol, that outsiders can't afford the time to do many things 
better (themself) or don't care, because they want use some standards 
nevertheless and Rebol drops out as an option


so I vote for 2. with the ability for 1. maybe by the possibilities 
tree rewriting (or dialect rewriting) offers (I have not much glue 
about this - so some of the experts should know)

I think Gabriel proposal is to rewrite the XML into an RXML "A easy 
to manipulate representation of XML in rebol". Then you rewrite back 
to XML if you need to.

this group exists for a long time, and IIRC initially we were more 
or less discussing rebol - XML interoperability - SAX or DOM parser 
in rebol .... while from what is being discussed now, sounds like 
slightly bit different topic?

Jaime: that's what I meant too. But the discussion jumps around quite 
a bit and as some of these terms are unfamilar (besides the simple 
I know what you're talking about) - it's hard to know what to vote 
for :-).

I once used XML as a file format, just to play around with it. And 
later I found out, that I'd broken so many rules, that no other gram 
was able to read it anyways. ;-)

it turns out that i can do tree rewriting as a subset of dialect 
rewriting. it's a bit tricky but works well.

and, it's a few lines of code (half a page or so)

on top of this, one could probably implement something similar to 
xslt, to translate a tree (parsed from xml) to another tree (maybe 
xhtml or another xml doc)

can we think of a generic way to select data represented with a dialect?

I have often missed structural pattern matching in REBOL, something 
like the match statement in Nemerle (I'm sure it's in other functional 
languages but that's the first that came to mind). You could combine 
a structural pattern specification dialect (like XPath) with a structure 
building dialect (like XSLT), and then make the dialect compilable 
to REBOL code that can be used over and over again. It would be like 
a regex compiler for structures - I would use this every day.


All you would have to do to implement actual XPath syntax would be 
to specify a standard mapping of XML semantics in REBOL data structures 
(see my block model in this group from last October) and then have 
compile the XPath syntax (in a string) to the structure matching 
dialect. Then you could work from there.


(Gabriele, sorry if this seems redundant - I'm trying to explain 
tree rewriting in more REBOL-like terms).

can we think of a generic way to select data represented with a dialect?


Do you mean "selecting dialected data" or "a dialect to select data 
that's in format X"?

when i think about representing data conceptually, i tend to always 
come up with a graph or a tree (then i map the conceptual graph to 
a relational model, or maybe to a dialect). so for selecting data 
a "navigation" approach (which is basically what xpath does) seems 
rather natural for me; then you can map the navigation to SELECT 
statements etc if needed.

so maybe my question is: is graph navigation (or, if you think it 
is general enough, tree navigation) a general enough selection model, 
or do you think that it would be missing something?

You can do some structural pattern matching with parse rules, but 
with how parse is currently implemented it can be a little awkward. 
The lack of arguments to parse rules make recursion quite difficult, 
and the lack of local variables make the rules difficult to use concurrently. 
It is difficult to examine both the data type and the value of elements 
in block parsing, to switch to string parsing mode for string elements, 
to parse lists, hashes or parens, to direct the parse flow based 
on semantic criteria (which is needed to work around any of these 
other problems).


And don't even get me started on the difficulties of structure rebuilding. 
The thing that is the most difficult to do in parse is the easiest 
thing to do with regexes: Search and replace. Didn't we make a web 
site years ago collecting suggestions for improving parse? Wasn't 
a replace operation one of those suggestions? What happened with 
that?


Structural pattern matching and rebuilding currently has to be done 
with a mix of parse and REBOL code that is tricky to write and debug. 
If parse doesn't get improved, I'd rather use a nice declarative 
dialect, preferably with before and after structures, and have the 
dialect processor generate the parse and REBOL code for me. If that 
dialect is powerful enough to be written in itself then we'll really 
be cooking.

Brian, did you post a rambo on parse after a discussion we have a 
while ago ?

my rewrite function works quite well for search and replace. it still 
has the limitations of parse, though, but they don't seem a huge 
problem so far.

we want to compile it to a forth-like processor

do you have common examples that you consider problematic for parse? 
we can probably use rewrite on the parse rules themselves to extend 
them in a similar way that compile-rules does.

Well, I'm back after a long time off the air... Now back online and 
talking from a brand new iMac, and I enjoy it :-)

We'll use it in production very soon. I took a SAX approach because 
we've to manipulate big XML files, and it was a mean to boost performences.

Folks seem to be using/talking about it ... just do a google search 
on "RebelXML". ;)

Well, I just had a quick look. It seems to be clean code, well organised. 
Perhaps I can find some time to test it out myself in a few days.

hehe... I have a validating schema parser which uses a modified RebXML 
engine... but I still have not had the balls to ask my client if 
we would be willing to make it open source.... I'm sure he would 
benefit from the extra time people might put on it.

the change in RebXML was to forego of a few limitiations and to allow 
direct xpath like useage of the loaded xml... which can't be done 
with RebXML out of the box.

The HTML Dialect can do a bit of XML

Good ... a few choices

REBOL's built in BUILD-MARKUP function can also be a good choice.

Which was the first apss at RSP (1 of 2 choices) I handede to Carl. 
I think build-markup does only support <%= %> not <% %> (which I 
always found a pity)

( took me a while to figure out that one ...  )

How are people creating large xml documents where there are large 
numbers of elements and where the data is being drawn from a database.

Model the document first as a Rebol object!, and then generate the 
xml from the object?

That's a good method.

Pekr thinks there is a tool that converts xml to a rebol object ... 
anyone know what it is?

wait a bit, I'll find it - it was cool stuff from XML REBOL guru. 
That person used it for his work ...

Gavin Mckenzie was the guy who wrote a xml parser

>> do %xml-parse.r

Script: "A more XML 1.0 compliant set of XML parsing tools." (2-Mar-2005)
** Script Error: Invalid argument:
    Parses XML code and returns a tree of blocks.
    This is a more XML 1.0 compliant parse than the...
** Where: throw-on-error
** Near: func [[{
    Parses XML code and returns a tree of blocks.
    This is a more XML 1.0 compliant parse than the built-in
...
>>

ie. can't use : inside a set-word

I know we discussed writing a SOAP:// protocol years and years ago 
on the mailing list ... but that never got done.

I made a little change to the http protocol to send SOAP messages 
.. so that I could access the National Library of Medicine's RxNorm 
API.

I read that most web APIs are REST based, but there are still a significant 
number based on SOAP, and also JSON

The web and soap/http are in a sense REST applications (REST is just 
WS over HTTP) though both use a limited subset of REST arguments 
and have to work around as such.


The web is limited (by the HTML spec) to the verbs 'get and 'post, 
and post content types of 'application/x-www-form-urlencoded (default) 
or 'multipart/form-data (used to upload files).  For the most part, 
the web is RESTful as we usually only want to 'get resources.  However, 
other operations typically violate REST principles, as all other 
resource actions (create, update, delete) have to squeeze through 
the get/post/url-encode/multipart pipe.  The Rebol HTTP protocol 
as standard is designed to mimic this and requires patching to move 
beyond get/post/url-endode (even for multipart)


SOAP as I understand it, when using HTTP only uses 'post - the post 
content contains the actual request.  Where it varies from the web 
(and Rebol HTTP) is the need for the 'text/xml content type.


REST itself is limited only by HTTP.  It uses theoretically limitless 
HTTP (v1.1) verbs (though most common patterns use 'get, 'put, 'post 
and 'delete).  It uses any encoding.  It uses HTTP headers as parameters 
(eg. the 'Accept header specifies the desired return type).  Therefore, 
any HTTP protocol designed for REST will accomodate SOAP requests.

Probably more a pure HTML question, and showing my complete lack 
of HTML knowledge these days, but how would I go about automatically 
updating a device (an IP Phone in my case) that has a page (http://10.1.1.7/admin.html) 
with a whole bunch of phone numbers in separate fields and a submit 
button that posts changes back? I can generate the page with the 
data I want submitted back, but I can't work out how to mimic pressing 
the submit button from a specific URL.

Ashley, I may be missing your question.


Are you asking, how from an IP phone (like a SIP phone), you would 
"sync" your phonebook (contacts) from a website?

ashley, do they have a telnet/SSH interface?

Ashley  it looks just like what is after the ? in a GET to a  *.cgi?name="value"&N2="v2"

Ah, thanks. I'll give that a go.

ashley, look at the source for the page, and search for the <form> 
tag. if method="GET", as Tom said, look at the url after pressing 
the submit button and just do a read on a similarly composed url. 
if method="POST", you need to look at all the <input> tags, figure 
out what the query string would be, and send it via POST using read/custom. 
(you could also use wireshark or similar to look at the query string 
the browser is sending if you don't want to look for the <input> 
tags)

All works, "read/custom url reduce ['POST query-string]" did the 
trick! Thanks guys.

My little 64 line script now does the following:


 1) Read Address Book vCard file and extract a list of number/name 
 pairs (I prefix the numbers with 'n to assist with lookups)

 2) Read each Linksys SPA942 IP Phone's call history and create a 
 sorted list of number/frequency pairs

 3) Join these 2 lists and create a query string for matches and an 
 exception report for numbers without an address book entry
	4) POST merged and updated name/number pairs back to each phone


Script took 2 hours to write and debug, runs in 2-3 seconds and gives 
us the features of an advanced call management facility for free. 
Once again, REBOL to the rescue (my business partner shook his head 
when he saw this and just said, "but HOW can REBOL do all this???").

It's also a refernce to the "special" talent of Carl in terms of 
mixing colors ;-)

it's at times like that, that REBOL deserves advertising with a live 
demo.

oh i have a better bad puns: GUI-lty

This is a quickie -- designed to make 'parse-xml output more parseable:

http://www.ross-gill.com/r/qxml.r

Any thoughts, comments?

A tag block will always be [tag! any [refinement! [string! | none!]] 
[string! | none! | block!]]

I've changed this a little.  More or less parseable.

I thought about the # convention.  # can be used in parse literally. 
 It may have no semantic meaning, but is a very concise anchor.

Also, a tag with no attributes containing only text will only contain 
text:

All the 'into values are a bit of a pain, but work can be broken 
up...

Only one method at the moment - get-by-tagname


Note, this is not an attempt to implement W3 DOM.  Just a quick approximation 
for fast manipulation (hence the name).  It's object happy, not sure 
of the weight considerations as such.

This is not an exercise in bloat, I plan to implement only a few 
key methods.  Though if anyone has any requests?

Ok, another revision.  This has a few more methods, I may strip them 
down to read-only, as I don't need to manipulate the object though 
I left them in for completeness.

>> do http://www.ross-gill.com/r/qdom.r
connecting to: www.ross-gill.com
Script: "QuickDOM" (none)
>> doc: load-dom {<some><xml id="foo">to try</xml></some>}
>> foo: doc/get-by-id "foo"
>> foo/name
== <xml>
>> foo/value
== [
    /id "foo" 
    # "to try"
]
>> kids: foo/children
== [make object! [
        name: #
        value: "to try"
        tree: [
            # "to try"
        ]
        position: [
   ...
>> kids/1/value
== "to try"
>> doc/tree/<some>/<xml>/(#)           
== "to try"

Now has anyone written a recursive routine to turn a rebol object 
into XML?  I couldn't find anything like this on rebol.org yet it 
doesn't sound hard to do ...

There must be something, but I don't have anything here that turned 
up, and I don't remember doing one myself. If it helps, you could 
use the JSON converter in %json.r as a starting point.

>> probe obj
make object! [
    a: "testing"
    b: "again"
    c: make object! [
        d: "testing2"
        e: "again2"
        f: make object! [
            g: "testing3"
            h: "again3"
        ]
    ]
    i: "finished"
]

gives this 

<a>
    testing
</a>
<b>
    again
</b>
<c>
    <d>
        testing2
    </d>
    <e>
        again2
    </e>
    <f>
        <g>
            testing3
        </g>
        <h>
            again3
        </h>
    </f>
</c>
<i>
    finished
</i>

format-xml: func [ xml
    /local out space prev
][
    out: copy ""
    spacer: copy ""
    prev: copy </tag>
    foreach tag load/markup xml [
        either tag = find tag "/" [
            ; we have a close tag
            

            ; reduce the spacer by a tab unless the previous was an open tag
            either not tag? prev [
                ; not a tag
                remove/part spacer 4
            ][
                ; is a tag
                if prev = find prev "/" [
                    ; last was a closing tag
                    remove/part spacer 4
                ]
            ]
        ][ 
            either tag? tag [
                ; current is tag
                ; indent only if the prev is not a closing tag
                if not prev = find prev "/" [
                    insert/dup spacer " " 4
                ]
            ][
                ; is data
                insert/dup spacer " " 4 
            ]
        ]
        repend out rejoin [ spacer tag newline ]
        prev: copy tag
    ]
	view layout compose [ area (out) 400x400 ]
]

obj2xml: func [ obj [object!] out [string!]
	/local o 
][
	foreach element next first obj [
		repend out [ to-tag element ]
		either object? o: get in obj element [
			obj2xml o out
		][
			repend out any [ o copy "" ]
		]		
		repend out [ to-tag join "/" element ]
	]
]

a modified version of John's rebXML  tools.  changed the output structure 
to allow rebol's path notation to be used to traverse the loaded 
xml.

I've never posted that specific version cause it was closed source 
for a client.   but I have my own new engine, which does the same, 
but attacking the parse rules directly... its probably faster.
I've not released it.

I wrote a simple xpath compiler too (but don't know where it is now).

a later version, using schema validation, understands multiple subelements 
and automatically converts them to blocks IIRC.

so you do document/element/3/subelement/#attribute.

my engine does support embedded types, but ignored it by default... 
it was also byte reversible... a loaded xml block loaded through 
the engine was saved back exactly, byte for byte, checksum proofed.

my newer version doesn't have the schema validation process.... that 
is a very complex engine to build.   schemas and Parse traversal 
do not follow the same algorythm... so its a bitch to implement.

You should add a comment to the discussion page if you remember.

Not a good idea for data objects, which could number in the thousands, 
each with their own bound copy of the functions.

the init is a context with one function, to which you supply the 
outer (instance) which holds the data:

my-tag: context [
	data: "tototo"
	attribute-1: "red"
	class: context [
		init: func [instance][
			instance/data: copy ""
			instance/attribute-1:  copy "blue"
		]
	]
]

to init the an instance of my-tag:

new-tag: make my-tag [class/init self]

Perhaps I'm not clear on this ....  
If I create a pharmacy object like this


pharmacy: make object! [
	name: none
	init: func [ n ][
		self/name: n
	]
]


is the init function shared by all the subsequent pharmacy instances?

it is bound each time, so if you have 2000 instances, you actually 
have 2000 times that function in ram, it adds up quickly for larger 
objects... for such a simple object, it might not be all that bad...

well, I doubt that I would have more than a few hundred objects... 
but ...

but its a large object.  still using the class system, I can allocate 
1000000 nodes using about 400MB.  with instances, 10000 obects take 
much more than that.

With explicit construction in the spec block, like this:
a: make proto [
    b: make inner-proto [...]
]

Every MAKE object! takes a spec block that is an init function, in 
effect.

so , instead of 

a: make pharmacy []

I have to 

a: make pharmacy [ address: make addressobj []]

If that is the case, perhaps I need a 'create function with each 
object, and at init time, iterate thru all the objects calling their 
create function ?