AltME groups: search

The Chair has denounced members alluding to motive or personality.


Efforts were taken to deal with 'striking from the record', but with 
no official code

or constitution it was deemed unworkable, at this stage.  As another 
issue with more

than one open motion, challenges to statements are usually lost once 
new business

has been tabled.  This is a rule that will need clarification in 
the Modified Rules of
Order.


The Chair is at fault for directly naming Qtask, but felt as it had 
already been mentioned

by name, that a representative be allowed to interject comment in 
defense...perhaps in

error.  Another issue that will need clarification in the Modified 
Rules is regarding
procedural mistakes by the Chair.


Points regarding use of a proprietary system are an issue that will 
require more debate
and are points well raised and well taken.


The Chair is committed to proper Rules of Order, and will do it's 
utmost to uphold these

principles.  This will be carried out with a due sense of authority 
once a constitution has
been ratified by the assembly.

Also, if I may address the mood from the peanut gallery (one of whom 
apparently of Czech origin was marauding in the chamber), may I point 
out that consensual decision-making has never been proposed as a 
means of immediate resolution, rather well-considered decisions based 
on compromise (which active participants would also do well to remember) 
that most, if not all, can be comfortable with.  With regard to the 
elaborate formality (my powdered wig is very fetching, by the way), 
while language used is unfortunately anglo-centric, is expressive 
and better suited to conveying intent with narrower scope for misinterpretation.

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.

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

Today I am having trouble updating a ticket in the rebol3 project. 
I do "Update Ticket" and the changes stay there, except the "Fixed 
in" field changes, and when I go back to View Tickets the changes 
aren't there, nor are they when I go back to the ticket. Creating 
and updating comments works though.

I do not see it as a bug, necessarily, it would be much harder to 
implement it this way as a mezzanine

And it's the same as the mezzanine behavior, at least in my tests. 
In which case do you find the mezzanine to be different?

Could someone add a whole bunch of versions to CureCode for the latest 
host kit? Maybe also add some provisional ones for the next little 
while so that we don't need to do this with every release.

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?

Does it have to be a separate project or can it be a category of 
R3 project?
BrianH, what do you think?

The problem with making a separate project is that it is difficult 
to move tickets from one project to another when they are misfiled. 
The other problem is that some tickets apply to both the core and 
the GUI. I would be OK with creating a separate project if we had 
a way to move tickets. But I would be even more happy with being 
able to filter by category in the detail view, which would allow 
us to effectively do the same thing with a single project.

ok, feel free to do whatever is needed. thanks.

Do multiple projects on the same server share the same ticket number 
space? I assumed so because it was easy for you to do project moving. 
This would make it possible to do cross-project referencing of related 
tickets in the ticket descriptions and comments :)

Even if it means changing a lot of tickets, the difference between 
those should be more clear. Using severity to declare difficuty has 
been useful both to decide which tickets to do when and for negotiating 
(not everything can be fixed, and not everything is really a bug). 
But we haven't really been using the developer priorities, because 
there's too many tickets, and because we have been going with more 
of a work flow system instead of a priority system, except for crash 
and block bugs which get higher precedence if we can. Managing priorities 
has been mostly done on a per-developer basis, with me keeping track 
of the tickets as a whole, and Carl doing the big picture.

We do need a field that contains information about the scale/difficulty 
of the problem, and that is what we have been using the severity 
field for in the R3 project. Basically, anything that requires just 
a tweak to help strings or error messages gets text; then there's 
simple tweaks or minor fixes; new datatypes or fundamental changes 
to major functions gets major; requests to changes in basic evaluation 
semantics gets major, or dismissed, depending on the possibility 
of such a change (some are impossible without breaking REBOL completely). 
The other settings (crash and block) are actually severity. We use 
those levels of difficulty to schedule fixes or in some cases defer 
until later.

Yup. I think that it should be two fields. At this point we have 
so much to do that the only way we can really judge priorities based 
on user need is through comments left on the ticket by other people. 
There is just too much to do, and too many unanswered questions, 
and a lot of stuff just needs to be put off until we can do it. Once 
we get past the first release we will be better able to just fix 
things when they go wrong. For now, we assume that anything short 
of a crash or block was at least important enough to report, so it 
should be considered.

I try to not do this all the time as it gets tiresome, and at some 
point the UI problem will be fixed.

