AltME groups: search

Latest version: I need to build a package first, can be done rapidly, 
but no install script yet available, you'll have to figure it out.

Will: I'm already using my business SVN repository. Managing a new 
public repository would be currently too time-consuming for me. I 
prefer for now making snapshot archives for download. Once CC will 
be a bit more mature (having an install script for example), I'll 
probably move it on a public one.

Everyother system I've used which has reset the password has used 
a different link each time.

If I input a search item, then to clear the search item I have to 
clear it, and hit enter to resubmit with a blank search field?

Is there a filter to on searches to only show active issues?

Doc, well, when I tried to log in for the first time I get the "Sorry. 
this page cannot be displayed.." error.  After fooing around with 
it for a while I thought perhaps the curecode code had to be located 
inside the root-dir. I originally had it on another drive. Well, 
that seemed to fix it. Thanks.

Such error message means that a REBOL error! has been raised in a 
RSP script or in %app-init.r. The error is then logged in %trace.log 
for you to review. I should make a customized error page by the way.

Doc, yes,  I realized that it was representative of an error after 
trying to create a test page to read a mysql db using your mysql 
library (just to test my mysql install). I wsa wondering though whether 
it's true that all the scripts have to be located within the root-dir? 
 That is, in my case, I had the curecode folder on a different drive.adn 
referenced that via the "root-dir" in the curecode web-app section. 
Well, actually, that was generated bu the "install.r" script. Just 
curious.
Thanks.

Webapp's root-dir must point to the folder where CureCode application 
is located. The install script doesn't move anything nor creates 
any file, it just builds the bugs database and prints out a webapp 
definiton based on the location of the CureCode folder, and answers 
you give.

Would be better to create a R3 GUI project  now ... or filter them 
off and import them later on?

Doc, you might want to add a feature to curecode so that a user has 
a default project so we don't need to choose it everytime.

Just wondering if  others are experiencing this behavior and/or this 
is a Cheyenne issue. After so many hours I have to restart the Cheyenne 
services in order for curecode to work. Cheyenne is working in that 
I can go to any other page.

I'll try logging out and seeing if that makes a difference. Maybe 
the session expires and then on this local machine (also runs the 
services), it needs the service restart.

james, I have no such issues, but I guess it depends on how intensely 
the database is used. maybe write a separate test script that performs 
db access and reads some curecode tables into the browser. if it 
doesn't work, when curecode fails, then the db connection must be 
bad.

James, I've never experienced that. CC's default session expiration 
time is 30 minutes. I'll install Cheyenne as service on my XP box 
and will see how it behaves with CC after a few hours.

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.

Can you run it for a whole day in normal mode (not as service) to 
see if it's related to service mode?

Alright. I ran it  overnight as an application and it produced the 
error. But, I also had the browser running overnight. I just closed 
and re-launched the browser and now it works. Perhaps it is a cache 
issue.

I think we can at least say that it is not related to the cheyenne 
services.

Thanks for testing. Good to know, I think that's probably related 
to the way session expiration is handled in CC. I'll see if I can 
reproduce that with a short session timeout.

After a few attempts playing with expired sessions, I can't reproduce 
your issue with the latest SVN revision. Try to run Cheyenne in verbose 
mode using : -vvv as command line argument and send me the log chey-* 
log file once the error happens.

Hmm. I thought I was running it in verbose mode but maybe not. I 
do not see that file. I sent the files a little earlier.

Got them. I give it a look today.

Thanks. I've been trying to make the categories more useful, when 
you're fixing a bunch of related bugs. This should help.

It seems that some users are still not able to sign up for a curecode 
account:

http://www.rebol.com/cgi-bin/blog.r?view=0457#comments

I've activated all pending accounts manually. It seems that some 
hosting mail services like qip.ru have a hard time dealing with 8bit 
encoded emails. I've sign up for an account @hotbox.ru and will fix 
this issue in Cheyenne's MTA.

CureCode server will be down for a few seconds for maintenance starting 
from now.

Oldes, that would require to setup a dedicated web server for that 
maintenance page. As usually, the service interruption is just for 
a few seconds, it's most of the time not even noticed by users.

If I have to take down the server for a longer time, I'll provide 
an info page.

Database migration done. Curecode.org domain's IP has been changed 
to point to a new server, so during the DNS propagation time, curecode.org 
will work on both the old and new server (24-48h). Both Curecode 
instances are now pointing to the same database instance on the new 
server. If all goes well, you shouldn't notice anything, nor have 
any downtime. Let me know if there's any issue.

