R2-Beta - OSX - Debugging

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

#UserMessageDate
733CarlIt is untested, but I am typing this message from an AltMe that is using it, so it must work to some degree.31-Jul-08 17:16
732CarlNew OSX SDK uploaded here in test folder.31-Jul-08 17:16
731HenrikI'm not sure which one we need to test here. I've been using rebview-osx from May 5th for a while without problems except for fonts, but maybe that's not the right version?2-Jul-08 19:41
730Carlhttp://www.rebol.com/article/0368.html - about OSX SDK2-Jul-08 19:26
729RobertStill no new OSX SDK...22-Jun-08 15:57
728RobertCarl, can we get a new OSX SDK release that includes the color fix?7-Jun-08 9:55
727CarlI think we will release it this way for now.5-May-08 15:04
726CarlYes, it will be slower, depending on the app. (Because we are blitting entire window.)5-May-08 15:03
725Henrikdo you intend to release it now or wait until there is a proper fix and/or a fix for the font problems under Leopard?5-May-08 6:39
724Henriklooks like it works fine, although it's a tad slower. interesting that some tests use both cores, which I guess is something quartz does.5-May-08 5:56
723Carlin releases/tests folder5-May-08 5:28
722CarlUploaded rebview for osx. Try it out.5-May-08 5:28
721CarlSeems to work ok, even typing with full screen refresh.4-May-08 23:53
720CarlTyping this message from OSX using a native Intel version of AltME.4-May-08 23:53
719CarlBTW, in the apps I've tried, it seems fast enough so far.4-May-08 23:34
718CarlI have spent several hours on OSX quartz API over the last couple days.

Generally, I never give up. But I really must limit my time here... because R3 work is more important!

What I am going to do is blit the entire window. This is not efficient; however, it does produce a perfect OS window output (because all the mechanics are being done in REBOL internally, not in quartz).