I *do* use the fields according to their label. Severity is severity. 
The severity of the user's problem can't be explained without context 
- a field would be useless, you have to give the context in the description 
or comments. The severity for the developers can be expressed in 
a field though, as the context is just the language itself.

We need to break it into two fields. One for the users to report 
their damage, one for us to use for determining the severity of the 
problem (whatever you want to call that). The user damage field wouldn't 
help us much in the process of fixing the user's problems or satisfying 
their requests, but users apparently expect one. We would get the 
real info from the summary, description, example code and comments, 
same as we do now. Without those details the importance of the fix/enhancement 
to the user is impossible to determine, but with those details we 
can really work on the user's problems and understand their priorities.

We still don't have a good way to set priorities in CureCode though, 
for planning releases. We have to do it manually. The CC priority 
field is OK for general priorities, but not for our priorities because 
our priorities vary from release to release, depending on what area 
of the code we are focusing on.

the next time I try to use curecode, it loads up the error page.

 Could you be more specific? On what page do you let the browser open? 
 What do you do when you resume your work after the session expires 
 (on what link/button do you click)?

Doc, it says in the trace.log that there is an SQL error:


** User Error : ERROR 1064 : You have an error in your SQL syntax; 
check the manual that corresponds to your MySQL server version for 
the right syntax to use near '' at line 6 
	** Where: none 
	** Near:  [do-sql/flat 'r3bugs [{

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
	]

This is annoying. I do not know why, but in Chrome, I am de facto 
unable to log in to CC. Do you have any idea, what may be the culprit?

I guess there needs to be a formal limit to what RT does and what 
community should do. It can't be expected that RT would maintain 
console support on an obscure OS. OTOH you might expect HTTP to work 
as a result of RT work or someone close to RT.

It's clearly explain in the link you pointed.

Note B

OPEN is called twice. It is moded. The mode is determined by the 
existence of the IP address. If the IP address is not known, the 
LOOKUP happens, otherwise the CONNECT happens. This also means that 
if you do an OPEN of a port where you provide the IP address, no 
lookup is done; you skip directly to CONNECT. If it is necessary 
to determine if the IP address is known (a rare situation), use QUERY 
-- which can be called at any time and is very fast.

what do I need to change??

what do you get if you simply telnet to the server?

whenever you set a new state, you'll have to do it via client/spec/state 
in any case

To get the ip address I suspect all you have to do is do a query 
on a port once the lookup has completed

Now how to do a reverse dns lookup??

i don't have any idea how to do that

IIRC we need UDP to do a DNS request.

so you need to do a read port inside the read event?

Do we need to clear the port data after a read ?

what is it good for? That way you have to read-out all data from 
buffer first, before you do "reverse" (read/write) operation, or 
you mess the data, no?

it sounds to me as an unnecessary complication. I don't like it. 
But maybe Carl tried to create push on programmers, pushing them 
to do sequency of read/write correctly?

you'll have to do a PASV before each new request

currently we have to do wait foo/..../subport, as far as i can tell

what would you like the error handler to do in case the password 
is wrong?

btw graham, do you happen to have heard of git?

oops .. need to do a STOR

http://www.linkedin.com/ppl/webprofile?vmi=&id=1690833&pvs=pp&authToken=iSCS&authType=name&locale=en_US&trk=ppro_viewmore&lnk=vw_pprofile


Holger's linkedin details ... wonder if someone could persuade him 
to do SSL again but for R3 ?

not much else to do .. just delete, create directory, rename .... 
and append to existing file

Because noone understands it, it doesn't do what we need it to, and 
the port model is different.

I could use the .torrent file parser now, even before we start writing 
the protocol, to do file management utilities.

And so all you have to do is track what tags you are using with your 
commands....

I don't have the time right now... too much work to do ...

Pekr, "just wrapping" other code is not easy to do right, and takes 
time and effort. Less time and effort than rewiting it from scratch 
in some cases (likely including SSL and SSH), but still not a trivial 
effort.

I want to do it using REBOL end-to-end.

The r2 imap protocol is pretty basic ... so I don't see that we need 
do more than that ....except perhaps allow users to pass custom commands 
to the server.

As Andreas notes, a write to the port inside the awake handler is 
fine .. but outside the handler, you have to do a wait on the port 
to do anything.

Also i found that without using a timeout value, it doesn't work 
for me 

So, I removed the 'read cmdport from write-cmdport function, and 
put the wait instead in the actor 'read ...

