AltME groups: search

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.

We don't really have a field that we are using to state the importance 
to the reporter of the bug, but that is obvious from the description 
and comments, and we set the priority field accordingly. I would 
like a better approach than this, so if the description of our practices 
helps in any way then that would be great.

I don't oppose the developers using a difficulty field, but using 
severity for it is misleading to users, and frustrating when seeing 
it changed, because that seems to ignore their concerns

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.

The other thing that gets something bumped up in priority at this 
point is whether it is an easy fix, for great user benefit, and applies 
to functions or code that we are going over for other reasons now 
anyways. Your DELINE bug is one of those, Kaj. There are more severe 
bugs in that function that have already put it on the priority list, 
your reported bug should be easy to fix too, it affects a real current 
user base in a significant way, and it hints at the possibility of 
a worse hidden problem. These combined make #1794 a near-term priority.

For example, that DELINE bug. I circumvented it, so it's not critical 
to me anymore. But I could only choose between minor and major, so 
I thought for someone trying to process Slovenian text, it would 
be a major problem. If there had been an option "normal", I would 
have chosen that

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

Except the people actually using CureCode to determine and plan fixes 
and changes. The people to whom those fields matter.

We are in design mode, and for CureCode as well apparently. All tickets 
are important, or else they wouldn't have been reported.

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.

Keep in mind that I am not suggesting that this be called a "user 
damage" field. I think that it shouldn't be called "severity", because 
that only applies to bugs and issues. Perhaps "importance" would 
be better, as it applies to notes and wishes as well.

If a user lables a bug as "crash", that's significant enough, and 
Carl always wants to fix those first

Yeah, the importance field should definitely have crash and block 
importances.

And we reviewers would occasionally raise the importance if the submitter 
underestimated it, such as when it affects more users, or when it 
is a *really* good idea :)

The crash and block settings are the odd ones out of the current 
severity field. They should be moved to the importance field.

There was a 5h outage on curecode.org affecting cheyenne-server.org 
and softinnov.org. It has been fixed just a few minutes ago.


After short investigation, it seems that a PHP internal issue (frozen 
process) caused a fatal error in Cheyenne main process. The error 
is very weird, see below the disarmed REBOL error :

make object! [
    code: 301
    type: 'script
    id: 'need-value
    arg1: evt:
    arg2: none
    arg3: none
    near: [evt: do-events 
        either none? evt
    ]
    where: 'do-cheyenne-app
]


So, DO-EVENTS (which is basically just WAIT [ ]) returned an unset! 
value. Does anyone know here if this a known behaviour or a REBOL 
bug?

Doc, I am interested into using your product for tracking bug of 
other applications but we need Project and Subproject. Is there any 
plan to add subprojects ?

The ZIP file is 0.9.12, I left an older file version when I built 
the 0.9.12 archive. Issue fixed and 0.9.12 archive re-published. 
Thanks for reporting this issue.

Doc, I still have issues with the cookies created from Curecode. 
Essentially, when I leave the browser open and the session expires, 
the next time I try to use curecode, it loads up the error page. 
I just manually delete the cookie and I'm good and I have extended 
the timeout as well which helps. I was wondering in the httpd.cfg 
file if there is any value for curecode's timeout that will make 
it endless (perhaps "none" ? ). Thanks. It is a very usefule app.

I'll have to verify when it happens again but I think it's the "Sorry. 
this page cannot be displayed." And any link clicked will cause this 
to come up.  Doc, this is not super important because changing the 
timeout helps. I'll wait until it happens again and give you better 
details. How's that  sound?

Thanks, that would help, as I tried several times to reproduce your 
issue without success. By the way, what browser (and version) are 
you using?

At some point recently, Chrome started saving the username and password 
in CureCode. Don't know whether this was a CC or Chrome change, but 
it's welcome either way.

