R2-Beta - OLD - 2.7.6 Testing (Coordinate testing of 2.7.6 release)

Return to Index Page
Most recent messages (500 max) are listed first.

#UserMessageDate
423BrianHI 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-08 15:16
422PekrBrianH - how fast is View on Eee? :-)21-Mar-08 15:13
421GabrieleQtask 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-08 14:58
420BrianHCore, 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-08 14:47
419Brent2.7.6 bugs with "tested" status changed to "complete".18-Mar-08 19:54
418GabrieleR3's port model is completely different, not to mention that view is completely different too.16-Mar-08 21:24
417Henrikperhaps leaks. I think I'm going to post a bit of code.16-Mar-08 19:48
416GrahamMove to bugs?16-Mar-08 19:46
415Henrikperhaps we should make a separate group for this16-Mar-08 19:45
414Henrikif I remove the wait loop and just wait once, no leak happens.16-Mar-08 19:44
413GrahamAnyone tested this under R3?16-Mar-08 19:42
412GrahamSo, the leak is in View16-Mar-08 19:40
411Grahamwhen I close the window in the original code .. the leak stops16-Mar-08 19:38
410Grahamnothing here16-Mar-08 19:37
409Henriklooks like I'm reading it wrong. now I get no leak.16-Mar-08 19:37
408Henrika: open/binary/direct/no-wait tcp://:9000 wait a

This produces a 16 byte leak

16-Mar-08 19:35
407GrahamGot an example?16-Mar-08 19:35
406Henrikand the fewer leaks there are16-Mar-08 19:34
405HenrikIf I'm reading this right, we're talking about multiple leaks. The more code I remove, the smaller the leaks get.16-Mar-08 19:34
404GrahamI thought my app was also leaking ... but luckily after 2Mb it stopped climbing!16-Mar-08 19:34
403HenrikWill you should try Instruments... it's really interesting :-)16-Mar-08 19:32
402WillArpit's now at 124MB, after 22 hours, stopping it.16-Mar-08 19:22
401HenrikI think the code can be reduced16-Mar-08 19:19
400GrahamOk, everyone seems to confirm that this bug is still present. I've added it here.16-Mar-08 18:54
399Henrikyet another leak when I close the window :-) (I don't even know if I'm reading this right)16-Mar-08 18:14
398Henrikdon't know if it's the same, but now I can see a memory leak in font handling when the window opens.16-Mar-08 18:12
397Henrikmy sampling rate was too low. it's a constant leak. over 30 seconds, 136 leaks are produced.16-Mar-08 17:12
396HenrikLibrary: libSystem.B.dylib Symbol Name: malloc

I don't suppose this is useful?