FYI, my DNS hosting company doesn't allow lowering the TTL, so I 
had to resort to such solution to avoid service interruption due 
to DNS propagation. The new IP is a failover address that I can attach 
freely to any of our servers without any delay, so future server 
migration will be easier to handle.

CureCode application upgraded to 0.9.11. Changelog :

	o FEAT: Custom captcha system replaced by ReCaptcha.

 o FEAT: Auto-adjusting scale for bar charts in stats (more accurate 
 and readable).
	o FEAT: Category selector added in tickets list detailed view

 o FEAT: Empty attached file section not shown anymore in tickets 
 read-only view.
	

 o FIX: When clicked, attached files will now show up in browser's 
 window by default.

 o FIX: When attaching file in a new ticket, the returned attached 
 filename was 'none'.

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.

Does it happen on any tickets or just a specific one?

I've only checked #1513 - I don't like to make test changes because 
they're logged. I can check another after I finish writing a comment.

Still fails. I want to change #1513 to status: dismissed, severity: 
"not a bug".

Can you try with a different browser?

I found a post on the exact model IE8 uses to change its rendering 
mode. http://blogs.msdn.com/ie/archive/2010/03/02/how-ie8-determines-document-mode.aspx

Can't find anything wrong in the database, I'll give a look at your 
session data in memory, can you post me your public IP address privately 
please?

Sunanda: you can use tabs now to indent your code, they will be rendered 
as 4 spaces. Inserting <pre> tags is possible, I'm making a quick 
try at adding it right now.

Thanks.

Is tab the best choice? It's not easy/obvious how to type a tab in 
a webpage; though it's a good choice if you assume we are cutting'n'pasting 
from a text editor.

Right, the purpose was better support cut&pasting from a text editor.

I don't know. Accepting pre tags in the input (with no attributes) 
would work too, I guess. I just know that I never post code from 
a text editor into CureCode comments. Instead, it is always written 
directly or copied from the console. In neither case are there tabs 
- all spaces.

I've got a weird bug in 0.9.8. I don't know if this has been fixed: 
When first selecting Main and then very quickly selecting Add Ticket, 
I get the Main page when selecting the Add Ticket page every time. 
It won't stop.

Could be a cache issue with Chrome... in the mouse over the add ticket 
link it shows add-ticket.rsp, but it loads index.rsp instead, when 
clicking on it.

One enhancement request - a check box, which would allow me to receive 
comments to particular bugs, or even state-changes, so that I am 
informed, that some bug got fixed. Would anyone else find it usefull?

Brian - your selfless? func was added as a native :-)

I wasn't aware SELFLESS? took a word argument at all. It works consistently 
with object arguments. We may have to report this.

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

Just tested, and the native works correctly in all cases, object 
and word. Your first test was correct too, since the 'i tested was 
a different 'i.

In other word, as `bind? d` is a selfless context which happens to 
contain a 'self word, I'd actually _expect_ `selfless? bind? d` to 
return true.

One nice thing to be able to see is a graph of the  resolved issues 
vs the submitted issues

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.

I guess a whole bunch and then some provisional ones is maybe too 
many ;-)

106 was only out for a day before being superceded

I was just laughing at myself - what I wrote earlier was a bit redundant.

but whomever added 107 could've added a few more - does it matter 
if some versions won't be used?

The latest version is what is shown by default when making a new 
ticket, and most people don't change that default. This means that 
the reviewer has to change the versions to match the currently released 
version. This is why we don't add versions to CureCode that exceed 
the latest version, or at most the version that we are actively working 
on at the moment.

Could someone with sufficient permissions please re-open bug#1665. 
This is cleary a bug which needs to be addressed:

http://www.curecode.org/rebol3/ticket.rsp?id=1665

Just curious if you can do a diff on the RT prebuilt binaries and 
the ones you build yourself with the same compiler.

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?

Carl: yes, and I produced a new Cheyenne revision to fix all the 
remaining issues regarding running as non-root.

James: looks like a session expiration issue in CureCode, you should 
be redirected to login screen when that happens instead of getting 
an error, I'll see if I can reproduce that tomorrow. Btw, what's 
your CureCode version?

Is the CureCode running the R3 tracker a plain 0.9.11? Or has it 
custom modifications?