trying 0.9.12 and getting this crash:


        URL  = /bugs/
        File = /home/henrikmk/serve/www/bugs/head.rsp

        ** Script Error : Invalid path value: locals 
        ** Where: repend 
        ** Near:  [request/config/locals/instance 
%title.inc

It should be something like this:

mysql://user:[pass-:-localhost]/bugs


I also tried it in a different console and it only appears if the 
mysql-protocol is not loaded.

actually no, I already read through the install.r file and there 
is no reference to anything but SQL queries and a message which contains 
a description of the webapp, but not worker-libs.

I kill the old session with kill -9 and start the new after that

it did not. there was a large number of errors, since there were 
no checks if the tables were actually existing or not and I couldn't 
tell whether the upgrade script actually finished.

Yes, I checked the db content and it contains the block I posted 
above.

Redirection trapped

 is a debug feature, not an error. If debug mode is activated, it 
 produces a intermediary page for HTTP redirection, you have a chance 
 to examine request and session before the redirection is done.

and a different browser is okay?

Way back when I reported that I was getting an error with the head.rsp 
file. Well, after being on a fix it binge, I decided to take a look 
at what was going on. It turns out that there were multiple instances 
of Cheyenne running. I am not referring to the multiple instances 
on normally sees but from another build altogether. I still don't 
know where that is getting launched from (I checked the startup and 
all the services etc in msconfig) but by kludging it and renaming 
the build I didn't want, it fixed the issue.

The domain issue.cc has expired since yesterday and is no more reachable. 
It seems I've missed something when transferring it to another registrar, 
so it might be unavailable for one or two more days.

(If you peek at worlds/rebol/chat/453.set you'll notice it's over 
20'000 messages that must be loaded into memory on server and every 
client.)

I would just use a DB and avoid loading it into memory...

We should start creating subgroups ... .. as we have for  R3 GUI 
and R3 Schemes

Maybe would be good to make RIF for it. Thatis supposed to be the 
killer app for RIF. (and that is what I understand the use of RIF)

Robert, It's interesting the tradeoff these days between a DB and 
loading REBOL data files.  For example, the MySQL that runs the wiki 
on REBOL.net consumes 130MB of main memory on that machine!

I drove IOS to the limit, it's using around 140MB. Would be much 
less with a DB and it's just faster if you need to slice & dice data-records 
form one or the other side.

And If I send a 20MB file it bombs... but you know that ;-). But 
that's not a critism. IMO one just needs to know when a DB can be 
of value to allow small-footprint scaling.

Why to use mySQL? FF, Chrome - those are using SQLite ... small and 
cool engine ...

I use firebird and it's only less than 1Mb .. so why is mysql consuming 
130mb ?

we need to get back to proper R3 releases though. You know, some 
few months ago, there was something like 80 tickets implemented per 
month. Now R3 development is a bit halted. It is important to finish 
some features, before jumping to different tasks. The most important 
right now is to enhance extensions and finish Host Kit (especially 
move View to command! interface), so that ppl can continue with their 
contributions. But that is not happening. I can see even some questions 
towards Extension usability to not being answered on R3 Chat. We 
should really refocus ....

having played with customizing the extension kit by merging some 
of the extension code into (on my own)... and building a generic 
call-back system for R3, I can see how it was a bit of a pain when 
Carl extracted View out of the core and put into an extension.  its 
not a trivial task and there are one or two things missing which 
where probably added to the last host kit and extension package to 
fill the gaps.


for one thing, Carl must have had to unify the source files and possibly 
re-organise a bit of the includes.  this is the kind of work that 
is tricky, painfull and extremely bug prone... with ZERO gratification. 
 it just craps out over and over, until you resolve all the dependencies, 
bugs, missing links and figure out how to re-organize code until 
the make tree "works".  


if it where just one OS/compiler it wouldn't be that bad for such 
a fluent C coder like Carl, but having to support ALL of them in 
a consistent way is very painfull and usually laborious.

And this is the trace ...