It turns out, I think you can allocate separate buffers, but you 
must know how to do it... and I've not tried it yet, so have not 
mentioned it either.

well, I think you normally read the data and then decide what to 
do with it.  So, you have saved it somewhere ...

Carl is usually responsive when you give him something to look at.


if all he has to do is direct users into improving code, his intellect 
is much more usefull than if he is occupied hammering code out and 
sifting thru tedious RFCs.

Yeah. Which we need to do too.

Anyway, Maarten had to do all of this because he chose to use the 
REST method of interacting with aws.  To it seems much simpler to 
use SOAP instead.

OK, but how does the native as 'read knows, what to do, if it is 
passed a port type? It is done somewhere in low level? In other words 
- which functions can be overriden that way?

SOAP looks much easier to implement compared with the tricky stuff 
you have to do with REST.

I am not aware of any R3 scripts that do emailing. The details of 
the preferences infrastructure hasn't even been discussed yet, except 
for undoing the old behavior of %rebol.r and %user.r and replacing 
them with something secure. In general, "our aliases" are put in 
a module that you import if you want to.

Say you wanted to create an HTTP header, and it had nothing to do 
with HTTP. Are you sure you want to create the same header? Or are 
you sure that you don't actually want to extend the existing http 
scheme? The author isn't psychic.

Making code reusable takes planning. If you want to reuse code safely, 
do the planning. Or copy and paste.

If I knew how to do this, it would be done already. Learning how 
is on my todo list, but I'm hoping someone else (like you) gets to 
it first.

Not assuming that yet. All you have to do is say that you are taking 
charge of R3 SSL and you will get all the help you need. I would 
suggest using the Putty SSL code as a start because it's small and 
license compatible (i.e. not a GPL derivative).

Hmm... Andreas already volunteered to do the Arm port ...and had 
no reply.

I'm lost in current somewhat fragmented documentation on asynchronous 
networking. Does anyone happen to know of an example somewhere on 
how to do a http request and meanwhile displaying a progress bar 
or just print some progress info to the console? I know I have to 
use a AWAKE handler, but I just don't grasp what to do therein.


Let's say I want to PRIN "." to the console (or draw something to 
the GUI) every 0.25 secs the http request is taking . Are there any 
docs out there on how to accomplish something like that?

In R2 you'd do a wait to allow the GUI to update ... but you can't 
do a wait inside a wait

you need basically to respond to 'connect and do a read, use 'read 
events to report progress, and use 'done to know when all the data 
is ready.

Graham, do you mean use 'do-style to run an actor?

No, I mean how do you update the gui while in the middle of a network 
operation ?  The only way to force the gui to change is to generate 
a GUi event, like a mouse click etc but a fake event

Yes ... as I redefine net-log in the gui to do the updating, and 
net-log is used inside pro-fax.r

The first was written by Carl to do /View development, way back when, 
and never released (afaict). DevBase 2 was derived from that, and 
DevBase 3 was based on the lessons learned from 2.

graham I've commented it in DB chat , to be honest I thin Carl would 
do it better but I cannot wait more

we can't wait for Carl to do everything .. just have to be prepared 
to discard our work if he rewrites it!

deeper reason, you can't add refinement to existing functions (overlapped 
as actors).
I just think copy is more suited to do so (because of /part)

How to pass a received data from awake handler to actor level? I 
can do Print port/data it works, but I need return a value from read 
actor

For instance, do we really need to support the manual connection 
pooling that R2 does? By this I mean requiring you to open a database 
port and then doing a FIRST on that port to get the actual connection. 
Shouldn't it be possible to just open a port in one step, and have 
the connection pooling be internal or otherwise hidden?

Quick poll: Should READ of an odbc port return flat data, and READ/lines 
return nested blocks? I know it's the opposite of how it was in R2, 
but since we don't have READ/custom we have to make do with what 
we have. For WRITE/lines I've been leaning towards bulk inserts.

However, if you do FIRST of an R3-style dbconnection port, I was 
going to return a R2-style dbconnection port, or at least something 
that acts like one (in particular, it will act like ChristianE's 
odbc scheme). You should be able to use R2-style odbc code without 
change.

The advantage of this is that you should be able to do really simple 
shortcuts for some operations.

R2-style:
db: open odbc://server
dbc: first db
insert dbc "select * from catalog.schema.object"
copy dbc

R3 style:
read/lines odbc://server/catalog.schema.object

