AltME groups: search

CureCode v0.9.10 changelog :

	o FEAT: Ticket's attached files management added.
	

 o FIX: Default query parameters corruption for anonymous users fixed.

 o FIX: Issue #1371 regarding policy for ticket deletion by owner.
	o FIX: Dimissed ticket can't be changed by the owner anymore.

 o FIX: Ordering not working properly for all filters and columns.
	o FIX: Minor missing translations for french catalog.

	o LOOK: Added Henrik's 33% fix for page header.

 o LOOK: "Example code" field now use PRE tag for better rendering 
 of source code.

Can we have it so that the userid and password prepopulate?

It wouldn't matter if I could prepopulate the userid and password 
...

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?

Can't see anything wrong with your prefs data nor in the prefs saving 
code. Your current default project is "All Projects", selecting R3 
project in the droplist, then going to Profile and hitting "Set default..." 
button should work, can you try it again?

Reset password link: CC's reset password link can only be compromised 
if someone get access to your email account or if he's able to sniff 
your web traffic. I'm not sure that the risk of someone taking control 
of your CC account and mixing up your posted tickets, or spamming 
comments is severe enough to raise the security protections higher. 
I usually apply protecting measures proportionnally to the level 
of risks involved. If you can convince me that the current level 
of protection used in CC is not high enough, I will raise it.

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.

Yes, I see that. What I was referring to was whether or not Cheyenne 
can see outside of  host's root-dir. BTW, the whole thing (Cheyenne 
and Curecode) work great.

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

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.

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.

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.

OK, I will. This morning I quit the browser and started the browser 
up again. It works fine. So the context where I have that issue is 
when the page is left open for some period of time.

Doc, the Curecode page. OK, I let it sit overnight and got the error. 
Which log do you want ? Trace-80? Default-access?

All of them (including chey-<pid>.log file if you have it). Just 
zip them and send them to me by email. Thanks for taking the time 
to help me investiguate this issue.

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.

SimpleMachines forum is switching into temp page informing about 
maintenance mode - so people see the message, but are not able to 
access dynamic content, databases and so.

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.

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.

Code examples lose all indentation and look ugly, eg:
  http://www.curecode.org/rebol3/ticket.rsp?id=1529&cursor=3


Would it be possible to add even the lightest of lightweight markup 
codes so we could specify <pre> for code examples?

No, I mean in code submissions in CureCode comments (rather than 
the example code section). I often type the code directly in the 
text field, and can't use tabs there because they are used for navigation.

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.

(and now, the question is, whether this behaviour is more useful, 
than the one of the mezzanine function.)

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.

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?

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

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.

and the usual path with A108 isn't published... ask henrik or one 
of the others who are working on it.

and as it does not crash the pre-built A107 binaries, I doubt it 
will with A108.

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?

OK, this morning, I went into FF's Cookie browser and searched for 
cookies from my domain where curecode is. There were none.  I went 
to view my curecode page and it was not going to work. I know this 
because the project select shows "none." I then went back to the 
cookies section and there was one for the domain. I deleted that, 
refreshed the curecode page and it worked. 

Now, one thing about my usual usage of curecode and that is during 
any given day, I will end up logging in several times after my sessions 
expire.

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

0.9.11 beta. Sometimes I am redirected to the login screen but the 
selection  is none and from there it will go to the rsp error. Thanks. 
Knowing that I can remove that cookie is pretty easy.

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 tend to use Google Reader, and no IM. So simple new ticket and 
new comment notifications would work for me.

Thanks Doc.    P.S. I re-ran an install of CureCode today and it 
is failing on the sql file (build-db.sql)  used to define the data 
base and tables.  I found it and moved it but now I am failing on 
webapp setup.

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.

There are tickets in the REBOL 3 project already that apply to the 
GUI, and others that apply to CureCode. Both would be nice to move.

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.

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.

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.

It didn't happen during my mods, it happens when converted from edit 
to view mode every time. And it converts back when you go into edit 
mode (at least visibly).

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

In addition, on RAMBO:

1. For presets, I can select the # per page.
2. Preset categories seem more obvious
3. Search is better
4. I like ability to see summary and description in lists

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.

#666: "I don't want to change anything or learn anything new. REBOL 
2 is perfect and nothing should ever change." :-))

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.

I agree with Doc that severity is set by the reporter, and should 
thus not be confused with difficulty of solving for the developers

Upgrade done. Changes:

o FEAT: Short URLs for tickets direct referencing added.

o FIX: double escaping of HTML entities in description and comments 
removed.

o FIX: vertical spacing of RSS image when navigation buttons are 
not present.

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.

When you use an actor like 'open, it checks to see if the actor is 
defined in the network scheme and invokes that.

and if they don't take a port, you can't use them without redefining 
their behaviour

you can easily make `read/seek rif://data/file 1` work, by creating 
a custom open? actor and using that in your read actor

and in your read actor, you'll then simply do:

either open? port [{read was invoked as `open rif:// + read`}] [{read 
was invoked directly as read rif://}]

try to open the port at first
and then call your read function with it

But I think I'll refine the example and add an open? actor as well.

I made it 
read: func [port [port!] /seek number [integer!] ] [

		either empty? port/locals [
		open port
            	return Get-RIF port number
		][
		return Get-RIF port number
		]

and it works now

And second is more speed?

Pavel, the names for the get/put operations of key-value stores are 
PICK and POKE.

I guess you took the "!REBOL Schemes" too literally. It is "!REBOL3 
Schemes" Graham intented, and in fact, already renamed this group 
to. (It was "!REBOL3 Network Schemes" previously.)

Yeah. And more approriate :)

Pavel, you were right the first time in trying to implement GET/PUT 
actors, but you got the names wrong. Try again with PICK and POKE.

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!

And you don't need to pass data, they both share the same context 
via the port parameter

There is alot of doc in wiki, but the examples is to be written yet, 
that is why I asked. BTW all the simply schemes at Graham Chiu's 
site  (il dottore :) simply doesn work for me, and yes I've upgraded 
make-scheme to sys/make-scheme for A110. Unfortunately the only scheme 
I know working is the http scheme, but it is too high class to I 
can understand the process.

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.

And from subport (tcp) to scheme level port? Can low level awake 
write directly to scheme locals?

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

Ah, and R3 goes beta when it has enough schemes...

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.

Sorry, TCP, DNS, probably UDP, and files/directories are also needed 
for beta.

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

I also believe it because, when I first ported my CMS to R3 almost 
two years ago, it didn't fully work, so I decided not to use it; 
and now that I have ported it again I expected the same, but it has 
turned out that I'm using the R3 version now

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)

we can be in beta another xy months, then do few RCs, and then 3.0.

when I try to evt: make event! [type: 'custom code: 1] I got: 
== make event! [
    type: 'custom
    offset: 1x0
]

ie code dissappears and the value is merged into offset curiously 
is it intended?

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?

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

Hopefully after /string and such were added to READ :(

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.

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.

Your rejection of R3 style is what your block scheme infamous, and 
fun too :)

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.

I'm sure Linux, Mac and such have non-blocking I/O APIs too.

It makes sense for Node.js, and would make sense for other compiled 
languages like Red and World. I suppose Topaz could build an R3-style 
port model on top of Node.js as well.

It increase the GC refreshing rate and makes the pauses shorter

it has been reported as being as much as 50% faster though all the 
explorer reporting becomes totally wrong... i.e. instead of wasting 
time trying to determine how fast and how much time it takes, it 
just does its copy and reporting is completely off, but its actually 
much faster.

Sounds like a trade-off between throughput and responsiveness