AltME groups: search

I have to admit, I'm awed by the size -- is this the least that it 
will take to get a reasonable XML implementation in Rebol?  And how 
to manipulate and store a SAX structure?

maybe we could contact Gavain to cooperate with us. I once asked 
him and he told me something like that it does 80% of what normally 
ppl need ...

and besides that - look at other XML libraries ... compress your 
script and the size is ok :-)

Gavain's scripts did work for me, did not try above referred and 
updated version ...

Maybe we could start with examples in xml and how they could look 
in rebol? with some dialect for the extras?

Well, internally we have references. And externally we can use some 
dialect, 
  127 [name "tag-name" data "data"]
  [name "ref-name" reference 127

// document.getElementsByTagName("H1") returns a NodeList of the 
H1
// elements in the document, and the first is number 0:
var header = document.getElementsByTagName("H1").item(0);

// the firstChild of the header is a Text node, and the data
// property of the text node contains its text:
header.firstChild.data = "A dynamic document";
// now the header is "A dynamic document".

// Get the first P element in the document the same way:
var para = document.getElementsByTagName("P").item(0);
// and change its text too:
para.firstChild.data = "This is the first paragraph.";

// create a new Text node for the second paragraph

var newText = document.createTextNode("This is the second paragraph.");
// create a new Element to be the second paragraph
var newElement = document.createElement("P");
// put the text in the paragraph
newElement.appendChild(newText);

// and put the paragraph on the end of the document by appending 
it to
// the BODY (which is the parent of para)
para.parentNode.appendChild(newElement);

So if we implement this api in rebol, we could use standard documentation? 
And browsers are based on DOM, we could map that to rebol-plugin 
and control browser?

so what is the difference basically in when you parse XML document 
using SAX and using DOM?

Thats what i understand from the overviews. Then comes how it works, 
and i am quickly back to real parse and load..

There are two major types of XML (or SGML) APIs:

Tree-based APIs

    These map an XML document into an internal tree structure, then allow 
    an application to navigate that tree. The Document Object Model (DOM) 
    working group at the World-Wide Web Consortium (W3C) maintains a 
    recommended tree-based API for XML and HTML documents, and there 
    are many such APIs from other sources. 
Event-based APIs

    An event-based API, on the other hand, reports parsing events (such 
    as the start and end of elements) directly to the application through 
    callbacks, and does not usually build an internal tree. The application 
    implements handlers to deal with the different events, much like 
    handling events in a graphical user interface. SAX is the best known 
    example of such an API.

It should work -- XML -> DOM -> XML -- with the DOM being a document 
structure and a collection of methods for manipulating itself.

Yes, load is our tree, parse our events. Think of parse as "Here 
comes the word 'file. Yuppa, and a real 'file! . Good, and a 'binary!. 
(fine, now i store that data in that file)"

What are the SAX methods for manipulating an XML document, and how 
easy is it to save the changes?

Chris - following is true imo which favors SAX with me:


Tree-based APIs are useful for a wide range of applications, but 
they normally put a great strain on system resources, especially 
if the document is large. Furthermore, many applications need to 
build their own strongly typed data structures rather than using 
a generic tree corresponding to an XML document. It is inefficient 
to build a tree of parse nodes, only to map it onto a new data structure 
and then discard the original.

The thing is - result of DOM parsing is tree representation of document 
- in Rebol .... the question is, what if you need data organised 
otherwise? You will have to search that tree and build such structure 
which fits you anyway ....

ok, is anywhere complete and nice DOM specs? W3C org?

Petr, that is exactly what the DOM does -- and web site elements 
*are* xml.

>> source parse-xml+
parse-xml+: func [[{
    Parses XML code and returns a tree of blocks.
    This is a more XML 1.0 compliant parse than the built-in
    REBOL parse-xml function.
}
        code [string!] "XML code to parse"
    ]][
    xml-parse/parser/parse-xml code
]

Chris -- I don't get that problem,

But you did make me look closer, and my earlier statement was wrong.
I'm using

http://www.rebol.org/cgi-bin/cgiwrap/rebol/download-a-script.r?script-name=xml-object.r
Which is similar to xml-parse, but not identical.
Example of usage:
probe: first reduce xml-to-object parse-xml
     {<?xml version="1.0" encoding="ISO-8859-1"?>
      <xxx>11</xxx>
     }

i im using the scripts made by Gavin the code is great, but libs 
for dom implementation are out there and are free i dont know why 
not to use this natively  in rebol i feel like the stone age here, 
tell me if im wrong but i feel like a cave man doing my parsing like 
this. if the code is free and the implementation is easy why not 
to have this in rebol ? just because we can exeed 650k ?

I think it's fair to say that Carl is not fond on XML:
http://www.rebol.net/article/0110.html
http://www.rebol.net/article/0108.html

(And, to be precise, neither am I....But there is a lot of it out 
there, and REBOL needs to work with it better)

XML is not a silver bullet rebol block are much powerfull than XML, 
thats if you'r dealing REBOL's only deployment, but when ic comes 
to manage interoperability things get a bit messy and confused.

I am with Chris here. XML may not be silver bullet, but you can do 
nothing if the other party decides to use and communicate using XML 
- you either can handle, or you can't - simple as that. You can argue 
with them about rebol and its blocks, they will not care :-)