<-- trace == unset!
    --> ?? msg . .
        --> case [ any [ ... .
            --> any [ word? :name ...
                --> word? msg
            <-- word? == true
        <-- any == true
            --> ajoin [name ": " mold name...
                --> get msg .
            <-- get == "A0003 OK [READ-WRITE] SELECT completed"
                --> mold "A0003 OK [READ-WRIT... . . .

            <-- mold == {"A0003 OK [READ-WRITE] SELECT completed"}

        <-- ajoin == {msg: "A0003 OK [READ-WRITE] SELECT completed"}
            --> print {msg: "A0003 OK [REA...
msg: "A0003 OK [READ-WRITE] SELECT completed"
        <-- print == unset!
    <-- case == true
<-- ?? == "A0003 OK [READ-WRITE] SELECT completed"
    --> ?? generator . .
        --> case [ any [ ... .
            --> any [ word? :name ...
                --> word? generator
            <-- word? == true
        <-- any == true
            --> ajoin [name ": " mold name...
                --> get generator .
            <-- get == "A0003"
                --> mold "A0003" . . .
            <-- mold == {"A0003"}
        <-- ajoin == {generator: "A0003"}
            --> print {generator: "A0003"}
generator: "A0003"
        <-- print == unset!
    <-- case == true
<-- ?? == "A0003"

    --> find "A0003 OK [READ-WRIT... "A0003" true 5 . . . . . . . . . 
    . .
<-- find == none
    --> ?? r . .
        --> case [ any [ ... .
            --> any [ word? :name ...
                --> word? r
            <-- word? == true
        <-- any == true
            --> ajoin [name ": " mold name...
                --> get r .
            <-- get == none
                --> mold none . . .
            <-- mold == "none"
        <-- ajoin == "r: none"
            --> print "r: none"
r: none
        <-- print == unset!
    <-- case == true
<-- ?? == none
    --> trace false . .

I was trying to download Rebol3 on Mac OS X today and I was not able 
to. Is there an updated alpha for R3?

SQLite is not that appropriate for server side apps where there can 
be multiple processes writing into it. It's awesome for client apps 
(which chrome is) but I had some very bad experiences lately using 
it on server even without the multiple writers problem because I 
was aware of that and I used it in specific way.

By that I mean it was untolerable slow on some VPS where I assume 
same disc was used for streaming media, update was taking seconds 
while I could on the same system open a 1M rebol data file change 
it and save it back in almost no time. I couldn't get it why this 
is happening, and this was at neglegibly small database. I moved 
whole app that uses sqlite to some vps where it's almost alone on 
whole server because of this. And at Site Assistant where I used 
sqlite only for "mailbox" for bots (to send them work) I had to switch 
to mysql for this (it was the same server that blocked this heavily)

On a totally different note .. I don't know if this is doable or 
not, and if it makes sense, but I vould like to propose in discussion 
that at least native functions have some flag for if function is 
pure / side effects free or not ?

My reason is this, big aspect of rebol is it's code / data duality 
and runtime interpretation of code, meaning you can send it around 
and all. But if I want to accept sent functions/code I want in many 
cases that they work as pure functions giving me some value out of 
my values (calculate something). Not modify anything / mutate my 
runtime env. without me knowing.

For example let's say there is rebol interpreter that holds some 
big data in memory and listens on some port. You send it a function 
that if will run on data items to determine if you want that item 
or not and send you the filtered items. If you could know that the 
function used for filter is pure e.g. only returns true false on 
some given item, and can't touch anything outside would be very nice 
even if you trust the source of filter function, and critical in 
cases where you cant.

(and in most cases you can't really trust anything you get over network)

So, Beer, Rugby and LNS don't do that....

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

But most people would send the request as a dialect and let the other 
side do the query.

so, if you can cryptographically sign your function ... and then 
send it ... well.

if each internal system is secure on it's own owerall security is 
better. for example if you controll the client in this story too 
you think you all is well, but you could still crash the server by 
mistake, for example owerwriting some global variable of it, and 
input data that you get from users (in case of an webapp) can then 
include various techniques for code injections (like they do now 
with SQL injections)

unbelievably .... how much functionality we miss even compared to 
R2. And we dare to call it  "soon"-to-be-beta product

and more than 0.9x alpha ... I still have one somewhere :-)

Next up is http://www.rebol.net/r3blogs/0274.htmlcompressed modules/scripts. 
I have some interesting tricks to make them seamless to use and make, 
but I have to get a little sleep before I can really dig in to them.

I want to specify that a datestamp is the required parameter .. and 
that a date is not enough

So, some DBs have a date type, and a datestamp type

I'm just saying this to try and explain what I mean

If you are talking about user input, then it is best to parse and 
construct. That way any errors can be flagged.

If you are getting the data from a string and can afford to be strict, 
use TO-DATE. Like this:
>> d: to-date "24-Jan-2010/0:00"
== 24-Jan-2010/0:00
>> d/time
== 0:00
>> d: to-date "24-Jan-2010"
== 24-Jan-2010
>> d/time
== none

Sometimes you want to import a module more than once, sometimes you 
don't. If you want to redo it every time then don't set a name in 
the spec - that turns it into a mixin. And named modules can be upgraded 
at runtime.

Time ago I have written about porting REBOL3 to the .NET platform 
and Java VM.

The reason ? There is a big universe of libraries and frameworks 
immediately usable that would bring many developers to the REBOL 
platform.

Considering .NET and JAVA VM as alternate OS to develop REBOL3 for 
would be a big step forward to me.

In life we must first accept a comprimise to bring our ideology to 
the world.

I like the idea of a REBOL executable whose size is less than 1MB 
but I want to use it as soon as possible and in many scenarios as 
possible.

Would it be so difficul for REBOL Tech. to understand that this starting 
compromise would be instead the best possible way to pubblicize REBOL 
?

Then, with the time, the standalone version of REBOL3 will surely 
gain additional libraries and componet but until then we will have 
a  great ecosystem already available !

Giuseppe - long time ago, I proposed to port REBOL to JAVA VM, at 
that time it was Tao's Intent system, as I thought Amiga will become 
widespread and popular once again ;-)

... even back at that time, some ppl objected, that coding REBOL 
in JAVA or .NET would make it really slow. Instead of that, what 
was proposed was the integration work. Now with R3 Host Kit and Extensions 
infrastructure, it is really doable. R3 core already runs on many 
systems, and the porting was done in a week or two? I think that 
even ARM version is in the works ....

So, as for .NET - you mostly talk Windows. And there is no standalone 
.NET system - it is just layer upon OS, being it Windows, or Linux 
(Mono). And we have R3 for those two OSes awailable. So - why to 
slow-down REBOL, coding it in pure .NET, instead of doing integration 
work?

Getting REBOL to JAVA VM might be more interesting, as there is probably 
many HW platforms JAVA runs on, but REBOL does not. But OTOH - those 
porting efforts are going to be mainly in community hands anyway. 
Only the language interpreter itself stays closed-source, the rest 
is open-sourced. As for me - I prefer getting R3 in a raw state to 
many platforms, instead of slowing it down and porting it to JAVA 
or .NET directly.

and: data: read %myfile

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?

Robert, you need an extra account. I remember the R3 bug system by 
going to curecode.org and clicking "bug tracker".

Damned, I was not supposed to link to this page ... and this group 
is web public ....

Petr, see it as a smart marketing action. Make it hidden, mighty 
and people will take a look. IMO Apple knows this to perfection. 
Creating a huge hype & buzz upfront new products.

Rebol's future lies in R3.  So, prioritizing the website over r3 
development, and hence blocking all the developers, seems an odd 
choice

+1 (it's an important step, yes. But all people that care about R3 
at the moment are here and know how to use it.)

We should present our own priority list and compare them ...

and sometimes leaving a problem alone for a while allows a much better 
solution present itself.

I agree with Graham - in fact it is highly demotivating and frustrating 
situation. Some points of my analysis are ignored, and exactly predictable. 
When website redo and 2.x upgrade was announced, I knew exactly what 
happens and what it means for R3. Not a one week halt, but it is 
stalled for more than one month already.

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.

Henrik - maybe ppl too want to choose, what they work on? :-) E.g. 
Graham started the work on Schemes. He really SHOULD (and was supposed 
to be) supported. Nothin happened. Robert throwed some Extension 
related questions to R3 Chat - no answers too ...

A number of us said that R3 chat was a waste of resources ... and 
... now, barely anyone uses it.

So people can choose what to work on and Carl can't?

Carl can do what he wants .. and that's the problem

Pekr, Graham knows more about schemes and protocols now than he did 
before. I'd say there is a win there.

Graham, so should we shut down the open R3 chat, which you and I 
can fix bugs in and use the AltME that people don't like because 
it's closed source?

Might as well shut down R3 chat as Carl isn't using it .. and that 
was supposed to be his communication channel

Who says that Carl isn't using it? I see some private messages trickling 
in once in a while. And Graham, you didn't respond to my question 
that I posted there 3 hours ago to help resolve the document editing 
situation on rebol.com.

Type "6739", press Enter, press J and the previous author is Graham.

And the point is we are blocked while Carl goes incommunicado ago 
...

posted 4 and 5 days ago. a couple more earlier in the month.

There is an unheard of (for RT) transparence of work done on the 
website (http://www.rebol.com/recent.html). A cynic might think, 
though, that it can surely be only a matter of time until that page 
is locked down and protected and whatnot.

And that's why we never visited ...

Still, I don't think that all this shiny website freshness does justify 
the total lack of R3-related activity and/or communication. Just 
as one could sense at least a tiny bit of R3 momentum ...

a R3 ODBC scheme and others (mysql etc...)

it would be fun to counter JEE6 and make it easier & simpler with 
an example of pestore or something else ;-)