4-May-08 23:32
717Gabrielei'll get in touch with Jim O' Connor and see if he can help us with this. sorry I haven't had time yet to look more into this.25-Apr-08 5:01
716HenrikI agree. It doesn't bother me too much. As long as View programs will at least _run_. :-)24-Apr-08 17:30
715CarlLater, when we know more (probably from R3 project) we can fix it in a better way.24-Apr-08 17:02
714CarlI think it I get some time this weekend, I will write a small fast blitter, just for now to get OSX release out.24-Apr-08 17:02
713Henrikto me colors look more correct than before, except red is blue, but graphics are distorted though.23-Apr-08 14:49
712Gabrielei should be able to look at it monday.19-Apr-08 7:36
711GabrieleQuartz may be applying filters, and maybe there's something wrong with the provider too (i think it should be right, but i'm not 100% sure of what osx expects there)19-Apr-08 7:35
710CarlLooking closer at it, maybe not.19-Apr-08 6:38
709CarlI should note that REBOL uses this function for copying bits between internal buffers too, not just to the window.19-Apr-08 3:53
708CarlResize the window a bit to see it refresh -- close to how it should look.19-Apr-08 3:52
707CarlRun it, and click in the window anywhere to see odd things happen.19-Apr-08 3:47
706CarlUploaded rv2-osx for you to try, and to watch the debug output.19-Apr-08 3:46
705CarlAlso, many of the sizes are wrong.19-Apr-08 3:37
704CarlBut, there is a bigger problem.... the position on many things is wrong.19-Apr-08 3:37
703CarlUsing ...Order32Big gets us the closest.19-Apr-08 3:12
702CarlThe bad news is that the colors are still not correct.19-Apr-08 3:11
701CarlIt's been quite interesting. The good news it compiles and links ok!19-Apr-08 3:11
700CarlGabriele, I wanted to get back to you about the Quartz blitter...19-Apr-08 3:10
699Gabrielei've been told that this does not require any other change. but, i don't know about what you need to include/link with so i can't say there won't be problems there. also, there is one thing that seems a bit strange to me, and maybe it's an objective c thing... i've noted that in the comments.31-Mar-08 18:01
698CarlI am wondering how compatible quartz will be with the rest of the code... since we use windowing and events from the old api.31-Mar-08 17:20
697CarlOk, I'll take a look. Thanks.31-Mar-08 17:19
696WillArpGrazie Gabriele 8)27-Mar-08 19:19
695GabrieleI'm sure there's a lot of room for optimizations, and more research may be needed. But I have no easy way to test this function so I think it's better for me to just upload it for you to review.27-Mar-08 14:16
694GabrieleNote: I have not tested this in any way, so please review it!27-Mar-08 14:14
693GabrieleI have uploaded osx-blit-quartz.c in the Other directory.27-Mar-08 14:13
692GabrieleCarl, a friend gave me a possible solution by using Quartz to draw the bitmap on screen. I'll try to put together a replacement for osxblit.c and then we can try it out. In the meantime Reichart is getting me in touch with an OSX guru - so we'll definitely find a way to solve this.21-Mar-08 19:19
691GabrieleRobert, that would need to happen at every redraw, and require allocating a new buffer. It's just too slow, better using the ppc version on Rosetta.21-Mar-08 14:56
690RobertCan't we swap bytes in the final buffer via a short and very fast ASM code section? Will costs some cycles but better than screwed up colors.21-Mar-08 13:22
689CarlIt's very standard code.20-Mar-08 19:20
688CarlSure.20-Mar-08 19:19
687GabrieleIs it ok to post the osx blit code around? i want to ask reichart (i think he has OSX people), and some other friends.20-Mar-08 18:26
686Carl(every time I compile ;)20-Mar-08 17:12
685CarlAnd, please don't tell me all those functions are deprecated -- I know that all too well !20-Mar-08 17:12
684CarlPosted the code in Other folder.20-Mar-08 17:11
683CarlIt maybe difficult to change byte order, unless it is in the final render stage somewhere.20-Mar-08 17:09
682CarlStrange thing is... this is the only OS that shows it wrong. I think even the PPC Linux is correct, and of course PPC OSX too.20-Mar-08 17:08
681Cyphreyes, this would be a serious slowdown. If there is no OS support for that then the only solution imo si to render the backbuffer with the right order. For DRAW this can be done easily but I don't know how much work is to switch the byte order for the rest of View.20-Mar-08 10:46
680Pekrwould it slow down View too much, if you would convert before the blit on such affected OS?19-Mar-08 10:05
679Gabrieleif not, please post the code snippet somewhere, and we'll be asking around.19-Mar-08 8:52
678Gabrielewould it be possible to keep the image data as ARGB instead of BGRA internally?19-Mar-08 8:52
677WillArpWhere will we look for an osx guru to port R3 to osx and start rebol-cocoa bridging project?19-Mar-08 3:29
676WillArp8)19-Mar-08 3:26
675Carluploading altme to others folder19-Mar-08 3:25
674Carlfixed19-Mar-08 3:25
673Carlhmmm ppc is gzip intel is gz ... same but browser does not recognize first one19-Mar-08 3:23
672Carlwill post in just a bit19-Mar-08 3:19
671Carlpage updated19-Mar-08 3:19
670WillArpstill hoow do I run Altme intel ?19-Mar-08 3:16
669WillArpthanks19-Mar-08 3:15
668Carl(www.rebol.net)19-Mar-08 3:14
667CarlOSX uploaded to builds/sdk area.19-Mar-08 3:14
666CarlIt seems odd to me we don't have this problem on any other OSes or cpu's ... that I know of.19-Mar-08 2:49
665CarlI will also post our blit code somewhere, for people to take a look at it, in case anyone has some ideas.19-Mar-08 2:49
664CarlI will also post a license.key in the distribution, so all the tools are enabled for testing purposes.19-Mar-08 2:45
663CarlSo, I am going to release a beta version of OSX Intel 10.4+ including the SDK. You can try it if you like. Also, know that it is good enough to run AltME, so that's a good test.19-Mar-08 2:44
662CarlI would guess that there must be a fairly simple fix, but I do not have time to research it, there's a lot to do on 3.0 that needs my immediate attention.19-Mar-08 2:43
661CarlStatus: so far, we've found no one who knows how to fix our basic OSX Intel problem (that our colors are in BGRA fromat, but the API wants ARGB order).19-Mar-08 2:43
660TomCI am nigh-infinatly patient and would be content to build it myself14-Mar-08 21:31
659GrahamDoesn't have to be a simultaneous release.14-Mar-08 21:00
658Henrikoh yeah PPC with colors fixed would be fine.14-Mar-08 20:30
657Gabrielenowhere. :) use wine :P14-Mar-08 20:21
656WillArpwhere do I get the Intel Altme?14-Mar-08 20:20
655BrianHBe sure to use the new-style 1.3.6x rebcode naming, not the old-style 1.3.5x naming for Oldes' special edition.14-Mar-08 20:16
654GabrieleMaybe we can release OSX PPC too? better than nothing :)14-Mar-08 20:14
653GrahamAnd Oldes' rebcode special edition :)14-Mar-08 19:52
652GrahamOh ... and tomc's Solaris core14-Mar-08 19:51
651GrahamGreat.14-Mar-08 19:50
650CarlWin32 and Linux14-Mar-08 19:50
649GrahamA release today would be good then.14-Mar-08 19:49
648CarlYes.14-Mar-08 19:47
647GrahamIf it's an OSX only problem .. can we release others and fix OSX later?14-Mar-08 19:46
646CarlI am not happy about holding up R2 on OSX Intel due to this simple color problem.14-Mar-08 19:43
645CarlOtherwise any RGB swap would still make white. ;)14-Mar-08 19:43
644CarlSo, that's why white is yellow.14-Mar-08 19:42
643Carlyes... I think its due to BGRA <--> ARGB will swap blue for alpha and v.v.14-Mar-08 19:42
642Gabriele(maybe it's the alpha channel though.)14-Mar-08 18:25
641Gabrielethere's one thing to notice... even gray looks "greenish" here. so it may be more than just a byte order problem.14-Mar-08 18:23
640Gabrieleexcept for the known bugs, rv-osx seems to run fine here.14-Mar-08 18:22
639HenrikI would love to do it for quickly capturing ideas.14-Mar-08 18:03
638BrianHI never had much use for speech-to-text - all programming languages in modern use are unpronouncable to varying degrees.14-Mar-08 18:00
637Henrikor maybe just speech-to-text that works14-Mar-08 17:50
636Henriktext completion would be more fun14-Mar-08 17:48
635BrianHSpelling correction is overrated in a technical context.14-Mar-08 17:31
634BrianHNice.14-Mar-08 17:30
633Carlstill no spelling correcter :)14-Mar-08 17:30
632Carlpaste14-Mar-08 17:30
631Carl(cut and past with lines ;)14-Mar-08 17:30
630CarlREBOL/Encap 2.7.6.2.5 (14-Mar-2008) Copyright 2008 REBOL Technologies REBOL is a Trademark of REBOL Technologies All rights reserved.14-Mar-08 17:30
629Carlugly colors, but its at least 2x speed, and watch this...14-Mar-08 17:29
628BrianHWhat color is the window? :)14-Mar-08 17:29
627CarlTyping this message from AltME OSX Intel.14-Mar-08 17:28
626CarlThe cocoa stuff is so asbstracted, you have no idea what's really going on.14-Mar-08 17:23
625Carlyes 9 was14-Mar-08 17:22
624Carl:)14-Mar-08 17:22
623BrianHThink of it as accessibility - you need to support mentally challenged OSes too :)14-Mar-08 17:22
622HenrikI'm betting OS9 was almost easier?14-Mar-08 17:22
621Carl(because we require multiplexing gui, file streams, and network streams)14-Mar-08 17:21
620Carlthe problem so far has been that cocoa does not look "smart enough" to own the event stream ;)14-Mar-08 17:21
619Henrikthere are so many things to hook into and if you don't take advantage of it, OSX won't help you much. a blessing from cocoa developers perspective, but a curse for everyone else. it's basically why most ported software sucks under OSX.14-Mar-08 17:21
618Carlit will be quite the project to figure out how R3 runs in cocoa, since both want to "own" the event stream14-Mar-08 17:20
617Henrikif you are not a cocoa citizen in OSX land, you won't reap the benefits.14-Mar-08 17:19
616BrianHYes, particularly since that will also include apps for the iPhone and iPod Touch.14-Mar-08 17:19
615Carlthe subject of how to design a proper osx app in3.0 is going to be very interesting14-Mar-08 17:17
614Carlyes, we'll have to move on to 3.0.... nearly everything here is obsolete for osx14-Mar-08 17:16
613Carlwas14-Mar-08 17:16
612Carlthe f-key problem as new -- go back to prior test beta, and it will likely crash14-Mar-08 17:15
611Henrikthere is another problem, namely the redraw of windows that were recently hidden. we'll save it for later, but it could be a good heads up for what needs to be done to avoid that. it's also a problem in other programs that use custom UIs.14-Mar-08 17:10
610HenrikF-keys are not crashing anything, but they've never caused trouble for me.14-Mar-08 17:06
609Henrikand clipboard works14-Mar-08 17:05
608Henrikcaret placement is much better with the font here, which is either Lucida Grande or Geneva.14-Mar-08 17:05
607Carluploaded - please test14-Mar-08 17:00
606Carluploading OSX for all to try -- but note colors are still wrong.14-Mar-08 16:52
605Carlgeneral font problem? I'd say it's more than that. In general, it's going to take 3.0 to fix this stuff, because we need some OSX experts working on it.14-Mar-08 16:49
604Carlworks fine in arial, but not lucida14-Mar-08 16:48
603Henrikperhaps it's part of the general font problem14-Mar-08 16:45
602Carllooks like it is more font-dependent not size dependent14-Mar-08 16:44
601Carlprobably, but not sure... let me see...14-Mar-08 16:40
600Henrikabout the caret fix, so it will only be accurate for a few font sizes?14-Mar-08 16:37
599HenrikWinXP has that tendency to change keyboard language in the middle of everything.14-Mar-08 16:37
598Henriknow fix my stupid keyboard... :-(14-Mar-08 16:36
597Henrikvery cool >/(14-Mar-08 16:35
596CarlOk, clipboard fixed.14-Mar-08 16:35
595CarlI think the caret position needs to be based on font size, which it is not (currently).14-Mar-08 16:34
594CarlI don't have a great fix for it yet, just a rough patch.14-Mar-08 16:33
593Carlit was off by 2 pixels ;)14-Mar-08 16:33
592Henrikcurious about 1: what was the problem?14-Mar-08 16:23
591Carl1. fixed caret offset (2 pixels) 2. fixed crash from function keys (as was case on linux too) 3. working on clipboard fix right now14-Mar-08 16:22
590CarlA few updates regarding pending items...14-Mar-08 16:20
589CarlWow, so in this case Mr. Bill has outdone Mr. Steve.14-Mar-08 16:20
588Cyphrereferences: http://developer.apple.com/documentation/Carbon/Reference/QuickDraw_Ref/Reference/reference.html#//apple_ref/c/func/NewGWorld

http://developer.apple.com/documentation/QuickTime/Reference/QTRef_CompDecomp/Reference/reference.html#//apple_ref/doc/uid/TP40003437-CH1g-QTNewGWorld

14-Mar-08 13:33
587CyphreBTW There is also NewGWorld() function in QuickDraw but this IMO won't help either. AFAIK The only function which is able to create offscreen buffer with specific pixel format is: QTNewGWorld() from the QuickTime framework. Maybe it is possible to use CopyBits on it? But this would nee probably some experimenting.14-Mar-08 13:31
586CyphreI have found this thread: http://lists.apple.com/archives/quartz-dev/2006/Jul/msg00055.html So it looks rgb ordering is problematic even in Quartz (but maybe it has been improved as this is from 2006)

It looks there is no way to specify a pixelformat for PixMap. It is possible to switch AGG so it will be using different color component order so it matches the OSX Intel platform but I don't know if the rest of R2 View code is able to do it?

14-Mar-08 13:20
585Gabrielelet me know if there's anything you want me to try.14-Mar-08 7:58
584Gabrielethis means though, that i have no way to directly check the internal format of image!14-Mar-08 7:57
583Gabriele(as it should be)14-Mar-08 7:56
582GabrieleCarl, View 1.3.0 on PPC gives a weird result on my make image! test above, but View 2.7.5 gives the same output as above. So MOLD has probably been changed to give the same output on all platforms.14-Mar-08 7:56
581Gabrieleit's the why we need to figure out :)14-Mar-08 7:24
580Gabrielethat's correct.14-Mar-08 7:24
579CarlMy guess is that it turns up green on OSX.14-Mar-08 0:10
578CarlBTW, best minimal test for diagnostics is:

i: make image! 100x100 i/rgb: 255.0.0 view make face [image: i]

14-Mar-08 0:10
577CarlCould be. I hope Cyphre knows.14-Mar-08 0:05
576Gabriele(indeed they deprecated this stuff on 10.4, so they are probably assuming that apps using this are from the ppc era)14-Mar-08 0:04
575Gabrielethat is, they still want the image in the ppc order14-Mar-08 0:04
574Gabrieleactually... if my guess is right, the fact is that OSX kept the API the same between ppc and intel14-Mar-08 0:03
573Carlok14-Mar-08 0:03
572Gabrielei'll try that on PPC tomorrow to see what's the result.14-Mar-08 0:03
571CarlBut, that's not relevant to OSX display problem.14-Mar-08 0:02
570CarlIt sure seems like it.14-Mar-08 0:02
569CarlBGRA14-Mar-08 0:02
568Gabrieleso, does this mean that the molded image is platform dependent?14-Mar-08 0:01
567Gabrielewindows gives the same result, so this seems to be correct14-Mar-08 0:01
566Gabriele>> i == make image! [2x1 #{ 010203050607 } #{ 0408 }] >> to binary! i == #{0302010407060508}13-Mar-08 23:52
565Carl>> make image! [1x1 #{010203}] == make image! [1x1 #{ 010203 }]13-Mar-08 23:52
564CarlHmmm.... Why does that seem wrong to me?13-Mar-08 23:51
563Gabriele>> i == make image! [5x5 #{ FFFEFD000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000... >> to binary! i == #{ FDFEFF0000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000000...13-Mar-08 23:48
562Gabrielethis is what i'm seeing on rvosx5:13-Mar-08 23:48
561CarlFor little, it's just a straight copy from the image bitmap.13-Mar-08 23:47
560CarlWhen running on big endian, we reverse the bits.13-Mar-08 23:47
559Carlyes13-Mar-08 23:46
558Gabrieledoes to binary! reorder the bytes depending on platform?13-Mar-08 23:45
557CarlIt's a good question.13-Mar-08 23:43
556Gabrieleare they little endian on ppc too?13-Mar-08 23:41
555CarlNo, actually I think we keep them in little-endian order. Cyphre can confirm.13-Mar-08 23:40
554CarlWow, wouldn't that be fun... having to reorder the bits for each blit.13-Mar-08 23:40
553Gabriele(my guess is that for compatibilty with PPC apps the images have to be kept in big endian order, so not in the native processor order)13-Mar-08 19:39
552Gabrielewould it be possible to keep them in memory in the "correct" order instead of having to reorder them?13-Mar-08 19:38
551Gabrielefrom what i see it is very likely that you have to rearrange the bytes before the call.13-Mar-08 19:37
550Gabrieleit seems that RGBDirect is the only valid value there13-Mar-08 19:23
549Gabriele(found it)13-Mar-08 19:22
548Gabrielewhat type is pixmap above?13-Mar-08 19:19
547Gabrieleagreed, but some apps are not portable anyway. in any case... this is something for the future, and for the community13-Mar-08 19:12
546CarlI will not use REBOL client apps that cannot run on all the main systems.13-Mar-08 18:53
545CarlBut, if developers do that, then they are not mainstream REBOL apps.13-Mar-08 18:53
544Gabrieledinner, bbs13-Mar-08 18:53
543CarlAnyway, for now, we need to get colors fixed.13-Mar-08 18:53
542Gabrielebut... if we give developers options, then they can use the platform specific features if they know that they don't need the portability. for normal scripts one uses the platform neutral features.13-Mar-08 18:52
541CarlYes, and I am soooo ready.13-Mar-08 18:52
540Gabrieleyou know... that's why we need our own os ;)13-Mar-08 18:51
539CarlThe OS worlds of Win32, OSX, and *nix are moving further apart... they are diverging at a high level.13-Mar-08 18:51
538CarlFont interfaces are getting higher and higher level.13-Mar-08 18:50
537CarlBut, I worry a great deal about fonts.13-Mar-08 18:49
536CarlI think so to. These days, I think the CPU to g-card blits are fast enough.13-Mar-08 18:49
535Gabrielei think AGG should be the default, with the option (community developed etc.) of a Quartz backend.13-Mar-08 18:48
534CarlSo, there is a very slippery road here... if we start using local OS 2D functions, then R will render different on every OS, and we will be back to where Java was in 1997.13-Mar-08 18:48
533Gabrieleyeah, they have their own version of effect-lab.r too :)13-Mar-08 18:47
532CarlFor example, they want us to use Quartz. But Quartz duplicates the functions of our AGG lib, but of course, not exactly.13-Mar-08 18:47
531GabrieleR3, no?13-Mar-08 18:47
530CarlWe will need to move to the new API, but from what I can tell, it is going to be a huge project.13-Mar-08 18:46
529CarlIn fact, now, if you use apple online dev docs, a yellow box pops up for each api function to warn developers.13-Mar-08 18:45
528CarlYes, of course. 95% of the API we use deprecated. :)13-Mar-08 18:45
527Gabrielenothing, of course it has been deprecated :)13-Mar-08 18:44
526CarlAnd your point is... what?13-Mar-08 18:44
525Gabriele:)13-Mar-08 18:44
524Gabriele/* * CopyBits() *** DEPRECATED *** * * Mac OS X threading: * Not thread safe * * Availability: * Mac OS X: in version 10.0 and later in ApplicationServices.framework [32-bit only] but deprecated in 10.4 * CarbonLib: in CarbonLib 1.0 and later * Non-Carbon CFM: not available */13-Mar-08 18:43
523Carl(It's quite funny that it works fine on PPC - but not Intel.)13-Mar-08 18:42
522CarlREBOL functions are all spelled in reb new-code style: Copy_Bits().13-Mar-08 18:41
521Henrikit's a quickdraw funtion13-Mar-08 18:41
520CarlYes.13-Mar-08 18:40
519GabrieleIs CopyBits an OSX function? i can search for it in the apple docs if so and see if there's an easy fix.13-Mar-08 18:40
518Henrikif that color bug gets fixed, the fonts can wait till 2.7.7. at least we can see and use View windows under Leopard.13-Mar-08 18:40
517CarlBut, I am no expert on OSX.13-Mar-08 18:39
516CarlI am guessing that we need something other than RGBDirect.... we need it to reorder the bits based on the different endian order.13-Mar-08 18:38
515CarlI think I sent the source before, but here's the code that does the blit:

SetRect(&(*pixmap)->bounds, 0, 0, iw, ih); (*pixmap)->rowBytes = ((short)(iw * sizeof(REBCNT)) | 0x8000); // <- indicates PixMap (*pixmap)->baseAddr = (Ptr)VAL_IMAGE_BITS(src); (*pixmap)->packSize = ih * iw * 4; (*pixmap)->pmVersion = 4; (*pixmap)->packType = 0; (*pixmap)->packSize = 0; (*pixmap)->pixelType = RGBDirect; (*pixmap)->pixelSize = 32; (*pixmap)->cmpCount = 3; (*pixmap)->cmpSize = 8; CopyBits((BitMap *)(*pixmap), GetPortBitMapForCopyBits(wport), &sr, &dr, srcCopy, nil);

13-Mar-08 18:38
514CarlYes, it's QD. Looks like we are passing BGRA bitmaps to an ARGB system.13-Mar-08 18:36
513Gabrieleagreed.13-Mar-08 18:35
512BrentG: right, I was assuming it was going to be fixed in 2.7.6. If it doesn't, then it's a released bug and would be tracked in RAMBO. My understanding is #46 hasn't been released yet - it only exists in the private 2.7.6 beta here, so shouldn't be tracked in the public RAMBO universe.13-Mar-08 15:55
511Cyphreah, then Carl please specify what graphic API are you using in R2. QuickDraw?12-Mar-08 21:42
510HenrikCyphre, all colors are wrong in the OSX build, so it's probably not restricted to DRAW.12-Mar-08 21:38
509CyphreCarl, re RGB order: Is the RGB ordering related only to DRAW or you mean the 'screen blit' in generic way?12-Mar-08 21:30
508Gabrieleit mainly depends on when it can be fixed. if we expect to fix it for 2.7.6 then ok, but if it's going to be fixed in 2.7.7 then maybe it should go in RAMBO as a known bug.12-Mar-08 21:25
507Brentcorrection: "I don't think #46 should go"...12-Mar-08 21:17
506BrentI don't think #46 shouldn't go in the change log since it wasn't broken in 2.7.5 and only caused by 2.7.6 changes. Since RAMBO is public, I submit it is used for released bugs, or at least public beta bugs, not internal alpha and beta testing. $0.0212-Mar-08 21:16
505Gabrielebtw Carl, you made a comment earlier i think... that /output does not imply /wait. is that really so? do you have an example? (maybe I misunderstood.)12-Mar-08 20:46
504Henrikdepends on how change log is generated...12-Mar-08 19:46
503CarlGood question, since it is not released yet.12-Mar-08 19:31
502Gabriele#4612-Mar-08 19:17
501Gabrieledo you want me to add it to RAMBO too?12-Mar-08 19:14
500Gabrieleok12-Mar-08 19:12
499CarlGabriele, if you think it's a bug, add it to tracker with an example I can use to confirm the bug/fix. Thanks.12-Mar-08 19:11
498Gabrielefurthermore... you get the correct return code in the system port in 2.7.5... so we now have a workaround for qtask ;) a bit late i guess ;)12-Mar-08 18:07
497Gabriele2.7.5 does not have the problem12-Mar-08 18:06
496Gabrieleseems a new problem, let me check 2.7.5...12-Mar-08 18:03
495CarlSo, is this a new problem or old?12-Mar-08 17:15
494Gabriele"is getting a queuing" = "is queuing"12-Mar-08 16:36
493Gabrielewhat i see is that the system port is getting a queuing the child termination messages, but the awake is not being called unless some other events happens (eg. i press some key at the console)12-Mar-08 16:35
492Gabrielemay have broken the sys port though... investigating...12-Mar-08 16:33
491Gabrieleseems to work ok12-Mar-08 16:31
490Gabrielechecking linux now...12-Mar-08 16:30
489CarlI will check on that system port... and you should too.12-Mar-08 15:27
488CarlDid you test linux version too?12-Mar-08 15:24
487Gabrieleconfirmed CALL now works here.12-Mar-08 10:06
486Gabrieleconfirmed rvosx5 works here12-Mar-08 10:04
485GabrieleCould it be that the sigchild handler was used by the system port? i use the system port to get child termination messages in the Network Detective.12-Mar-08 9:57
484WillArpbtw my eavy batch script that was failing on 2.7.5 seams to run properly with latest, cheyenne no problem as well.. thank you! bye12-Mar-08 4:47
483Carltime to go, enjoy!12-Mar-08 4:46
482WillArphouch! thats eavy ;)12-Mar-08 4:46
481CarlAnd, in R3, I'm going to let some other very lucky person manage that code as open source!12-Mar-08 4:46
480CarlThat is the reason why CALL is non-trivial to implement (1200 lines of C code).12-Mar-08 4:45
479Carlso, for instance, you do a CALL that does a stream... over say, a minute... then you will see output update during that.12-Mar-08 4:45
478Carlright.12-Mar-08 4:44
477WillArpso call output returns as soon as ther is output, wiat will still wait for completation before returning?12-Mar-08 4:44
476Carlno12-Mar-08 4:42
475WillArpcall/output and call/output/wait are exactly the same right?12-Mar-08 4:42
474CarlNeed to upload that.12-Mar-08 4:34
473CarlBTW, this will fix linux too.12-Mar-08 4:34
472CarlYep, tomorrow. I use the bat life to restrict OSX activities, or they would take all my time, and nothing else would get done.12-Mar-08 4:34
471WillArpthanks!12-Mar-08 4:33
470WillArp8-) if you are still in mood, there are still traker items #13 (very annoying when pasting into altme) and #14 (makes selecting text difficult,also understanding where cursor is)12-Mar-08 4:33
469CarlSo, keep a sharp eye out for zombies!12-Mar-08 4:33
468Carluploaded - rebcore-osx212-Mar-08 4:32
467Carl22% battery12-Mar-08 4:30
466WillArpcore is good12-Mar-08 4:29
465Carlworks. do you want core or view?12-Mar-08 4:29
464WillArpon osx when quitting cheyenne (which launch subprocesses with call) with cpu busy at more than 30% sometimes one rebol process doesn't quit and burn cpu, hopefully this may resolve this issue as well12-Mar-08 4:14
463CarlOf which there should be only one, and will terminate when the main terminates, so no sigchild should be required.12-Mar-08 4:12
462CarlThe only other fork I can see is the async DNS subprocess.12-Mar-08 4:11
461CarlNot quite time for a test version. Must determine what other child procs there are, and find out why we would ignore their terminations.12-Mar-08 4:07
460CarlWe were competing with our own sigchild handler.12-Mar-08 4:06
459WillArpgreat, test version? 8)12-Mar-08 4:06
458CarlThat (above) was the race.12-Mar-08 4:05
457Carlyes12-Mar-08 4:05
456WillArpdoes it return right values always?12-Mar-08 4:04
455CarlThat's it! Reverted my changes from Sunday, and temporarily removed the sigchild handler, and CALL works great!12-Mar-08 4:03
454WillArpwaiting to test12-Mar-08 3:53
453CarlGoing over to my linux box to try out the theory.... back in a while.12-Mar-08 3:52
452CarlI must imagine that Holger added this to avoid accumulating process zombies.12-Mar-08 3:51
451CarlSo, indeed we very well may be dropping the signal in the case of CALL.12-Mar-08 3:49
450CarlHey, there's new hope, found this in posix main.c:

#if defined(SIGCHLD) static void child_handler(int sig) { if(Child_PID<=0) Child_PID=waitpid(-1,&Child_Status,WNOHANG); signal(SIGCHLD,child_handler); } #endif

12-Mar-08 3:49
449CarlChecking...12-Mar-08 3:47
448CarlMaybe we already have one setup... for some other child procs... and it is interferring!?12-Mar-08 3:47
447CarlInteresting... in considering that fact....12-Mar-08 3:46
446CarlI guess the next thing to do is setup a sigchild handler to watch for termination, but I am worried there will be a race with the select() call. That is, if select processes first, then will we still get a sigchild after that?12-Mar-08 3:44
445Carlallow.12-Mar-08 3:37
444CarlA good OS design would use message ports and allow the child to queue a termination message to the parent, then terminate asynchronously. This would allow the parent to check the termination status any time, but also alow the child to release its resources independent of the parent.12-Mar-08 3:37
443CarlCorrection, not orphan above, a waitable zombie. Got to use correct unix terms.12-Mar-08 3:35
442CarlNote, here unix is synonymous with linux and bsd.12-Mar-08 3:33
441CarlSince I've always been appalled by the design of the unix kernel, I've never tried to look that much deeper into things like this.12-Mar-08 3:33
440CarlIf I comment out the select() it works fine. However, that means the pipe will not get handled properly.12-Mar-08 3:31
439CarlThe problem is: we call select() prior to doing the waitpid(). The select() is used to check the IO channels for activity, but this action apparently releases the child process orphan. This is the only answer I've been able to conclude.12-Mar-08 3:30
438CarlYes... but not sure the solution.12-Mar-08 3:28
437WillArpany news about call ?12-Mar-08 3:21
436CarlCyphre: in OSX, do you know how to change the RGB byte order for the screen blit?12-Mar-08 2:11
435WillArplocal path problem, sorry12-Mar-08 1:52
434Henrikno problem12-Mar-08 1:46
433Carlok, gn, thanks for testing.12-Mar-08 1:46
432CarlThe peacock thinks he is a turkey. He has been part of the group for more than a year.12-Mar-08 1:45
431Henrikgotta go to bed. night. :-)12-Mar-08 1:45
430WillArpdemos not working here, checking local configs..12-Mar-08 1:43
429Henrik:-)12-Mar-08 1:42
428WillArphaha 8)12-Mar-08 1:42
427Carl(got interrupted -- by 40 turkeys outside my window -- and one peacock too)12-Mar-08 1:42
426Carldemos ok here too12-Mar-08 1:41
425WillArpmm.. checking again12-Mar-08 1:40
424Henrikall demos work fine here12-Mar-08 1:39
423WillArpno no windows in the back, try any demos12-Mar-08 1:39
422WillArppressing esc I get: REBOL console error (1) before it quits12-Mar-08 1:39
421Henrikthe window might be thrown to the back. an old View OSX bug12-Mar-08 1:38
420WillArpin desktop, any script I click, I see in the dock a process is started, but no window show up for those12-Mar-08 1:37
419Henrikit could be geneva 12, but I won't rule out Lucida12-Mar-08 1:36
418Henrikyes, I get those all the time too. I suppose it's every time a redraw is made.12-Mar-08 1:35
417WillArpgetting a lot of: Font Name: arial Checking cache... GetFontFamily Find_Font12-Mar-08 1:35
416WillArplatest build does boot, strange colors, Henrik, you sure it is Lucida Grande? Looks to me more like Geneva 12 which was always system default, not sure12-Mar-08 1:31
415CarlYes. Unfortunateky, the change I had to make may invalidate the SDK for 2.7.6. So I will need to check no that.12-Mar-08 1:29
414Henrikyes, it's odd. but I can finally test View scripts :-)12-Mar-08 1:28
413CarlWe will need to investigate the font problem.12-Mar-08 1:27
412CarlWell, at least now view comes up. I can fix color.12-Mar-08 1:27
411Henrikyes, looks like what I'd expect under Tiger12-Mar-08 1:26
410Carlok, uploaded12-Mar-08 1:25
409Henrikhopefully as png and not pdf12-Mar-08 1:24
408Henrikit should be the desktop12-Mar-08 1:24
407CarlI need it as file.12-Mar-08 1:24
406Carlwhere did it save?12-Mar-08 1:24
405Henrikin OSX? cmd-shift-4, press space so the cursor becomes a camera and hover over the window you want and click12-Mar-08 1:23
404Carl(how to best grab window and save as file?)12-Mar-08 1:22
403CarlHm, yes that is different than here.12-Mar-08 1:22
402Henrik/Users/Henrik/font_lab.png12-Mar-08 1:21
401Carlgoto viewtop, select tools, font-lab12-Mar-08 1:20
400Henrikand courier new in the editor12-Mar-08 1:16
399Henrikit does try to load arial though12-Mar-08 1:16
398Henrikno, it appears to be lucida grande. all writing has the same size and does not have bold style.12-Mar-08 1:15
397CarlSo, that is not arial?12-Mar-08 1:15
396Henrikwell, the size is the same too12-Mar-08 1:14
395Carlchecking...12-Mar-08 1:13
394CarlI wonder if font name is case sensitive?12-Mar-08 1:13
393HenrikI've uploaded a picture of it in Users/Henrik/font_issue.png12-Mar-08 1:13
392Henriknow the font used seems to be Lucida Grande, as can be seen in AltME.12-Mar-08 1:11
391CarlThat is good. Funky colors are good.12-Mar-08 1:10
390Henrikand it can't be because I'm tired and it's 2 AM :-)12-Mar-08 1:10
389HenrikI see funky colors.12-Mar-08 1:09
388CarlGreat!12-Mar-08 1:09
387Henrikit boots!12-Mar-08 1:09
386Henrikdownloading12-Mar-08 1:07
385Carluploaded rvosx512-Mar-08 1:05
384Carl(changing boot sequence)12-Mar-08 0:43
383Carlwell, let me try another method...12-Mar-08 0:15
382Henrikmaybe I don't if you upload it12-Mar-08 0:14
381Henrik:-)12-Mar-08 0:14
380Carlnow I get a bus error.12-Mar-08 0:14
379Carlok, building another fix.12-Mar-08 0:12
378CarlThis is very interesting.....12-Mar-08 0:06
377CarlBecause like Amiga, components get sorted by priority.12-Mar-08 0:06
376CarlLoad Components Component "REBOL Mezzanine Extensions" 1.2.0 [121936] Component "REBOL Network Auto-Configure" 1.9.0 [34224] ... ... lines... Init Components Component "REBOL Mezzanine Extensions" 1.2.0 [121936] Component "REBOL Network Auto-Configure" 1.9.0 [34224] ...12-Mar-08 0:06
375Henrikah :-)12-Mar-08 0:04
374CarlI assumed you were in the init part... because those component lines look the same in both sections.12-Mar-08 0:04
373Carlyou're not even into the init.... you are still in load12-Mar-08 0:03
372Carlah, wait...12-Mar-08 0:02
371Carlhow is that possible?12-Mar-08 0:01
370Henrik/Users/henrikmk/Desktop/rvosx4 -w [REBOL Main] Init Core1 Init Core2 Datatypes Natives System Object Errors Init Secondary Init Mezzanine Init Install Load Components Component "REBOL Mezzanine Extensions" 1.2.0 [121936] Component "REBOL Network Auto-Configure" 1.9.0 [34224] Component "Windows Installer" 1.3.0 [104272] Component "REBOL Internet Protocols" 1.71.0 [741952] Component "Dynamic Library Access" 1.5.0 [1152] Component "Command Shell Access" 1.10.0 [2880] Component "Graphics" 1.3.0 [7584] Component "Draw System" 1.1.0 [1568] Component "View and VID" 1.158.0 [63232] Find_Font Font Name: arial Checking cache... GetFontFamily Bus error12-Mar-08 0:01
369BrianHDo either of you have license.key?12-Mar-08 0:00
368Henrikyep, there they are12-Mar-08 0:00
367Carlyes12-Mar-08 0:00
366Henrikah12-Mar-08 0:00
365Carluse -w I think to avoid it12-Mar-08 0:00
364HenrikMD5 (/Users/henrikmk/Desktop/rvosx3) = bc661350e16ecb53abe3a85104efda1f12-Mar-08 0:00
363Carlit happens in middle.12-Mar-08 0:00
362Henriksame here12-Mar-08 0:00
361CarlMD5 (VIEW-PRO/rvosx4) = f60ed6b8bc269cfb17320b7603745aa211-Mar-08 23:59
360Henrikthe screen is cleared. is it supposed to be cleared at the beginning of the boot sequence or in the middle of it?11-Mar-08 23:59
359HenrikI don't get those.11-Mar-08 23:58
358CarlComponent "Licensing" 1.11.0 [5632] Init View (info) Init Font: system 12 opening, sizing, info building font table - outline metrics11-Mar-08 23:57
357CarlVerify that -- not rvosx4?11-Mar-08 23:56
356HenrikComponent "REBOL Mezzanine Extensions" 1.2.0 [121936] Component "REBOL Network Auto-Configure" 1.9.0 [34224] Component "Windows Installer" 1.3.0 [104272] Component "REBOL Internet Protocols" 1.71.0 [741952] Component "Dynamic Library Access" 1.5.0 [1152] Component "Command Shell Access" 1.10.0 [2880] Component "Graphics" 1.3.0 [7584] Component "Draw System" 1.1.0 [1568] Component "View and VID" 1.158.0 [63232] Find_Font Font Name: arial Checking cache... GetFontFamily Bus error11-Mar-08 23:54
355Carluploading rvosx4...11-Mar-08 23:53
354CarlOk, found bug I think.11-Mar-08 23:50
353CarlThere is an init sequence error here. Checking...11-Mar-08 23:47
352CarlAh... ha...11-Mar-08 23:46
351Carlok11-Mar-08 23:46
350HenrikI don't know if you can. I use AltME in VMWare where it works.11-Mar-08 23:46
349Carlhow do I cut and paste to altme with correct lf?11-Mar-08 23:45
348Henrikthis is all I see11-Mar-08 23:44
347HenrikComponent "REBOL Mezzanine Extensions" 1.2.0 [121936] Component "REBOL Network Auto-Configure" 1.9.0 [34224] Component "Windows Installer" 1.3.0 [104272] Component "REBOL Internet Protocols" 1.71.0 [741952] Component "Dynamic Library Access" 1.5.0 [1152] Component "Command Shell Access" 1.10.0 [2880] Component "Graphics" 1.3.0 [7584] Component "Draw System" 1.1.0 [1568] Component "View and VID" 1.158.0 [63232] Find_Font Font Name: arial Checking cache... GetFontFamily Bus error11-Mar-08 23:44
346CarlDo you see Init View (info) ?11-Mar-08 23:42
345Carlyes, it is.11-Mar-08 23:42
344Henrikno, but a strange thing here is that the terminal only outputs text starting from "Component "REBOL Mezzanine Extensions"". It's as if the the screen is cleared of any text prior to that line.11-Mar-08 23:42
343CarlE.g. Init Font: system 1211-Mar-08 23:40
342Carlis there anything before that? do you see an init for System font?11-Mar-08 23:39
341Carlgoogling it...11-Mar-08 23:23
340HenrikFind_Font Font Name: Arial Checking Cache... GetFontFamily Bus error11-Mar-08 23:19
339Carlwhat font name?11-Mar-08 23:19
338Carlchecking...11-Mar-08 23:18
337HenrikGetFontFamily BusError11-Mar-08 23:18
336Henrikdownloading11-Mar-08 23:16
335Carladded more prints related to font setup... run rvosx311-Mar-08 23:16
334Carlchecking...11-Mar-08 23:08
333Carlback11-Mar-08 23:08
332HenrikGot it working now. Same error as Gabriele.11-Mar-08 22:52
331Henrikthe OSX version won't let me use more than one world per machine. quite annoying.11-Mar-08 22:47
330Henrik1.2.15 under VMWare11-Mar-08 22:47
329Gabrielewhich version of altme are you running btw? i'm using the windows version under wine (CrossOver)11-Mar-08 22:46
328Henriknow it crashed with a different crash :-)11-Mar-08 22:44
327HenrikI'll see if I can get AltME going first.11-Mar-08 22:44
326Gabrieledo you want me to send you the file by other means? (mail? http?)11-Mar-08 22:44
325Henrikcan't test here yet, my AltME has some registry error so I can't get into R2-Beta from my macbook.11-Mar-08 22:42
324Gabrielethe above is just what i get...11-Mar-08 22:42
323Henrikshouldn't there be more information around the View and VID boot information?11-Mar-08 22:41
322GabrieleDate/Time: 2008-03-11 23:38:34.661 +0100 OS Version: Mac OS X 10.5.2 (9C2028) Report Version: 6