XML as an interchange format is common, as Pekr says.....It many 
ways it is better than CVS files that we used to use.

But XML as a sort of toy in-memory database that can be updated with 
APIs like DOM -- well that is a lurch into a strange direction, and 
not one I'd he happy to take.

2) and to a lesser extent 3) are key to progressing.

Perhaps a hash for attributes and a block for contents. How would 
you represent namespaces?

Petr, it's best to know what format you're parsing to before you 
actually attempt to parse.  I'm making the assumption that the results 
of parse-xml, parse-xml+ and xml-to-object are unsuitable for manipulation.

Chris, you assume wrong. They may be a little awkward but standard 
path and block manipulations can be used on the structures generated 
by those parsers, as long as you stick to the overall structural 
conventions.

in fact, I like his templating system and I don't want to allow any 
other kind of templating system, which does not respect my requirements. 
Temle is good here. Even Jaime likes it or so it seems :-)

Maybe we could look at those, study the code and then start to talk 
of which way to go ...

Perhaps I don't understand Temple fully, but it doesn't so much manipulate 
an arbitrary XML file, rather pick and choose parts of a larger XML-based 
template?

hmm, dunno of how to explain it. It simply parses XML, creates block 
of blocks structure. Then you have those functions like find-by-id, 
find-by-name, etc., which you can use to manipulate values ... then, 
once done, you generate XML. What I did not like is, that ti builds 
the structure from the scratch, so e.g. with html page, you loose 
nice formatting, comments etc. But others said, you could have pointers 
from such nodes to original doc and rebuild the doc properly ...

Objects aren't a good way to store XML values or even attributes. 
XML attribute names can be specified using characters that are difficult 
to use in REBOL words, like :, and you can't add and remove fields 
from objects at runtime. Hashes are better to store attributes, with 
keys and values of strings. Blocks are best to store element contents, 
with perhaps the none value to specify closed elements.

For what I had in mind, these fears are perhaps not appropriate. 
 Ill try and compose a quick example...

You could then represent other XML data items using a word in the 
tag spot and then type-specific contents. For example:
[comment "comment text"]

Yes, it's big and bulky, but it is not intended for consumption by 
the user, any less than a View object is...

Remember that objects in REBOL have a lot more overhead than blocks, 
and that XML documents can get quite large. Unless you are using 
an event-driven parser, every bit of memory you can save is a good 
thing.

The data structure I am suggesting would be for internal use only. 
You should have a dialect for specifying common XML operations and 
have the dialect processor handle the structure.

I understand the need for efficiency, I am also mindful of completeness. 
 The DOM is a complete standard for accessing XML (and I appreciate 
that the 'O' in DOM does not necessarily mean Rebol object! :o)

