00:00:00 --- log: started forth/06.09.24 00:31:25 --- quit: JasonWoof ("off to bed") 01:15:06 --- join: fission (n=fission@pdpc/supporter/active/fission) joined #forth 02:07:39 --- join: Astrobe (n=fred@c-real.rouen-wireless.net) joined #forth 02:55:50 --- quit: segher (Nick collision from services.) 02:56:00 --- join: segher (n=segher@dslb-084-056-157-197.pools.arcor-ip.net) joined #forth 03:31:03 --- join: uiuiuiu (i=ian@dslb-084-056-247-011.pools.arcor-ip.net) joined #forth 03:55:57 --- quit: ayrnieu (Read error: 110 (Connection timed out)) 04:01:53 --- quit: Astrobe ("Lost terminal") 04:38:28 --- join: PoppaVic (n=pete@0-1pool73-161.nas24.chicago4.il.us.da.qwest.net) joined #forth 05:06:09 --- quit: madwork (Read error: 110 (Connection timed out)) 05:30:51 --- join: astrobe (n=fred@c-real.rouen-wireless.net) joined #forth 06:47:38 --- quit: PoppaVic ("Pulls the pin...") 06:49:10 --- join: PoppaVic (n=pete@0-1pool47-189.nas30.chicago4.il.us.da.qwest.net) joined #forth 08:53:22 --- join: Bushmills (n=l@wpc3131.amenworld.com) joined #forth 08:53:30 'morning 08:55:57 'evening 08:57:01 gm 08:57:33 indeed 08:57:36 hiya 09:13:07 --- quit: cods (Nick collision from services.) 09:15:05 --- part: Bushmills left #forth 09:17:45 * Raystm2 stretch * 09:17:56 * Raystm2 rub eyes 09:19:15 --- nick: Quiznos -> Quibbler 09:20:03 ray 09:23:18 --- nick: Quibbler -> Quiznos 09:31:30 --- log: started forth/06.09.24 09:31:30 --- join: clog_ (n=nef@bespin.org) joined #forth 09:31:30 --- topic: 'Welcome to #forth. We discuss the Forth programming language, simplicity, and a variety of technical subjects. Introduction: http://tinyurl.com/kvawv | Starting Forth: http://tinyurl.com/rm7pq | Thinking Forth: http://tinyurl.com/nsy4j | Gforth compiler: http://tinyurl.com/s8uho | ANS/ISO Forth Standard doc: http://tinyurl.com/nx7dx | Paste >5 lines: http://forth.pastebin.ca/' 09:31:30 --- topic: set by Quartus on [Wed Aug 30 23:43:43 2006] 09:31:30 --- names: list (clog_ PoppaVic astrobe uiuiuiu segher fission Cheery Snoopy42 saon madgarden virl Quartus__ TreyB nighty__ Zarutian neceve _ugly nighty clog jcw Zymurgy Raystm2 Quiznos @Quartus lukeparrish virsys @crc michaelw ohub ccfg juri_ warpzero) 09:31:47 hehe I Quiznos. I keep thinking your trying to talk to ray ( a nick in another chat I belong to ) and not me. 09:31:53 How are you. :) 09:32:52 greedy lexing? 09:33:17 I don't know what that means. 09:33:23 wrong chan 09:33:28 ah. 09:34:43 I had that problem with irssi at first because I wanted to use split windows stuff. Now I don't split anymore. too tricky. 09:46:02 --- quit: clog (Connection timed out) 09:46:02 --- nick: clog_ -> clog 10:20:27 http://digg.com/gadgets/DOS_Emulator_for_Palm_OS_released Quartus (but you probably already know about this) 10:21:41 I didn't. That's a novelty. 10:22:05 It's great! Now you can run edlin. 10:22:21 Slowly :) 10:22:29 Yea, I imagine so. 10:24:19 --- quit: astrobe ("leaving") 10:24:28 I don't see any indication of how fast/slow it is. Did you catch anything? 10:24:40 The alpha page says it's slow. 10:25:17 It's based on dosbox, which if you've ever tried it is quite slow relative to the pc you're running on. 10:53:45 --- join: PoppaVic1 (n=pete@0-1pool74-124.nas24.chicago4.il.us.da.qwest.net) joined #forth 10:54:09 --- quit: PoppaVic (Nick collision from services.) 10:54:16 --- nick: PoppaVic1 -> PoppaVic 10:54:20 --- part: PoppaVic left #forth 10:54:37 --- join: PoppaVic (n=pete@0-1pool74-124.nas24.chicago4.il.us.da.qwest.net) joined #forth 10:55:39 --- quit: PoppaVic (Client Quit) 10:57:51 --- join: PoppaVic (n=pete@0-1pool74-124.nas24.chicago4.il.us.da.qwest.net) joined #forth 11:01:02 --- quit: saon (Remote closed the connection) 11:01:09 --- join: saon (i=1000@c-71-199-235-144.hsd1.fl.comcast.net) joined #forth 11:18:45 --- quit: PoppaVic ("Pulls the pin...") 11:25:37 --- join: JasonWoof (n=jason@c-71-192-33-206.hsd1.ma.comcast.net) joined #forth 11:25:37 --- mode: ChanServ set +o JasonWoof 11:51:39 --- quit: Snoopy42 () 11:58:34 --- join: saon_ (i=1000@c-71-199-235-144.hsd1.fl.comcast.net) joined #forth 11:58:36 --- quit: saon (Read error: 54 (Connection reset by peer)) 12:07:08 --- join: Snoopy42 (i=snoopy_1@dslb-084-058-190-251.pools.arcor-ip.net) joined #forth 13:06:12 --- quit: uiuiuiu (Read error: 145 (Connection timed out)) 13:06:28 --- join: snowrichard (n=richard@12.18.108.162) joined #forth 13:24:50 --- quit: saon_ (Remote closed the connection) 13:25:32 --- join: saon (i=1000@c-71-199-235-144.hsd1.fl.comcast.net) joined #forth 13:39:57 --- quit: snowrichard ("Leaving") 13:43:06 --- join: saon_ (i=1000@c-71-199-235-144.hsd1.fl.comcast.net) joined #forth 13:43:53 --- quit: saon (Read error: 104 (Connection reset by peer)) 14:16:48 --- quit: neceve ("Leaving") 14:22:54 --- quit: Cheery ("Download Gaim: http://gaim.sourceforge.net/") 16:03:13 --- quit: virl ("Verlassend") 16:58:14 --- join: slava (n=slava@CPE0080ad77a020-CM000e5cdfda14.cpe.net.cable.rogers.com) joined #forth 16:58:14 --- mode: ChanServ set +o slava 17:06:58 --- join: nighty_ (n=nighty@H123.C72.B0.tor.eicat.ca) joined #forth 17:14:13 --- quit: nighty__ (Read error: 110 (Connection timed out)) 18:40:07 --- join: LoganCapaldo (n=logan@ool-457a8e39.dyn.optonline.net) joined #forth 18:40:25 Hello 18:40:46 hi 18:40:56 So I just became aware of this kind of construct: : RETURN R> DROP ; 18:41:16 And I was wondering if anyone had done a forth call/cc? 18:41:22 factor has callcc 18:42:44 * LoganCapaldo looks at factor 18:42:47 interesting 18:43:04 Your RETURN there will effect a return from the caller in a Forth that a) uses the return stack as the subroutine stack, and b) uses one cell per return address. 18:43:14 yeah, its not very portable 18:43:21 heh 18:43:38 seems to work in gforth 18:43:47 so I take it its not as cool as I thought it was? 18:43:59 in factor the return stack is not accessible in this manner at all 18:44:05 the >r/r> stack is distinct, called the retain stack 18:44:05 It's a well-worn technique, but still pretty cool. You can build continuations with it. 18:45:05 Neat. Thanks for answering my question 18:45:27 EXIT is the usual name. 18:45:32 For your RETURN, that is. 18:45:53 But the technique of twiddling return addresses, that's more broadly applicable, but non-portable as mentioned. 18:46:18 cool 18:46:45 i bet gforth has EXIT 18:47:38 I have no doubt it does. I came across it looking at a BNF DSL for forth, had something like : || IF R> DROP 1 THEN ; 18:48:21 or something 18:48:25 I think I mangled it 18:48:42 but it would EXIT the word as soon as it matched a production 18:48:55 so that led me off ona tangent 18:49:09 and my googling for forth call/cc did not work out how I wanted to ;) 18:49:37 call/cc is not possible (or just very hard) without GC 18:50:03 I think what I really meant to look for was probably forth setjmp, longjmp :) 18:50:22 That BNF can be done without the return-stack manipulation, actually. 18:50:33 which now that I think about it, would be real easy with just one global 18:50:55 Forth has CATCH/THROW which are roughly equivalent to setjmp and longjmp. 18:50:55 assuming I'm still allowed to twiddle the return stack anyway ;) 18:51:06 cool 18:52:56 Hypothetically, a forth could have catch and throw built on this twiddling, correct? 18:53:37 Well, the return-stack pointer has to be adjusted by catch/throw, and the return stack is as good a place as any to store the exception frame. 18:53:48 That's interesting, Gforth appears to implement catch and throw on top of the exception system 18:53:54 (see is so cool) 18:54:19 CATCH/THROW *are* the exception system, though Gforth may have named subfactors in there. 18:54:25 ahhh 18:54:43 I thought catch/throw were like Common Lisp/Ruby catch throw 18:54:56 (for control flow, no errors) 18:55:25 They can be used for control flow. THROW is a non-local return to the most recent CATCH. 18:55:31 Yeah 18:56:26 I meant in common lisp for instance catch and throw exist for the express purpose of non-local returns, w/o implying any sort of error/exception. (Orthogonal to exceptions). 18:56:39 so I got thrown when I saw those names 18:56:47 actually CL programmers prefer lexical returns with block/return 18:57:16 slava: heh, didn't say they preferred anything ;) 18:57:26 an uncaught throw in a standard forth will result in a console-level message, but they're not necessarily for errors. 18:57:50 ok 18:58:07 just trying to wrap my head around all this stuff 19:05:47 Some words expect the address on the stack, and some words look ahead in the input stream (['] foo execute vs. see foo). Other than the obvious cases, how does one decide which form to use? 19:06:05 You mean when writing new words? 19:06:09 Yes 19:06:25 I build the stack version and the parsing version. The parsing version calls the stack version. 19:06:35 Look ahead versions seem RPN-contrary. 19:07:02 They're for convenience. Forth doesn't have RPN as an ideal, it's just a natural result of being stack-based. 19:07:36 if the parameter is fixed at compile time, you can use lookahead 19:07:42 if it has to be passed around at run time, you obviously cannot 19:07:45 hmm. 'see' is a good example. My forth requires the CFA to be on the stack. gforth uses the look ahead version. I can see gforths being easier to use, but it just doesn't feel right. 19:08:20 in factor see takes a word from the stack because in some places it is actually called by other code that locates a word somehow 19:08:32 Since you run see from the console, always interactively, for it not to forward parse is silly. 19:08:53 but not always interactively, Quartus 19:08:56 You may also have need of (see) or equivalent that uses an xt from the stack. No reason not to have both. 19:09:04 for example i have a web application for browsing the dictionary 19:09:10 it calls see 19:09:20 Sure, it calls see's functionality, anyway. 19:09:55 But forcing a user to type ' foo see instead of see foo isn't aiming higher from a UI perspective. 19:10:09 it doesn't seem like much of a difference 19:10:27 i have a bunch of words like 'usage' which lists callers, etc. providing read-ahead and stack versions of every such word would be annoying 19:10:35 I think what I find annoying about lookaheads is knowing which is a lookahead and which isn't. Once you know the system, yea, it's easy. 19:10:55 i use a convention where lookahead word names end with : 19:11:02 That's a good idea. 19:11:12 --- join: EdLin (n=chacha@as5800-1.216-194-2-3.nyc.ny.metconnect.net) joined #forth 19:11:18 Pretty much anything that needs a word name parses ahead in a standard system. As I say, when I build a new word that needs a name, I build both the internal factor that reads from the stack, and the one that parses forward. 19:12:07 The other side of it is that something like see may not be able to achieve what it does from just an xt, in a given system. 19:12:09 Sure. The stack version can be considered a given, if you will. But deciding if a word needs a lookahead is more the question. 19:12:41 neat. I just wrote a tail recursive word using that R> business 19:12:57 not really useful 19:12:58 factor has tail call optimization 19:13:02 but cool 19:13:23 slava: It's ok I already d/led factor, I promise to play with it ;) 19:13:48 If you like continuations, have you looked at Adam Dunkels protothreads library? 19:15:07 How can you tail recurse with R> ? 19:15:20 RECURSE would be the word you're looking for. Or just BEGIN AGAIN. 19:16:04 Quartus: I didn't implement the recusion (I used RECURSE) 19:16:15 How did R> come into it? 19:16:27 Sounds like he implemented his own version of EXIT. 19:17:15 Quartus: http://forth.pastebin.ca/181542 19:17:25 jcw: basically 19:17:38 it's silly 19:17:50 since all it's saving is the storage of the return addresses 19:17:52 I'm not at all sure what that code does. 19:17:54 might as well be a loop 19:18:40 Quartus: well assuming we are in one of those forths where the assumptions you mentioned earlier holds 19:19:02 Is EMPTY supposed to remove all the items from the data stack? 19:19:07 yeah 19:19:18 Well, you've got a good start at winning an obfuscation prize. :) 19:19:34 heh 19:19:47 : empty begin depth while drop repeat ; 19:19:56 Yeah I know 19:20:30 I just enjoyed the fact that I basically manually tail call "optimized" it, and got away with it 19:20:42 (optimized for a very loose definition of the word) 19:20:47 You know what's sad? In mine, I'd write a native word called 'ndrop' where the top stack argument was the number of items to drop. 19:20:52 depth ndrop 19:21:00 jcw: I wrote ndrop many times ;) 19:21:10 in factor its { } set-datastack 19:21:12 the oroginal empty was depth ndrop 19:24:35 No need for a native word -- : ndrop 0 ?do drop loop ; 19:24:57 yep 19:25:03 thats what mine looked like 19:25:25 You know me better than that, Quartus. I still think better in C. 19:25:31 Only one way to learn. 19:25:55 Native words in C? I thought you were supposed to write them in ASM? 19:26:26 If your Forth-alike dealie is written in C, then you probably write them in C. 19:26:37 aha 19:26:49 Oh, I came up with a possible name for mine: FOLICLE 19:27:00 FOrth-LIke Computer Language Experiment 19:27:06 heh 19:27:07 factor's core is in C, but a lot of words are replaced by assembler intrinsics by the compiler 19:27:09 Pretty fscking lame, eh? 19:27:28 jcw, yes, very 19:27:29 for example the 'drop' word only calls out into C during bootstrap 19:27:41 afterwards it compiles to SUB ESI,4 (on x86) 19:29:01 Gforth does the same, though it doesn't inline the call. 19:29:13 well gforth is direct threaded, right? 19:29:16 gforth-fast's drop is add esi,4 next 19:29:30 No, it comes in three flavours 19:29:41 ah, that's right 19:30:54 --- quit: madgarden (Read error: 104 (Connection reset by peer)) 19:31:31 FORD means Found On Roadside, Dead. Does FORTH mean Found On Roadside, Thrashing Helplessly? 19:31:59 Only if C is the grade given to the language. :) 19:32:22 i hate C 19:32:34 maybe hate is too strong, but i dislike it, even for low-level stuff 19:32:39 unfortunately there's no real alternative 19:33:11 if factor was fully self hosting, i'd have to write code to emit native dynamically linked binaries on all platforms, which is a huge amount of work 19:33:26 i do want to reduce the C part over time to an image loader, and nothing else 19:33:30 A real programmer could crank that out on a weekend. 19:34:01 and have it work on Mac OS X (x86, PPC), Linux (x86, PPC, AMD64), Windows (x86), Solaris (x86, AMD64) and FreeBSD (x86, AMD64)? 19:34:09 OK, maybe an extra day for that. 19:34:39 I'm just hasslin' ya. Factor is damned impressive. 19:34:42 you're being sarcastic, i know 19:34:59 although java programmers look at me the same way when i say that stuff they spend weeks on can be done in a few hours in rails 19:35:20 "Java" and "programmers" don't really go together in the same sentence. 19:35:37 business-suit wearing meeting attending entities 19:35:50 Java is for people who can't grasp BASIC. 19:35:59 java is surpsingly hard to grasp 19:36:07 looked at generics in 1.5? 19:36:15 I don't look at Java at all, anymore. 19:36:18 the FAQ is 400 pages long, all confusing corner cases 19:36:20 nor do I 19:37:33 When Java first came out, I was intrigued by it. I wrote some gauge classes (speedo, fuel, rpm, oil pressure/temp, etc) and some weather instrument classes. Then I tried to do serial port stuff with it, and promptly got disgusted. From then, it only went down hill. 19:37:44 I find Java ridiculously complex. I try to avoid it. 19:37:52 One thing I have noticed that when you get one Java programmer in a company, you seem to develop an infestation of them. 19:37:56 i did some serial port work in java in 2002 19:37:59 I think they breed behind the PCs or something. 19:38:14 credit card authorization, which is done over a phone line with a modem 19:38:27 rewriting a VB program in java 19:38:27 Probably had to buy a class, didn't you? 19:38:34 the VB app was totally undocumented, with all logic in one function 19:39:19 i got paid very well, though. :) 19:41:03 This company that I've been consulting to for 3 years got bought. One of the things we had was a Java programmer who wrote this crazy-huge application for managing the locks, user database, attributes, etc. Over a period of 4 years or so, I think it grew to around 250,000 lines. It was unstable as hell, had a user interface where the workflow made no sense at all. When we got bought, they took him aside, said "We're not interested 19:41:04 in your application, we'll be using an industry standard", and gave him his walking papers. 19:41:45 largest java codebase i worked on was on the order of 500,000 LOC 19:41:51 Really? They should be finding whoever hired him and gave him that unbounded task, and fire that person. 19:41:58 i wrote a 90,000 LOC java program myself 19:42:08 seems like a lot until yo urealize most of it is boilerplate 19:42:20 That would be the owners of the company, before they sold it. 19:42:27 They didn't come with the purchase either. 19:42:35 Point being, it's not the coder's fault. 19:42:54 Poorly written software most certainly is. 19:42:54 So the new owners sacked a guy who probably knew the process in great detail. Bright move. 19:42:58 Unbounded, perhaps not. 19:43:27 No, letting him go was not a mistake. I'm the person who knows the process in great detail. 19:43:53 I wrote all the firmware for the locks. Since they're using an industry standard tool for the management, what he knew was pretty irrelevant. 19:44:54 Irrelevant because what he knew was localized to what he wrote. And the industry as a whole uses a completely different work flow from what he did. 19:46:50 The whole problem with the previous owners was they did what I call "carrot sales". If someone looked like they might buy a few dozen units, that became the carrot that week. We'd have to make changes for that customer, because they thought if they offered that to that customer, they'd buy units. That's not the way the real market for this product works. As such, things were in a constant state of flux, products got little to no t 19:46:50 esting before the direction changed next week. 19:47:22 --- join: madgarden (n=madgarde@Kitchener-HSE-ppp3577114.sympatico.ca) joined #forth 19:47:23 Some of us would try to tell them time and time again that what they were doing was not the way to run a company. And it fell on deaf ears. 19:47:28 large java codebases have a habit of developing bugs which are simply impossible to track down and fix. 19:47:40 jcw: at least you didn't get fired for telling that. 19:49:02 This was another stupid thing they did. I was the *only* person who knew anything about the firmware, and I was a contractor. I have things documented, but no one would be able to pick up the product and make changes in a short amount of time, if I got hit by a truck. 19:49:51 Yea, it's a nice employment security, but it's a dumb way to run a company. Now that we've got bought by a company that's not run by idiots, I've been pushing to make at least one other person as knowledgable as I am about the product. And that's starting to happen. 19:50:08 i'm going to sleep 19:50:10 good night 19:50:30 ciao 20:37:40 --- join: nighty__ (n=nighty@H123.C72.B0.tor.eicat.ca) joined #forth 20:40:51 --- quit: nighty_ (Read error: 145 (Connection timed out)) 21:13:38 --- quit: nighty__ (Remote closed the connection) 23:35:11 --- join: Cheery (n=Cheery@a81-197-19-23.elisa-laajakaista.fi) joined #forth 23:59:59 --- log: ended forth/06.09.24