Exception Type: EXC_BAD_ACCESS (SIGBUS) Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000504 Crashed Thread: 0

11-Mar-08 22:40
321Gabrielecrash report seems to be like previous versions.11-Mar-08 22:40
320Carlhuh?11-Mar-08 22:39
319Gabriele[REBOL Main] Init Core1 Init Core2 Datatypes Natives System Object Errors Init Secondary Init Mezzanine Init Install Load Components Component "REBOL Mezzanine Extensions" 1.2.0 [121936] Component "REBOL Network Auto-Configure" 1.9.0 [34560] Component "Windows Installer" 1.3.0 [104272] Component "REBOL Internet Protocols" 1.71.0 [741952] Component "Dynamic Library Access" 1.5.0 [1152] Component "Command Shell Access" 1.10.0 [2880] Component "Graphics" 1.3.0 [7584] Component "Draw System" 1.1.0 [1568] Component "View and VID" 1.158.0 [63232] Bus error11-Mar-08 22:39
318Carlbrb - need food11-Mar-08 22:38
317Carlrvosx211-Mar-08 22:37
316Carlah good, will save some time. uploading from osx directly11-Mar-08 22:37
315Carllet me see if this works...11-Mar-08 22:35
314Carllogging in from osx11-Mar-08 22:35
313Carlok ready to upload...11-Mar-08 22:34
312HenrikCarl, turn down the screen brightness to minimum. :-)11-Mar-08 22:30
311Carlyes, doing that11-Mar-08 22:30
310Gabrieledo you think you can get some more debug prints in, so we can narrow down where it is failing?11-Mar-08 22:29
309Carlgoal is to fix this bug before my laptop bat dies. I'm at 86% now.11-Mar-08 22:21
308CarlOk, so... let's look at some code...11-Mar-08 22:20
307Gabrielei don't think REBOL is using CF from the child of a fork()...11-Mar-08 15:31
306Henrikhttp://www.mail-archive.com/freetype@nongnu.org/msg01513.html - I have no idea whether this is useful. We don't use freetype under OSX for View rendering, AFAIK?11-Mar-08 10:03
305Henrikperhaps, if we are using some old method of loading fonts that does not work anymore11-Mar-08 9:57
304Gabriele(same version here)11-Mar-08 7:20
303Gabrieledid we get to the point where there are incompatibilities between versions of fonts? :)11-Mar-08 7:18
302HenrikArial v. 5.01.2x here10-Mar-08 23:56
301Henrikperhaps we should do version checks on all the fonts?10-Mar-08 23:29
300Carlok10-Mar-08 23:19
299Gabrielegoing to get some sleep. will check back here tomorrow morning.10-Mar-08 23:18
298WillArpcopied the Arial famiily from 10.4.11 to 10.5.2, still crash10-Mar-08 23:17
297Carlok10-Mar-08 23:16
296Gabrielethe system shows: Arial, Arial Black, Arial Hebrew, Arial Narrow, Arial Rounded MT Bold, Arial Unicode MS10-Mar-08 23:13
295Gabrielei think i do. (have seen it in font lists) checking...10-Mar-08 23:12
294CarlSimple question: do you have arial font?10-Mar-08 23:12
293Gabrieleotoh, i don't know how many rebolers have Leopard - if most are on Tiger it could be considered non critical. (that is, i'm obviously biased is saying that's critical ;)10-Mar-08 23:12
292WillArpI vote for 1, cheyenne wont start 8)10-Mar-08 23:12
291CarlIt's going to take a few hours. Probably tomorrow... your time, before something to try out.10-Mar-08 23:11
290CarlYes, ok.10-Mar-08 23:10
289Gabriele2) seems much more critical (view does not run)10-Mar-08 23:09
288Carlwhich one to fix first?10-Mar-08 23:09
287CarlThere are 2 bugs here: 1. CALL/wait -- need to spend some time and get some tests going 2. Crash in fonts -- need to check all system func return values more carefully (a guess)10-Mar-08 23:09
286GabrieleCarl, not sure if it would be of any help but... i could set up an ssh account for you on this machine. then you can test directly.10-Mar-08 23:05
285WillArpleopard has easyer threading manipulation and script bridging, hopefully R3 will be leopard optimized, R2 for older platforms10-Mar-08 23:04
284CarlSo, I'm going to go rework the CALL tests so I can use the in 2.7.6 -- these days, tests are more critical than code.10-Mar-08 23:04
283CarlInteresting stuff. But our perf is ok. Maybe later on 3.0 we can try some tricks.10-Mar-08 23:03
282CarlBut, then, it does not support Unicode directly.10-Mar-08 23:02
281CarlAnd of course, the entire OSX API we use is deprecated. We're supposed to use Quartz these days.10-Mar-08 23:01
280WillArpmaybe here? http://developer.apple.com/carbon/tipsandtricks.html#ImprovePerformance10-Mar-08 23:01
279CarlLet me know if you find anything about font crashes. ;)10-Mar-08 23:00
278CarlIs it just the gdb? Yes, that is a standard method used on Unix systems.10-Mar-08 23:00
277CarlWill, what part of the tips and tricks did you want to show me?10-Mar-08 23:00
276WillArp8)10-Mar-08 22:59
275Gabrieleand of course it's not crashing on Carl's machine. :)10-Mar-08 22:59
274WillArpok10-Mar-08 22:59
273GabrieleWill, gdb is no help to us because there are no debugging symbols in the rebol exe.10-Mar-08 22:59
272WillArphttp://developer.apple.com/carbon/tipsandtricks.html#Gdb ?10-Mar-08 22:58
271CarlI did not see it because it's part of the command tests.10-Mar-08 22:57
270CarlAh.... actually there is a test suite for CALL.10-Mar-08 22:57
269WillArpmaybe some tips here? http://developer.apple.com/carbon/tipsandtricks.html10-Mar-08 22:56
268CarlI am checking to see if I have any such tests in the archive.10-Mar-08 22:56
267CarlYes.10-Mar-08 22:55
266GabrieleCarl: would the test suite need to include an external program to call that was multiplatform as well? Should it call REBOL itself?10-Mar-08 22:53
265WillArpthis is the kind of workarounds.. image-size?: func [f /local o t r][ r: false t: 0 while [all[not r t < 5]][ t: add t 1 attempt[ o: copy "" call/output/wait join {sips -g pixelHeight -g pixelWidth } f o o: parse o "" r: to-pair rejoin [select o "pixelWidth:" "x" select o "pixelHeight:"] ] ] r ]10-Mar-08 22:51
264WillArpyes10-Mar-08 22:46
263Gabrieleconfirmed that call works better on that release, but it still has the random return value bug.10-Mar-08 22:45
262CarlWithout that, we'll just continue to break stuff.10-Mar-08 22:45
261CarlI think the only practical way to fix CALL is to write a test suite for it.10-Mar-08 22:45
260CarlThe source of the problem is most likely the fix for CALL/wait made for Linux. It is the same code.