Sunanda, I'm sorry if that was rude :(  As long as the data structure 
can handle the semantics in the XML standards, including extras like 
namespaces and such, then you won't have to extend them.

Chris, it would be just as efficient to use word values for your 
type field, and easier to understand.

One practical word of caution.
I built a full-text indexer entirely in REBOL.

It extensively uses deeply nested blocks with frequent insertions 
and deletions.

It took several days of tweaking to stop the code crashing REBOL's 
garbage collection.

*** Large, deeply nested and active: may be pushing some internal 
limits.

With a linear structure, it is harder to add a child node -- you 
must append the parent node, set the child's parent node, and find 
the child's place in the document (the tricky part).

With the block position format, you can just test the first member 
to get the type of the data item, and then do something like this 
to access it:

    set a: context [name: namespace: attributes: contents: none] elem
or perhaps this
    set [name namespace attributes contents] elem

A linear structure would be deeply nested - it's just that the nesting 
would be a dialect, and hard to change.

If you use a linear structure it would probably be best to use a 
list instead of a block to better facilitate insertions and deletions. 
This would be OK because you would have to access it in a linear 
way anyways. But if you are doing that, you might as well be using 
an event-based parser instead of a DOM.

Ok, on a nested structure -- you do get-elements-by-tag-name, this 
returns a any-block! of elements with that tag name.  How do you 
take any one of these elements and get the parent element?

; Something like this, semantically at least, and would need adjustment 
based on the actuall block structure
get-element-by-name: func [x n /local l t c] [
    worker: func [x p w] [
        if n = t: first x [
            l: insert l context [elem: x parent: p where: w]
        ]
        t: fourth x
        forall t [worker first t x t]
    ]
    l: make list! 0
    t: fourth x
    forall t [worker first t x t]
    head l
]

I agree.....

I tend to avoid hash! and use straight block! for values I'm reloaded 
from external storage.
Block! makes the loading much faster. 

Hash! may be faster once loaded, but I don't do enough processing 
to offset the loading disadvantage.

Carl has talked several times about a binary format for saving REBOL 
structures (can't find any references off-hand).

That would probably solve this problem as what is saved is, in effect. 
the internal in-memory format: useless for non-REBOL data exchange 
and perhaps dangerous for cross-REBOL releases data exchange, but 
much much faster as it'd avoid most of the parse and load that REBOL 
does now.

it is simply about feeling safe, so that IT manager can be sure and 
tell himself - look, someone other uses it too ....

Yes, they want to be able to look forward. And REBOL stays "risky" 
in their critical eyes :-)

I can do a code review. And C++ is compilable by any standard compiler.

customers usually don't want to see a code ;-) And it is same like 
we coded with CA-VO ... we bought a library and did not care for 
its internals, if things worked ....:-)

Just wanted to say, that I needed async postge SQL protocol, so I 
used the Nenad's non-async version located here: http://rebol.softinnov.org/pgsql/
and made async my own version, which is available here: http://box.lebeda.ws/~hmm/rebol/a-pgsql.r

At this moment I'm testing it for logging messages into DB form this 
experimental chat I'm working on: http://box.lebeda.ws/~hmm/and 
it was running without problems, the chat is working and data stared. 
I will make more tests after I finish some app. design things.

A question about nenads original pgsql (0.90),


