| # | User | Message | Date |
| 1298 | Dockimbel | Domain issue.cc is down again, it seems that the configuration wasn't completed after the transfert. I've fixed the config options so it should be back online in 24 hours max. | 22-Dec 16:05 |
| 1297 | Ladislav | Perfect, doc. | 14-Nov 15:51 |
| 1296 | Dockimbel | Domain issue.cc is up again. | 14-Nov 14:58 |
| 1295 | Dockimbel | 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. | 11-Nov 20:20 |
| 1294 | james_nak | 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. | 22-Oct 18:53 |
| 1293 | Ladislav | "internal Chrome prefetching" - looks more like postfetching taking into account how sluggish it is | 9-Oct 11:22 |
| 1292 | Dockimbel | It works from here with Chrome too. It might be an internal Chrome prefetching or DNS caching issue. | 9-Oct 9:48 |
| 1291 | Henrik | I don't have issues in Chrome. | 9-Oct 6:59 |
| 1290 | Ladislav | In IE it seems to work in a snappy way | 9-Oct 6:15 |
| 1289 | GrahamC | and a different browser is okay? | 9-Oct 6:14 |
| 1288 | Ladislav | I usually have to wait, until Chrome tells the page is currently unavailable | 9-Oct 6:11 |
| 1287 | GrahamC | Works for me using Chrome | 9-Oct 5:54 |
| 1286 | Ladislav | 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? | 9-Oct 5:50 |
| 1285 | Ladislav | Aha, now it finally worked | 10-Sep 8:11 |
| 1284 | Ladislav | Strange, I am getting "page unavailable" | 10-Sep 8:11 |
| 1283 | Henrik | works for me | 10-Sep 8:10 |
| 1282 | Ladislav | Does the CureCode currently work for you? | 10-Sep 8:03 |
| 1281 | Dockimbel | Glad to hear that. :-) | 22-Aug 12:15 |
| 1280 | Henrik | my curecode seems to be running OK now. | 22-Aug 12:13 |
| 1279 | Dockimbel | I have upgraded the install script in v0.9.12 archive to handle the mysql-protocol.r installation. | 22-Aug 12:13 |
| 1278 | Henrik | ah, ok. good. | 22-Aug 12:03 |
| 1277 | Dockimbel | "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. | 22-Aug 12:03 |
| 1276 | Henrik | hmm.. that was either caused by debug/on or my lastpass plugin | 22-Aug 12:01 |
| 1275 | Henrik | 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. | 22-Aug 11:59 |
| 1274 | Henrik | ok, that works now. | 22-Aug 11:59 |
| 1273 | Dockimbel | I have test it locally, it should fix your upgrading issue. | 22-Aug 11:55 |
| 1272 | Dockimbel | (make a backup before) | 22-Aug 11:54 |
| 1271 | Dockimbel | You should delete the content of PREFS table, CureCode will recreate correct new data if no PREFS record is found: DELETE FROM prefs | 22-Aug 11:54 |
| 1270 | Henrik | Yes, I checked the db content and it contains the block I posted above. | 22-Aug 11:39 |
| 1269 | Dockimbel | Hmm, wait, I need to check the database content, it seems that the PREFS table might contain obsolete data that are not processed by the upgrade script. | 22-Aug 11:39 |
| 1268 | Dockimbel | It should work okay with v0.9.12. It might be caused by an obsolete session object. You should follow the %.rsp-sessions suppression process once again. | 22-Aug 11:35 |
| 1267 | Dockimbel | Looking into that issue... | 22-Aug 11:33 |
| 1266 | Henrik | I don't see anything about filters in the upgrade script. | 22-Aug 11:32 |
| 1265 | Henrik | 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] ? | 22-Aug 11:31 |
| 1264 | Dockimbel | Thanks, I'm adding it to the online archive. | 22-Aug 11:24 |
| 1263 | Henrik | the rss.gif image is missing from the img/ directory. | 22-Aug 11:22 |
| 1262 | Henrik | I'm doing each part manually now. | 22-Aug 11:21 |
| 1261 | Dockimbel | As I said, the script is for v0.9.6, for your v0.9.8, you should have checked manually which tables are already created. You should then comment the lines in the upgrade script to match your configuration. | 22-Aug 11:19 |
| 1260 | Henrik | 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. | 22-Aug 11:17 |
| 1259 | Dockimbel | The upgrading script should have created all required tables. | 22-Aug 11:15 |
| 1258 | Henrik | ok, missing table... | 22-Aug 11:14 |
| 1257 | Henrik | that seemed to be it. now I'm back to this morning's crash when clicking bug entries in the database. | 22-Aug 11:14 |
| 1256 | Dockimbel | GLOBALS section of %httpd.cfg | 22-Aug 11:12 |
| 1255 | Henrik | where is the worker-libs block supposed to be located? | 22-Aug 11:11 |
| 1254 | Dockimbel | 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. | 22-Aug 11:10 |
| 1253 | Dockimbel | Try with ls -laR | grep sessions while Cheyenne is fully stopped. | 22-Aug 11:09 |
| 1252 | Henrik | ls -lR | grep sessions reveals no such file | 22-Aug 11:05 |
| 1251 | Dockimbel | You should stop Cheyenne completly, remove the %.rsp-sessions file found in Cheyenne working folder, then restart it. | 22-Aug 11:02 |
| 1250 | Henrik | I kill the old session with kill -9 and start the new after that | 22-Aug 11:00 |
| 1249 | Dockimbel | Have you restarted Cheyenne fully after the changes in httpd.cfg? | 22-Aug 10:59 |
| 1248 | Henrik | Another crash in index.rsp: sess: session/content if all [ not sess/login? none? validate/full [action word! *] 'identify = request/content/action ][ SESS appears to be NONE. | 22-Aug 10:58 |
| 1247 | Dockimbel | You're right, it is missing, I'm adding it right now. | 22-Aug 10:56 |
| 1246 | Henrik | 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. | 22-Aug 10:52 |
| 1245 | Dockimbel | Btw, all these setup steps are handled by the %private/install.r when doing a new installation. | 22-Aug 10:51 |
| 1244 | Henrik | I see. | 22-Aug 10:50 |
| 1243 | Dockimbel | 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 ] | 22-Aug 10:49 |
| 1242 | Henrik | In 0.9.8 there is a reference to mysql-protocol.r in app-init.r, but it's gone in 0.9.12. | 22-Aug 10:48 |
| 1241 | Henrik | There is no reference to mysql-protocol.r anywhere in the source code. Could that be it? | 22-Aug 10:44 |
| 1240 | Henrik | 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. | 22-Aug 10:37 |
| 1239 | Dockimbel | You should check that <removed> part for an invalid definition. | 22-Aug 10:33 |
| 1238 | Henrik | now I get an invalid port spec: ** Access Error : Invalid port spec: mysql://<removed> ** Where: do-sql ** Near: [do-sql/flat 'bugs any [ | 22-Aug 10:06 |
| 1237 | Henrik | ok, thanks. | 22-Aug 9:32 |
| 1236 | Dockimbel | Be sure to backup your database before using it. | 22-Aug 9:31 |
| 1235 | Dockimbel | http://curecode.org/dl/upgrade-096-0910.zip I am not sure it applies to 0.9.8, you'll need to check if the new SQL tables are already there or not. | 22-Aug 9:30 |
| 1234 | Henrik | ok, it looks like I'm going to need that upgrade script. where can I find it? it's not included in the distribution. | 22-Aug 9:17 |
| 1233 | Henrik | I see, thanks. | 22-Aug 8:59 |
| 1232 | Henrik | private$ ls ChangeLog.txt build-db.sql generate-load.r helper.r instances access-control.r db-abstract.r generate-test.r install.r | 22-Aug 8:59 |
| 1231 | Dockimbel | 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" ] | 22-Aug 8:59 |
| 1230 | Henrik | There doesn't seem to be such a script. There is however an install.r script. | 22-Aug 8:58 |
| 1229 | Henrik | I see, will try. | 22-Aug 8:57 |
| 1228 | Dockimbel | It's the %private/upgrade-096-0910.r script. | 22-Aug 8:56 |
| 1227 | Dockimbel | Have you followed the migration process? There's a migration script in the archive, probably in the /private folder. | 22-Aug 8:55 |
| 1226 | Henrik | This is with the latest cheyenne release 0.9.20. | 22-Aug 8:53 |
| 1225 | Henrik | 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 | 22-Aug 8:50 |
| 1224 | Henrik | if there are no dangers in upgrading curecode, I may do that instead. | 22-Aug 8:37 |
| 1223 | Henrik | well, it worked before, but I'm curious about the near '<unknown char>' bit | 22-Aug 8:36 |
| 1222 | Dockimbel | I will have a look, but it has probably been fixed since v0.9.8. | 22-Aug 8:35 |
| 1221 | Henrik | 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 [{ | 22-Aug 8:29 |
| 1220 | Dockimbel | I guess it's a Chrome change, last update on CureCode site was in January. | 25-Jun 9:24 |
| 1219 | BrianH | 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. | 24-Jun 22:48 |
| 1218 | Dockimbel | No problem, I am used to multiplex different tasks. ;-) | 22-Jun 17:52 |
| 1217 | james_nak | 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. | 22-Jun 17:50 |
| 1216 | Dockimbel | Do you have a browser plugin or any other tool installed that could remove or alter in any way your browser cookies? | 22-Jun 17:43 |
| 1215 | Dockimbel | 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? | 22-Jun 17:42 |
| 1214 | james_nak | Besides, no one else seems to have this issue so it could very well be something on my side. | 22-Jun 17:42 |
| 1213 | james_nak | 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? | 22-Jun 17:40 |
| 1212 | Dockimbel | "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)? | 22-Jun 17:17 |
| 1211 | Dockimbel | There is no endless timeout value. Such feature would blow up the server's RAM sooner or later. | 22-Jun 17:16 |
| 1210 | james_nak | 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. | 22-Jun 17:12 |
| 1209 | Dockimbel | James: sure, I did that during my coffee break ;-) | 24-May 15:45 |
| 1208 | james_nak | NP ... get back to RED. :-) | 24-May 15:36 |
| 1207 | Dockimbel | 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. | 24-May 15:34 |
| 1206 | james_nak | 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. | 24-May 15:22 |
| 1205 | Ladislav | http://issue.cc/r3/1027 The state of the ticket should be revised | 1-May 5:11 |
| 1204 | Dockimbel | 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. | 6-Feb-11 16:43 |
| 1203 | GiuseppeC | 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 ? | 6-Feb-11 16:19 |
| 1202 | Dockimbel | "password recovery service"; sure, from home page -> Reset Password link | 6-Feb-11 9:24 |
| 1201 | Robert | Ok, worked. | 5-Feb-11 23:00 |
| 1200 | BrianH | I don't know if there is a password recovery service; why don't you find out? | 5-Feb-11 23:00 |
| 1199 | Robert | :-) Good to know... let's try if I remember my password. | 5-Feb-11 22:59 |
| 1198 | BrianH | Also Robert-Muench (another login) | 5-Feb-11 22:57 |
| 1197 | BrianH | Loginid Robert. | 5-Feb-11 22:55 |
| 1196 | BrianH | You have one already. | 5-Feb-11 22:54 |
| 1195 | Robert | Doc, can you create a CC login for me please. Thx. | 5-Feb-11 22:51 |
| 1194 | Henrik | it's ok. now we have it. :-) | 27-Jan-11 15:15 |
| 1193 | Dockimbel | Sorry for the delay, I forgot about it until Henrik mentioned it again yesterday. | 27-Jan-11 14:58 |
| 1192 | Henrik | cool :-) | 27-Jan-11 14:54 |
| 1191 | Rebolek | Great, thanks. | 27-Jan-11 14:51 |
| 1190 | Dockimbel | R3 GUI project added to CureCode, ticket http://issue.cc/r3/1837 moved to R3 GUI. I've added alpha 110 & 111 to versions list, let me know if you need categories too (I would need an ordered list of items for that). | 27-Jan-11 14:50 |
| 1189 | Henrik | any update on adding the R3 GUI as a project to curecode? | 26-Jan-11 15:09 |
| 1188 | Maxim | I've never seen this. | 13-Jan-11 23:00 |
| 1187 | Dockimbel | 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? | 23-Dec-10 10:47 |
| 1186 | Dockimbel | I've changed the format of the GUID field in RSS feeds, so you'll get duplicate entries for the recent changes, just ignore them or delete the old ones. | 20-Dec-10 13:04 |
| 1185 | Dockimbel | Version 0.9.12 sources package released: http://curecode.org/dl/curecode-0912.zip | 20-Dec-10 12:54 |
| 1184 | BrianH | The crash and block settings are the odd ones out of the current severity field. They should be moved to the importance field. | 14-Dec-10 5:08 |
| 1183 | BrianH | 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 :) | 14-Dec-10 5:01 |
| 1182 | BrianH | Yeah, the importance field should definitely have crash and block importances. | 14-Dec-10 4:56 |
| 1181 | Kaj | If a user lables a bug as "crash", that's significant enough, and Carl always wants to fix those first | 14-Dec-10 4:56 |
| 1180 | BrianH | 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. | 14-Dec-10 4:53 |
| 1179 | BrianH | 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. | 14-Dec-10 4:49 |
| 1178 | BrianH | 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. | 14-Dec-10 4:46 |
| 1177 | Kaj | If you want to keep explaining yourself to unsuspecting users, I apparently can't stop you | 14-Dec-10 4:40 |
| 1176 | Kaj | Come on, then you should just remove the field | 14-Dec-10 4:39 |
| 1175 | BrianH | We are in design mode, and for CureCode as well apparently. All tickets are important, or else they wouldn't have been reported. | 14-Dec-10 4:38 |
| 1174 | Kaj | 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 | 14-Dec-10 4:37 |
| 1173 | BrianH | 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. | 14-Dec-10 4:35 |
| 1172 | Kaj | You're reversing the meaning of the field by changing it from severity of the inconvenience of the bug to severity of the inconvenience of the fix | 14-Dec-10 4:32 |
| 1171 | BrianH | Except the people actually using CureCode to determine and plan fixes and changes. The people to whom those fields matter. | 14-Dec-10 4:31 |
| 1170 | Kaj | 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 | 14-Dec-10 4:30 |
| 1169 | BrianH | 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. | 14-Dec-10 4:29 |
| 1168 | BrianH | I try to not do this all the time as it gets tiresome, and at some point the UI problem will be fixed. | 14-Dec-10 4:26 |
| 1167 | Kaj | It would be a lot easier to just use fields according to their lable :-) | 14-Dec-10 4:26 |
| 1166 | BrianH | Which is why I have to explain this a lot. I have written at least a dozen ticket comments to this effect. | 14-Dec-10 4:25 |
| 1165 | Kaj | So you were communicating that it was difficulty minor, so easy to fix. But to most people, I'm afraid, it would appear as dismissing their major problem as being minor | 14-Dec-10 4:24 |
| 1164 | BrianH | Yup, that is how we have been treating that field. Severity for the user always varies based on their own circumstances. | 14-Dec-10 4:24 |
| 1163 | Kaj | Then you changed it to minor. I reverse engineered that action to conclude that you interpreted the field as severity for you instead of severity for the user | 14-Dec-10 4:23 |
| 1162 | Kaj | 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 | 14-Dec-10 4:21 |
| 1161 | Kaj | I don't oppose changing the submitted severity according to some standard, either. Just the misnamed intention of the field | 14-Dec-10 4:19 |
| 1160 | BrianH | Of course we could tell all of that from the description :) | 14-Dec-10 3:17 |
| 1159 | BrianH | 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. | 14-Dec-10 3:14 |
| 1158 | BrianH | For instance, the main criteria for priorities at this stage of development is whether the ticket affects basic semantics of the language, or crashes the interpreter. Any such changes need to be done before the first release, or else code might be written that depends on the old semantics. By that standard, the importance to the submitter is of limited scope in comparison to the importance to the whole community. This is not to diminish the need of an individual user, this is just the stage we are at. | 14-Dec-10 3:07 |
| 1157 | BrianH | 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. | 14-Dec-10 3:00 |
| 1156 | BrianH | 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. | 14-Dec-10 2:57 |
| 1155 | Kaj | Yes, I understand, but the field is still mislabled | 14-Dec-10 2:51 |
| 1154 | BrianH | But the confusion is pretty awkward. | 14-Dec-10 2:51 |
| 1153 | BrianH | 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. | 14-Dec-10 2:50 |
| 1152 | Kaj | 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 | 14-Dec-10 2:45 |
| 1151 | Kaj | Thanks for the quick fix, Doc ;-) | 14-Dec-10 2:39 |
| 1150 | BrianH | 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. | 13-Dec-10 23:00 |
| 1149 | BrianH | 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. | 13-Dec-10 22:57 |
| 1148 | BrianH | 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. | 13-Dec-10 22:43 |
| 1147 | BrianH | 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. | 13-Dec-10 22:38 |
| 1146 | Dockimbel | Ticket 1794 (http://issue.cc/r3/1794) now renders special characters correctly. | 13-Dec-10 21:29 |
| 1145 | Dockimbel | 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. | 13-Dec-10 21:28 |
| 1144 | Dockimbel | I'm upgrading Cheyenne version on curecode.org, if you're editing something, better save it right now. | 13-Dec-10 21:24 |
| 1143 | Kaj | Developers shouldn't even care much about difficulty, because everything should be doable, or they wouldn't be developers, so priority is more important | 13-Dec-10 21:00 |
| 1142 | Kaj | Reporters basically don't care about difficulty, because if they could judge it, they could probably also fix it themselves | 13-Dec-10 20:59 |
| 1141 | Kaj | I agree with Doc that severity is set by the reporter, and should thus not be confused with difficulty of solving for the developers | 13-Dec-10 20:59 |
| 1140 | BrianH | 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. | 13-Dec-10 18:36 |
| 1139 | Dockimbel | The UI should better separate those 2 categories. "Priority" should have go down with other "developer" fields, but it wasn't very good-looking when I tried it at the beginning. I was waiting for more fields to be added (for better balance) before moving it down. | 13-Dec-10 18:22 |
| 1138 | Dockimbel | In other words, "severity" is set by the emitter while "priority' is a field in the hands of the developers. | 13-Dec-10 18:17 |
| 1137 | Dockimbel | About severity vs priority: you can see "severity" as an issue property while "priority" is a processing workflow property. | 13-Dec-10 18:16 |
| 1136 | BrianH | Works for R2 tickets as well, as a backwards-compatibility argument :) | 13-Dec-10 18:12 |
| 1135 | Dockimbel | #666: "I don't want to change anything or learn anything new. REBOL 2 is perfect and nothing should ever change." :-)) | 13-Dec-10 18:12 |
| 1134 | BrianH | 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. | 13-Dec-10 18:12 |
| 1133 | BrianH | Part of the reason that I would like to move to CC for R2 is because most of the bugs found in R2 are found during the development of R3 nowadays. Even if we have to be more stringent about backwards compatibility, we still want the cross-referencing, at least for the R2 equivalent of bug #666. Plus, I know CC better. | 13-Dec-10 18:09 |
| 1132 | Dockimbel | 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 ;-)). | 13-Dec-10 18:06 |
| 1131 | Dockimbel | Well, it's all doable, I just need to find some time to add these features (not sure how Rambo's search feature is working). | 13-Dec-10 18:03 |
| 1130 | BrianH | Now, the categories thing is project-specific, so that can just be migrated over. I'm not sure what he means by the rest. | 13-Dec-10 18:02 |
| 1129 | BrianH | He was also concerned about having a backup of the data, just in case. Lots of server failures lately. | 13-Dec-10 18:01 |
| 1128 | BrianH | 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 | 13-Dec-10 18:00 |
| 1127 | BrianH | Carl said this when I suggested moving the R2 bug tracking from RAMBO to a project in CureCode: | 13-Dec-10 18:00 |
| 1126 | BrianH | Cool, that will work nicely. | 13-Dec-10 17:59 |
| 1125 | Dockimbel | sorry, "space" not "spaces" | 13-Dec-10 17:58 |
| 1124 | Dockimbel | Yes, same number spaces for all projects of a single instance (/rebol3 in this case). | 13-Dec-10 17:58 |
| 1123 | BrianH | 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 :) | 13-Dec-10 17:44 |
| 1122 | BrianH | Nice :) | 13-Dec-10 17:42 |
| 1121 | Dockimbel | About direct ticket references, I'm adding short URLs to reference tickets in the form: http://issue.cc/r3/<ticket id> | 13-Dec-10 17:33 |
| 1120 | BrianH | Direct ticket references like those from the RSS or typed out here cause the no-arrow-buttons thing. That makes it easy to check the alignment. | 13-Dec-10 17:31 |
| 1119 | Dockimbel | Thanks, good catch! | 13-Dec-10 17:25 |
| 1118 | BrianH | 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. | 13-Dec-10 17:08 |
| 1117 | Dockimbel | Right, it's a rendering issue that I've fixed. I'll put it online in a few hours. | 13-Dec-10 17:04 |
| 1116 | BrianH | 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). | 13-Dec-10 16:23 |
| 1115 | Oldes | It's for sure CC bug as it converts the HTML entity into bug link. | 13-Dec-10 8:49 |
| 1114 | Kaj | It could be that this happened during Brian's modification. I probably reviewed my own entry, although I don't actively remember | 13-Dec-10 4:07 |
| 1113 | Kaj | It encodes it as a special HTML entity, but double so that it is not shown as the original character | 13-Dec-10 4:04 |
| 1112 | Kaj | http://curecode.org/rebol3/ticket.rsp?id=1794&cursor=4 | 13-Dec-10 4:04 |
| 1111 | Kaj | I entered an R3 bug about a character in Slovenian text, but CureCode also mistreats it: | 13-Dec-10 4:04 |
| 1110 | BrianH | The RSS feeds seem to work in Google Reader. | 13-Dec-10 3:42 |
| 1109 | Dockimbel | 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. | 12-Dec-10 18:36 |
| 1108 | Dockimbel | Kaj: thanks, that was a major feature missing in CC, I'm glad I've finally found the time to implement it. | 12-Dec-10 18:36 |
| 1107 | Kaj | Very useful | 12-Dec-10 18:27 |
| 1106 | Dockimbel | 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. | 12-Dec-10 18:05 |
| 1105 | Dockimbel | 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. | 12-Dec-10 18:00 |
| 1104 | BrianH | 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. | 12-Dec-10 4:10 |
| 1103 | Kaj | Hey, I was just missing a user search field :-) | 12-Dec-10 2:52 |
| 1102 | Dockimbel | "isolated search field" means that it's not included when <all> is selected (due to over-complicated SQL code to get accurate results). | 11-Dec-10 22:39 |
| 1101 | Dockimbel | I made the following changes on my dev instance of CureCode: o FEAT: Added the ability to move tickets between projects. o FEAT: New search field: "User". o FEAT: New isolated search field: "Commented by". o FEAT: RSS feed added for projects changes. o FIX: double line breaks in PRE tags in comments removed. o FIX: stats bar graphs were never displaying per-project stats. I'll put it online tomorrow. If I missed an important bug to fix, let me know. | 11-Dec-10 22:37 |
| 1100 | BrianH | 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. | 10-Dec-10 19:17 |
| 1099 | Dockimbel | BrianH: "But I would be even more happy with being able to filter by category in the detail view, [...]" Category are already present in detail view (you just need to ensure that the project selector is on "REBOL 3.0"). Did I miss something? | 10-Dec-10 17:13 |
| 1098 | Henrik | ok, feel free to do whatever is needed. thanks. | 6-Dec-10 12:24 |
| 1097 | Dockimbel | So, I'll add a R3 GUI project as soon as the "move ticket" feature will be put online. | 6-Dec-10 11:40 |
| 1096 | Dockimbel | 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. | 6-Dec-10 11:38 |
| 1095 | BrianH | 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. | 6-Dec-10 10:42 |
| 1094 | BrianH | I would be even happier with both, of course :) | 6-Dec-10 10:38 |
| 1093 | BrianH | 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. | 6-Dec-10 10:34 |
| 1092 | Dockimbel | Does it have to be a separate project or can it be a category of R3 project? BrianH, what do you think? | 6-Dec-10 10:07 |
| 1091 | Henrik | Any news on having an R3 GUI project under Curecode? | 6-Dec-10 9:44 |
| 1090 | MikeL | 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. | 28-Nov-10 19:26 |
| 1089 | Dockimbel | I confirm that the REBOL wiki is not responding. For CureCode API, you can read it through Google's cache at http://webcache.googleusercontent.com/search?q=cache:Z0Rflqyek5QJ:www.rebol.net/wiki/CureCode+curecode+api&hl=fr&gl=fr&strip=1 | 28-Nov-10 16:49 |
| 1088 | MikeL | This site seems to be down http://rebol.net/wiki/CureCode#API_documentation | 28-Nov-10 16:39 |
| 1087 | Henrik | Doc, you can create an R3 GUI project in Curecode, if you like (or can). This way, we don't pollute the REBOL 3 project with GUI bugs. | 24-Nov-10 18:19 |
| 1086 | Ladislav | Could somebody mark http://www.curecode.org/rebol3/ticket.rsp?id=1672&cursor=92 as complete, please? | 8-Nov-10 13:27 |
| 1085 | Gregg | Thanks for the API reminder Doc! | 29-Oct-10 16:40 |
| 1084 | Maxim | problem with IM is that when you're not there they usually aren't as well managed for looking up stuff "after the fact" rss clients on the other hand are optimized specifically for that use case | 28-Oct-10 21:11 |
| 1083 | Maxim | same for me. | 28-Oct-10 21:09 |
| 1082 | BrianH | I tend to use Google Reader, and no IM. So simple new ticket and new comment notifications would work for me. | 28-Oct-10 21:06 |
| 1081 | Dockimbel | 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. | 28-Oct-10 21:03 |
| 1080 | Dockimbel | BrianH: I'll see if your feature request can be easily added. | 28-Oct-10 20:42 |
| 1079 | Dockimbel | 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 | 28-Oct-10 20:40 |
| 1078 | Maxim | also a switch to enable mail notification of any of my posts or those I have commented on would be GREAT. | 28-Oct-10 19:38 |
| 1077 | Maxim | ah ok. | 28-Oct-10 19:36 |
| 1076 | BrianH | The suggestion was for Doc :) | 28-Oct-10 19:35 |
| 1075 | Maxim | I can't add a search field. | 28-Oct-10 19:35 |
| 1074 | BrianH | Not as useful when searching for "BrianH" or "meijeru", but it might come in handy for "Maxim" :) | 28-Oct-10 19:33 |
| 1073 | BrianH | 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. | 28-Oct-10 19:31 |
| 1072 | Maxim | I'd add add a simple new search key, "comment author" I think that pretty much does what I need. | 28-Oct-10 19:29 |
| 1071 | Maxim | doesn't work, it only matches the comment text. so the only relevant one returned is the one where carl says "good point maxim" | 28-Oct-10 19:28 |
| 1070 | BrianH | 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. | 28-Oct-10 19:28 |
| 1069 | Maxim | nope. good point... I try that... | 28-Oct-10 19:26 |
| 1068 | BrianH | Have you tried searching the comments for your name? | 28-Oct-10 19:26 |
| 1067 | BrianH | True, it probably only works when you are interested in all the tickets, not just the ones you have commented on. | 28-Oct-10 19:25 |
| 1066 | Maxim | or maye a "me" could stand in for our user name (quick to type) | 28-Oct-10 19:24 |
| 1065 | Maxim | 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" | 28-Oct-10 19:24 |
| 1064 | Maxim | yeah but that's everyone's comments, just those you commented on. | 28-Oct-10 19:23 |
| 1063 | BrianH | I sort by recent changes, comments show up as such changes. But not comment modifications though. | 28-Oct-10 19:20 |
| 1062 | Maxim | thing=think | 28-Oct-10 19:19 |
| 1061 | Maxim | 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. | 28-Oct-10 19:19 |
| 1060 | Dockimbel | 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. | 28-Oct-10 17:27 |
| 1059 | Dockimbel | CureCode server upgraded to Cheyenne r104. All is going well. | 28-Oct-10 17:25 |
| 1058 | Andreas | Great, thanks! | 27-Oct-10 21:34 |
| 1057 | Dockimbel | Additions to v0.9.11in production:
- Added the "import account" form in registering page. Seems that's all the differences. | 27-Oct-10 21:32 |
| 1056 | Andreas | Thanks Nenad, "mostly 0.9.11" is already sufficient. | 27-Oct-10 21:30 |
| 1055 | Dockimbel | I'm checking my logs to give you a more accurate answer. | 27-Oct-10 21:26 |
| 1054 | Dockimbel | It's supposed to be 0.9.11, I might have done a few minor patches since 0.9.11 public release. | 27-Oct-10 21:25 |
| 1053 | Andreas | Is the CureCode running the R3 tracker a plain 0.9.11? Or has it custom modifications? | 27-Oct-10 21:20 |
| 1052 | james_nak | 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. | 11-Oct-10 20:21 |
| 1051 | Dockimbel | 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? | 11-Oct-10 18:34 |
| 1050 | Dockimbel | Carl: yes, and I produced a new Cheyenne revision to fix all the remaining issues regarding running as non-root. | 11-Oct-10 18:31 |
| 1049 | james_nak | 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. | 11-Oct-10 15:37 |
| 1048 | james_nak | Doc, yes, I will. I think you're on to something. I was thinking that it was on the remote side today. I'll check that tomorrow before I log in. Thanks. | 10-Oct-10 23:50 |
| 1047 | Carl | Doc: did you see my email regarding the security issue? | 10-Oct-10 22:19 |
| 1046 | Dockimbel | James: could you try to delete all the cookies on your remote browser when you see that error, then try accessing CureCode server again. | 10-Oct-10 22:15 |
| 1045 | james_nak | Doc, thanks. It's Cheyenne/0.9.20 | 9-Oct-10 17:18 |
| 1044 | Dockimbel | p: open http://your-server print p/locals/header/server | 9-Oct-10 17:05 |
| 1043 | james_nak | How does one tell? | 9-Oct-10 15:25 |
| 1042 | Dockimbel | James: I've never seen such error before. What version of Cheyenne are you using? | 9-Oct-10 14:21 |
| 1041 | james_nak | 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? | 9-Oct-10 10:58 |
| 1040 | Ladislav | http://www.rebol.net/r3blogs/0339.html explains, why A108 isn't available yet. I cannot test it either yet | 5-Oct-10 15:06 |
| 1039 | Graham | Just curious if you can do a diff on the RT prebuilt binaries and the ones you build yourself with the same compiler. | 5-Oct-10 1:03 |
| 1038 | Andreas | and as it does not crash the pre-built A107 binaries, I doubt it will with A108. | 5-Oct-10 0:22 |
| 1037 | Maxim | and the usual path with A108 isn't published... ask henrik or one of the others who are working on it. | 5-Oct-10 0:21 |
| 1036 | Andreas | so how should i try A108 then :) ? | 5-Oct-10 0:21 |
| 1035 | Maxim | I don't have it. | 5-Oct-10 0:20 |
| 1034 | Andreas | if you give me an A108, then i'll try | 5-Oct-10 0:19 |
| 1033 | Maxim | did you try in A108 ? | 5-Oct-10 0:08 |
| 1032 | Andreas | 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 | 5-Oct-10 0:07 |
| 1031 | BrianH | 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. | 21-Sep-10 20:20 |
| 1030 | Graham | All men are created equal | 11-Sep-10 5:59 |
| 1029 | AdrianS | I like that you give everyone the same treatment. No one escapes Graham's cutting comments! | 11-Sep-10 5:54 |
| 1028 | Graham | might add up to 130Mb! | 11-Sep-10 5:51 |
| 1027 | AdrianS | but whomever added 107 could've added a few more - does it matter if some versions won't be used? | 11-Sep-10 5:35 |
| 1026 | AdrianS | I was just laughing at myself - what I wrote earlier was a bit redundant. | 11-Sep-10 5:33 |
| 1025 | Graham | I guess you should have been more explicit ... is anyone using alpha 18? | 11-Sep-10 5:12 |
| 1024 | Graham | 106 was only out for a day before being superceded | 11-Sep-10 5:11 |
| 1023 | AdrianS | I guess a whole bunch and then some provisional ones is maybe too many ;-) | 11-Sep-10 5:07 |
| 1022 | AdrianS | 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. | 10-Sep-10 15:41 |
| 1021 | Gregg | Comment added. | 30-Aug-10 22:27 |
| 1020 | Ladislav | Are there additional comments to #1631? | 24-Aug-10 11:25 |
| 1019 | Brock | Chris' Google Chart API Dialect may be what you are looking for. http://www.rebol.org/view-script.r?script=charts-api.r | 1-Aug-10 14:48 |
| 1018 | Graham | One nice thing to be able to see is a graph of the resolved issues vs the submitted issues | 1-Aug-10 9:51 |
| 1017 | BrianH | OK, got it, good point. I'll pt that note in the ticket. | 8-May-10 16:28 |
| 1016 | Andreas | 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. | 8-May-10 16:27 |
| 1015 | Andreas | selfless? bind? d == true looks good to me. | 8-May-10 16:26 |
| 1014 | Ladislav | see above | 8-May-10 16:25 |
| 1013 | BrianH | How did you create d? | 8-May-10 16:25 |
| 1012 | Ladislav | >> mezz-selfless? d
== false >> mezz-selfless? bind? d == false | 8-May-10 16:24 |
| 1011 | BrianH | 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? | 8-May-10 16:20 |
| 1010 | Ladislav | , while the last test result differs from the result of the mezzanine | 8-May-10 16:19 |
| 1009 | Ladislav | yes, I know that | 8-May-10 16:18 |
| 1008 | BrianH | 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. | 8-May-10 16:18 |
| 1007 | Ladislav | I do not see it as a bug, necessarily, it would be much harder to implement it this way as a mezzanine | 8-May-10 16:15 |
| 1006 | Ladislav | (the same result) | 8-May-10 16:13 |
| 1005 | Ladislav | >> d: repeat self 1 ['self]
== self >> selfless? bind? d == true | 8-May-10 16:13 |
| 1004 | BrianH | I wasn't aware SELFLESS? took a word argument at all. It works consistently with object arguments. We may have to report this. | 8-May-10 15:54 |
| 1003 | Ladislav | It surely is harder to document... | 8-May-10 11:18 |
| 1002 | Ladislav | (and now, the question is, whether this behaviour is more useful, than the one of the mezzanine function.) | 8-May-10 11:18 |
| 1001 | Ladislav | Nevertheless, this is where the native SELFLESS? differs from the mezzanine one: >> d: repeat self 1 ['self] == self >> selfless? d == true | 8-May-10 11:17 |
| 1000 | Ladislav | >> selfless? c == true | 8-May-10 11:13 |
| 999 | Ladislav | >> c: repeat i 1 ['i]
== i >> selfless? 'i == false | 8-May-10 11:12 |