In summary, Linux appears to have a bug related to process cleanup that purges the return status for a process prior to the parent reading it.

10-Mar-08 22:44
259WillArpwell, call "open something" work in 2.7.5 intel10-Mar-08 22:44
258Henrikah, sorry10-Mar-08 22:44
257Gabrielecall works ok there? so the fixes for call for linux broke the other posix?10-Mar-08 22:43
256WillArpthe difference was 300% increase in speed...10-Mar-08 22:43
255WillArpthere was this intel release of 2.7.5 http://www.rebol.net/builds/024/rebol2705024i10-Mar-08 22:43
254Henrik2.7.6 is the first intel release10-Mar-08 22:42
253Gabrielenot that it should make a huge difference in theory... but i guess it does in practice.10-Mar-08 22:42
252Gabriele2.7.5 is not intel though, or did i miss a release?10-Mar-08 22:42
251CarlOk.10-Mar-08 22:42
250WillArpworked in 2.7.510-Mar-08 22:41
249WillArpyes, call without /wait does nothing in 2.7.610-Mar-08 22:40
248CarlOSX and Linux share the Posix code for CALL.10-Mar-08 22:40
247CarlIs this CALL bug new on 2.7.6?10-Mar-08 22:39
246WillArpalso I have looping call scripts that crashes rebol or return wrong results randomly, hopefully this get fixed as well, it'a a major no show for batch scripting, etc10-Mar-08 22:38
245Gabrieleconsidering that the result value is wrong too, we could say that CALL is broken on OSX. otoh, since view does not even start, this should probably not be a surprise :)10-Mar-08 22:37
244WillArpah ok10-Mar-08 22:37
243WillArpis /wait always needed?10-Mar-08 22:37
242Gabrieleso there is a problem with CALL without /wait10-Mar-08 22:36
241WillArpok so this works as well: call/wait "open /System/Library/CoreServices/Finder.app"10-Mar-08 22:36
240Gabrieleyour above call works with /wait10-Mar-08 22:36
239WillArpcall/wait "ls" works10-Mar-08 22:35
238Gabrielehmm, maybe it's not really working without /wait?10-Mar-08 22:35
237Gabrieletry call/wait "ls"10-Mar-08 22:34
236Gabrielethe output is not collected. but i assume the command is being run.10-Mar-08 22:34
235WillArpworks with 2.7.510-Mar-08 22:34
234WillArpthis doesn't work: call "open /System/Library/CoreServices/Finder.app"10-Mar-08 22:34

Return to Index Page