# | User | Message | Date |
733 | Carl | It 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 |
732 | Carl | New OSX SDK uploaded here in test folder. | 31-Jul-08 17:16 |
731 | Henrik | I'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 |
730 | Carl | http://www.rebol.com/article/0368.html - about OSX SDK | 2-Jul-08 19:26 |
729 | Robert | Still no new OSX SDK... | 22-Jun-08 15:57 |
728 | Robert | Carl, can we get a new OSX SDK release that includes the color fix? | 7-Jun-08 9:55 |
727 | Carl | I think we will release it this way for now. | 5-May-08 15:04 |
726 | Carl | Yes, it will be slower, depending on the app. (Because we are blitting entire window.) | 5-May-08 15:03 |
725 | Henrik | do 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 |
724 | Henrik | looks 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 |
723 | Carl | in releases/tests folder | 5-May-08 5:28 |
722 | Carl | Uploaded rebview for osx. Try it out. | 5-May-08 5:28 |
721 | Carl | Seems to work ok, even typing with full screen refresh. | 4-May-08 23:53 |
720 | Carl | Typing this message from OSX using a native Intel version of AltME. | 4-May-08 23:53 |
719 | Carl | BTW, in the apps I've tried, it seems fast enough so far. | 4-May-08 23:34 |
718 | Carl | I 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 |
717 | Gabriele | i'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 |
716 | Henrik | I agree. It doesn't bother me too much. As long as View programs will at least _run_. :-) | 24-Apr-08 17:30 |
715 | Carl | Later, when we know more (probably from R3 project) we can fix it in a better way. | 24-Apr-08 17:02 |
714 | Carl | I 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 |
713 | Henrik | to me colors look more correct than before, except red is blue, but graphics are distorted though. | 23-Apr-08 14:49 |
712 | Gabriele | i should be able to look at it monday. | 19-Apr-08 7:36 |
711 | Gabriele | Quartz 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 |
710 | Carl | Looking closer at it, maybe not. | 19-Apr-08 6:38 |
709 | Carl | I should note that REBOL uses this function for copying bits between internal buffers too, not just to the window. | 19-Apr-08 3:53 |
708 | Carl | Resize the window a bit to see it refresh -- close to how it should look. | 19-Apr-08 3:52 |
707 | Carl | Run it, and click in the window anywhere to see odd things happen. | 19-Apr-08 3:47 |
706 | Carl | Uploaded rv2-osx for you to try, and to watch the debug output. | 19-Apr-08 3:46 |
705 | Carl | Also, many of the sizes are wrong. | 19-Apr-08 3:37 |
704 | Carl | But, there is a bigger problem.... the position on many things is wrong. | 19-Apr-08 3:37 |
703 | Carl | Using ...Order32Big gets us the closest. | 19-Apr-08 3:12 |
702 | Carl | The bad news is that the colors are still not correct. | 19-Apr-08 3:11 |
701 | Carl | It's been quite interesting. The good news it compiles and links ok! | 19-Apr-08 3:11 |
700 | Carl | Gabriele, I wanted to get back to you about the Quartz blitter... | 19-Apr-08 3:10 |
699 | Gabriele | i'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 |
698 | Carl | I 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 |
697 | Carl | Ok, I'll take a look. Thanks. | 31-Mar-08 17:19 |
696 | WillArp | Grazie Gabriele 8) | 27-Mar-08 19:19 |
695 | Gabriele | I'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 |
694 | Gabriele | Note: I have not tested this in any way, so please review it! | 27-Mar-08 14:14 |
693 | Gabriele | I have uploaded osx-blit-quartz.c in the Other directory. | 27-Mar-08 14:13 |
692 | Gabriele | Carl, 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 |
691 | Gabriele | Robert, 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 |
690 | Robert | Can'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 |
689 | Carl | It's very standard code. | 20-Mar-08 19:20 |
688 | Carl | Sure. | 20-Mar-08 19:19 |
687 | Gabriele | Is 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 |
686 | Carl | (every time I compile ;) | 20-Mar-08 17:12 |
685 | Carl | And, please don't tell me all those functions are deprecated -- I know that all too well ! | 20-Mar-08 17:12 |
684 | Carl | Posted the code in Other folder. | 20-Mar-08 17:11 |
683 | Carl | It maybe difficult to change byte order, unless it is in the final render stage somewhere. | 20-Mar-08 17:09 |
682 | Carl | Strange 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 |
681 | Cyphre | yes, 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 |
680 | Pekr | would it slow down View too much, if you would convert before the blit on such affected OS? | 19-Mar-08 10:05 |
679 | Gabriele | if not, please post the code snippet somewhere, and we'll be asking around. | 19-Mar-08 8:52 |
678 | Gabriele | would it be possible to keep the image data as ARGB instead of BGRA internally? | 19-Mar-08 8:52 |
677 | WillArp | Where will we look for an osx guru to port R3 to osx and start rebol-cocoa bridging project? | 19-Mar-08 3:29 |
676 | WillArp | 8) | 19-Mar-08 3:26 |
675 | Carl | uploading altme to others folder | 19-Mar-08 3:25 |
674 | Carl | fixed | 19-Mar-08 3:25 |
673 | Carl | hmmm ppc is gzip intel is gz ... same but browser does not recognize first one | 19-Mar-08 3:23 |
672 | Carl | will post in just a bit | 19-Mar-08 3:19 |
671 | Carl | page updated | 19-Mar-08 3:19 |
670 | WillArp | still hoow do I run Altme intel ? | 19-Mar-08 3:16 |
669 | WillArp | thanks | 19-Mar-08 3:15 |
668 | Carl | (www.rebol.net) | 19-Mar-08 3:14 |
667 | Carl | OSX uploaded to builds/sdk area. | 19-Mar-08 3:14 |
666 | Carl | It 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 |
665 | Carl | I 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 |
664 | Carl | I will also post a license.key in the distribution, so all the tools are enabled for testing purposes. | 19-Mar-08 2:45 |
663 | Carl | So, 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 |
662 | Carl | I 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 |
661 | Carl | Status: 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 |
660 | TomC | I am nigh-infinatly patient and would be content to build it myself | 14-Mar-08 21:31 |
659 | Graham | Doesn't have to be a simultaneous release. | 14-Mar-08 21:00 |
658 | Henrik | oh yeah PPC with colors fixed would be fine. | 14-Mar-08 20:30 |
657 | Gabriele | nowhere. :) use wine :P | 14-Mar-08 20:21 |
656 | WillArp | where do I get the Intel Altme? | 14-Mar-08 20:20 |
655 | BrianH | Be 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 |
654 | Gabriele | Maybe we can release OSX PPC too? better than nothing :) | 14-Mar-08 20:14 |
653 | Graham | And Oldes' rebcode special edition :) | 14-Mar-08 19:52 |
652 | Graham | Oh ... and tomc's Solaris core | 14-Mar-08 19:51 |
651 | Graham | Great. | 14-Mar-08 19:50 |
650 | Carl | Win32 and Linux | 14-Mar-08 19:50 |
649 | Graham | A release today would be good then. | 14-Mar-08 19:49 |
648 | Carl | Yes. | 14-Mar-08 19:47 |
647 | Graham | If it's an OSX only problem .. can we release others and fix OSX later? | 14-Mar-08 19:46 |
646 | Carl | I am not happy about holding up R2 on OSX Intel due to this simple color problem. | 14-Mar-08 19:43 |
645 | Carl | Otherwise any RGB swap would still make white. ;) | 14-Mar-08 19:43 |
644 | Carl | So, that's why white is yellow. | 14-Mar-08 19:42 |
643 | Carl | yes... I think its due to BGRA <--> ARGB will swap blue for alpha and v.v. | 14-Mar-08 19:42 |
642 | Gabriele | (maybe it's the alpha channel though.) | 14-Mar-08 18:25 |
641 | Gabriele | there'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 |
640 | Gabriele | except for the known bugs, rv-osx seems to run fine here. | 14-Mar-08 18:22 |
639 | Henrik | I would love to do it for quickly capturing ideas. | 14-Mar-08 18:03 |
638 | BrianH | I never had much use for speech-to-text - all programming languages in modern use are unpronouncable to varying degrees. | 14-Mar-08 18:00 |
637 | Henrik | or maybe just speech-to-text that works | 14-Mar-08 17:50 |
636 | Henrik | text completion would be more fun | 14-Mar-08 17:48 |
635 | BrianH | Spelling correction is overrated in a technical context. | 14-Mar-08 17:31 |
634 | BrianH | Nice. | 14-Mar-08 17:30 |
633 | Carl | still no spelling correcter :) | 14-Mar-08 17:30 |
632 | Carl | paste | 14-Mar-08 17:30 |
631 | Carl | (cut and past with lines ;) | 14-Mar-08 17:30 |
630 | Carl | REBOL/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 |
629 | Carl | ugly colors, but its at least 2x speed, and watch this... | 14-Mar-08 17:29 |
628 | BrianH | What color is the window? :) | 14-Mar-08 17:29 |
627 | Carl | Typing this message from AltME OSX Intel. | 14-Mar-08 17:28 |
626 | Carl | The cocoa stuff is so asbstracted, you have no idea what's really going on. | 14-Mar-08 17:23 |
625 | Carl | yes 9 was | 14-Mar-08 17:22 |
624 | Carl | :) | 14-Mar-08 17:22 |
623 | BrianH | Think of it as accessibility - you need to support mentally challenged OSes too :) | 14-Mar-08 17:22 |
622 | Henrik | I'm betting OS9 was almost easier? | 14-Mar-08 17:22 |
621 | Carl | (because we require multiplexing gui, file streams, and network streams) | 14-Mar-08 17:21 |
620 | Carl | the problem so far has been that cocoa does not look "smart enough" to own the event stream ;) | 14-Mar-08 17:21 |
619 | Henrik | there 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 |
618 | Carl | it will be quite the project to figure out how R3 runs in cocoa, since both want to "own" the event stream | 14-Mar-08 17:20 |
617 | Henrik | if you are not a cocoa citizen in OSX land, you won't reap the benefits. | 14-Mar-08 17:19 |
616 | BrianH | Yes, particularly since that will also include apps for the iPhone and iPod Touch. | 14-Mar-08 17:19 |
615 | Carl | the subject of how to design a proper osx app in3.0 is going to be very interesting | 14-Mar-08 17:17 |
614 | Carl | yes, we'll have to move on to 3.0.... nearly everything here is obsolete for osx | 14-Mar-08 17:16 |
613 | Carl | was | 14-Mar-08 17:16 |
612 | Carl | the f-key problem as new -- go back to prior test beta, and it will likely crash | 14-Mar-08 17:15 |
611 | Henrik | there 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 |
610 | Henrik | F-keys are not crashing anything, but they've never caused trouble for me. | 14-Mar-08 17:06 |
609 | Henrik | and clipboard works | 14-Mar-08 17:05 |
608 | Henrik | caret placement is much better with the font here, which is either Lucida Grande or Geneva. | 14-Mar-08 17:05 |
607 | Carl | uploaded - please test | 14-Mar-08 17:00 |
606 | Carl | uploading OSX for all to try -- but note colors are still wrong. | 14-Mar-08 16:52 |
605 | Carl | general 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 |
604 | Carl | works fine in arial, but not lucida | 14-Mar-08 16:48 |
603 | Henrik | perhaps it's part of the general font problem | 14-Mar-08 16:45 |
602 | Carl | looks like it is more font-dependent not size dependent | 14-Mar-08 16:44 |
601 | Carl | probably, but not sure... let me see... | 14-Mar-08 16:40 |
600 | Henrik | about the caret fix, so it will only be accurate for a few font sizes? | 14-Mar-08 16:37 |
599 | Henrik | WinXP has that tendency to change keyboard language in the middle of everything. | 14-Mar-08 16:37 |
598 | Henrik | now fix my stupid keyboard... :-( | 14-Mar-08 16:36 |
597 | Henrik | very cool >/( | 14-Mar-08 16:35 |
596 | Carl | Ok, clipboard fixed. | 14-Mar-08 16:35 |
595 | Carl | I think the caret position needs to be based on font size, which it is not (currently). | 14-Mar-08 16:34 |
594 | Carl | I don't have a great fix for it yet, just a rough patch. | 14-Mar-08 16:33 |
593 | Carl | it was off by 2 pixels ;) | 14-Mar-08 16:33 |
592 | Henrik | curious about 1: what was the problem? | 14-Mar-08 16:23 |
591 | Carl | 1. fixed caret offset (2 pixels) 2. fixed crash from function keys (as was case on linux too) 3. working on clipboard fix right now | 14-Mar-08 16:22 |
590 | Carl | A few updates regarding pending items... | 14-Mar-08 16:20 |
589 | Carl | Wow, so in this case Mr. Bill has outdone Mr. Steve. | 14-Mar-08 16:20 |
588 | Cyphre | references:
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 |
587 | Cyphre | BTW 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 |
586 | Cyphre | I 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 |
585 | Gabriele | let me know if there's anything you want me to try. | 14-Mar-08 7:58 |
584 | Gabriele | this means though, that i have no way to directly check the internal format of image! | 14-Mar-08 7:57 |
583 | Gabriele | (as it should be) | 14-Mar-08 7:56 |
582 | Gabriele | Carl, 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 |
581 | Gabriele | it's the why we need to figure out :) | 14-Mar-08 7:24 |
580 | Gabriele | that's correct. | 14-Mar-08 7:24 |
579 | Carl | My guess is that it turns up green on OSX. | 14-Mar-08 0:10 |
578 | Carl | BTW, 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 |
577 | Carl | Could be. I hope Cyphre knows. | 14-Mar-08 0:05 |
576 | Gabriele | (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 |
575 | Gabriele | that is, they still want the image in the ppc order | 14-Mar-08 0:04 |
574 | Gabriele | actually... if my guess is right, the fact is that OSX kept the API the same between ppc and intel | 14-Mar-08 0:03 |
573 | Carl | ok | 14-Mar-08 0:03 |
572 | Gabriele | i'll try that on PPC tomorrow to see what's the result. | 14-Mar-08 0:03 |
571 | Carl | But, that's not relevant to OSX display problem. | 14-Mar-08 0:02 |
570 | Carl | It sure seems like it. | 14-Mar-08 0:02 |
569 | Carl | BGRA | 14-Mar-08 0:02 |
568 | Gabriele | so, does this mean that the molded image is platform dependent? | 14-Mar-08 0:01 |
567 | Gabriele | windows gives the same result, so this seems to be correct | 14-Mar-08 0:01 |
566 | Gabriele | >> i == make image! [2x1 #{ 010203050607 } #{ 0408 }] >> to binary! i == #{0302010407060508} | 13-Mar-08 23:52 |
565 | Carl | >> make image! [1x1 #{010203}] == make image! [1x1 #{ 010203 }] | 13-Mar-08 23:52 |
564 | Carl | Hmmm.... Why does that seem wrong to me? | 13-Mar-08 23:51 |
563 | Gabriele | >> i == make image! [5x5 #{ FFFEFD000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000... >> to binary! i == #{ FDFEFF0000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000000... | 13-Mar-08 23:48 |
562 | Gabriele | this is what i'm seeing on rvosx5: | 13-Mar-08 23:48 |
561 | Carl | For little, it's just a straight copy from the image bitmap. | 13-Mar-08 23:47 |
560 | Carl | When running on big endian, we reverse the bits. | 13-Mar-08 23:47 |
559 | Carl | yes | 13-Mar-08 23:46 |
558 | Gabriele | does to binary! reorder the bytes depending on platform? | 13-Mar-08 23:45 |
557 | Carl | It's a good question. | 13-Mar-08 23:43 |
556 | Gabriele | are they little endian on ppc too? | 13-Mar-08 23:41 |
555 | Carl | No, actually I think we keep them in little-endian order. Cyphre can confirm. | 13-Mar-08 23:40 |
554 | Carl | Wow, wouldn't that be fun... having to reorder the bits for each blit. | 13-Mar-08 23:40 |
553 | Gabriele | (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 |
552 | Gabriele | would it be possible to keep them in memory in the "correct" order instead of having to reorder them? | 13-Mar-08 19:38 |
551 | Gabriele | from what i see it is very likely that you have to rearrange the bytes before the call. | 13-Mar-08 19:37 |
550 | Gabriele | it seems that RGBDirect is the only valid value there | 13-Mar-08 19:23 |
549 | Gabriele | (found it) | 13-Mar-08 19:22 |
548 | Gabriele | what type is pixmap above? | 13-Mar-08 19:19 |
547 | Gabriele | agreed, but some apps are not portable anyway. in any case... this is something for the future, and for the community | 13-Mar-08 19:12 |
546 | Carl | I will not use REBOL client apps that cannot run on all the main systems. | 13-Mar-08 18:53 |
545 | Carl | But, if developers do that, then they are not mainstream REBOL apps. | 13-Mar-08 18:53 |
544 | Gabriele | dinner, bbs | 13-Mar-08 18:53 |
543 | Carl | Anyway, for now, we need to get colors fixed. | 13-Mar-08 18:53 |
542 | Gabriele | but... 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 |
541 | Carl | Yes, and I am soooo ready. | 13-Mar-08 18:52 |
540 | Gabriele | you know... that's why we need our own os ;) | 13-Mar-08 18:51 |
539 | Carl | The OS worlds of Win32, OSX, and *nix are moving further apart... they are diverging at a high level. | 13-Mar-08 18:51 |
538 | Carl | Font interfaces are getting higher and higher level. | 13-Mar-08 18:50 |
537 | Carl | But, I worry a great deal about fonts. | 13-Mar-08 18:49 |
536 | Carl | I think so to. These days, I think the CPU to g-card blits are fast enough. | 13-Mar-08 18:49 |
535 | Gabriele | i think AGG should be the default, with the option (community developed etc.) of a Quartz backend. | 13-Mar-08 18:48 |
534 | Carl | So, 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 |
533 | Gabriele | yeah, they have their own version of effect-lab.r too :) | 13-Mar-08 18:47 |
532 | Carl | For 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 |
531 | Gabriele | R3, no? | 13-Mar-08 18:47 |
530 | Carl | We 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 |
529 | Carl | In 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 |
528 | Carl | Yes, of course. 95% of the API we use deprecated. :) | 13-Mar-08 18:45 |
527 | Gabriele | nothing, of course it has been deprecated :) | 13-Mar-08 18:44 |
526 | Carl | And your point is... what? | 13-Mar-08 18:44 |
525 | Gabriele | :) | 13-Mar-08 18:44 |
524 | Gabriele | /* * 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 |
523 | Carl | (It's quite funny that it works fine on PPC - but not Intel.) | 13-Mar-08 18:42 |
522 | Carl | REBOL functions are all spelled in reb new-code style: Copy_Bits(). | 13-Mar-08 18:41 |
521 | Henrik | it's a quickdraw funtion | 13-Mar-08 18:41 |
520 | Carl | Yes. | 13-Mar-08 18:40 |
519 | Gabriele | Is 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 |
518 | Henrik | if 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 |
517 | Carl | But, I am no expert on OSX. | 13-Mar-08 18:39 |
516 | Carl | I 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 |
515 | Carl | I 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 |
514 | Carl | Yes, it's QD. Looks like we are passing BGRA bitmaps to an ARGB system. | 13-Mar-08 18:36 |
513 | Gabriele | agreed. | 13-Mar-08 18:35 |
512 | Brent | G: 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 |
511 | Cyphre | ah, then Carl please specify what graphic API are you using in R2. QuickDraw? | 12-Mar-08 21:42 |
510 | Henrik | Cyphre, all colors are wrong in the OSX build, so it's probably not restricted to DRAW. | 12-Mar-08 21:38 |
509 | Cyphre | Carl, 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 |
508 | Gabriele | it 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 |
507 | Brent | correction: "I don't think #46 should go"... | 12-Mar-08 21:17 |
506 | Brent | I 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.02 | 12-Mar-08 21:16 |
505 | Gabriele | btw 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 |
504 | Henrik | depends on how change log is generated... | 12-Mar-08 19:46 |
503 | Carl | Good question, since it is not released yet. | 12-Mar-08 19:31 |
502 | Gabriele | #46 | 12-Mar-08 19:17 |
501 | Gabriele | do you want me to add it to RAMBO too? | 12-Mar-08 19:14 |
500 | Gabriele | ok | 12-Mar-08 19:12 |
499 | Carl | Gabriele, 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 |
498 | Gabriele | furthermore... 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 |
497 | Gabriele | 2.7.5 does not have the problem | 12-Mar-08 18:06 |
496 | Gabriele | seems a new problem, let me check 2.7.5... | 12-Mar-08 18:03 |
495 | Carl | So, is this a new problem or old? | 12-Mar-08 17:15 |
494 | Gabriele | "is getting a queuing" = "is queuing" | 12-Mar-08 16:36 |
493 | Gabriele | what 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 |
492 | Gabriele | may have broken the sys port though... investigating... | 12-Mar-08 16:33 |
491 | Gabriele | seems to work ok | 12-Mar-08 16:31 |
490 | Gabriele | checking linux now... | 12-Mar-08 16:30 |
489 | Carl | I will check on that system port... and you should too. | 12-Mar-08 15:27 |
488 | Carl | Did you test linux version too? | 12-Mar-08 15:24 |
487 | Gabriele | confirmed CALL now works here. | 12-Mar-08 10:06 |
486 | Gabriele | confirmed rvosx5 works here | 12-Mar-08 10:04 |
485 | Gabriele | Could 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 |
484 | WillArp | btw my eavy batch script that was failing on 2.7.5 seams to run properly with latest, cheyenne no problem as well.. thank you! bye | 12-Mar-08 4:47 |
483 | Carl | time to go, enjoy! | 12-Mar-08 4:46 |
482 | WillArp | houch! thats eavy ;) | 12-Mar-08 4:46 |
481 | Carl | And, in R3, I'm going to let some other very lucky person manage that code as open source! | 12-Mar-08 4:46 |
480 | Carl | That is the reason why CALL is non-trivial to implement (1200 lines of C code). | 12-Mar-08 4:45 |
479 | Carl | so, 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 |
478 | Carl | right. | 12-Mar-08 4:44 |
477 | WillArp | so call output returns as soon as ther is output, wiat will still wait for completation before returning? | 12-Mar-08 4:44 |
476 | Carl | no | 12-Mar-08 4:42 |
475 | WillArp | call/output and call/output/wait are exactly the same right? | 12-Mar-08 4:42 |
474 | Carl | Need to upload that. | 12-Mar-08 4:34 |
473 | Carl | BTW, this will fix linux too. | 12-Mar-08 4:34 |
472 | Carl | Yep, 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 |
471 | WillArp | thanks! | 12-Mar-08 4:33 |
470 | WillArp | 8-) 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 |
469 | Carl | So, keep a sharp eye out for zombies! | 12-Mar-08 4:33 |
468 | Carl | uploaded - rebcore-osx2 | 12-Mar-08 4:32 |
467 | Carl | 22% battery | 12-Mar-08 4:30 |
466 | WillArp | core is good | 12-Mar-08 4:29 |
465 | Carl | works. do you want core or view? | 12-Mar-08 4:29 |
464 | WillArp | on 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 well | 12-Mar-08 4:14 |
463 | Carl | Of which there should be only one, and will terminate when the main terminates, so no sigchild should be required. | 12-Mar-08 4:12 |
462 | Carl | The only other fork I can see is the async DNS subprocess. | 12-Mar-08 4:11 |
461 | Carl | Not 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 |
460 | Carl | We were competing with our own sigchild handler. | 12-Mar-08 4:06 |
459 | WillArp | great, test version? 8) | 12-Mar-08 4:06 |
458 | Carl | That (above) was the race. | 12-Mar-08 4:05 |
457 | Carl | yes | 12-Mar-08 4:05 |
456 | WillArp | does it return right values always? | 12-Mar-08 4:04 |
455 | Carl | That's it! Reverted my changes from Sunday, and temporarily removed the sigchild handler, and CALL works great! | 12-Mar-08 4:03 |
454 | WillArp | waiting to test | 12-Mar-08 3:53 |
453 | Carl | Going over to my linux box to try out the theory.... back in a while. | 12-Mar-08 3:52 |
452 | Carl | I must imagine that Holger added this to avoid accumulating process zombies. | 12-Mar-08 3:51 |
451 | Carl | So, indeed we very well may be dropping the signal in the case of CALL. | 12-Mar-08 3:49 |
450 | Carl | Hey, 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 |
449 | Carl | Checking... | 12-Mar-08 3:47 |
448 | Carl | Maybe we already have one setup... for some other child procs... and it is interferring!? | 12-Mar-08 3:47 |
447 | Carl | Interesting... in considering that fact.... | 12-Mar-08 3:46 |
446 | Carl | I 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 |
445 | Carl | allow. | 12-Mar-08 3:37 |
444 | Carl | A 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 |
443 | Carl | Correction, not orphan above, a waitable zombie. Got to use correct unix terms. | 12-Mar-08 3:35 |
442 | Carl | Note, here unix is synonymous with linux and bsd. | 12-Mar-08 3:33 |
441 | Carl | Since 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 |
440 | Carl | If I comment out the select() it works fine. However, that means the pipe will not get handled properly. | 12-Mar-08 3:31 |
439 | Carl | The 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 |
438 | Carl | Yes... but not sure the solution. | 12-Mar-08 3:28 |
437 | WillArp | any news about call ? | 12-Mar-08 3:21 |
436 | Carl | Cyphre: in OSX, do you know how to change the RGB byte order for the screen blit? | 12-Mar-08 2:11 |
435 | WillArp | local path problem, sorry | 12-Mar-08 1:52 |
434 | Henrik | no problem | 12-Mar-08 1:46 |
433 | Carl | ok, gn, thanks for testing. | 12-Mar-08 1:46 |
432 | Carl | The peacock thinks he is a turkey. He has been part of the group for more than a year. | 12-Mar-08 1:45 |
431 | Henrik | gotta go to bed. night. :-) | 12-Mar-08 1:45 |
430 | WillArp | demos not working here, checking local configs.. | 12-Mar-08 1:43 |
429 | Henrik | :-) | 12-Mar-08 1:42 |
428 | WillArp | haha 8) | 12-Mar-08 1:42 |
427 | Carl | (got interrupted -- by 40 turkeys outside my window -- and one peacock too) | 12-Mar-08 1:42 |
426 | Carl | demos ok here too | 12-Mar-08 1:41 |
425 | WillArp | mm.. checking again | 12-Mar-08 1:40 |
424 | Henrik | all demos work fine here | 12-Mar-08 1:39 |
423 | WillArp | no no windows in the back, try any demos | 12-Mar-08 1:39 |
422 | WillArp | pressing esc I get: REBOL console error (1) before it quits | 12-Mar-08 1:39 |
421 | Henrik | the window might be thrown to the back. an old View OSX bug | 12-Mar-08 1:38 |
420 | WillArp | in desktop, any script I click, I see in the dock a process is started, but no window show up for those | 12-Mar-08 1:37 |
419 | Henrik | it could be geneva 12, but I won't rule out Lucida | 12-Mar-08 1:36 |
418 | Henrik | yes, I get those all the time too. I suppose it's every time a redraw is made. | 12-Mar-08 1:35 |
417 | WillArp | getting a lot of: Font Name: arial Checking cache... GetFontFamily Find_Font | 12-Mar-08 1:35 |
416 | WillArp | latest 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 sure | 12-Mar-08 1:31 |
415 | Carl | Yes. 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 |
414 | Henrik | yes, it's odd. but I can finally test View scripts :-) | 12-Mar-08 1:28 |
413 | Carl | We will need to investigate the font problem. | 12-Mar-08 1:27 |
412 | Carl | Well, at least now view comes up. I can fix color. | 12-Mar-08 1:27 |
411 | Henrik | yes, looks like what I'd expect under Tiger | 12-Mar-08 1:26 |
410 | Carl | ok, uploaded | 12-Mar-08 1:25 |
409 | Henrik | hopefully as png and not pdf | 12-Mar-08 1:24 |
408 | Henrik | it should be the desktop | 12-Mar-08 1:24 |
407 | Carl | I need it as file. | 12-Mar-08 1:24 |
406 | Carl | where did it save? | 12-Mar-08 1:24 |
405 | Henrik | in OSX? cmd-shift-4, press space so the cursor becomes a camera and hover over the window you want and click | 12-Mar-08 1:23 |
404 | Carl | (how to best grab window and save as file?) | 12-Mar-08 1:22 |
403 | Carl | Hm, yes that is different than here. | 12-Mar-08 1:22 |
402 | Henrik | /Users/Henrik/font_lab.png | 12-Mar-08 1:21 |
401 | Carl | goto viewtop, select tools, font-lab | 12-Mar-08 1:20 |
400 | Henrik | and courier new in the editor | 12-Mar-08 1:16 |
399 | Henrik | it does try to load arial though | 12-Mar-08 1:16 |
398 | Henrik | no, it appears to be lucida grande. all writing has the same size and does not have bold style. | 12-Mar-08 1:15 |
397 | Carl | So, that is not arial? | 12-Mar-08 1:15 |
396 | Henrik | well, the size is the same too | 12-Mar-08 1:14 |
395 | Carl | checking... | 12-Mar-08 1:13 |
394 | Carl | I wonder if font name is case sensitive? | 12-Mar-08 1:13 |
393 | Henrik | I've uploaded a picture of it in Users/Henrik/font_issue.png | 12-Mar-08 1:13 |
392 | Henrik | now the font used seems to be Lucida Grande, as can be seen in AltME. | 12-Mar-08 1:11 |
391 | Carl | That is good. Funky colors are good. | 12-Mar-08 1:10 |
390 | Henrik | and it can't be because I'm tired and it's 2 AM :-) | 12-Mar-08 1:10 |
389 | Henrik | I see funky colors. | 12-Mar-08 1:09 |
388 | Carl | Great! | 12-Mar-08 1:09 |
387 | Henrik | it boots! | 12-Mar-08 1:09 |
386 | Henrik | downloading | 12-Mar-08 1:07 |
385 | Carl | uploaded rvosx5 | 12-Mar-08 1:05 |
384 | Carl | (changing boot sequence) | 12-Mar-08 0:43 |
383 | Carl | well, let me try another method... | 12-Mar-08 0:15 |
382 | Henrik | maybe I don't if you upload it | 12-Mar-08 0:14 |
381 | Henrik | :-) | 12-Mar-08 0:14 |
380 | Carl | now I get a bus error. | 12-Mar-08 0:14 |
379 | Carl | ok, building another fix. | 12-Mar-08 0:12 |
378 | Carl | This is very interesting..... | 12-Mar-08 0:06 |
377 | Carl | Because like Amiga, components get sorted by priority. | 12-Mar-08 0:06 |
376 | Carl | Load 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 |
375 | Henrik | ah :-) | 12-Mar-08 0:04 |
374 | Carl | I assumed you were in the init part... because those component lines look the same in both sections. | 12-Mar-08 0:04 |
373 | Carl | you're not even into the init.... you are still in load | 12-Mar-08 0:03 |
372 | Carl | ah, wait... | 12-Mar-08 0:02 |
371 | Carl | how is that possible? | 12-Mar-08 0:01 |
370 | Henrik | /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 error | 12-Mar-08 0:01 |
369 | BrianH | Do either of you have license.key? | 12-Mar-08 0:00 |
368 | Henrik | yep, there they are | 12-Mar-08 0:00 |
367 | Carl | yes | 12-Mar-08 0:00 |
366 | Henrik | ah | 12-Mar-08 0:00 |
365 | Carl | use -w I think to avoid it | 12-Mar-08 0:00 |
364 | Henrik | MD5 (/Users/henrikmk/Desktop/rvosx3) = bc661350e16ecb53abe3a85104efda1f | 12-Mar-08 0:00 |
363 | Carl | it happens in middle. | 12-Mar-08 0:00 |
362 | Henrik | same here | 12-Mar-08 0:00 |
361 | Carl | MD5 (VIEW-PRO/rvosx4) = f60ed6b8bc269cfb17320b7603745aa2 | 11-Mar-08 23:59 |
360 | Henrik | the 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 |
359 | Henrik | I don't get those. | 11-Mar-08 23:58 |
358 | Carl | Component "Licensing" 1.11.0 [5632] Init View (info) Init Font: system 12 opening, sizing, info building font table - outline metrics | 11-Mar-08 23:57 |
357 | Carl | Verify that -- not rvosx4? | 11-Mar-08 23:56 |
356 | Henrik | 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 error | 11-Mar-08 23:54 |
355 | Carl | uploading rvosx4... | 11-Mar-08 23:53 |
354 | Carl | Ok, found bug I think. | 11-Mar-08 23:50 |
353 | Carl | There is an init sequence error here. Checking... | 11-Mar-08 23:47 |
352 | Carl | Ah... ha... | 11-Mar-08 23:46 |
351 | Carl | ok | 11-Mar-08 23:46 |
350 | Henrik | I don't know if you can. I use AltME in VMWare where it works. | 11-Mar-08 23:46 |
349 | Carl | how do I cut and paste to altme with correct lf? | 11-Mar-08 23:45 |
348 | Henrik | this is all I see | 11-Mar-08 23:44 |
347 | Henrik | 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 error | 11-Mar-08 23:44 |
346 | Carl | Do you see Init View (info) ? | 11-Mar-08 23:42 |
345 | Carl | yes, it is. | 11-Mar-08 23:42 |
344 | Henrik | no, 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 |
343 | Carl | E.g. Init Font: system 12 | 11-Mar-08 23:40 |
342 | Carl | is there anything before that? do you see an init for System font? | 11-Mar-08 23:39 |
341 | Carl | googling it... | 11-Mar-08 23:23 |
340 | Henrik | Find_Font Font Name: Arial Checking Cache... GetFontFamily Bus error | 11-Mar-08 23:19 |
339 | Carl | what font name? | 11-Mar-08 23:19 |
338 | Carl | checking... | 11-Mar-08 23:18 |
337 | Henrik | GetFontFamily BusError | 11-Mar-08 23:18 |
336 | Henrik | downloading | 11-Mar-08 23:16 |
335 | Carl | added more prints related to font setup... run rvosx3 | 11-Mar-08 23:16 |
334 | Carl | checking... | 11-Mar-08 23:08 |
333 | Carl | back | 11-Mar-08 23:08 |
332 | Henrik | Got it working now. Same error as Gabriele. | 11-Mar-08 22:52 |
331 | Henrik | the OSX version won't let me use more than one world per machine. quite annoying. | 11-Mar-08 22:47 |
330 | Henrik | 1.2.15 under VMWare | 11-Mar-08 22:47 |
329 | Gabriele | which version of altme are you running btw? i'm using the windows version under wine (CrossOver) | 11-Mar-08 22:46 |
328 | Henrik | now it crashed with a different crash :-) | 11-Mar-08 22:44 |
327 | Henrik | I'll see if I can get AltME going first. | 11-Mar-08 22:44 |
326 | Gabriele | do you want me to send you the file by other means? (mail? http?) | 11-Mar-08 22:44 |
325 | Henrik | can'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 |
324 | Gabriele | the above is just what i get... | 11-Mar-08 22:42 |
323 | Henrik | shouldn't there be more information around the View and VID boot information? | 11-Mar-08 22:41 |
322 | Gabriele | Date/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 |
321 | Gabriele | crash report seems to be like previous versions. | 11-Mar-08 22:40 |
320 | Carl | huh? | 11-Mar-08 22:39 |
319 | Gabriele | [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 error | 11-Mar-08 22:39 |
318 | Carl | brb - need food | 11-Mar-08 22:38 |
317 | Carl | rvosx2 | 11-Mar-08 22:37 |
316 | Carl | ah good, will save some time. uploading from osx directly | 11-Mar-08 22:37 |
315 | Carl | let me see if this works... | 11-Mar-08 22:35 |
314 | Carl | logging in from osx | 11-Mar-08 22:35 |
313 | Carl | ok ready to upload... | 11-Mar-08 22:34 |
312 | Henrik | Carl, turn down the screen brightness to minimum. :-) | 11-Mar-08 22:30 |
311 | Carl | yes, doing that | 11-Mar-08 22:30 |
310 | Gabriele | do you think you can get some more debug prints in, so we can narrow down where it is failing? | 11-Mar-08 22:29 |
309 | Carl | goal is to fix this bug before my laptop bat dies. I'm at 86% now. | 11-Mar-08 22:21 |
308 | Carl | Ok, so... let's look at some code... | 11-Mar-08 22:20 |
307 | Gabriele | i don't think REBOL is using CF from the child of a fork()... | 11-Mar-08 15:31 |
306 | Henrik | http://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 |
305 | Henrik | perhaps, if we are using some old method of loading fonts that does not work anymore | 11-Mar-08 9:57 |
304 | Gabriele | (same version here) | 11-Mar-08 7:20 |
303 | Gabriele | did we get to the point where there are incompatibilities between versions of fonts? :) | 11-Mar-08 7:18 |
302 | Henrik | Arial v. 5.01.2x here | 10-Mar-08 23:56 |
301 | Henrik | perhaps we should do version checks on all the fonts? | 10-Mar-08 23:29 |
300 | Carl | ok | 10-Mar-08 23:19 |
299 | Gabriele | going to get some sleep. will check back here tomorrow morning. | 10-Mar-08 23:18 |
298 | WillArp | copied the Arial famiily from 10.4.11 to 10.5.2, still crash | 10-Mar-08 23:17 |
297 | Carl | ok | 10-Mar-08 23:16 |
296 | Gabriele | the system shows: Arial, Arial Black, Arial Hebrew, Arial Narrow, Arial Rounded MT Bold, Arial Unicode MS | 10-Mar-08 23:13 |
295 | Gabriele | i think i do. (have seen it in font lists) checking... | 10-Mar-08 23:12 |
294 | Carl | Simple question: do you have arial font? | 10-Mar-08 23:12 |
293 | Gabriele | otoh, 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 |
292 | WillArp | I vote for 1, cheyenne wont start 8) | 10-Mar-08 23:12 |
291 | Carl | It's going to take a few hours. Probably tomorrow... your time, before something to try out. | 10-Mar-08 23:11 |
290 | Carl | Yes, ok. | 10-Mar-08 23:10 |
289 | Gabriele | 2) seems much more critical (view does not run) | 10-Mar-08 23:09 |
288 | Carl | which one to fix first? | 10-Mar-08 23:09 |
287 | Carl | There 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 |
286 | Gabriele | Carl, 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 |
285 | WillArp | leopard has easyer threading manipulation and script bridging, hopefully R3 will be leopard optimized, R2 for older platforms | 10-Mar-08 23:04 |
284 | Carl | So, 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 |
283 | Carl | Interesting stuff. But our perf is ok. Maybe later on 3.0 we can try some tricks. | 10-Mar-08 23:03 |
282 | Carl | But, then, it does not support Unicode directly. | 10-Mar-08 23:02 |
281 | Carl | And of course, the entire OSX API we use is deprecated. We're supposed to use Quartz these days. | 10-Mar-08 23:01 |
280 | WillArp | maybe here? http://developer.apple.com/carbon/tipsandtricks.html#ImprovePerformance | 10-Mar-08 23:01 |
279 | Carl | Let me know if you find anything about font crashes. ;) | 10-Mar-08 23:00 |
278 | Carl | Is it just the gdb? Yes, that is a standard method used on Unix systems. | 10-Mar-08 23:00 |
277 | Carl | Will, what part of the tips and tricks did you want to show me? | 10-Mar-08 23:00 |
276 | WillArp | 8) | 10-Mar-08 22:59 |
275 | Gabriele | and of course it's not crashing on Carl's machine. :) | 10-Mar-08 22:59 |
274 | WillArp | ok | 10-Mar-08 22:59 |
273 | Gabriele | Will, gdb is no help to us because there are no debugging symbols in the rebol exe. | 10-Mar-08 22:59 |
272 | WillArp | http://developer.apple.com/carbon/tipsandtricks.html#Gdb ? | 10-Mar-08 22:58 |
271 | Carl | I did not see it because it's part of the command tests. | 10-Mar-08 22:57 |
270 | Carl | Ah.... actually there is a test suite for CALL. | 10-Mar-08 22:57 |
269 | WillArp | maybe some tips here? http://developer.apple.com/carbon/tipsandtricks.html | 10-Mar-08 22:56 |
268 | Carl | I am checking to see if I have any such tests in the archive. | 10-Mar-08 22:56 |
267 | Carl | Yes. | 10-Mar-08 22:55 |
266 | Gabriele | Carl: 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 |
265 | WillArp | this 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 |
264 | WillArp | yes | 10-Mar-08 22:46 |
263 | Gabriele | confirmed that call works better on that release, but it still has the random return value bug. | 10-Mar-08 22:45 |
262 | Carl | Without that, we'll just continue to break stuff. | 10-Mar-08 22:45 |
261 | Carl | I think the only practical way to fix CALL is to write a test suite for it. | 10-Mar-08 22:45 |
260 | Carl | The 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 |
259 | WillArp | well, call "open something" work in 2.7.5 intel | 10-Mar-08 22:44 |
258 | Henrik | ah, sorry | 10-Mar-08 22:44 |
257 | Gabriele | call works ok there? so the fixes for call for linux broke the other posix? | 10-Mar-08 22:43 |
256 | WillArp | the difference was 300% increase in speed... | 10-Mar-08 22:43 |
255 | WillArp | there was this intel release of 2.7.5 http://www.rebol.net/builds/024/rebol2705024i | 10-Mar-08 22:43 |
254 | Henrik | 2.7.6 is the first intel release | 10-Mar-08 22:42 |
253 | Gabriele | not that it should make a huge difference in theory... but i guess it does in practice. | 10-Mar-08 22:42 |
252 | Gabriele | 2.7.5 is not intel though, or did i miss a release? | 10-Mar-08 22:42 |
251 | Carl | Ok. | 10-Mar-08 22:42 |
250 | WillArp | worked in 2.7.5 | 10-Mar-08 22:41 |
249 | WillArp | yes, call without /wait does nothing in 2.7.6 | 10-Mar-08 22:40 |
248 | Carl | OSX and Linux share the Posix code for CALL. | 10-Mar-08 22:40 |
247 | Carl | Is this CALL bug new on 2.7.6? | 10-Mar-08 22:39 |
246 | WillArp | also 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, etc | 10-Mar-08 22:38 |
245 | Gabriele | considering 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 |
244 | WillArp | ah ok | 10-Mar-08 22:37 |
243 | WillArp | is /wait always needed? | 10-Mar-08 22:37 |
242 | Gabriele | so there is a problem with CALL without /wait | 10-Mar-08 22:36 |
241 | WillArp | ok so this works as well: call/wait "open /System/Library/CoreServices/Finder.app" | 10-Mar-08 22:36 |
240 | Gabriele | your above call works with /wait | 10-Mar-08 22:36 |
239 | WillArp | call/wait "ls" works | 10-Mar-08 22:35 |
238 | Gabriele | hmm, maybe it's not really working without /wait? | 10-Mar-08 22:35 |
237 | Gabriele | try call/wait "ls" | 10-Mar-08 22:34 |
236 | Gabriele | the output is not collected. but i assume the command is being run. | 10-Mar-08 22:34 |
235 | WillArp | works with 2.7.5 | 10-Mar-08 22:34 |
234 | WillArp | this doesn't work: call "open /System/Library/CoreServices/Finder.app" | 10-Mar-08 22:34 |