It's supposed to be 0.9.11, I might have done a few minor patches 
since 0.9.11 public release.

I'm checking my logs to give you a more accurate answer.

I've seen in the trace logs a few minor errors with the CureCode 
API that I'll fix in the next days. 

I'll also have a look at Gregg's issue with double line-breaks when 
posting comments using the PRE tag.

one thing I am missing in curecode is a way to track stuff I've commented 
on.   as tickets roll, I find it very frustrating to go back to check 
comments made by others.


I thing a option for "commented by me" in the filters or search would 
be really helpfull for everyone.

Maybe also a simple `if not open? port [open port]` will suffice 
in your case.

when you directly use read on a path, i'm not sure that your 'open 
function is called

but we"re missing a rename actor

we can use a proxy actor

We have a separate !REBOL3 Schemes group on purpose. Please don't 
rename it.

We didn't have a separate !REBOL3 Schemes group.

We created a bunch of spinoff groups because !REBOL3 was getting 
too busy.

I think the group name should be tweaked a bit more to remove the 
"Scheme" inside the bracketed part. I don't see the need to have 
it mentioned twice.

I tried to launch a task! to wait for other port inputs and to keep 
the console safe.
But WAIT seems not working inside a task!

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

Interresting, when I write to global variable at awake level everything 
works OK. Somebody give me a hint how to send received data from 
awake to actor level please.

An awake functions deals with events.
An event has a port  property.
An actor takes a port as input parameter.
Here the link.

If the port contains locals vars, they can both (the awake and the 
actor) access the port's locals.

Sure, they both share a cross reference in their locals, like in 
R2.

Finally I've got it, so now I have a time scheme returning (RFC 868) 
integer number of seconds from 1-Jan-1900. I tried to define refinement 
/date to return well formated date!. But there is no possibility 
to define different refinement except of hadcoded one so I have to 
use /lines for that, silly.

ChristianE the idea arises from the fact the time server send only 
response and close immediately, so I only implemented Read actor. 
The problem is that you may not create a new refinement but only 
redefine one existing. 

time scheme needs a little polishing and will be posted to script 
library.

Anyway you are right the only possibility how to controll the scheme 
in wider borders is to write a command block and wait for reply. 
Another not so generall would be write into port state context and 
use this as switch for read actor.

Pavel, I would not be surprised.   I have not looked at this stuff 
for over a year.   Yes, wik.is is now defunct and so my site is gone.
See https://github.com/gchiu/Rebol3/tree/master/protocols

R3 may go beta before any additional schemes are added - "enough" 
is a matter of opinion, and for core functionality, HTTP is enough 
(only needed for CHAT and UPGRADE). HTTP should be improved before 
beta though.

Brian is working on it, and if he says Carl is working towards a 
beta, I believe him

Further, I can see that most of the important restructurings have 
been done last year, and the source publication has been sorted out, 
so I am now able to fill in missing pieces with extensions, with 
a reasonable certainty that the interface is stable

In other words, Core is usable, extensible and published now (since 
a few months)

Yeah, maybe Carl should put a beta moniker on it ASAP.

I am wondering how one would implement the IMAP4 IDLE command .. 
see http://tools.ietf.org/html/rfc2177


It seems that once one sends an IDLE command, the server might then 
send a response back any time up to the server's inactivity timeout.

which would lead to the client timing out on a tcp port

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?

It did strike me as a kludge

Just came up with a way to maintain R2 compatibility and still support 
the advantages of the R3 style. Just working through the details.

Has anyone made an R3 scheme for testing? I mean a scheme that implements 
every possible port action, but just logs the values passed in. I 
want to get a better idea about how refinements are passed in to 
non-native schemes, if there are any potential security holes, etc.

This scheme is not doing the R2-style two level db, dbconnection 
scheme, it's doing the one-level R3 style with the db connection 
being internal. COPY of a port copies the port itself, returning 
a new connection to the same database. COPY/part returns n new connections. 
The R3 style uses READ and WRITE, not COPY and INSERT.

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.

Async was pretty limited in R2 because you had to start the GUI event 
loop, which only the View builds had. With R3, even core has an event 
loop, and a lot of stuff uses it.

My scheme only open regular files (not a messaging pipe)

It would be interesting to see if there would be a way to make an 
async file scheme using the async or non-blocking file APIs of various 
operating systems. This would be needed to support WinRT-based applications 
for Windows 8, for instance.

Sounds like a trade-off between throughput and responsiveness