16-Mar-08 17:10
395Henrikwow, Instruments show a leak every 0.61 minutes.16-Mar-08 17:06
394Henrikthe script ran up to about 45 MB RAM. I've stopped it now to test in Instruments.16-Mar-08 17:04
393HenrikPerhaps some hints here, for those who want to read about ObjectAlloc: http://www.cocoadev.com/index.pl?ObjectAlloc16-Mar-08 14:43
392Henrikwill be about 3-4 hours before I can test.16-Mar-08 14:26
391Henrikyes, thanks. found that too.16-Mar-08 14:26
390WillArpah when you Choose Executable, you have fields for parameters.. have to go , good luck Henrik 8)16-Mar-08 14:08
389WillArpnope, 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-08 14:03
388Henrikso you can see the leaks now?16-Mar-08 13:56
387WillArpInstruments does look really nice, pity I can't interpret output, but what changes a lot is Library: HIToolbox, ResponsibleCaller: ReceiveNextEvent16-Mar-08 13:55
386Henrikyes. downloading xcode now, but am not sure I can cram it onto this disk...16-Mar-08 13:46
385WillArpare you on Leopard?16-Mar-08 13:38
384Henrikapparently 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-08 13:27
383Henrikthe output does not look very useful to me.16-Mar-08 13:17
382HenrikI 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-08 13:16
381Henrikit does climb slowly, about 10 kb/s16-Mar-08 13:14
380Henrikit's now at 29.21 MB16-Mar-08 13:13
379HenrikI'll let it run for a few more hours. would be nice if we could log that.16-Mar-08 13:13
378WillArpso you do not see increases in Activity Monitor? strange, maybe let it run a couple more hours16-Mar-08 12:57
377Henrikit's been running for about 2 hours.16-Mar-08 12:55
376Henrikgoing 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-08 12:51
375WillArpit is now at 95.31MB16-Mar-08 12:36
374HenrikI'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-08 10:19
373Gabrielei'll see if i can find the version I had wich kept track of the GC behavior and measured actual leak.16-Mar-08 8:57
372WillArphave no pc here, will do tomorrow if nobody else can16-Mar-08 0:32
371CarlCurious. Try it on XP too.16-Mar-08 0:30
370WillArpnow at 42.35 MB16-Mar-08 0:29
369WillArphmm 34.5MB, slowly but leaking? maybe someone else should retest?15-Mar-08 22:43
368WillArpGraham: osx/intel here15-Mar-08 22:28
367GrahamIt goes to 7 mb on 2.6 and 10 mb on 2.7 for me15-Mar-08 22:22
366Graham30Mb ??15-Mar-08 22:22
365WillArpso 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 helpfull15-Mar-08 22:21
364GrahamHenrik, 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-08 22:09
363CarlStats 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-08 21:49
362Henrik"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-08 21:36
361HenrikI bet it's what I see in some rugby scripts, but that's almost impossible to dig out.15-Mar-08 21:34
360Gabrielecan 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-08 21:32
359GabrieleWill, that is normal, it's how the GC works.15-Mar-08 21:30
358WillArp/view 2.7.6.2.515-Mar-08 21:07
357Henrikrecycle?15-Mar-08 21:07
356WillArpthen again: 7680577 bytes total memory allocated by REBOL kernel 3956401 bytes total memory allocated by REBOL kernel15-Mar-08 21:06
355WillArpthe 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 kernel15-Mar-08 21:06
354GrahamCan http://www.rebol.net/cgi-bin/rambo.r?id=3593& be marked as fixed ?15-Mar-08 20:17
353CarlBoth 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-08 23:05
352Carlyes14-Mar-08 23:04
351GrahamLinux ..14-Mar-08 18:11
350GrahamIs a 2.7.6 enface being released for testing ?14-Mar-08 18:11
349BrianHIn 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-08 15:59
348CyphreI 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-08 12:11
347Gabriele(oh, i see Carl already answered that :)14-Mar-08 7:28
346Gabrielequestion: is the fact that "callback" is used elsewere relevant?14-Mar-08 7:27
345CarlNote: The word callback used in this manner (as function type) does not conflict with callback used in other contexts.14-Mar-08 3:33
344Brentah, 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-08 3:27
343BrentBrianH, 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-08 3:25
342GrahamYeah ... I often use "callback" as a parameter too14-Mar-08 2:29
341AntonNote: read-net and read-thru have a 'callback' parameter.

/progress callback {Call func [total bytes] during transfer. Return true.}˜