I have a database using UNICODE as the encoding, and try to connect 
via pgsql.
Characters get encoded as, e.g.  \010 ( #"^/" ) etc. 

I tried to change the client encoding within postgresql to winxxxx, 
or latinxxx, but it made no difference.

any ideas?

and you can also change line 276:

Im' using the non async version with these changes with no problems 
and use UNICODE encoding as well

I have PostSQL 8.2

It seems that I can connect and send SQL commands and they are executed, 
but whenever in the SQL script/string appears word TABLE I am getting 
error:
>> insert db {CREATE TABLE my_table (
{    prod_no integer, name text, price numeric);}
** Script Error: Invalid argument: TABLE
** Where: forever
** Near: to integer! trim pos

Any workaround?
Thanks!

SQLite is not memory based imo. It was RebDB. SQLite is the coolest 
thing on earth for the purpose it is supposed to serve :-) I mean 
- small, embeddable SQL engine. MySQLLib is not good solution imo, 
as it does not use SQL syntax and is not even free for embedded stuff.

As for PostGress, IIRC the driver was in better state than the one 
of mySQL? It even used continual parsing. Doc said later on even 
mySQL driver will be rewritten that way, and maybe it already is, 
dunno.

I will have multiple clients accessing the database .. webserver, 
 update utiliities and main engine

By the way, ODBC and OLEDB are the native access methods of MS SQL 
Server - they are not an add-on layer. The tcp line protocol is the 
same protocol that the client libraries use. I think there is a few 
open source libraries that support the tcp connections (such as FreeTDS), 
though they may not be very current. You might be able to look at 
their code and docs to figure out the protocol.

ok i have the dll and i wonder what to do now .... if anyone can 
give me informations ....

If you have Command or the SDK write a wrapper using C Callbacks 
(google for that + rebol) and the /Library component

I am trying PGSQL with Doc's protocol and getting 'open pgsql'  error 
"** Script Error: find expected series argument of type: series object 
port bitse
t

** Near: fast-query: either args: find port/target"     This is Postgres 
9.0 recently downloaded.   Anyone having success with it?

Doc,   PgSQL does not have same 'send-sql' and /flat options.   Is 
there a reason they can not parallel the mySQL use?

It looks like copy and paste but it had a warning on it   --- ;--- 
Internals (do not touch!)---   ..... which I took as "[this means 
you!]" .... I will give it a try in later today

Yes, there's a few  insertions to do on lower-level parts. I'll take 
a few minutes to do it after lunch. Btw, I don't have any pgsql server 
available, nor have time to setup one, so I'll let you test and eventually 
debug the new version. ;-)

I am trying some of the code from mySQL and get a PgSQL error "** 
Script Error: Invalid argument: TABLE
** Where: forever
** Near: to integer! trim pos"

The error message seems to be the problem ... the table is CREATEd 
and is usable from new rebol sessions which load the protocol fresh.

Thanks Doc.  I can work around that TABLE message using the pgAdmin. 
 The Send-SQL and /FLAT protocol updates work exactly the same as 
on MySQL for me.

Anton, is there a way to use Com and OneNote?

Is there any way to get around the fact that Rebol faces are not 
native Windows "windows"? (i.e. don't have a handle on the system). 
Speech recognition command & control does not work with Rebol apps 
as long as that is the case and I need that...

The Speech Reco software is the one that comes built-in with Windows 
XP and Windows Vista (BTW, speech reco in Vista is much better than 
in XP). It analyzes widgets on the screen by running through all 
the windows handles (just about everything on a Windows screen is 
a window) and their labels, so it actually knows there's a menubar 
with a file menu on it so you can do things like say "Menu" "File" 
"Open" and it simply works for almost all native apps. It sends the 
equivalent commands by sending Windows messages to the windows. Problem 
is, since Rebol widgets do not have their own handles, the system 
never finds them, doesn't know they're there or that messages can 
be sent to them...

It would probably be easier to wrap the Speech API and use it directly.

That ouwl defeat the purpose; the idea is that the system works for 
all apps and that the apps themselves do not need to do anything 
to have it. Wrapping the API and then building it into every single 
app is not a feasible option. Do you think it's possible to adapt 
the Vid and RebGUI dialects to integrate with the SPeech API so everything 
built with those at least would work? (don't know much about how 
dialects work yet)

I don't know of anyone that's wrapped the ability to use native Windows 
controls in a REBOL dialect, though it *might* be possible. I think 
Cal (and maybe Cyphre or Oldes) have emebedded native OS windows 
in a View window. You might also be able to do it by creating your 
own windows, using the API, and then interacting with them behind 
the scenes. It would be a lot of work though, and be highly OS specific.

Pekr: You can create and control any windows dialog if you have the 
API available. (and this can be applied to any other OS feature). 
So it is possible to create native GUI controlable at the higher 
level of some dialect(simmilar to VID/Rebgui). People who are making 
common apps don't need to access it at face level but ofcourse such 
system would be based on face-like objects with methods related to 
Windows GUI elements etc.

which is why it's probably not worth doing for anything other than 
Windows and OSX. For linux, it would be ... wow... how many different 
GUI systems do we have there? :-)