Yes, it's been a while... so I'd first like to do a quick bug fix 
release, then move into the other changes, as we've talked about.

yes, but sending a function / code over is probably the most effective 
way to execute on the server side and also the most consistent, not 
that you have to invent some subdialect that you then interpret. 
If you knew function is pure or locked/prevented to touch anything 
outside it you could trust it.


And using code as data directly not reinventing some limited "code" 
for stuff like this is the whole strongpoint of rebol and lisps. 
That's why they say "Any sufficiently complicated C or Fortran program 
contains an ad hoc, informally-specified, bug-ridden, slow implementation 
of half of Common Lisp."


for example you have a database of users, you want to get all who 
are between age 20 and 30 ... you can send it  function [ user ] 
[ all [ gerater? user/age  20 lesser? user/age 30 ] ]


If you can't do this how else could you solve it so elegantly? And 
you would have to use/learn as client (and code on the server side) 
some limited and "a little different" language to do it

doesn't seem to do much ...

rebol3 is not in a process of production but design + production 
so I would not be too restrictive on carl jumping from one thing 
to another. he is also only one, so he can't just do r3 for 2 years 
straight

Do we have any xml helper functions?  


eg.  enclose-tag: func [ tag name ][ ajoin [ to-tag tag name to-tag 
join "/" tag ]]

How to do it in R3? First read gives binary. And decloak produces 
something totally different (binary too), even when using /with.

BTW: R3-CC link is hard to find. And do I have an account from either 
R3-Chat or AltMe? Or do I need to get an extra one?

Sorry, I'm playing devil's advocate here. But, really, there is still 
a ton of things to do that doesn't involve Carl. The function reference 
manual is only 30% done and that took me a week to do. So why don't 
a couple of people here continue the work? I won't have time for 
the next few months. Carl has asked for this several times, and this 
is something that really needs to be done.

why do you want to start at the end?

Perhaps it makes better sense for Carl to do this now to test specific 
areas of R3. During this, Carl has also posted curecode reports.

I use another nice stuff from Gabriele in there :-) I do remember, 
that some nice libs were created even for the Detective. But maybe 
Gabriele wants to keep Qtask related stuff separated?

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

2) In your script, use something like:

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

module [
    Imports: [%mezz/filter-html.r]
] [
    ; ....
]

The package you mention has files with a different extension, .rlp. 
Apparently the package needs to be  cooked on a strange OS different 
than Windows. (Gabriele: It currently requires GNU Make, however, 
those crazy people  still using Windows could rewrite remake.r to 
do all the work).

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
    ]

modules were designed to help with building larger applications. 
i understand it can get in your way if you are doing something very 
small. You can still just DO the scripts but then you need to resolve 
the dependencies yourself, ie. do all the needed scripts in order. 
(there is a function inside tests/run.r that returns a block with 
all the modules a module depends on.)

you can navigate with GET-NODE, I haven't needed something like XSLT 
Paths yet (I had something closer to that in Temple).

root: load-html ...
p: get-node root/childs/html/childs/body/childs/p ; for eg.


most of the logic to do what you want is already in trees.r actually, 
because of the rewrite-tree function (that I don't use anymore). 
Anyway, a simple way would be:

get-node-with-id: func [root id] [
    if id = get-node root/prop/id [return root]
    foreach child get-node root/childs [
        if get-node-with-id child id [return child]
    ]
    none
]

Hi Gabriele,


I'm trying out your power-mezz for the first time.  Do you have any 
other documentation on how to set it up properly?
Here is what I'm doing:


power-mezz-path:	to-path e:/Projects/PT/Rebol/power-mezz-built-1.0.0/
print "Starting mezz/module.r"
do power-module:	to-url ajoin [power-mezz-path 'mezz/module.r]
print	"Returned mezz/module.r"
load-module/from power-mezz-path
module [
	imports: [%mezz/html-to-text.r]
	]
--> e:/Projects/PT/Rebol/power-mezz-built-1.0.0/
--> Starting mezz/module.r

** Access Error: Invalid port spec: e:/Projects/PT/Rebol/power-mezz-built-1.0.0/mezz/module.r

** Near: do power-module: to-url ajoin [power-mezz-path 'mezz/module.r]

Any ideas on what I did wrong?

Hi Maxim,


I'm still learning Rebol, but I'd like to see how I can use Power-Mezz. 
 How do you install it?

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.