AltME groups: search

actually, a search field to select by comment author would be even 
better... so that I could search stuff to see if someone specific 
commented on a comment of mine.

like search-comment = "brian max"

or maye a  "me" could stand in for our user name  (quick to type)

It might only find ones where you were mentioned by name, not the 
ones where you commented. The latter would be a good enhancement 
to CC.

I'd add add  a simple new search key, "comment author"  I think that 
pretty much does what I need.

Just add a new search field "User" and have it pick up tickets not 
only submitted by you but also those commented on by you. You are 
likely to be interested in both.

I can't add a search field.

also a switch to enable mail notification of any of my posts or those 
I have commented on would be GREAT.

I'm planning to add a customizable RSS feed for each ticket for managing 
notifications. I would like also to remind everyone of the CureCode 
API that enable any REBOL coder to easily build any kind of clients 
(making a tool that checks on some tickets changes should be trivial). 
See http://rebol.net/wiki/CureCode#API_documentation

Btw, I've also thought about adding a XMPP interface for sending 
notifications directly to your favorite Jabber-compatible instant 
messenger. Maybe better than a RSS feed, I guess more people are 
using an IM client than a RSS client.

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.

Understood. I agree with the need for a "move ticket" feature and 
adding categories in detail view. I should be able to work on that 
this week, there's a lot of changes pending already for CureCode.

So, I'll add a R3 GUI project as soon as the "move ticket" feature 
will be put online.

You are right, I hadn't noticed. You might want to put a disabled 
category selector in all projects mode, with text in it suggesting 
to select a project, as a UI discoverability improvement.

Hey, I was just missing a user search field :-)

Those improvements sound good to me. This might be enough to start 
planning to make a REBOL 2 project and migrate the RAMBO tickets 
to it.

CureCode new version 0.9.12 is online. (see changes 4 messages above)


RSS-based notifications were added both at project and at ticket 
level :

- project notifications: ticket added/deleted/moved, comment added/changed/deleted, 
status changed
- ticket notifications: any change


I'll monitor this group in the next days for any issue caused by 
this new release. I also might add a couple new minor features in 
the meantime. Once this release is stabilized, I'll upgrade the source 
archive.

Btw, RSS notifications can be accessed from the RSS icon on the upper-right 
corner of tickets list and tickets details page. Default polling 
delays are provided in the RSS feeds, but if your looking for long-term 
changes on a given ticket, I recommend you to set your RSS reader 
polling delay to 24h for the tickets feed.

Kaj: thanks, that was a major feature missing in CC, I'm glad I've 
finally found the time to implement it.

More about the new "move" feature:

- the "Move Ticket" button only appears if there's more than one 
project defined.

- Moving a ticket to another project resets the following fields: 
"version", "fixed in" and "category" (these are project-specific 
fields). Their old values are logged in history if they need to be 
set back.

I entered an R3 bug about a character in Slovenian text, but CureCode 
also mistreats it:

It encodes it as a special HTML entity, but double so that it is 
not shown as the original character

Right, it's a rendering issue that I've fixed. I'll put it online 
in a few hours.

I just noticed that the ticket RSS link is in a fixed location but 
the ticket itself isn't: it depends on whether the < > navigator 
buttons are there. It doesn't look bad either way, but you might 
consider moving it down a few pixels.

Yes, same number spaces for all projects of a single instance (/rebol3 
in this case).

Carl said this when I suggested moving the R2 bug tracking from RAMBO 
to a project in CureCode:

He was also concerned about having a backup of the data, just in 
case. Lots of server failures lately.

About server failures, my server is pretty solid (SSD drives, recent 
hw) and full DB backups are done every day by a batch script on a 
remote  machine (my local home server, a Eeebox ;-)).

The biggest UI problem I've noticed is the semantic overlap between 
the severity and priority fields. I've been saying that severity 
is for difficulty and priority is for importance, but then there 
are importance settings in the severity list (crash and block). That 
could stand to be a bit cleaner.

Works for R2 tickets as well, as a backwards-compatibility argument 
:)

About severity vs priority: you can see "severity" as an issue property 
while "priority" is a processing workflow property.

In other words, "severity" is set by the emitter while "priority' 
is a field in the hands of the developers.

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.

Some things aren't doable because they are incompatible with REBOL 
on a basic semantic or syntactic level. It is not a matter of developer 
ability, and such requests are made more often than you would think.