14-Mar-08 2:25
340PaulI prefer callback.14-Mar-08 2:12
339GrahamI prefer callback! because callback might often be used for something else.14-Mar-08 1:00
338BrianHI prefer callback (more recent, looks less like a type so fewer possible name conflicts), but don't really care either way.14-Mar-08 0:57
337Grahamcallback!14-Mar-08 0:56
336CarlStatus update: waiting on: http://www.rebol.net/upnews/0025.html14-Mar-08 0:52
335BrianHDB 2.7.714-Mar-08 0:28
334CarlWe need to move to different group.14-Mar-08 0:28
333CarlNote: We cannot make that change in 2.7.6.14-Mar-08 0:27
332CarlRestated, do we want to discontinue support for ODBC 2?14-Mar-08 0:27
331CarlWell, the question is more in general.... to all developers.14-Mar-08 0:26
330Graham3.525 as well14-Mar-08 0:26
329BrianH3.525 on XP, 3.526 on 2003.14-Mar-08 0:25
328BrianHI'm using 3.525 and 3.526 here.14-Mar-08 0:25
327CarlIt has an option to build with ODBC 3. But, you need to tell me which you prefer.14-Mar-08 0:24
326CarlR2 uses ODBC 2.14-Mar-08 0:24
325CarlREBOL calls SQLSetConnectOption()14-Mar-08 0:22
324CarlREBOL never calls SQLSetConnectAttr()14-Mar-08 0:21
323Carlchecking...14-Mar-08 0:18
322BrianHI get the above error "SQLSetConnectAttr failed" during the open. I get Graham's error during the copy.14-Mar-08 0:17
321BrianHHere'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-08 0:16
320GrahamThe silly thing won't trace again and I deleted the log to test with 2.7.614-Mar-08 0:14
319BrianHI get the same error as Graham as well. I think that the connect error might be significant too.14-Mar-08 0:14
318BrianHNote, I just realized that I was testing with 2.7.5 and getting the same errors.14-Mar-08 0:13
317CarlG: what caused that?14-Mar-08 0:12
316BrianHI can post a whole log if you like, with the test script.14-Mar-08 0:10
315BrianHFrom the log. I have no way of returning the string, short of writing a program.14-Mar-08 0:09
314BrianHDuring connect: DIAG [IM006] [Microsoft][ODBC Driver Manager] Driver's SQLSetConnectAttr failed (0)14-Mar-08 0:09
313Grahambadmem doesn't sound good!14-Mar-08 0:07
312GrahamI'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-08 0:07
311Carl(trims first)14-Mar-08 0:01
310CarlIn 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-08 0:00
309CarlSo, be sure to print the length of the string above. If it has spaces, then that's why we fail.13-Mar-08 23:59
308Carl>> to-decimal "1.0" == 1.0 >> to-decimal "1.0 " ** Script Error: Invalid argument: 1.013-Mar-08 23:58
307Carl#3 happens if after the parse of the float, the input length is not equal to the parse end point.13-Mar-08 23:58
306Carl1. missing mantissa digits: .e10 2. missing exponent digits 1.0e 3. invalid length13-Mar-08 23:57
305CarlReasons for failure are:13-Mar-08 23:57
304CarlActually, it does not do that. It directly tries the decimal conversion.13-Mar-08 23:57
303Gabriele(ie. they get loaded as integer! which is not decimal! and so it fails?)13-Mar-08 23:55
302Gabrielemaybe rebol does not like that there's no .0 (1 instead of 1.0)?13-Mar-08 23:54
301Grahamin the odbc data source administrator. Never used it though.13-Mar-08 23:53
300GrahamYes, there is a tracing tab13-Mar-08 23:52
299BrianHThe three values were 1.0, 2.2 and 3.0.13-Mar-08 23:52
298BrianHGreat, point me to it.13-Mar-08 23:52
297GrahamBrian, there is an ODBC trace tool I think13-Mar-08 23:52
296BrianHC:\>sqlcmd -E -d "HJBDB Convert" -Q "select * from dbo.blah" a ------------------------ 1 2.2000000000000002 3

(3 rows affected)

13-Mar-08 23:51
295CarlTesting #43:

>> unset-reg-funcs ** Script Error: unset-reg-funcs has no value ** Near: unset-reg-funcs

