00:00:00 --- log: started forth/06.03.18 00:26:19 --- join: virl (n=virl@chello062178085149.1.12.vie.surfer.at) joined #forth 00:48:50 * JasonWoof tips his hat to virl stylishly 00:54:25 JasonWoof, ehm thanks..? 00:57:52 JasonWoof, are you happy about a new hat? 01:01:06 nah, I just miss seeing my friends on discworld 01:01:10 mud 01:02:28 --- join: Cheery (i=Henri@a81-197-45-47.elisa-laajakaista.fi) joined #forth 01:03:32 discworld mud? 01:10:04 yeah 01:10:13 it's amazing 01:10:21 discworld.atuin.net 01:10:47 wonderful time waster 01:10:55 ok, I gotta go to bed 01:11:01 I'm being productive, but not quickly 01:11:08 keep doing braindead things 01:26:07 --- quit: JasonWoof ("off to bed") 03:34:11 --- join: ravenEx (i=ravenEx@VPN-239-156.aichyna.com) joined #forth 04:58:22 --- join: tathi (n=josh@pdpc/supporter/bronze/tathi) joined #forth 05:20:19 --- quit: tathi ("leaving") 05:54:04 --- join: Invifer4 (n=Invifer4@12-208-98-237.client.insightBB.com) joined #forth 06:13:49 --- nick: segher_ -> segher 06:15:35 --- join: PoppaVic (n=pete@0-1pool65-188.nas22.chicago4.il.us.da.qwest.net) joined #forth 08:25:01 --- quit: PoppaVic ("Pulls the pin...") 08:35:01 --- join: PoppaVic (n=pete@0-1pool46-165.nas30.chicago4.il.us.da.qwest.net) joined #forth 08:43:35 --- quit: ravenEx (Read error: 131 (Connection reset by peer)) 08:46:49 ahh... I think I begin to see a pattern.. a light at the end of the tunnel. 08:48:00 poppavic: it might just be a train coming in your direction, be careful! 08:48:15 yeah, I expect that - circling it now 08:49:17 its a cross between "the compiler" and "data-passing" 08:55:05 I would be happy when I would see a light at the end of the tunnel, so fucking much issues. 08:55:41 no joke... and a shitload are all in the FFI zone. 08:57:15 FFI zone? FFI = Foreign Function Interface, but what's a FFI zone? 08:59:52 back, sorry - yeah... THe area around FFI... Even "stacks" 09:00:57 I think I've just discovered another weakness/strength that flaws at the very least FFI 09:01:24 still trying to phrase my doc-entry sensibly, but I can "see" it now. 09:05:21 Mostly, I'm noticing how "the stack" is just a r/w "stream" as compared to every other "stackframe system". 09:06:12 Looking into the latter, I recall most folks see me as paranoid, but then turn around and extoll assert() 09:07:19 The former is looking more and more like just dicking around with the "input stream" with what we usually call "macros". 09:08:40 And, it all sounds insanely-weird.. until you start digging with a backhoe. 09:14:46 Oh.. and, (of course), you might even be tempted to use a "direct-threaded" system - and still run yer head into the wall of access/permissions and security. 09:15:04 ..and relocatability. 09:19:41 I think the former are why folks prefer to recompile source over and over. 09:21:04 I can't really say I disagree with them, but it's inconvenient, unfriendly and suggests a variety of issues. 09:21:11 lalala 09:21:21 arke: indeed 09:21:55 arke: and folks wonder why I live with editors and C compilers? ;-> 09:31:50 No "snappy comeback"? 09:41:51 snappy comeback? 09:41:52 whats that? 09:41:53 ;) 09:42:14 I thought not 09:44:08 If I could manage to get the latest gforth to build, and spend the weeks to understand the autoshit-voodoo, I might have an answer to the whole mess. I just doubt it... 09:45:42 I think we are just at an impasse.. Most folks don't realize that FORTH was originally embedded/device-oriented. 09:46:10 in effect, the language WAS the OS. 09:46:47 ..and the shell.. 09:50:24 but we still have some 09:50:30 hmm? 09:50:34 colorforth. 09:50:42 Spare me. 09:50:54 Consider me "colorblind" 09:50:56 Oh come on. 09:51:05 Nope 09:51:19 Even if CF didn#t use color as part of the syntaxits pretty much as forth as it gets 09:51:31 ahhh, no - it isn't 09:51:40 why not? :) 09:52:15 It expects color (or cases/text) to be useful. 09:52:41 Editors are not languages, and terminals are not editors either 09:53:32 Basically, "colorforth" played the same games that ancient ANSI-wordstar did. 09:53:59 "all these 'modes' suggest some other damned thing" 09:54:12 don't you think the unification is exactly along the lines of forth? 09:54:25 ok, I don't like how the modes are implemented, that could be a bit nicer 09:54:53 I would doubt it, Chuck is - for starters - of the mind that "every function and program should be rewritten for a platform" 09:54:58 but thats not the point 09:55:18 unification of functionality, i meant 09:55:19 it is the point 09:55:39 I'm talking from a programmers perspective, not from a users perspective 09:55:55 oh, forget unify - think std-form and translations. think reintegration 09:55:59 from a programmers perspective, you have a shell, editor, and language, combined into one. 09:56:06 bad 09:56:09 and all forth. 09:57:02 why? 09:57:13 We need less assumption/integration and more layering/use. 09:58:23 Very early on, under FIG, we had "an editor" - thank christ it was encapsulated and lived in BLOCKS. and ported 100% - until it got to the keyboard. 09:59:22 shit needs drivers/support, and more and more generalization. (optimizing should be late and relies on platforms and patterns) 10:00:59 oh yes, i agree there 10:01:07 I've been looking for several weeks for something called "libevent" - I've a bad feeling I lack it. Yet, the silly bastard just unifies an assortment of issues. 10:01:19 libevent? 10:01:36 --- join: tathi (n=josh@pdpc/supporter/bronze/tathi) joined #forth 10:01:56 arke: yeah, supposed to deal with files, signals, file-changes, devices/mice or whatever... Apparently there is no powerbook port. 10:02:24 right. 10:02:27 Sorta' an "Uber Select/Poll" 10:02:59 thats somewhat nice. 10:03:27 Meanwhile, folks seem to think lisp uber forth and forth/lisp != libs, plugins, programs. just source. 10:03:58 ..somewhere along the line, shit just isn't doing FFI or translatable. 10:04:20 ..and Forthish has too many good ideas for this to acceptable. 10:05:18 wait what? 10:05:28 wait? 10:05:28 could you retype those last 3 lines in english pleae? :D 10:05:49 arke, I can repost.. THey mean what I said. 10:06:12 --- join: crc (i=crc@pool-70-110-170-219.phil.east.verizon.net) joined #forth 10:07:35 Folks seem to believe lisp is superior to forth, which I doubt. Mostly, lisp wants to bypass the whole universe and generate machine - not interactively. And, that neither forth or lisp are well suited to FFI into asm or C. 10:08:41 I figure we've umpty-assemblers for a reason, and C funnels that a bit, and everything else should be able to talk their dialects. 10:10:43 Forth ends up being a shell that can create pcode, export .o and import the same - or .a or .so - libs/plugins. 10:12:20 Near as I can tell, there is nothing remotely similar. BUT, not one forth can play with it's own pcode (interactive) plus export shit that is really "compiled" and can import/integrate/ 10:13:14 ..and lord knows, no forths can import and integrate even a .a, let alone .o, or .so, or plugins. 10:14:16 ..and, I always ask WHY!?! And, I always answer myself "because folks do not want to admit to other tools and formats". 10:14:38 * crc has little use for being able to export to .a or .so 10:14:59 as to importing, a basic ffi suffices for my needs thus far 10:15:03 I do If I want shit that's static, I'll order it up. 10:15:17 --- part: tathi left #forth 10:15:40 there is no "basic ffi" - I've examined several packages, and they all blow - one way or another. 10:15:43 PoppaVic: then code it and use it if nothing exists that meets your needs 10:16:00 PoppaVic: the ffi in retro and reva suffices for my needs 10:16:07 --- join: LOOP-HOG (n=chatzill@sub22-119.member.dsl-only.net) joined #forth 10:16:10 if it's not what you need/want, code your own 10:16:19 crc: are you suggsting the usual "either it's 'SH' or not" issue? 10:16:25 ? 10:16:40 as in, use sh or write a program 10:17:02 PoppaVic: I believe SwiftForth allows you to do it, or at least for windows 10:17:07 if you want a forth that can import/export any .so, you'll have to code it 10:17:20 --- mode: ChanServ set +o crc 10:17:46 crc: I'm aware of it: I was pointing out there are at least 2, (if not three), levels 10:18:10 I personally don't worry about "levels"; I code for my current needs, nothing more 10:20:54 yep.. Been there, done that - then I grew up and anted to reuse shit I'd written over and over. 10:20:55 --- join: Serg_Penguin (i=Serg_Pen@ppp85-140-28-188.pppoe.mtu-net.ru) joined #forth 10:21:11 nothing keeps me from reusing code 10:21:27 sure it does. But, ok. 10:21:52 * crc fails to see how not worrying about the future possiblities keeps me from reusing existing code 10:22:02 /anted/wanted/ 10:22:16 --- join: segher_ (n=segher@dslb-084-056-167-057.pools.arcor-ip.net) joined #forth 10:22:38 * Serg_Penguin always writes nt just program but also a library 10:24:06 Serg_Penguin: you are aware that Forth "officially" has no "lib" support? 10:25:50 It's in a weird corner... It is an interpretive-compiler - and never gets much deeper than that, sensibly. 10:25:52 PoppaVic: are you aware that there is no single "Forth" that speaks for all? ;) 10:26:01 crc: most assuredly. 10:26:34 There _are_ commercial products that can play, but not one idiotic-variant bothers to contest them. 10:26:42 so, something like SwiftForth which does support creating and importing .DLL's under Windows "officially" has "lib" support 10:27:05 sure, dll and doze. Good deal.. I'm proud they got that far. 10:27:24 I've accessed DLLs through SF b/f 10:27:50 "SF b/f"? Why do I care about doze? 10:28:37 well, you are either a Windows person or a Unix person. If I could get a Forth desktop with the softs I need I'd do that 10:28:47 crc: I'm not even remotely arguing against forthish, but I find the end-results sort of disturbing. 10:28:54 I can't browse the web or check email in colorforth 10:29:16 neither forth nor *nix requires a "desktop" 10:29:29 I am used to using one 10:29:40 And I still can't read my emails in ColorForth 10:30:02 I can't do ANYTHING in ColorForth besides program in Forth 10:30:04 So am I, as well as a termwin.. My brother breathes doze, and has no idea what a dir or file is. 10:30:16 LOOP-HOG: that's not what ColorForth is intended for though 10:30:21 by "lib" i mean not a C lib or DLL, but a palette of code what i can cut'n'paste later 10:30:22 Right. 10:30:37 Serg_Penguin: that's not remotely a library 10:30:49 --- quit: segher (Read error: 110 (Connection timed out)) 10:30:52 not in the unix or windows sense 10:31:00 it's a *source* library 10:31:11 right 10:31:43 * crc maintains a small library of source code for retroforth users to draw from 10:31:56 In that case, the BEST you can hope for is open/seek/readN/close 10:32:59 i got basically two "libs": terse control words and address registers 10:33:20 + maybe arbitrary stacks of arbitrary item length 10:33:25 they are NOT libs.. 10:33:29 they are. 10:33:39 nope 10:33:44 yes 10:33:56 just not binary, prepackaged bunches of functions 10:34:06 And "block-files" are not libs, either - they just come closer 10:34:22 block files are text files with special formatting, nothing else 10:34:30 yeah... not true 10:34:32 ? 10:34:35 my oldie DOS forth does supports pre-compiled units ;)) 10:34:35 how so? 10:34:54 but i don't use the feature ;)) 10:35:43 a block-file is simply a filwith 1K incrememts of text that CAN format internally. You still end up lexing/parsing/interp/compiling. 10:35:57 it just writes top piece of dictionary to disk 10:35:58 that's still involved in a binary library too 10:36:19 crc: yep, and therein is where folks want to die 10:36:28 * crc could care less 10:36:40 ok. then, it's not an issue 10:36:46 --- join: JasonWoof (n=jason@pdpc/supporter/student/Herkamire) joined #forth 10:36:46 --- mode: ChanServ set +o JasonWoof 10:36:48 if you are so disturbed by this all, just write a language that does what you want 10:36:54 yep 10:37:05 pretty sad 10:37:15 complaining about it gets nowhere, especially among a community of hard headed forthers :) 10:37:23 (or any other language for that matter) 10:37:31 not really, most are hard-headed-asmers 10:38:01 still, the point is taken 10:39:30 "gather yee roses as you can" 10:42:39 --- quit: crc () 10:49:14 --- join: crc (i=crc@pool-70-110-170-219.phil.east.verizon.net) joined #forth 10:49:47 --- part: Serg_Penguin left #forth 10:56:16 --- join: _crc (i=crc@pool-70-110-170-219.phil.east.verizon.net) joined #forth 10:56:16 --- quit: crc (Read error: 104 (Connection reset by peer)) 11:04:39 so the summary oof what PoppaVic meant was that he don't like the way forth generally handles the concept of libs 11:04:55 not exactly, but close 11:07:56 well, iirc every interpreted language does something similiar to forth 11:08:26 Forth _has_ no concept of "libs", in any way, shape or form... It just wants to "interpret": be it source or pcode. 11:09:57 It merely has input-sources and state and failures/pass 11:09:58 well, Forth is the collection of Forth Systems, you know the good old speaking 'when you know one forth you know one forth' 11:10:31 yeah, and I am well aware "Forth: the worlds most unsupported language" 11:11:02 It just gets old, because there are so MANY good ideas. 11:11:27 ..and so MUCH "resistance" to changing it 11:11:28 and there comes the reason why some people like me invent something different 11:11:43 virl: I know, nai.. 11:12:59 much resistance? where is the resistance? 11:13:01 I just thing the "wholeness" of XML is overkill, even for a translator. I;m still looking into the bottom-up alternatives. 11:13:42 resistance: "this is the way it is, (here and generally), suffer us and die" 11:14:10 well, I don't see it. 11:14:28 I do. But, that's ok: I've been at the mess for decades 11:17:12 We still end up with a shell/interp at the TOP, and feed in source or link/load precompiled, or link/load binary. And, those three levels tend to bug folks. AND, (frankly), it means voodoo or reorganizing concepts 11:17:23 C is similiar with it's different implementations and compiler features which make it sometimes hard to port. I only see that it's the same with forth, only a little bit bigger. 11:17:37 ..and Each link/load SUGGESTS: save. 11:18:06 Yes, and you are right.. C has similar issues. 11:18:30 Fewer, but similar 11:19:09 Anyway, I think it's time for a snooze... Before I have to make dinner. Stay well, virl/folks... 11:19:14 --- quit: PoppaVic ("Pulls the pin...") 11:23:49 well, the people are the problem, if nobody would use his right of freedom, then there wouldn't be different implementations. 11:38:14 --- quit: _crc (Read error: 110 (Connection timed out)) 11:39:12 --- join: slava (n=slava@CPE0080ad77a020-CM000e5cdfda14.cpe.net.cable.rogers.com) joined #forth 11:55:49 factor is so damn fast.. 11:56:00 hmph 11:56:25 JasonWoof, is that untrue? 11:56:28 isn't it in java? 11:58:13 our god wrote it again in ugly C 12:00:41 oh, lemme see if the C version works on my box 12:02:44 I was hmphing about java. but looks like this C stuff is further along than I thought 12:03:09 (not that I like C terribly, but it's nice that it can make binaries that start up in less than 2 minutes) 12:04:08 make binaries? 12:04:22 how long does the ./f boot.image.ppc thing take? 12:04:38 gcc -o foo foo.c 12:04:40 ehm.. factor is this sort of smalltalk image thingy 12:05:02 well, on my machine it takes 5-10 minutes 12:05:17 ahh, now it's moving again 12:05:28 it printed messages up to "Compiling 1+" then sat there for a long time 12:05:39 then printed "Compiling zero?" 12:06:03 if these are really just compiling individual words this could take days 12:11:36 I'm really interested why it takes to compile so simple things like '+' or '/' one minute and more.. 12:11:52 me too 12:12:37 I think math words support many argument types, but still 12:13:10 but you say it's fast once you build it? 12:13:25 that was sarcastic ;-) 12:13:35 oh 12:13:45 so my "hmph" was right on the money 12:13:49 but when you believe the words of slava it is or should be 12:14:21 yep it was.. 12:14:54 you gotta understand that that java people's idea of fast is like a dust mite's idea of big. 12:15:13 dust mite's? 12:15:30 tiny creatures that float around on dust particles 12:16:30 my idea of a commandline program that is fast, is that it's done before you can get your finger off the enter key 12:16:44 same as my idea of compiling something fast 12:17:07 both of my recent forth systems can compile themselves fast 12:19:51 I hope that what I want to produce also compiles itself fast. 12:20:46 I'm really new to implementing interpreter systems. especially for such systems like a forthish one. 12:21:23 cool 12:21:26 go for it! 12:21:50 get something simple working first/quick 12:24:05 yeah, I did that already something simple working but that was some months ago, my problem until yet was the dictionary. 12:28:11 Jason, LOL 12:28:11 it takes a long time to compile because when compiling the first few words, everything runs in the interpreter 12:28:28 its not like a user recompiles the system three times a day 12:29:37 --- quit: Cheery ("Leaving") 12:30:03 so the interpreter is extremly slow? 12:30:17 yes 12:31:08 but why is it slower than a perl script doing the same? 12:31:28 its faster than perl, except at I/O which i haven't optimized much yet 12:32:12 holy crap it's done! 12:36:03 --- nick: segher_ -> segher 12:36:32 JasonWoof, how do you implement dicts? 12:37:30 I only want to get infos for a better implementation of my xell vm. 12:38:10 I've been working with rather strange forth-like things 12:38:18 I usually just make an array for each field 12:38:36 but for a mor normal forth system I'd probably make a linked list of structs 12:38:50 a linked list is slow to search, i'd suggest a hashtable or tree 12:38:53 depends what your priorities are 12:39:00 linked lists are slow but simple 12:39:10 for speed arrays are better 12:39:14 well, you'd need to implement hashtables at some stage anyway, for other things 12:39:22 but it's a bit more complex unless you just make them eat loads of memory 12:39:23 an array still requires a linear search 12:39:36 yeah, hash tables are still faster and more complex 12:40:06 slava: I did this: ./f factor.image -shell=ui 12:40:19 and it said: 12:40:19 Front end processor commands: 12:40:19 t -- throw exception in Factor 12:40:21 ... 12:40:32 does it work without the shell parameter? 12:40:37 hash tables combined with multiple wordlists is still doing my head in. i think i'll just make the wid part of the name for hashing :-) 12:40:55 seems to 12:40:57 says: 12:41:00 Loading factor.image... relocating... done 12:41:00 Factor 0.80 on linux/ppc 12:41:06 then I can type: 1 2 + . 12:41:13 and it says 7? :) 12:41:13 and it prints 3 12:41:30 are you on linux/ppc? 12:41:33 yes 12:41:40 : 123+*. 7 ; 12:41:53 do you have hardware OpenGL? 12:41:54 erm, and a dot, ouch 12:42:26 yeah, but it tends to crash my system 12:42:35 slava: the ui uses opengl? 12:42:43 the error comes up because it can't find the libraries and that's esay to fix, but without OpenGL working its pointless to try 12:42:54 ok 12:42:58 I won't bother then 12:43:13 somehow opengl takes my system down hard sometimes 12:43:15 i don't really support obsolete systems without OpenGL, its not worth the effort 12:43:26 obsolete? 12:43:28 yes 12:43:33 what's obsolete? 12:43:37 a cheap geforce card is 20$ 12:43:41 install os x and you have hardware gl 12:43:57 so you _do_ support obsolete systems _with_ opengl? wow. 12:44:18 for some reason all software opengl implementions are horribly slow 12:44:28 and other than opengl its not clear what cross-platform graphics library to use 12:44:41 show me a graphics card for $20 with 30MB of ram or more that will work on my computer and I can plug my apple flatpannel into and I'll buy it. 12:44:54 last I checked something like this was going for $150 on ebay 12:45:30 it won't work with linux anyway, there's no nvidia driver for linux/ppc 12:45:31 what are you doing with gl anyway? 12:45:34 drawing stuff 12:45:45 http://factorcode.org/multi-window-test.png 12:45:45 flight simulators? 12:46:04 no, just widgets that don't look like windows 3.1 12:46:22 yikes 12:46:39 can't abide widgets :) 12:46:57 and a bit of alpha-blending, for text rendering. this is faster with hardware than software 12:47:17 that depends 12:47:44 well SDL_ttf is a dog compared to putting the text in a texture and drawing with OpenGL 12:47:49 if you want to do high quality font rendering, hardware *cannot* do it at all 12:47:56 i just cache a texture for each character 12:47:59 it's a dog yes, and dog ugly, too 12:48:05 you don't need opengl to get 32bit color... 12:48:12 then call display lists in a loop to render the text 12:48:32 that only works fine as long as every character is always exactly pixel-aligned 12:48:50 it is 12:49:01 ahh, that makes sense 12:49:32 i have a high-end video card, i'm not going to waste time writing my own code to draw lines when i can use OpenGL 12:49:51 line drawing is fun 12:49:54 well in that case, you have only a few fonts at a few sizes to choose from; and software rendering could be blistering fast, too 12:50:11 that is a very valid point, yes 12:50:21 with OpenGL you can do rotation and other effects 12:50:22 do you build ev erything on top of opengl? 12:50:24 yes 12:50:29 nice nice 12:50:57 subset of opengl of course, the full thing is way too heavy 12:51:16 what do you mean? 12:51:35 i only use a small subset of opengl features of course. no atmospheric effects or phong shading :) 12:51:38 you only need a subset of opengl for all your ui needs 12:51:46 yes, but i have a binding that covers the whole library 12:52:27 i'd do the gui at a layer inbetween the "full" opengl and the low-level hardware-supported thing 12:52:48 that doesn't make sense 12:52:52 I haven't fully decided what I'm going to do for a graphics api 12:53:09 take a look at cairo 12:53:20 I don't think I'm going to do alpha channels 12:53:30 slava: oh let me guess, your thing runs in an existing OS, with an existing working full opengl library? 12:53:38 segher: yes 12:53:45 well sure, just use it, then 12:54:10 no sense in being spartan just because you can ;-) 12:54:18 i just sit on top of cocoa and x11 12:54:44 "cocoa" does what i described 12:55:24 x11 still has their stack upside down 12:55:57 --- quit: LOOP-HOG ("ChatZilla 0.9.61 [Mozilla rv:1.7.5/20041217]") 12:56:02 yes 12:56:18 although they're catching up with the recent x.org extensions 12:56:33 not nearly there yet though :-( 12:57:15 and you cannot really, if you want to keep the old x11 protocol stuff in everything 12:57:29 os x has a lot of crud in it too, all the carbon stuff, quickdraw 12:57:35 but you don't have to -- just add a compatibility x11 layer _on top_ of the new great thing 12:58:02 yes definitely -- but the emulation sits _on top_ of the new stuff, not the other way around 13:02:52 factor is the first forth with a decent cocoa binding on os x 13:03:12 so make it fast as well now :-) 13:03:19 it is fast 13:03:39 i dunno, i just heard about minutes startup time 13:03:56 that's the initial compile time 13:04:05 oh heh 13:05:54 of course a toy forth compiles itself in 0.000001 seconds because it has no code 13:07:10 hey, my forth system compiles in <3s. _including_ flashing the thing to flash memory. and it is a full open firmware 13:07:25 and the initial compile is C + Perl :-) 13:14:02 yeah but you can't compare something basic like open firmware with a system designed for writing desktop apps 13:14:15 it has a gui. 13:14:22 might as well complain linux kernel takes longer to compile than freedos 13:14:56 oh i'm not complaining -- i'm just trying to say that to make it fast just takes optimising the correct things 13:15:38 if i strip out the optimizing compiler, then bootstrap will take 30 seconds or so 13:16:01 how much optimising does it do? 13:16:08 actually it takes 3 seconds with no compilation at all 13:16:32 it does some type inference and partial evaluation 13:16:46 constant propagation, you mean? 13:17:07 yes, partial evaluation is more general though 13:17:18 i know -- and often it isn't a win 13:17:41 it is if you manage to optimize out a lot of type dispatching 13:17:54 but it depends on what exactly you do 13:18:21 can't you statically figure out most types normally? 13:18:34 not most, but some, that's what the compiler does 13:18:40 or, that is what you mean, i guess :-) 13:18:42 --- join: tathi (n=josh@pdpc/supporter/bronze/tathi) joined #forth 13:18:44 right 13:19:23 doesn't mops do cocoa? 13:19:31 yes, but poorly 13:20:01 it's really easy to do it very poorly ;-) 13:21:31 heh 13:21:35 most things are easy to do poorly 13:22:19 well, there's C APIs/ABIs to do everything ObjC the easy way, already, so... :-) 13:22:42 in mops, you have to manually define messages and classes, you can't just "import" a class, also it makes no attempt to integreate objective C exceptions with the language; an objective C exception just crashes the program totally 13:23:02 oh wow 13:23:09 segher: i thought of using carbon but the stack juggling with calling a C function taking 9 arguments, some of which are out parameters, is prohibitive 13:23:32 and carbon is full of functions taking large numbers of parameters 13:24:15 no need to use carbon -- there is a C ABI. _plain_ C. 13:24:33 carbon is the C GUI library on OS X 13:24:40 oh in that way 13:24:51 nah, carbon is the old bluebox 13:24:59 no, carbon is native 13:25:02 'classic' is the OS 9 emulator 13:25:03 the m68k API/ABI 13:25:05 no 13:25:10 jesus 13:25:18 even 'classic' can run powerpc code, just OS 9 powerpc code 13:25:26 well it is, sorry if that doesn't fit into your world view 13:25:48 you can't run m68k code on os x 13:25:52 unless you're using classic 13:26:14 carbon is the "classic" API. it isw compiled to ppc code, for macosx and macos9 + the carbon compat layer, sure 13:26:23 carbon is a subset of the Mac OS 9 API, yes 13:26:56 mostly, yes. there's a few additions and changes, but those are quite minor (except that lowmem is gone altogether!) 13:28:07 carbon is meant as an easy way to port old stuff to macosx. hey, the port could even be done before macosx was available :-) 13:29:14 noone should ever use carbon for a new project. of course, apple using it for itunes is not a good example 13:29:54 esp. when they also try to pretend it was *not* a six-year old program already when it was first introduced 13:31:40 the finder uses carbon too 13:32:00 yeah 13:32:10 it uses C++ too, though 13:32:17 powerplant, i believe 13:32:21 rumour has, that the next version will be ObjC though 13:32:23 C++ framework built in carbon 13:32:31 yeah, the moto thing 13:32:36 formerly MW 13:32:56 built "on top of" i'd say 13:34:58 right 13:41:24 for what does a language like factor needs a 32bit ui? 13:41:39 yeah, why not 64-bit? 13:41:54 or whatever the native wordsize is :-) 13:41:55 I thought it did run on some 64-bit platforms? 13:42:25 dos runs on amd64 machines. so? 13:42:35