Everything is set by the reporter at first, often incorrectly. The 
severity field is a mix of data, some of which affects priority but 
most of which only has bearing on difficulty. I'd like to say the 
priority field is more important, but we have been having difficulty 
making it useful to us, and we mostly track priorities separately. 
Perhaps with some tweaks both of the fields could be more useful 
to us.

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

We were using it for the severity of the problem/wish itself, not 
for the severity of the problems that were caused to the users by 
the problem. A problem that requires a new datatype is a pretty severe 
problem - we only have the possibility of a limited set of those. 
Typesets are immediate values, not structures.

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.

This means that for now even if there is a user-need field, we pretty 
much need to ignore it because we have to assume that all tickets 
are important. In many cases the person who reported the problem 
doesn't realize how important it is. It's only in the discussions 
that the real importance becomes clear.

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

Which is why I have to explain this a lot. I have written at least 
a dozen ticket comments to this effect.

It would be a lot easier to just use fields according to their lable 
:-)

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.

As I said, I'm OK with adjusting it to a standard. But that would 
still be severity to the overall community, not severity to the developers. 
Nobody is interested in that

Severity of the change, not some measure of inconvenience. That is 
the main thing that can stop a ticket from being implemented at all, 
the most important field in that group. You are acting like developers 
of the language are more concerned about their own convenience. You 
know that is not the way we work.

That is exactly what I'm telling you. I'm merely asking you to try 
to think for a moment from the perspective of the users you're asking 
to report issues, instead of your own perspective

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.

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.

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

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

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?

any update on adding the R3 GUI as a project to curecode?

Doc, can you create a CC login for me please. Thx.

I don't know if there is a password recovery service; why don't you 
find out?

There's no "subproject" concept in CC, but you can use "category" 
field to divide a project. I have no plan to add such feature this 
year.

Doc, a little thing: the title.inc file for 0.9.12 needs to be updated. 
Or perhaps, the zip file is really .11. In any case, still a great 
app.

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.

Do you have a browser plugin or any other tool installed that could 
remove or alter in any way your browser cookies?

I use FF 5.0 (just upgraded this morning though. Previously it was 
4.0.1). As far as cookie altering tools, not that I know of, though 
I was wondering if AVG could be doing something. Anyway, I just cost 
you a few lost Red minutes. I'll wait until it happens again.
Thanks.

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.

I guess it's a Chrome change, last update on CureCode site was in 
January.

I will have a look, but it has probably been fixed since v0.9.8.

Have you followed the migration process? There's a migration script 
in the archive, probably in the /private folder.

There doesn't seem to be such a script. There is however an install.r 
script.

About your error, the newest CureCode versions require the definition 
of a LOCALS block in the webapp:

	locals [
		name		"REBOL3 Tracker"
		instance	%rebol3/
		short		"r3"
	]

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.

In 0.9.8 there is a reference to mysql-protocol.r in app-init.r, 
but it's gone in 0.9.12.

Btw, all these setup steps are handled by the %private/install.r 
when doing a new installation.

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.

It's a file starting with a dot (= hidden file), so -lR is not enough 
to list it. Also, it exists only when Cheyenne is not running.

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.

When logging in this line fails:

if sess/prefs/my-filter [sess/query: copy sess/prefs/my-filter]

The content of SESS/PREFS is:


[version 1 tickets-color-mode line tickets-alt-color #EEE default-project 
1]


I suppose this was meant to be stored in the database, but would 
a better check on this not be:


if select sess/prefs 'my-filter [sess/query: copy sess/prefs/my-filter]

?

(make a backup before)

now when logging in, I get a "redirection trapped" error, but I can 
then proceed to the correct URL via a link below the message.

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?

In IE it seems to work in a snappy way

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.

Ahhh... finally some sanity. For a short time at least.

!REBOL3 -OLD1    20905 messages
Core                         15498 messages

So, start a new group after 20000 messages?  For higher access speed

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

those 20k+ !REBOL3 messages are a mere 4.4MB on disk ...

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.

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.

If you're not using innodb, you should switch it off by uncommenting 
skip-innodb in /etc/mysql/my.cnf (default place for the config file). 
This will save you ~70MB. For the remaining 49MB, I don't know, I 
guess that a good part of that is used by caches.

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.

I'll give you a private link. Hang on...

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)

This is a bit off topic !

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 ?

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.

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

basically even better for this specifically would be that you could 
run a function in some sort of locked sandbox provided by runtime.

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