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