13-Mar-08 23:33
294CarlWorks. #10 tested.13-Mar-08 23:28
293CarlREBOL/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-08 23:28
292CarlSounds good. Sorry, I'm just a bit sassy today.13-Mar-08 23:22
291BrianHI'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-08 23:20
290CarlHey, 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.html13-Mar-08 23:19
289BrianHYou're the one with the source, you write it :)13-Mar-08 23:18
288CarlSurely 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-08 23:17
287BrianHI don't know what you mean. I get a block returned when doing this through REBOL.13-Mar-08 23:17
286CarlBH: I need to know what ODBC string you see being returned from the DB.13-Mar-08 23:16
285Gabrielechanged summary of #4613-Mar-08 23:15
284BrianHThat 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-08 23:15
283BrianHThe problem arises on databases connected to through MS SQL Native Client.13-Mar-08 23:13
282Carl#46 is NEW on recent builds, correct? Please add that to description if true. Thanks.13-Mar-08 23:13
281CarlIf 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-08 23:11
280CarlRegarding #45: The most likely cause is if the float returned by ODBC is not a valid decimal string format to REBOL.13-Mar-08 23:10
279CarlGraham: #44, enbase title fixed.13-Mar-08 23:07
278Gabriele2.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-08 23:00
277BrianHI'm OK either way, but if you want a differentiating factor, people are less likely to name datatypes CALLBACK.13-Mar-08 22:57
276CarlThat is the question, now isn't it.13-Mar-08 22:56
275CarlEither one is ok. (Just not both.)13-Mar-08 22:56
274BrianHWhich is really compatible?13-Mar-08 22:55
273Gabriele(otoh, fixing scripts is just a matter of search & replace, so maybe it's not important.)13-Mar-08 22:55
272Gabrieleit may be a good idea to allow both callback! and callback, for compatibility13-Mar-08 22:53
271CarlChecking...13-Mar-08 22:51
270CarlGraham: was able to get TITLE crash on cmdencap.13-Mar-08 22:51
269CarlPlease decide, then let me know.13-Mar-08 22:49
268Carlhttp://www.rebol.net/upnews/0025.html13-Mar-08 22:48
267CarlSo, the doc is wrong.13-Mar-08 22:43
266CarlGraham: 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-08 22:43
265BrianHWell, /seek is binary in cmdview.exe too, so that is alright.13-Mar-08 22:32
264BrianHI recall (perhaps incorrectly) CALLBACK was changed between 2.6.2 and 2.7.5.13-Mar-08 22:29
263CarlBH: errors were from fact that /seek is binary only.13-Mar-08 22:29
262CarlAnton, checking on CALLBACK question.... brb.13-Mar-08 22:28
261BrianHI am not aware of the tests he is asking about, nor can I find them. Does anyone else know?13-Mar-08 22:28
260BrianHBrent 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-08 22:27
259CarlCan you confirm that 2.7.6 crashes with title?13-Mar-08 22:26
258CarlGraham: 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-08 22:26
257GrahamAnton, it's from Benjamin's code.13-Mar-08 17:51
256AntonGraham, 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-08 14:38
255AntonCarl: 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-08 10:48
254AntonThanks Graham, I will try to keep compatibility.13-Mar-08 10:47
253GrahamOk, this was reported in http://www.rebol.net/cgi-bin/rambo.r?id=4227& and using "callback" instead of "callback!" may work.13-Mar-08 9:52
252GrahamWas support for callbacks in DLL routines removed?13-Mar-08 9:41
251Grahamin 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-08 9:40
250GrahamIn 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-08 9:39
249GrahamUncovering the Hidden DLL Function Callback Feature - http://www.rebol.com/article/0141.html13-Mar-08 9:39
248Graham#10 is fixed it says, and #23 is deferred to 2.7.7 as no time.13-Mar-08 1:43
247PaulWhat is the status on #10 and #23 in tracker? Anyone discussed those or are testing?12-Mar-08 23:21
246Grahamonly tested on windows12-Mar-08 19:45
245CarlIs #44 for all distros or just Linux?12-Mar-08 19:35
244CarlAh, that useful info to know. I investigated it a couple years ago, but probably did not try non-view versions.12-Mar-08 19:32
243GrahamDoesn't happen with the view versions of encap, only the non-view versions.12-Mar-08 19:28
242GrahamRemove the 'title from the encap header .. and it's fine.12-Mar-08 19:22
241GrahamIt encaps okay, but when you run the encapped app, it brings up DrWatson.12-Mar-08 19:21
240GrahamJust did ... Dockimbel also first noted this bug when encapping Cheyenne.12-Mar-08 19:20
239CarlGraham: can you add an example to #44, thanks.12-Mar-08 19:10
238CarlBe sure to check SSL in cmdview.12-Mar-08 17:53
237CarlSo, 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-08 17:52
236CarlGood archive fetch.12-Mar-08 17:50
235GrahamYes. 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 Kruse12-Mar-08 7:50
234GrahamYeah ... I got bitten by Rebol zombies before when using REBOL for cgi.12-Mar-08 7:46
233CarlNew Linux CORE uploaded.12-Mar-08 4:44
232CarlIf you google REBOL zombies, you can see it was a problem in the past. Let's not let that happen again.12-Mar-08 4:40
231CarlSo, in 2.7.6, keep an eye out for zombies. They could end up knocking down your door late at night.12-Mar-08 4:39
230CarlThis would have happened in say, the 2001 or 2002 timeframe, so this bug has been pending for a while, I would think.12-Mar-08 4:38
229CarlMy guess is that we had a problem with process zombies at some point, and someone used a shotgun to nail them tall.12-Mar-08 4:38
228CarlOk, 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-08 4:36
227CarlNotice 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-08 3:20
226BrentWas anyone able to test #10 after Carl uploaded the SDK?12-Mar-08 2:36
225BrianHNo, and copy/deep doesn't do that either.11-Mar-08 23:36
224HenrikbrianH, in the result, if the result contain series, would /deep remove the bindings inside that block?11-Mar-08 23:35
223BrianHI 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-08 23:34
222GrahamLogged into the tracker.11-Mar-08 7:15
221GrahamWell, having title in the encap header consistently produces a binary that crashes.11-Mar-08 7:09
220CarlFixed #43 too.11-Mar-08 5:38
219CarlIt's been uploaded, so #10 can be tested now.11-Mar-08 5:37
218BrentAh, I see.11-Mar-08 2:20
217PaulI guess we need SDK to test it.11-Mar-08 2:19
216BrentAnd 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-08 1:47
215BrentIs bug #10 the last one for windows? Or do we have some marked as "tested" that shouldn't be?11-Mar-08 1:44
214BrentWave volume bug appears tested. Changing status to "tested".11-Mar-08 1:42
213Pauloh sorry will do.10-Mar-08 23:42
212CarlPaul... since this is not for testing, you should move to correct chat group. Thanks.10-Mar-08 23:42
211Paullittle snippet I had10-Mar-08 23:41
210Paulrebol [] 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-08 23:40
209Paulnote sure of the intention of 'run actually. Is it something like for just running another program. For like in windows winexec:10-Mar-08 23:40
208Paulthat was their name for a function built on it.10-Mar-08 23:32
207PaulI called it winshellexecute because Gabriele and Gregg worked on that.10-Mar-08 23:32
206PaulShellExecuteA probably10-Mar-08 23:31
205PaulI'm hoping I got that right. Checking myself.10-Mar-08 23:20
204CarlI am not familiar with that. Can you provide me the URL to MSDN function def for that?10-Mar-08 23:19
203PaulWell windows is just winshellexecute if I understand what 'run is for.10-Mar-08 23:16
202CarlBut, if you have info for any platform, feel free to post it! The more we gather, the sooner it will be done.10-Mar-08 23:16
201Paulahhh of course....10-Mar-08 23:15
200CarlBecause it takes more research to determine how to do it cross-platform.10-Mar-08 23:14
199Paulcurious why is 'run being deferred?10-Mar-08 23:13
198PaulThen 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-08 23:11
197CarlAltME would many complaints from users who use wave for other apps too.10-Mar-08 23:07
196CarlCorrect. The bug was that you could not avoid setting it.10-Mar-08 23:07
195Gabrielethe wave volume bar affects all programs. so we should not do that.10-Mar-08 23:07
194Carlupdated tracker10-Mar-08 23:06
193PaulIt should move the wave volume bar though so I don't think that is a bug is it?10-Mar-08 23:06
192CarlYes, correct. The language of the bug report is wrong. It is the wave volume.10-Mar-08 23:06
191PaulThe wave volume bar is adjusted which is what I expected by the master volume bar remains unchanged.10-Mar-08 23:05
190PaulI only tested this by loading a wav file and changing its sound properties and reviewing the volume bars in windows.10-Mar-08 23:04
189Paul#22 doesn't seem to be a problem on the new beta for windows or on the older 2.7.510-Mar-08 23:02
188Paulok. Thanks Carl, thought we might have overlooked something for a moment.10-Mar-08 22:43
187CarlThe bug was the crash itself.10-Mar-08 22:42
186PaulGot ya. Thanks Gabriele. I thought it was a bit odd but I'm not a draw guru by any stretch.10-Mar-08 22:40
185Gabrieleotoh, maybe it should ignore the radial? not sure if that makes sense.10-Mar-08 22:39
184Gabriele*output10-Mar-08 22:39
183GabrielePaul: 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-08 22:39
182BrianHWillArp, do you depend on the old behavior? For that matter, do you depend on the hash! type?10-Mar-08 22:37
181Paulstatus in tracker says "tested" but I still see nothing but grey window here on windows.10-Mar-08 22:37
180BrianHIt was determined that a change in datatype that was only documented by the source was not a good idea.10-Mar-08 22:37
179PaulThat is the example code in the ticket.10-Mar-08 22:35
178Paulview layout [ box effect [ draw [ pen radial red line 10x10 100x100]]]10-Mar-08 22:35
177PaulRegarding the #4010 fix. What should we see when executing the example code in the ticket?10-Mar-08 22:34
176BrianHEXTRACT 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-08 22:31
175WillArp2.7.6: >> type? extract make hash! [a none] 2 == hash! 2.7.5:>> type? extract make hash! [a none] 2 == block!10-Mar-08 22:19
174WillArpbehaviour change due to extract fixes?10-Mar-08 22:17
173WillArpcontext 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.510-Mar-08 22:16
172WillArpcontext make hash! [a: none] context append extract make hash! [a none] 2 none10-Mar-08 22:15
171BrianHOK, tracker #10 could be fixed - no way to test without a /Face or /Pro build. Tracker #43 not built.10-Mar-08 21:54
170BrianHIt 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-08 21:49
169BrianHhelp "reg"10-Mar-08 21:46
168Henrika simple way to test #4064?10-Mar-08 21:23
167BrentGreat.10-Mar-08 21:16
166Henrikgot #4267 tested now with the latest OSX Core build.10-Mar-08 21:08
165BrentMoving #41 to tested with Gabe and Paul's test to verify.10-Mar-08 19:21
164BrentI know Paul tested 41 successfully.10-Mar-08 19:17
163Gabrielei don't like setting a ticket to tested unless i have at least two independent verifications of it being fixed.10-Mar-08 19:15
162Gabrielehave the non-linux ones been verified by someone other than me?10-Mar-08 19:14
161HenrikFour built bugs left. I think I got the Linux specific ones.10-Mar-08 19:01
160Henriksince it's a Posix bug10-Mar-08 18:37
159Henrikor at least #426710-Mar-08 18:36
158Henrikhmm... now if the remaining "Built" bugs are to be tested, then it's necessary with an OSX build of Core.10-Mar-08 18:35
157Henrikok :-)10-Mar-08 18:22
156BrentAh, well, evidently *I* don't have any status on it. We'll wait and see what Carl has.10-Mar-08 18:21
155HenrikSort of. :-) I have no requirements of an exe just now. It was just to make sure what status is on it.10-Mar-08 18:20
154BrentOh, 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-08 18:18
153BrentRight, I remember that now. I haven't heard anything since then.10-Mar-08 18:16
152Henriksince Carl doesn't have Leopard on Intel, I helped debugging it.10-Mar-08 18:15
151Henrikwe were debugging a font problem a few days ago that causes it to crash on startup, but priorities shifted away from that10-Mar-08 18:15
150BrentH: are you waiting on a recent change? I know Carl tested on OSX. Or are you looking for the exe?10-Mar-08 18:13
149Henrikany news on OSX /View?10-Mar-08 18:11
148BrentThanks Henrik!10-Mar-08 18:10
147BrentThanks anyway, Graham. Input so far has been helpful.10-Mar-08 18:10
146HenrikI'll work on it a bit. Ubuntu 7.10 here.10-Mar-08 18:09
145GrahamI"m at work all days soon .. no time to run tests now :(10-Mar-08 18:08
144BrentGreat, thanks Gabriele.10-Mar-08 18:07
143Gabrielei 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-08 18:06
142Gabrieleyes, that is fixed.10-Mar-08 16:56
141Brentthat is, AGG crash on view layout [ box effect [ draw [ pen radial red line 10x10 100x100]]]10-Mar-08 16:04
140BrentSo, there are still AGG problems, but the specific one in #4010 is fixed, yes?10-Mar-08 16:04
139Gabrielerebview-linux seems fine here. i think the AGG problems i see were there in 2.7.5 too.10-Mar-08 11:10
138Grahambut if you don't specify the full path for the font .. you get nothing10-Mar-08 10:53
137Gabriele(i'm on 7.10, not sure that makes much difference)10-Mar-08 10:53
136GrahamHaven't tried yet.10-Mar-08 10:53
135Gabrieledo those scripts in tools work correctly for you?10-Mar-08 10:52
134GrahamGabriele .. this works for me under Ubuntu http://www.compkarori.com/vanilla/display/AGG10-Mar-08 10:51
133GrahamHmm. I got AGG fonts working under Ubuntu 7.0410-Mar-08 10:48
132GabrieleUbuntu10-Mar-08 10:47
131Gabrielei think that was fixed last year.10-Mar-08 10:47
130GrahamIs the SSL line termination bug fixed ?10-Mar-08 10:47
129GrahamWhich distro ?10-Mar-08 10:46
128GabrieleViewtop/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-08 10:45
127GabrieleCarl, 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-08 10:36
126GrahamCarl, 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-08 10:24
125PaulDoesn't seem to crash but I only get a grey solid filled window.10-Mar-08 8:39
124PaulI think #4010 is only partially fixed.10-Mar-08 8:39
123CarlNot 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-08 8:38
122BrentSweet. Thanks Paul.10-Mar-08 3:02
121Paul>> write %test {1234 { 5678 { 9101 { } >> read %test == "1234^/5678^/9101^/" >> s: open/seek %test >> copy s == #{313233340D0A353637380D0A393130310D0A}10-Mar-08 3:01
120PaulWell then #41 tests ok on windows here.10-Mar-08 3:01
119BrentI'm more of an engineer than a programmer, though, so my coding opinions should be weighted appropriately. :-)10-Mar-08 3:00
118BrentMy 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-08 2:59
117PaulDid we want open/seek to return binary? (I'm referring to tracker #41)10-Mar-08 2:56
116BrentNot sure - I think BrianH uploaded the SDK for R2 to DevBase if you don't have it.10-Mar-08 2:51
115Paul#10 for windows will need SDK to test, right?10-Mar-08 2:47
114BrentIf you have negative test results for these, please post asap. Thanks for all the support!10-Mar-08 2:21
113BrentAnd Linux items: #3, #18, #20, #42 as well as #40, #41.10-Mar-08 2:20
112BrentLet's see... Windows items that need test verification: #10, #22, #40, #41. Anyone have any negative test results for these?10-Mar-08 2:19
111BrentAnyone with successful Linux test results on #3?10-Mar-08 2:17
110Carlright10-Mar-08 1:27
109Brentok, 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-08 1:26
108CarlAnd also, most of them are new to R2, so if they have a problem, will not break existing code.10-Mar-08 1:25
107BrentMany 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-08 1:24
106BrentSo we've got quite a few "built" items in the tracker that need to go to "tested".10-Mar-08 1:22
105Carluploading new rebview for linux.10-Mar-08 1:15
104CarlDeferred 23. No time.10-Mar-08 1:15
103CarlWhat an ordeal.10-Mar-08 1:14
102CarlI 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-08 1:13
101CarlI 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-08 1:12
100CarlYes, so, here's what I've ended up with...10-Mar-08 1:10
99BrentHey Linux is open source, send the fix in to Mr. Torvald. I'm sure he'd appreciate it.10-Mar-08 1:10
98CarlNow, not everyone is qualified to say that... but, I designed OS kernels for 15 years. ;)10-Mar-08 1:10
97Brentis there an acceptable workaround? You're the OS guy!10-Mar-08 1:09
96CarlSo, anyway, it appears that linux is fundamentally defective.10-Mar-08 1:08
95Brentanyway, OT for this group... carry on!10-Mar-08 1:08
94BrentSpurs team is like the REBOL team - international. French, Czech (at least they used to?), S. America. Good chemistry. ;-)10-Mar-08 1:08
93Brent7 pts.10-Mar-08 1:07
92CarlAh, did they lose?10-Mar-08 1:06
91BrentSad Spurs game. Less than 40% shooting ain't gonna do it...10-Mar-08 1:06
90Carlyes, but sigaction does not solve basic problem10-Mar-08 1:06
89BTiffinafaik (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-08 0:50
88CarlSo, 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-08 0:46
87CarlAnyway, that does not solve the problem. We've got to find a way to make it work.10-Mar-08 0:39
86CarlGoing 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-08 0:38
85CarlQuite 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-08 0:36
84CarlWell, seems to be more to it than that.10-Mar-08 0:34
83CarlIn my book, this is the classic process startup race.9-Mar-08 23:04
82CarlIn such cases, the waitpid() returns "no child processes"9-Mar-08 23:04
81CarlA race condition occurs when, after the fork(), the child runs to completion before fork() returns to the parent.9-Mar-08 23:03
80CarlOk, here is a summary...9-Mar-08 23:01
79Carlreally beginning to look like a linux bug... how is that possible??9-Mar-08 22:35
78Carlso... it appears to be some kind of race9-Mar-08 22:28
77Carlwrote some fork, exec, waitpid test progs... all seem ok.9-Mar-08 21:53
76Carlback -- watched a few mins of SA Spurs game.9-Mar-08 21:40
75Carltaking break -- going to lunch -- back in a while9-Mar-08 20:54
74CarlFedora9-Mar-08 20:53
73Brentwhat distribution are you using?9-Mar-08 20:52
72CarlNope. Command executes just fine, and status problem remains as stated above.9-Mar-08 20:51
71CarlReason: 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-08 20:50
70CarlTried removing the shell from the equation... and running the command directly in execlp().9-Mar-08 20:49
69Carl" 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-08 20:41
68Carlmust be something to do with execlp9-Mar-08 20:38
67CarlLooks 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-08 20:29
66Carlpossible, checking...9-Mar-08 20:24
65BrentThe 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-08 20:21
64Carlhow is this possible?9-Mar-08 20:18
63CarlMore info: I removed the waitpid entirely, and watch procs via ps.... and there is no zombie!!!9-Mar-08 20:18
62CarlI am providing a specific pid to waitpid. So, that should not happen.9-Mar-08 20:17
61BrentI'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-08 20:15
60Carlit 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-08 20:11
59Carlquestion 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-08 20:10
58Carlso, that's why status is invalid9-Mar-08 20:09
57Carlwaitpid is returning with -1, and the errno is "no child processes"9-Mar-08 20:09
56Carlstatus always returns as zero9-Mar-08 20:08
55Carlfork() execlp(...) loop on select() -- required to process other rebol events waitpid(pid, &status, WNOHANG)9-Mar-08 20:08
54CarlThe situation is this... we do:9-Mar-08 20:06
53CarlI've been working on #18 for more than an hour. It's been problematic.9-Mar-08 20:06
52CarlDo we have any Linux kernel guru's lurking around?9-Mar-08 20:05
51CarlGabriele: this is the bug that qtask guys need fixed, right?9-Mar-08 18:43
50CarlWorking on #18 now.9-Mar-08 18:42
49CarlSnagged it and slam dunk.9-Mar-08 18:33
48CarlSo, #20 still open.9-Mar-08 18:29
47CarlAdded insert-event-handler -- and see that the fkeys are returning odd words -- not schemes now, but not what they should be.9-Mar-08 18:28
46CarlFixed. But, related to #20.9-Mar-08 18:24
45CarlAdded #42.9-Mar-08 18:24
44CarlTesting... from altme in linux using function keys like up-arrow now.9-Mar-08 18:23
43Henrikno rush9-Mar-08 18:19
42CarlHenrik: ok. Working on Linux bugs right now, then will do.9-Mar-08 18:18
41CarlIs the test code tested?9-Mar-08 18:17
40CarlGraham: I've fixed #20, but the test code posted there still shows no Fkeys.9-Mar-08 18:17
39HenrikI'll test it, if you put it up9-Mar-08 16:31
38Carl(If anyone wants to try it anyway, let me know)9-Mar-08 15:59
37CarlJust wanted to mention the status.9-Mar-08 15:54
36CarlBut, 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-08 15:54
35CarlFinally got it building ok.9-Mar-08 15:52
34CarlThere 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-08 15:06
33CarlGoogling the error, the solution is to build under G++ not GCC. Doing so fails to link as well, but for other reasons.9-Mar-08 15:01
32CarlRegarding OSX: not able to build -- linker generates an error.9-Mar-08 15:00
31CarlAdded it to the title line9-Mar-08 14:59
30CarlSomehow I missed the word Linux in that bug report.9-Mar-08 14:59
29Carl#20 moved back to pending.9-Mar-08 14:57
28Gabrielecould it be the F-key bug? was that fixed yet? (i guess i should test it... :)9-Mar-08 13:33
27CarlMakes nice fast way to quit altme.9-Mar-08 4:14
26CarlSo do others (ctrl-func-keys). Interesting.9-Mar-08 4:13
25CarlInteresting, ctrl-left-arrow segfaults linux altme.9-Mar-08 4:12
24CarlBTW, 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-08 4:06
23CarlSeems to run pretty well, as I used AltME running 2.7.6 to upload it. :-)9-Mar-08 4:04
22CarlUploaded rebview for linux to releases/test folder.9-Mar-08 4:03
21Paul:-)9-Mar-08 4:00
20Carlyep, good9-Mar-08 4:00
19Paul>> do %misc-tests.r Tests Running... >> probe system/build 8-Mar-2008/10:56:59-8:00 == 8-Mar-2008/10:56:59-8:009-Mar-08 3:56
18Carlprobe system/build9-Mar-08 3:54
17Carlyes, good9-Mar-08 3:54
16Paul>> system/version == 2.7.6.3.18-Mar-08 21:14
15PaulI take it that is a good sign on the final beta?8-Mar-08 21:13
14Paul>> do %misc-tests.r Tests Running... >>8-Mar-08 21:13
13MaartenI know from experience that we need to test all the enccryption stuff (rsa, dh, ...) on *nix.8-Mar-08 18:44
12MaartenShift works :-)8-Mar-08 18:40
11CarlThe "pending" items are all on other OSes.... but still for 2.7.6 -- a few are critical.8-Mar-08 17:25
10BrianHPlease build or port test cases for the other functions, so we can fix those too.8-Mar-08 17:03
9BrianHThe fix for that has already been posted to DevBase, 20 minutes after release.8-Mar-08 17:02
8Paul>> 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.18-Mar-08 16:04
7HenrikInstead of building two different set of test cases.8-Mar-08 16:01
6HenrikI 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-08 16:01
5BrentYes. I think the pending items have been postponed until a later release.8-Mar-08 15:55
4Henrikso we test items marked "Built"?8-Mar-08 15:55
3BrentIf you're available to test this weekend, please jump in and post your results here. Many thanks!8-Mar-08 15:54
2BrentREBOL/View 2.7.6 is in /Releases/Test, and test driver in /Testing8-Mar-08 15:53
1BrentCreated this group to coordinate testing of 2.7.6 and gather results.8-Mar-08 15:52

Return to Index Page