(But for example Java has already such toolkit and IIRC it is huge 
opensource  Eclipse tool platform supported by IBM)

for me, RebGUI, look-wise, is very Windows like .... yet some of 
us, including you, Graham, complained that it looks dull, and if 
it could be prettified .... :-)

Just look for e.g. ad Ad-aware vs. Spy and Destroy. Spy & Destroy 
was chosen by many as better, yet I can see ppl chosing Ad-aware, 
because of different look actually ...

the question is, with Google and others pushing the envelope, how 
long OS itself will be driving factor of IT evoluion, or it will 
become a commodity :-)

From my POV  View is still very ligthweight and powerful system for 
OS independent solutions.

the problem, for me, for Bobik, and maybe for others, could also 
be, that VID simply has problems, and is not features/styles complete.

If I would consider different UI toolkit, maybe I would look to create 
some GTK or Qt bindings, as other scripting languages try to do ... 
those are existing, and even cross-platform, no?

...it should not be a luxury item either that you have to pay for

 Well, this all depends on the conditions.  You can expect this as 
 free stuff in Java world with much bigger developer base. But I don't 
 believe anyone here in our small comunity have enough time/resources 
 to spent hunderds hours on such project just to make some people 
 from the comunity happy and provide solution for their commercial 
 app for free ;)

Another possibility is that you find some company who is interested 
and pay the developement and make the source open for the comunity.

cyphre, hopefully it wouldn't have to be the end of it. it should 
be the final product that users should pay for and native support 
for GUIs is not the goal but the means. I think it would be a bit 
sad if Rebol had yet another essential component as payware. you 
can do most of this stuff for free on other languages, which would 
cause even smaller motivation for using Rebol as a development platform.


this is why I release my components (LIST-VIEW, Tester, Tab-view, 
TOOLBAR) as BSD licensed freeware. If I didn't, I would have zero 
users.

Cyphre - I also agree with your another pov, which you had in the 
past. It all seems simple at the beginning, but once you delve more 
deeply into it, things start to complicate. Bringing native OS binding 
for Rebol imo would cost many resources. And I believe first version 
would be just ugly wrapper, containing more or less stright conversion, 
using Win32 logic. Isn't there a fact, that others do use other, 
mainly cross-platform bindings? We have View, but wouldn't native 
toolkit project be just reinventing the wheel? Others use tk, gtk, 
qt, wxwidgets, etc.

this also means it would be problematic if one developer were to 
only create developer products, so we shouldn't do that. balance 
between end user and developer products :-)

Henrik: agree...you are surely payed by someone for your cool widgets 
and it is great you can share it with us. So the same can be with 
other dev products. This all depends on the 'sponsor'. People usually 
provide something to comunity in case they really need/use it for 
their own work and IMO in our case that is the only way we can get 
more complex solutions 'for free'.

I am very tempted to know, what is licensing model and extensibility 
model for R3. Really not much was said in that regard yet ...

Speech recognition command & control does not work with Rebol apps 
as long as that is the case and I need that...

 Terry claims speech recognition worls pretty well with his products.

I want to be able to go to websites, feed data to forms and fill 
them out and then grab the results .. where the forms are generated 
dynamically in javascript

But I have to put the drug in the top field, search, select the highlighted 
item in the list, move it to the right list and repeat till done 
.. then check interactions.

I shall try again!  I did try this before and got server errors generated.