| # | User | Message | Date |
| 423 | BrianH | I didn't do any speed tests, as I had no internet access at the time. The desktop preferences scrolling worked great - my friend was impressed. I didn't notice any signifcant delay in anything View did, so I'd say it was pretty fast. | 21-Mar 15:16 |
| 422 | Pekr | BrianH - how fast is View on Eee? :-) | 21-Mar 15:13 |
| 421 | Gabriele | Qtask runs on it (both on Linux and OSX Intel), so I think 2.7.6 is not hiding any bad surprises. :) I've only tested locally and for limited time though. But I think qtask.com will switch to 2.7.6 soon. | 21-Mar 14:58 |
| 420 | BrianH | Core, View and Command 2.7.6 seems to work on the Asus Eee with Xubuntu (friend's machine). I didn't know enough about the potential Linux bugs to know what to test for, but everythng I tried worked perfectly. | 21-Mar 14:47 |
| 419 | Brent | 2.7.6 bugs with "tested" status changed to "complete". | 18-Mar 19:54 |
| 418 | Gabriele | R3's port model is completely different, not to mention that view is completely different too. | 16-Mar 21:24 |
| 417 | Henrik | perhaps leaks. I think I'm going to post a bit of code. | 16-Mar 19:48 |
| 416 | Graham | Move to bugs? | 16-Mar 19:46 |
| 415 | Henrik | perhaps we should make a separate group for this | 16-Mar 19:45 |
| 414 | Henrik | if I remove the wait loop and just wait once, no leak happens. | 16-Mar 19:44 |
| 413 | Graham | Anyone tested this under R3? | 16-Mar 19:42 |
| 412 | Graham | So, the leak is in View | 16-Mar 19:40 |
| 411 | Graham | when I close the window in the original code .. the leak stops | 16-Mar 19:38 |
| 410 | Graham | nothing here | 16-Mar 19:37 |
| 409 | Henrik | looks like I'm reading it wrong. now I get no leak. | 16-Mar 19:37 |
| 408 | Henrik | a: open/binary/direct/no-wait tcp://:9000
wait a This produces a 16 byte leak | 16-Mar 19:35 |
| 407 | Graham | Got an example? | 16-Mar 19:35 |
| 406 | Henrik | and the fewer leaks there are | 16-Mar 19:34 |
| 405 | Henrik | If I'm reading this right, we're talking about multiple leaks. The more code I remove, the smaller the leaks get. | 16-Mar 19:34 |
| 404 | Graham | I thought my app was also leaking ... but luckily after 2Mb it stopped climbing! | 16-Mar 19:34 |
| 403 | Henrik | Will you should try Instruments... it's really interesting :-) | 16-Mar 19:32 |
| 402 | WillArp | it's now at 124MB, after 22 hours, stopping it. | 16-Mar 19:22 |
| 401 | Henrik | I think the code can be reduced | 16-Mar 19:19 |
| 400 | Graham | Ok, everyone seems to confirm that this bug is still present. I've added it here. | 16-Mar 18:54 |
| 399 | Henrik | yet another leak when I close the window :-) (I don't even know if I'm reading this right) | 16-Mar 18:14 |
| 398 | Henrik | don't know if it's the same, but now I can see a memory leak in font handling when the window opens. | 16-Mar 18:12 |
| 397 | Henrik | my sampling rate was too low. it's a constant leak. over 30 seconds, 136 leaks are produced. | 16-Mar 17:12 |
| 396 | Henrik | Library: libSystem.B.dylib
Symbol Name: malloc I don't suppose this is useful? | 16-Mar 17:10 |
| 395 | Henrik | wow, Instruments show a leak every 0.61 minutes. | 16-Mar 17:06 |
| 394 | Henrik | the script ran up to about 45 MB RAM. I've stopped it now to test in Instruments. | 16-Mar 17:04 |
| 393 | Henrik | Perhaps some hints here, for those who want to read about ObjectAlloc: http://www.cocoadev.com/index.pl?ObjectAlloc | 16-Mar 14:43 |
| 392 | Henrik | will be about 3-4 hours before I can test. | 16-Mar 14:26 |
| 391 | Henrik | yes, thanks. found that too. | 16-Mar 14:26 |
| 390 | WillArp | ah when you Choose Executable, you have fields for parameters.. have to go , good luck Henrik 8) | 16-Mar 14:08 |
| 389 | WillArp | nope, my bad, Instruments leaking can't be attached to running process, so that was from a simple rebview launch.. now if I start record, it launch rebview, then I click console but recording stops. Need to find how to run rebview -v and launch the test script. | 16-Mar 14:03 |
| 388 | Henrik | so you can see the leaks now? | 16-Mar 13:56 |
| 387 | WillArp | Instruments does look really nice, pity I can't interpret output, but what changes a lot is Library: HIToolbox, ResponsibleCaller: ReceiveNextEvent | 16-Mar 13:55 |
| 386 | Henrik | yes. downloading xcode now, but am not sure I can cram it onto this disk... | 16-Mar 13:46 |
| 385 | WillArp | are you on Leopard? | 16-Mar 13:38 |
| 384 | Henrik | apparently Instruments might be able to do it. it holds the capabilities of an older app called ObjectAlloc for earlier versions of OSX. But I don't have Instruments installed on my Intel mac. | 16-Mar 13:27 |
| 383 | Henrik | the output does not look very useful to me. | 16-Mar 13:17 |
| 382 | Henrik | I took a sample of the process. I don't know how useful that is. Is there not a program for OSX to test for memory leaks? I remember OmniGroup has made one, but it costs money. | 16-Mar 13:16 |
| 381 | Henrik | it does climb slowly, about 10 kb/s | 16-Mar 13:14 |
| 380 | Henrik | it's now at 29.21 MB | 16-Mar 13:13 |
| 379 | Henrik | I'll let it run for a few more hours. would be nice if we could log that. | 16-Mar 13:13 |
| 378 | WillArp | so you do not see increases in Activity Monitor? strange, maybe let it run a couple more hours | 16-Mar 12:57 |
| 377 | Henrik | it's been running for about 2 hours. | 16-Mar 12:55 |
| 376 | Henrik | going between 5-7 MB under OSX here in stats. showing 27.48 MB usage in Activity Monitor. in WinXP I have 4-6 MB usage with stats. showing about 30 MB usage in Task Manager. | 16-Mar 12:51 |
| 375 | WillArp | it is now at 95.31MB | 16-Mar 12:36 |
| 374 | Henrik | I've had some odd experiences with GC under OSX. A console can easily eat 500-1000 MB RAM if left running for a few days, but it only happens sometimes and usually when running the same build script in that console multiple times. | 16-Mar 10:19 |
| 373 | Gabriele | i'll see if i can find the version I had wich kept track of the GC behavior and measured actual leak. | 16-Mar 8:57 |
| 372 | WillArp | have no pc here, will do tomorrow if nobody else can | 16-Mar 0:32 |
| 371 | Carl | Curious. Try it on XP too. | 16-Mar 0:30 |
| 370 | WillArp | now at 42.35 MB | 16-Mar 0:29 |
| 369 | WillArp | hmm 34.5MB, slowly but leaking? maybe someone else should retest? | 15-Mar 22:43 |
| 368 | WillArp | Graham: osx/intel here | 15-Mar 22:28 |
| 367 | Graham | It goes to 7 mb on 2.6 and 10 mb on 2.7 for me | 15-Mar 22:22 |
| 366 | Graham | 30Mb ?? | 15-Mar 22:22 |
| 365 | WillArp | so running the test till now, before the first GC real mem grow to +-30MB from there it has grown to 32.8 in the last 40 minutes, I may let it run till tomorrow if results are helpfull | 15-Mar 22:21 |
| 364 | Graham | Henrik, I first saw this bug using Rugby too ... and I reported it to Maarten who confirmed and wrote the short test script. But it seems gone now. | 15-Mar 22:09 |
| 363 | Carl | Stats reports memory it knows about. If a function uses some other allocation method, such as a raw malloc, then it's not going to show up on stats. | 15-Mar 21:49 |
| 362 | Henrik | "Note that the mem usage allocated as by stats is constant, but Windows task manager shows the process slowly running away. " <-- I thought also it was normal that stats and Windows task manager not always show the same amount of memory used by the process. Can Carl shed some light on this? | 15-Mar 21:36 |
| 361 | Henrik | I bet it's what I see in some rugby scripts, but that's almost impossible to dig out. | 15-Mar 21:34 |
| 360 | Gabriele | can anyone confirm that there are no long term leaks? (i remember testing this when Maarten posted it, and i didn't find any leaks at the time, but i didn't run the script for a very long time.) | 15-Mar 21:32 |
| 359 | Gabriele | Will, that is normal, it's how the GC works. | 15-Mar 21:30 |
| 358 | WillArp | /view 2.7.6.2.5 | 15-Mar 21:07 |
| 357 | Henrik | recycle? | 15-Mar 21:07 |
| 356 | WillArp | then again: 7680577 bytes total memory allocated by REBOL kernel 3956401 bytes total memory allocated by REBOL kernel | 15-Mar 21:06 |
| 355 | WillArp | the test script for that bug returns total memory allocated by rebol kernel, it grows, than suddenly: 6673483 bytes total memory allocated by REBOL kernel 3958001 bytes total memory allocated by REBOL kernel | 15-Mar 21:06 |
| 354 | Graham | Can http://www.rebol.net/cgi-bin/rambo.r?id=3593& be marked as fixed ? | 15-Mar 20:17 |
| 353 | Carl | Both cases have been used. For more than a year, it's been CALLBACK. Prior to that, it was a hidden, unsupported feature that was only done for one or two OS platforms. | 14-Mar 23:05 |
| 352 | Carl | yes | 14-Mar 23:04 |
| 351 | Graham | Linux .. | 14-Mar 18:11 |
| 350 | Graham | Is a 2.7.6 enface being released for testing ? | 14-Mar 18:11 |
| 349 | BrianH | In the position where the word is referenced in the specification dialect, the only words that "callback" could conflict with are datatype names. I expect that datatype names without a ! on the end are unlikely to occur in REBOL code. | 14-Mar 15:59 |
| 348 | Cyphre | I personally prefer "callback" as it is not REBOL datatype. OTOH I'm good with any decision here just don't change it in the future ;) | 14-Mar 12:11 |
| 347 | Gabriele | (oh, i see Carl already answered that :) | 14-Mar 7:28 |
| 346 | Gabriele | question: is the fact that "callback" is used elsewere relevant? | 14-Mar 7:27 |
| 345 | Carl | Note: The word callback used in this manner (as function type) does not conflict with callback used in other contexts. | 14-Mar 3:33 |
| 344 | Brent | ah, yes, looking at the script, it's just a system/version printout. It confused me - this test must be old. It should probably be removed from the install. But not critical. | 14-Mar 3:27 |
| 343 | Brent | BrianH, the test I was referring to may be obsolete now - it's bundled in viewtop. In viewtop, click on REBOL folder, then Tests, and it's "New /seek refinement". I thought it was new - first debug line is "Running Seek Test 2.7.6.3.1 10-Mar-2008..." but maybe that's just a system/probe printout at the start of the test. | 14-Mar 3:25 |
| 342 | Graham | Yeah ... I often use "callback" as a parameter too | 14-Mar 2:29 |
| 341 | Anton | Note: read-net and read-thru have a 'callback' parameter. /progress callback {Call func [total bytes] during transfer. Return true.}˜ | 14-Mar 2:25 |
| 340 | Paul | I prefer callback. | 14-Mar 2:12 |
| 339 | Graham | I prefer callback! because callback might often be used for something else. | 14-Mar 1:00 |
| 338 | BrianH | I prefer callback (more recent, looks less like a type so fewer possible name conflicts), but don't really care either way. | 14-Mar 0:57 |
| 337 | Graham | callback! | 14-Mar 0:56 |
| 336 | Carl | Status update: waiting on: http://www.rebol.net/upnews/0025.html | 14-Mar 0:52 |
| 335 | BrianH | DB 2.7.7 | 14-Mar 0:28 |
| 334 | Carl | We need to move to different group. | 14-Mar 0:28 |
| 333 | Carl | Note: We cannot make that change in 2.7.6. | 14-Mar 0:27 |
| 332 | Carl | Restated, do we want to discontinue support for ODBC 2? | 14-Mar 0:27 |
| 331 | Carl | Well, the question is more in general.... to all developers. | 14-Mar 0:26 |
| 330 | Graham | 3.525 as well | 14-Mar 0:26 |
| 329 | BrianH | 3.525 on XP, 3.526 on 2003. | 14-Mar 0:25 |
| 328 | BrianH | I'm using 3.525 and 3.526 here. | 14-Mar 0:25 |
| 327 | Carl | It has an option to build with ODBC 3. But, you need to tell me which you prefer. | 14-Mar 0:24 |
| 326 | Carl | R2 uses ODBC 2. | 14-Mar 0:24 |
| 325 | Carl | REBOL calls SQLSetConnectOption() | 14-Mar 0:22 |
| 324 | Carl | REBOL never calls SQLSetConnectAttr() | 14-Mar 0:21 |
| 323 | Carl | checking... | 14-Mar 0:18 |
| 322 | BrianH | I get the above error "SQLSetConnectAttr failed" during the open. I get Graham's error during the copy. | 14-Mar 0:17 |
| 321 | BrianH | Here's my test script: db: open odbc://HJBDBConv dbc: first db insert dbc "select * from dbo.blah" print mold copy dbc close db The table dbo.blah has one column a that is float type. | 14-Mar 0:16 |
| 320 | Graham | The silly thing won't trace again and I deleted the log to test with 2.7.6 | 14-Mar 0:14 |
| 319 | BrianH | I get the same error as Graham as well. I think that the connect error might be significant too. | 14-Mar 0:14 |
| 318 | BrianH | Note, I just realized that I was testing with 2.7.5 and getting the same errors. | 14-Mar 0:13 |
| 317 | Carl | G: what caused that? | 14-Mar 0:12 |
| 316 | BrianH | I can post a whole log if you like, with the test script. | 14-Mar 0:10 |
| 315 | BrianH | From the log. I have no way of returning the string, short of writing a program. | 14-Mar 0:09 |
| 314 | BrianH | During connect: DIAG [IM006] [Microsoft][ODBC Driver Manager] Driver's SQLSetConnectAttr failed (0) | 14-Mar 0:09 |
| 313 | Graham | badmem doesn't sound good! | 14-Mar 0:07 |
| 312 | Graham | I'm seeing this in the trace .. rebcmdview 408-e44 EXIT SQLSetStmtOption with return code 0 (SQL_SUCCESS) HSTMT 00B51BA8 UWORD 9 <SQL_ROWSET_SIZE> SQLPOINTER 0x0000000A (BADMEM) | 14-Mar 0:07 |
| 311 | Carl | (trims first) | 14-Mar 0:01 |
| 310 | Carl | In 3.0, I've been trying to loosen that up a bit.... as was recently noted in 3.0's TO-WORD " abc " | 14-Mar 0:00 |
| 309 | Carl | So, be sure to print the length of the string above. If it has spaces, then that's why we fail. | 13-Mar 23:59 |
| 308 | Carl | >> to-decimal "1.0" == 1.0 >> to-decimal "1.0 " ** Script Error: Invalid argument: 1.0 | 13-Mar 23:58 |
| 307 | Carl | #3 happens if after the parse of the float, the input length is not equal to the parse end point. | 13-Mar 23:58 |
| 306 | Carl | 1. missing mantissa digits: .e10 2. missing exponent digits 1.0e 3. invalid length | 13-Mar 23:57 |
| 305 | Carl | Reasons for failure are: | 13-Mar 23:57 |
| 304 | Carl | Actually, it does not do that. It directly tries the decimal conversion. | 13-Mar 23:57 |
| 303 | Gabriele | (ie. they get loaded as integer! which is not decimal! and so it fails?) | 13-Mar 23:55 |
| 302 | Gabriele | maybe rebol does not like that there's no .0 (1 instead of 1.0)? | 13-Mar 23:54 |
| 301 | Graham | in the odbc data source administrator. Never used it though. | 13-Mar 23:53 |
| 300 | Graham | Yes, there is a tracing tab | 13-Mar 23:52 |
| 299 | BrianH | The three values were 1.0, 2.2 and 3.0. | 13-Mar 23:52 |
| 298 | BrianH | Great, point me to it. | 13-Mar 23:52 |
| 297 | Graham | Brian, there is an ODBC trace tool I think | 13-Mar 23:52 |
| 296 | BrianH | C:\>sqlcmd -E -d "HJBDB Convert" -Q "select * from dbo.blah"
a
------------------------
1
2.2000000000000002
3 (3 rows affected) | 13-Mar 23:51 |
| 295 | Carl | Testing #43: >> unset-reg-funcs ** Script Error: unset-reg-funcs has no value ** Near: unset-reg-funcs | 13-Mar 23:33 |
| 294 | Carl | Works. #10 tested. | 13-Mar 23:28 |
| 293 | Carl | REBOL/Pro 2.7.6.3.1 (10-Mar-2008) *** License key is missing. Special features are not available. *** Please put your license.key file in the correct directory. >> get-reg/hklm "Software\Macromedia\FlashPlayer" "CurrentVersion" == "6,0,88,0" | 13-Mar 23:28 |
| 292 | Carl | Sounds good. Sorry, I'm just a bit sassy today. | 13-Mar 23:22 |
| 291 | BrianH | I've never written ODBC code in C languages - just used wrapper code in Access, Delphi, .NET, various command line apps. Wait, I'll try the command line apps... | 13-Mar 23:20 |
| 290 | Carl | Hey, I could write it in a day, then sell it for $1000, and become Tembria. http://www.tembria.com/support/help/servermonitor/v4.0/odbceventmonitor.html | 13-Mar 23:19 |
| 289 | BrianH | You're the one with the source, you write it :) | 13-Mar 23:18 |
| 288 | Carl | Surely a company as almighty as MS must have an ODBC jig tool for watching ODBC events return to the client? It's a no-brainer tool. (A mid-level coder could write it in a day. But, not going to happen.) | 13-Mar 23:17 |
| 287 | BrianH | I don't know what you mean. I get a block returned when doing this through REBOL. | 13-Mar 23:17 |
| 286 | Carl | BH: I need to know what ODBC string you see being returned from the DB. | 13-Mar 23:16 |
| 285 | Gabriele | changed summary of #46 | 13-Mar 23:15 |
| 284 | BrianH | That means SQL 2005, including the free Express version (not tested with 2000 or MSDE). SQL Native Client and Express are free downloads, so testing should be pretty easy. | 13-Mar 23:15 |
| 283 | BrianH | The problem arises on databases connected to through MS SQL Native Client. | 13-Mar 23:13 |
| 282 | Carl | #46 is NEW on recent builds, correct? Please add that to description if true. Thanks. | 13-Mar 23:13 |
| 281 | Carl | If no other info can be provided, then the fix stands as is with the DB Graham provided. If you find it a problem on another DB, resubmit with that DB as a title. | 13-Mar 23:11 |
| 280 | Carl | Regarding #45: The most likely cause is if the float returned by ODBC is not a valid decimal string format to REBOL. | 13-Mar 23:10 |
| 279 | Carl | Graham: #44, enbase title fixed. | 13-Mar 23:07 |
| 278 | Gabriele | 2.6 used callback! afaik, while 2.7 callback. so some scripts use the former, and some the latter, that's why for compatibilty it would be good to support both. but as i said... it's probably a minor problem. (and i've never used callbacks so i have no preference :) | 13-Mar 23:00 |
| 277 | BrianH | I'm OK either way, but if you want a differentiating factor, people are less likely to name datatypes CALLBACK. | 13-Mar 22:57 |
| 276 | Carl | That is the question, now isn't it. | 13-Mar 22:56 |
| 275 | Carl | Either one is ok. (Just not both.) | 13-Mar 22:56 |
| 274 | BrianH | Which is really compatible? | 13-Mar 22:55 |
| 273 | Gabriele | (otoh, fixing scripts is just a matter of search & replace, so maybe it's not important.) | 13-Mar 22:55 |
| 272 | Gabriele | it may be a good idea to allow both callback! and callback, for compatibility | 13-Mar 22:53 |
| 271 | Carl | Checking... | 13-Mar 22:51 |
| 270 | Carl | Graham: was able to get TITLE crash on cmdencap. | 13-Mar 22:51 |
| 269 | Carl | Please decide, then let me know. | 13-Mar 22:49 |
| 268 | Carl | http://www.rebol.net/upnews/0025.html | 13-Mar 22:48 |
| 267 | Carl | So, the doc is wrong. | 13-Mar 22:43 |
| 266 | Carl | Graham: in 2.7.6, it is called CALLBACK not CALLBACK! The doc: http://www.rebol.com/article/0141.html shows it both ways (look at last example). | 13-Mar 22:43 |
| 265 | BrianH | Well, /seek is binary in cmdview.exe too, so that is alright. | 13-Mar 22:32 |
| 264 | BrianH | I recall (perhaps incorrectly) CALLBACK was changed between 2.6.2 and 2.7.5. | 13-Mar 22:29 |
| 263 | Carl | BH: errors were from fact that /seek is binary only. | 13-Mar 22:29 |
| 262 | Carl | Anton, checking on CALLBACK question.... brb. | 13-Mar 22:28 |
| 261 | BrianH | I am not aware of the tests he is asking about, nor can I find them. Does anyone else know? | 13-Mar 22:28 |
| 260 | BrianH | Brent asked this: Brian, is the New /seek refinement test in the View Tests supposed to pass? I got 20 errors running it inside of the latest cmdview.exe Carl put in the Releases/release folder. | 13-Mar 22:27 |
| 259 | Carl | Can you confirm that 2.7.6 crashes with title? | 13-Mar 22:26 |
| 258 | Carl | Graham: tried this example in enbase, and it did not crash: REBOL [ title: "Test" encap: [title "Example" quiet secure none] ] print "Testing" wait 3 | 13-Mar 22:26 |
| 257 | Graham | Anton, it's from Benjamin's code. | 13-Mar 17:51 |
| 256 | Anton | Graham, it looks like the above error is with Ben's original COMLib implementation, not mine, isn't it ? Mine doesn't use callbacks. | 13-Mar 14:38 |
| 255 | Anton | Carl: callback! -> callback I need to know whether this change was intentional and now official or a bug (possibly resulting from the great string change). | 13-Mar 10:48 |
| 254 | Anton | Thanks Graham, I will try to keep compatibility. | 13-Mar 10:47 |
| 253 | Graham | Ok, this was reported in http://www.rebol.net/cgi-bin/rambo.r?id=4227& and using "callback" instead of "callback!" may work. | 13-Mar 9:52 |
| 252 | Graham | Was support for callbacks in DLL routines removed? | 13-Mar 9:41 |
| 251 | Graham | in 2.7.6 I get this >> COMLib: load/library %com2rebol.dll >> setErrorHandler: make routine! [ [ errorProc [callback! [string! integer! return: [int]]] [ return: [integer!] [ ] COMLib "setErrorHandler" ** Script Error: Invalid argument: callback! ** Near: setErrorHandler: make routine! [ errorProc [callback! [string! integer! return: [int]]] return: [integer!] ] CO... | 13-Mar 9:40 |
| 250 | Graham | In 2.6.2 I see this >> COMLib: load/library %com2rebol.dll >> setErrorHandler: make routine! [ [ errorProc [callback! [string! integer! return: [int]]] [ return: [integer!] [ ] COMLib "setErrorHandler" >> | 13-Mar 9:39 |
| 249 | Graham | Uncovering the Hidden DLL Function Callback Feature - http://www.rebol.com/article/0141.html | 13-Mar 9:39 |
| 248 | Graham | #10 is fixed it says, and #23 is deferred to 2.7.7 as no time. | 13-Mar 1:43 |
| 247 | Paul | What is the status on #10 and #23 in tracker? Anyone discussed those or are testing? | 12-Mar 23:21 |
| 246 | Graham | only tested on windows | 12-Mar 19:45 |
| 245 | Carl | Is #44 for all distros or just Linux? | 12-Mar 19:35 |
| 244 | Carl | Ah, that useful info to know. I investigated it a couple years ago, but probably did not try non-view versions. | 12-Mar 19:32 |
| 243 | Graham | Doesn't happen with the view versions of encap, only the non-view versions. | 12-Mar 19:28 |
| 242 | Graham | Remove the 'title from the encap header .. and it's fine. | 12-Mar 19:22 |
| 241 | Graham | It encaps okay, but when you run the encapped app, it brings up DrWatson. | 12-Mar 19:21 |
| 240 | Graham | Just did ... Dockimbel also first noted this bug when encapping Cheyenne. | 12-Mar 19:20 |
| 239 | Carl | Graham: can you add an example to #44, thanks. | 12-Mar 19:10 |
| 238 | Carl | Be sure to check SSL in cmdview. | 12-Mar 17:53 |
| 237 | Carl | So, that solution was not compatible with CALL. However, the SIGs mentioned above are still handled as stated. Test it to see for sure. | 12-Mar 17:52 |
| 236 | Carl | Good archive fetch. | 12-Mar 17:50 |
| 235 | Graham | Yes. What is happening is: the Unix versions of Core 2.5 fork() during startup to create a background process for asynchronous DNS lookup. Under certain circumstances web servers brutally "kill" the spawned process (SIGTERM/SIGINT/SIGHUP), instead of just closing stdin gracefully. That leaves the DNS child process behind. We have added some more sophisticated signal handling/trapping to Command 2.0 (will also be in future Core versions) to handle the most common problems and shut down child processes in those situations. The good news is that even with Core 2.5 those zombies are basically harmless. They take up no CPU time and virtually no RAM. -- Holger Kruse | 12-Mar 7:50 |
| 234 | Graham | Yeah ... I got bitten by Rebol zombies before when using REBOL for cgi. | 12-Mar 7:46 |
| 233 | Carl | New Linux CORE uploaded. | 12-Mar 4:44 |
| 232 | Carl | If you google REBOL zombies, you can see it was a problem in the past. Let's not let that happen again. | 12-Mar 4:40 |
| 231 | Carl | So, in 2.7.6, keep an eye out for zombies. They could end up knocking down your door late at night. | 12-Mar 4:39 |
| 230 | Carl | This would have happened in say, the 2001 or 2002 timeframe, so this bug has been pending for a while, I would think. | 12-Mar 4:38 |
| 229 | Carl | My guess is that we had a problem with process zombies at some point, and someone used a shotgun to nail them tall. | 12-Mar 4:38 |
| 228 | Carl | Ok, so got a new fix for CALL on Linux systems. The above documented child termination race was caused by REBOL itself. For some reason, the main process immediately set up a signal handler to dismiss zombies, making it a race for the CALL function to get status back. This problem has been solved. Doing a build of Linux to post soon. | 12-Mar 4:36 |
| 227 | Carl | Notice to all users: If you add a bug into the tracker, please be sure to add some code that shows it or points to a place where we can obtain code to do it. | 12-Mar 3:20 |
| 226 | Brent | Was anyone able to test #10 after Carl uploaded the SDK? | 12-Mar 2:36 |
| 225 | BrianH | No, and copy/deep doesn't do that either. | 11-Mar 23:36 |
| 224 | Henrik | brianH, in the result, if the result contain series, would /deep remove the bindings inside that block? | 11-Mar 23:35 |
| 223 | BrianH | I just realized that the /deep refinement to TAKE doesn't do anything in the mezzanine version. My question is: What is the point to the /deep refinement? I can't think what use it would be. I mean, the data is removed from the original, including any contents, whether you use /deep or not. | 11-Mar 23:34 |
| 222 | Graham | Logged into the tracker. | 11-Mar 7:15 |
| 221 | Graham | Well, having title in the encap header consistently produces a binary that crashes. | 11-Mar 7:09 |
| 220 | Carl | Fixed #43 too. | 11-Mar 5:38 |
| 219 | Carl | It's been uploaded, so #10 can be tested now. | 11-Mar 5:37 |
| 218 | Brent | Ah, I see. | 11-Mar 2:20 |
| 217 | Paul | I guess we need SDK to test it. | 11-Mar 2:19 |
| 216 | Brent | And regarding #10, there was a question on a way to test this registry bug. I don't know, so if someone has a good suggestion, feel free to jump in. Thanks! | 11-Mar 1:47 |
| 215 | Brent | Is bug #10 the last one for windows? Or do we have some marked as "tested" that shouldn't be? | 11-Mar 1:44 |
| 214 | Brent | Wave volume bug appears tested. Changing status to "tested". | 11-Mar 1:42 |
| 213 | Paul | oh sorry will do. | 10-Mar 23:42 |
| 212 | Carl | Paul... since this is not for testing, you should move to correct chat group. Thanks. | 10-Mar 23:42 |
| 211 | Paul | little snippet I had | 10-Mar 23:41 |
| 210 | Paul | rebol []
winlib: load/library %kernel32.dll winexec-func: make routine! [ file [string!] Ucmdshow [long] return: [long] ] winlib "WinExec" winexec-func "notepad.exe" 1 halt | 10-Mar 23:40 |
| 209 | Paul | note sure of the intention of 'run actually. Is it something like for just running another program. For like in windows winexec: | 10-Mar 23:40 |
| 208 | Paul | that was their name for a function built on it. | 10-Mar 23:32 |
| 207 | Paul | I called it winshellexecute because Gabriele and Gregg worked on that. | 10-Mar 23:32 |
| 206 | Paul | ShellExecuteA probably | 10-Mar 23:31 |
| 205 | Paul | I'm hoping I got that right. Checking myself. | 10-Mar 23:20 |
| 204 | Carl | I am not familiar with that. Can you provide me the URL to MSDN function def for that? | 10-Mar 23:19 |
| 203 | Paul | Well windows is just winshellexecute if I understand what 'run is for. | 10-Mar 23:16 |
| 202 | Carl | But, if you have info for any platform, feel free to post it! The more we gather, the sooner it will be done. | 10-Mar 23:16 |
| 201 | Paul | ahhh of course.... | 10-Mar 23:15 |
| 200 | Carl | Because it takes more research to determine how to do it cross-platform. | 10-Mar 23:14 |
| 199 | Paul | curious why is 'run being deferred? | 10-Mar 23:13 |
| 198 | Paul | Then this is now working correctly on windows. Now the wav volume slider maintains its settings on adjusting the loaded wave files volume. So this is good. | 10-Mar 23:11 |
| 197 | Carl | AltME would many complaints from users who use wave for other apps too. | 10-Mar 23:07 |
| 196 | Carl | Correct. The bug was that you could not avoid setting it. | 10-Mar 23:07 |
| 195 | Gabriele | the wave volume bar affects all programs. so we should not do that. | 10-Mar 23:07 |
| 194 | Carl | updated tracker | 10-Mar 23:06 |
| 193 | Paul | It should move the wave volume bar though so I don't think that is a bug is it? | 10-Mar 23:06 |
| 192 | Carl | Yes, correct. The language of the bug report is wrong. It is the wave volume. | 10-Mar 23:06 |
| 191 | Paul | The wave volume bar is adjusted which is what I expected by the master volume bar remains unchanged. | 10-Mar 23:05 |
| 190 | Paul | I only tested this by loading a wav file and changing its sound properties and reviewing the volume bars in windows. | 10-Mar 23:04 |
| 189 | Paul | #22 doesn't seem to be a problem on the new beta for windows or on the older 2.7.5 | 10-Mar 23:02 |
| 188 | Paul | ok. Thanks Carl, thought we might have overlooked something for a moment. | 10-Mar 22:43 |
| 187 | Carl | The bug was the crash itself. | 10-Mar 22:42 |
| 186 | Paul | Got ya. Thanks Gabriele. I thought it was a bit odd but I'm not a draw guru by any stretch. | 10-Mar 22:40 |
| 185 | Gabriele | otoh, maybe it should ignore the radial? not sure if that makes sense. | 10-Mar 22:39 |
| 184 | Gabriele | *output | 10-Mar 22:39 |
| 183 | Gabriele | Paul: you should not see anything. that code used to crash view. it should not crash, but i guess it should not ouput anything either (since it's not valid draw code) | 10-Mar 22:39 |
| 182 | BrianH | WillArp, do you depend on the old behavior? For that matter, do you depend on the hash! type? | 10-Mar 22:37 |
| 181 | Paul | status in tracker says "tested" but I still see nothing but grey window here on windows. | 10-Mar 22:37 |
| 180 | BrianH | It was determined that a change in datatype that was only documented by the source was not a good idea. | 10-Mar 22:37 |
| 179 | Paul | That is the example code in the ticket. | 10-Mar 22:35 |
| 178 | Paul | view layout [ box effect [ draw [ pen radial red line 10x10 100x100]]] | 10-Mar 22:35 |
| 177 | Paul | Regarding the #4010 fix. What should we see when executing the example code in the ticket? | 10-Mar 22:34 |
| 176 | BrianH | EXTRACT used to always extract a block! value, whatever the source value was, a practice that led to obscure bugs. This impeded its use for any datatype other than block!, so it was decided as part of the R3 development to make EXTRACT useful for other series types as well. | 10-Mar 22:31 |
| 175 | WillArp | 2.7.6: >> type? extract make hash! [a none] 2 == hash! 2.7.5:>> type? extract make hash! [a none] 2 == block! | 10-Mar 22:19 |
| 174 | WillArp | behaviour change due to extract fixes? | 10-Mar 22:17 |
| 173 | WillArp | context make hash! [a: none] context append extract make hash! [a none] 2 none both lines return an error with 2.7.6, second one works on 2.7.5 | 10-Mar 22:16 |
| 172 | WillArp | context make hash! [a: none] context append extract make hash! [a none] 2 none | 10-Mar 22:15 |
| 171 | BrianH | OK, tracker #10 could be fixed - no way to test without a /Face or /Pro build. Tracker #43 not built. | 10-Mar 21:54 |
| 170 | BrianH | It looks like unset-reg-funcs was called, but not yet unset itself. So, if the test exe is supposed to be /View, unset-reg-funcs should be unset, and if it supposed to be /Face, all of the reg funcs should still be set. Either way, test failed. | 10-Mar 21:49 |
| 169 | BrianH | help "reg" | 10-Mar 21:46 |
| 168 | Henrik | a simple way to test #4064? | 10-Mar 21:23 |
| 167 | Brent | Great. | 10-Mar 21:16 |
| 166 | Henrik | got #4267 tested now with the latest OSX Core build. | 10-Mar 21:08 |
| 165 | Brent | Moving #41 to tested with Gabe and Paul's test to verify. | 10-Mar 19:21 |
| 164 | Brent | I know Paul tested 41 successfully. | 10-Mar 19:17 |
| 163 | Gabriele | i don't like setting a ticket to tested unless i have at least two independent verifications of it being fixed. | 10-Mar 19:15 |
| 162 | Gabriele | have the non-linux ones been verified by someone other than me? | 10-Mar 19:14 |
| 161 | Henrik | Four built bugs left. I think I got the Linux specific ones. | 10-Mar 19:01 |
| 160 | Henrik | since it's a Posix bug | 10-Mar 18:37 |
| 159 | Henrik | or at least #4267 | 10-Mar 18:36 |
| 158 | Henrik | hmm... now if the remaining "Built" bugs are to be tested, then it's necessary with an OSX build of Core. | 10-Mar 18:35 |
| 157 | Henrik | ok :-) | 10-Mar 18:22 |
| 156 | Brent | Ah, well, evidently *I* don't have any status on it. We'll wait and see what Carl has. | 10-Mar 18:21 |
| 155 | Henrik | Sort of. :-) I have no requirements of an exe just now. It was just to make sure what status is on it. | 10-Mar 18:20 |
| 154 | Brent | Oh, looking back to yesterday's chat, you asked Carl to put up the latest for you to test. Is that what you're still looking for? | 10-Mar 18:18 |
| 153 | Brent | Right, I remember that now. I haven't heard anything since then. | 10-Mar 18:16 |
| 152 | Henrik | since Carl doesn't have Leopard on Intel, I helped debugging it. | 10-Mar 18:15 |
| 151 | Henrik | we were debugging a font problem a few days ago that causes it to crash on startup, but priorities shifted away from that | 10-Mar 18:15 |
| 150 | Brent | H: are you waiting on a recent change? I know Carl tested on OSX. Or are you looking for the exe? | 10-Mar 18:13 |
| 149 | Henrik | any news on OSX /View? | 10-Mar 18:11 |
| 148 | Brent | Thanks Henrik! | 10-Mar 18:10 |
| 147 | Brent | Thanks anyway, Graham. Input so far has been helpful. | 10-Mar 18:10 |
| 146 | Henrik | I'll work on it a bit. Ubuntu 7.10 here. | 10-Mar 18:09 |
| 145 | Graham | I"m at work all days soon .. no time to run tests now :( | 10-Mar 18:08 |
| 144 | Brent | Great, thanks Gabriele. | 10-Mar 18:07 |
| 143 | Gabriele | i think i have tested all the tickets marked as built, on linux. if anyone else can test them, we can set them to tested. | 10-Mar 18:06 |
| 142 | Gabriele | yes, that is fixed. | 10-Mar 16:56 |
| 141 | Brent | that is, AGG crash on view layout [ box effect [ draw [ pen radial red line 10x10 100x100]]] | 10-Mar 16:04 |
| 140 | Brent | So, there are still AGG problems, but the specific one in #4010 is fixed, yes? | 10-Mar 16:04 |
| 139 | Gabriele | rebview-linux seems fine here. i think the AGG problems i see were there in 2.7.5 too. | 10-Mar 11:10 |
| 138 | Graham | but if you don't specify the full path for the font .. you get nothing | 10-Mar 10:53 |
| 137 | Gabriele | (i'm on 7.10, not sure that makes much difference) | 10-Mar 10:53 |
| 136 | Graham | Haven't tried yet. | 10-Mar 10:53 |
| 135 | Gabriele | do those scripts in tools work correctly for you? | 10-Mar 10:52 |
| 134 | Graham | Gabriele .. this works for me under Ubuntu http://www.compkarori.com/vanilla/display/AGG | 10-Mar 10:51 |
| 133 | Graham | Hmm. I got AGG fonts working under Ubuntu 7.04 | 10-Mar 10:48 |
| 132 | Gabriele | Ubuntu | 10-Mar 10:47 |
| 131 | Gabriele | i think that was fixed last year. | 10-Mar 10:47 |
| 130 | Graham | Is the SSL line termination bug fixed ? | 10-Mar 10:47 |
| 129 | Graham | Which distro ? | 10-Mar 10:46 |
| 128 | Gabriele | Viewtop/tools/ REBOL DL Maker and REBOL Icon Maker do not work correctly on Linux 2.7.6. it's probably the AGG fonts problem. (just mentioning it.) | 10-Mar 10:45 |
| 127 | Gabriele | Carl, can you post the Linux CALL code somewhere (blog?) so that we can get Linux kernel hackers to have a look at it? | 10-Mar 10:36 |
| 126 | Graham | Carl, are you able to also build rebcmd, and encmdface.exe ? I'm seeing some really odd problems with storing decimal values with ODBC under Wine, and I'm using the latest encmdface which is 2.6.2 from Dec 2005. The 2.7.5 SDK is missing encmdface for some reason. | 10-Mar 10:24 |
| 125 | Paul | Doesn't seem to crash but I only get a grey solid filled window. | 10-Mar 8:39 |
| 124 | Paul | I think #4010 is only partially fixed. | 10-Mar 8:39 |
| 123 | Carl | Not many beta testers around this weekend. They will have a few more hours to test... as the sun makes its way from Europe to Ukiah. ;) | 10-Mar 8:38 |
| 122 | Brent | Sweet. Thanks Paul. | 10-Mar 3:02 |
| 121 | Paul | >> write %test {1234 { 5678 { 9101 { } >> read %test == "1234^/5678^/9101^/" >> s: open/seek %test >> copy s == #{313233340D0A353637380D0A393130310D0A} | 10-Mar 3:01 |
| 120 | Paul | Well then #41 tests ok on windows here. | 10-Mar 3:01 |
| 119 | Brent | I'm more of an engineer than a programmer, though, so my coding opinions should be weighted appropriately. :-) | 10-Mar 3:00 |
| 118 | Brent | My understanding (not saying a whole lot) is seek is limited to binary mode. I say that from my interpretation of the RAMBO entry. http://www.rebol.net/cgi-bin/rambo.r?sort=1&limit=1&cmd=Search&id=3598&pattern= | 10-Mar 2:59 |
| 117 | Paul | Did we want open/seek to return binary? (I'm referring to tracker #41) | 10-Mar 2:56 |
| 116 | Brent | Not sure - I think BrianH uploaded the SDK for R2 to DevBase if you don't have it. | 10-Mar 2:51 |
| 115 | Paul | #10 for windows will need SDK to test, right? | 10-Mar 2:47 |
| 114 | Brent | If you have negative test results for these, please post asap. Thanks for all the support! | 10-Mar 2:21 |
| 113 | Brent | And Linux items: #3, #18, #20, #42 as well as #40, #41. | 10-Mar 2:20 |
| 112 | Brent | Let's see... Windows items that need test verification: #10, #22, #40, #41. Anyone have any negative test results for these? | 10-Mar 2:19 |
| 111 | Brent | Anyone with successful Linux test results on #3? | 10-Mar 2:17 |
| 110 | Carl | right | 10-Mar 1:27 |
| 109 | Brent | ok, so not a big deal if the new stuff isn't completely bug free - at least it didn't make the existing stuff worse? | 10-Mar 1:26 |
| 108 | Carl | And also, most of them are new to R2, so if they have a problem, will not break existing code. | 10-Mar 1:25 |
| 107 | Brent | Many are BrianH's mezzanine backports from R3. He's tested them on his systems successfully. I'm reviewing this group to see what other results we have to see if we can move any of them to "tested". | 10-Mar 1:24 |
| 106 | Brent | So we've got quite a few "built" items in the tracker that need to go to "tested". | 10-Mar 1:22 |
| 105 | Carl | uploading new rebview for linux. | 10-Mar 1:15 |
| 104 | Carl | Deferred 23. No time. | 10-Mar 1:15 |
| 103 | Carl | What an ordeal. | 10-Mar 1:14 |
| 102 | Carl | I have no more time to spend on it. In R3, it won't be my problem... it will be the REBOL linux user's community problem. ;) | 10-Mar 1:13 |
| 101 | Carl | I hold off the child until after I've done the first select(). Then signal it to go. And we had to remove the waitpid NOHANG option. So, it does hang. But, since this is all for CALL/wait, it should be ok. | 10-Mar 1:12 |
| 100 | Carl | Yes, so, here's what I've ended up with... | 10-Mar 1:10 |
| 99 | Brent | Hey Linux is open source, send the fix in to Mr. Torvald. I'm sure he'd appreciate it. | 10-Mar 1:10 |
| 98 | Carl | Now, not everyone is qualified to say that... but, I designed OS kernels for 15 years. ;) | 10-Mar 1:10 |
| 97 | Brent | is there an acceptable workaround? You're the OS guy! | 10-Mar 1:09 |
| 96 | Carl | So, anyway, it appears that linux is fundamentally defective. | 10-Mar 1:08 |
| 95 | Brent | anyway, OT for this group... carry on! | 10-Mar 1:08 |
| 94 | Brent | Spurs team is like the REBOL team - international. French, Czech (at least they used to?), S. America. Good chemistry. ;-) | 10-Mar 1:08 |
| 93 | Brent | 7 pts. | 10-Mar 1:07 |
| 92 | Carl | Ah, did they lose? | 10-Mar 1:06 |
| 91 | Brent | Sad Spurs game. Less than 40% shooting ain't gonna do it... | 10-Mar 1:06 |
| 90 | Carl | yes, but sigaction does not solve basic problem | 10-Mar 1:06 |
| 89 | BTiffin | afaik (and I don't Carl) There is a schitzoid problem in Linux signals. Part using the system v behaviour and parts bsd, so it has problems. iirc, the suggestion was using sigaction. Not that I'm helping, just spewing. | 10-Mar 0:50 |
| 88 | Carl | So, in summary, it works if we do this: 1. avoid subprocess termination prior to parent resumption 2. avoid calling select() to check I/O channel events 3. call waitpid() without WNOHANG option Then it works. | 10-Mar 0:46 |
| 87 | Carl | Anyway, that does not solve the problem. We've got to find a way to make it work. | 10-Mar 0:39 |
| 86 | Carl | Going through this exercise reminds me of how badly the signal system is imlemented in unix/linux. I detested it in 1979, and I continue to in 2008. What a piece of junk. I would take an Amiga Exec style kernel signal system any time, any day, over any *nix. | 10-Mar 0:38 |
| 85 | Carl | Quite a puzzle. If I write a simple little fork example, works great. But, in practice when you've got io channels and things to deal with, it does not seem to work. | 10-Mar 0:36 |
| 84 | Carl | Well, seems to be more to it than that. | 10-Mar 0:34 |
| 83 | Carl | In my book, this is the classic process startup race. | 9-Mar 23:04 |
| 82 | Carl | In such cases, the waitpid() returns "no child processes" | 9-Mar 23:04 |
| 81 | Carl | A race condition occurs when, after the fork(), the child runs to completion before fork() returns to the parent. | 9-Mar 23:03 |
| 80 | Carl | Ok, here is a summary... | 9-Mar 23:01 |
| 79 | Carl | really beginning to look like a linux bug... how is that possible?? | 9-Mar 22:35 |
| 78 | Carl | so... it appears to be some kind of race | 9-Mar 22:28 |
| 77 | Carl | wrote some fork, exec, waitpid test progs... all seem ok. | 9-Mar 21:53 |
| 76 | Carl | back -- watched a few mins of SA Spurs game. | 9-Mar 21:40 |
| 75 | Carl | taking break -- going to lunch -- back in a while | 9-Mar 20:54 |
| 74 | Carl | Fedora | 9-Mar 20:53 |
| 73 | Brent | what distribution are you using? | 9-Mar 20:52 |
| 72 | Carl | Nope. Command executes just fine, and status problem remains as stated above. | 9-Mar 20:51 |
| 71 | Carl | Reason: well, maybe sh (bash) has magic secret powers that allow it's child to fully terminate and leave no trace, after all this is a total hack of an OS (yes, linux). | 9-Mar 20:50 |
| 70 | Carl | Tried removing the shell from the equation... and running the command directly in execlp(). | 9-Mar 20:49 |
| 69 | Carl | " The behavior of execlp() and execvp() when errors occur while attempting to execute the file is historic
practice, but has not traditionally been documented and is not specified by the POSIX standard. BSD (and
possibly other systems) do an automatic sleep and retry if ETXTBSY is encountered. Linux treats it as a
hard error and returns immediately. Traditionally, the functions execlp() and execvp() ignored all errors except for the ones described above and ENOMEM and E2BIG, upon which they returned. They now return if any error other than the ones described above occurs. | 9-Mar 20:41 |
| 68 | Carl | must be something to do with execlp | 9-Mar 20:38 |
| 67 | Carl | Looks fine. Here's the output (from debug prints). This is for just a garbage command. Shell: /bin/bash Child! calling execlp Parent forked pid: 9820 Handle_Pipes(pid 9820) /bin/bash: asdf: command not found select(): -1 (exited flag = 0) waitpid(pid 9820) = res -1, errno No child processes - status: -1 select(): 0 (exited flag = 1) exit_code 255 | 9-Mar 20:29 |
| 66 | Carl | possible, checking... | 9-Mar 20:24 |
| 65 | Brent | The other condition for that ECHILD error besides no child processes to wait for is that the specified pid is not a child of the calling process. Any clues there? Wrong pid somehow? | 9-Mar 20:21 |
| 64 | Carl | how is this possible? | 9-Mar 20:18 |
| 63 | Carl | More info: I removed the waitpid entirely, and watch procs via ps.... and there is no zombie!!! | 9-Mar 20:18 |
| 62 | Carl | I am providing a specific pid to waitpid. So, that should not happen. | 9-Mar 20:17 |
| 61 | Brent | I'm definitely no guru. Does this help at all from http://www.gnu.org/software/libtool/manual/libc/Process-Completion.html >> If more than one eligible child process has status information available, one of them is chosen randomly, and its status is returned immediately. To get the status from the other eligible child processes, you need to call waitpid again. << | 9-Mar 20:15 |
| 60 | Carl | it sure looks like a linux kernel bug, but we know from experience, always point that finger last. (we like to think it is a kernel bug, but it is rare) | 9-Mar 20:11 |
| 59 | Carl | question is, why do we have no child? even in a race, the kernel holds the process as a zombie and remains waitable until we call waitpid(). | 9-Mar 20:10 |
| 58 | Carl | so, that's why status is invalid | 9-Mar 20:09 |
| 57 | Carl | waitpid is returning with -1, and the errno is "no child processes" | 9-Mar 20:09 |
| 56 | Carl | status always returns as zero | 9-Mar 20:08 |
| 55 | Carl | fork() execlp(...) loop on select() -- required to process other rebol events waitpid(pid, &status, WNOHANG) | 9-Mar 20:08 |
| 54 | Carl | The situation is this... we do: | 9-Mar 20:06 |
| 53 | Carl | I've been working on #18 for more than an hour. It's been problematic. | 9-Mar 20:06 |
| 52 | Carl | Do we have any Linux kernel guru's lurking around? | 9-Mar 20:05 |
| 51 | Carl | Gabriele: this is the bug that qtask guys need fixed, right? | 9-Mar 18:43 |
| 50 | Carl | Working on #18 now. | 9-Mar 18:42 |
| 49 | Carl | Snagged it and slam dunk. | 9-Mar 18:33 |
| 48 | Carl | So, #20 still open. | 9-Mar 18:29 |
| 47 | Carl | Added insert-event-handler -- and see that the fkeys are returning odd words -- not schemes now, but not what they should be. | 9-Mar 18:28 |
| 46 | Carl | Fixed. But, related to #20. | 9-Mar 18:24 |
| 45 | Carl | Added #42. | 9-Mar 18:24 |
| 44 | Carl | Testing... from altme in linux using function keys like up-arrow now. | 9-Mar 18:23 |
| 43 | Henrik | no rush | 9-Mar 18:19 |
| 42 | Carl | Henrik: ok. Working on Linux bugs right now, then will do. | 9-Mar 18:18 |
| 41 | Carl | Is the test code tested? | 9-Mar 18:17 |
| 40 | Carl | Graham: I've fixed #20, but the test code posted there still shows no Fkeys. | 9-Mar 18:17 |
| 39 | Henrik | I'll test it, if you put it up | 9-Mar 16:31 |
| 38 | Carl | (If anyone wants to try it anyway, let me know) | 9-Mar 15:59 |
| 37 | Carl | Just wanted to mention the status. | 9-Mar 15:54 |
| 36 | Carl | But, colors are completely wrong running in Intel. Must be a few missing #ifdefs for the endians. Will investigate, but OSX may be a bit delayed in release. | 9-Mar 15:54 |
| 35 | Carl | Finally got it building ok. | 9-Mar 15:52 |
| 34 | Carl | There are a couple of other problems... all of which appear to be new (since in fact I am typing this message on an OSX altme which works ok.) | 9-Mar 15:06 |
| 33 | Carl | Googling the error, the solution is to build under G++ not GCC. Doing so fails to link as well, but for other reasons. | 9-Mar 15:01 |
| 32 | Carl | Regarding OSX: not able to build -- linker generates an error. | 9-Mar 15:00 |
| 31 | Carl | Added it to the title line | 9-Mar 14:59 |
| 30 | Carl | Somehow I missed the word Linux in that bug report. | 9-Mar 14:59 |
| 29 | Carl | #20 moved back to pending. | 9-Mar 14:57 |
| 28 | Gabriele | could it be the F-key bug? was that fixed yet? (i guess i should test it... :) | 9-Mar 13:33 |
| 27 | Carl | Makes nice fast way to quit altme. | 9-Mar 4:14 |
| 26 | Carl | So do others (ctrl-func-keys). Interesting. | 9-Mar 4:13 |
| 25 | Carl | Interesting, ctrl-left-arrow segfaults linux altme. | 9-Mar 4:12 |
| 24 | Carl | BTW, prefix means: pre fix. As in, the pending items have not been fixed yet. E.g. call. I just wanted a baseline to start with prior to changes. | 9-Mar 4:06 |
| 23 | Carl | Seems to run pretty well, as I used AltME running 2.7.6 to upload it. :-) | 9-Mar 4:04 |
| 22 | Carl | Uploaded rebview for linux to releases/test folder. | 9-Mar 4:03 |
| 21 | Paul | :-) | 9-Mar 4:00 |
| 20 | Carl | yep, good | 9-Mar 4:00 |
| 19 | Paul | >> do %misc-tests.r Tests Running... >> probe system/build 8-Mar-2008/10:56:59-8:00 == 8-Mar-2008/10:56:59-8:00 | 9-Mar 3:56 |
| 18 | Carl | probe system/build | 9-Mar 3:54 |
| 17 | Carl | yes, good | 9-Mar 3:54 |
| 16 | Paul | >> system/version == 2.7.6.3.1 | 8-Mar 21:14 |
| 15 | Paul | I take it that is a good sign on the final beta? | 8-Mar 21:13 |
| 14 | Paul | >> do %misc-tests.r Tests Running... >> | 8-Mar 21:13 |
| 13 | Maarten | I know from experience that we need to test all the enccryption stuff (rsa, dh, ...) on *nix. | 8-Mar 18:44 |
| 12 | Maarten | Shift works :-) | 8-Mar 18:40 |
| 11 | Carl | The "pending" items are all on other OSes.... but still for 2.7.6 -- a few are critical. | 8-Mar 17:25 |
| 10 | BrianH | Please build or port test cases for the other functions, so we can fix those too. | 8-Mar 17:03 |
| 9 | BrianH | The fix for that has already been posted to DevBase, 20 minutes after release. | 8-Mar 17:02 |
| 8 | Paul | >> do %misc-tests.r Tests Running... FAIL: [#"a" = take d: copy "abc"] - none FAIL: [#"b" = take next d: copy "abc"] - none FAIL: [none? take tail d: copy "abc"] - none FAIL: [#"c" = take/last d: copy "abc"] - none FAIL: [#"a" = take/last d: copy "a"] - none FAIL: [none? take/last d: copy ""] - none FAIL: [1 = take d: copy [1 2 3]] - none FAIL: [2 = take next d: copy [1 2 3]] - none FAIL: [none? take tail d: copy [1 2 3]] - none FAIL: [3 = take/last d: copy [1 2 3]] - none FAIL: [1 = take/last d: copy [1]] - none FAIL: [none? take/last d: copy []] - none >> system/version == 2.7.6.3.1 | 8-Mar 16:04 |
| 7 | Henrik | Instead of building two different set of test cases. | 8-Mar 16:01 |
| 6 | Henrik | I suggest that we build test cases for each of the backported R3 items. To save time later on, these same test cases should be attached to the R3 versions of the same functions inside DevBase. | 8-Mar 16:01 |
| 5 | Brent | Yes. I think the pending items have been postponed until a later release. | 8-Mar 15:55 |
| 4 | Henrik | so we test items marked "Built"? | 8-Mar 15:55 |
| 3 | Brent | If you're available to test this weekend, please jump in and post your results here. Many thanks! | 8-Mar 15:54 |
| 2 | Brent | REBOL/View 2.7.6 is in /Releases/Test, and test driver in /Testing | 8-Mar 15:53 |
| 1 | Brent | Created this group to coordinate testing of 2.7.6 and gather results. | 8-Mar 15:52 |