00:00:00 --- log: started forth/04.06.22 00:09:43 mothing and lots of that is up. 00:09:47 nothing* 00:09:55 * arke is playing morrowind :) 00:18:16 --- quit: lalalim (Read error: 60 (Operation timed out)) 00:24:52 --- join: lalalim (~lalalim@pD95EA066.dip.t-dialin.net) joined #forth 00:34:52 Cynics may dismiss a private rocket soaring to 100 km 00:35:25 as an insignificant and unrealistic challenge to NASA 00:35:41 and government dominated space programs. Perhaps 00:35:56 they may see Rutan as a hobbyist on steroids, trying to 00:36:05 pander to an emerging "space tourism" market. All of 00:36:18 these would trivialize what is truly a pivotal and 00:36:27 profound milestone in the development of outer space. 00:36:56 That was a paragrapha out of an article from spacedaily.com 00:37:11 I especially like the phrase, "hobyist on steroids" 00:37:13 :^) 00:37:15 --- quit: LOOP-HOG () 01:55:45 --- join: solar_angel (~jenni@Toronto-HSE-ppp3685160.sympatico.ca) joined #forth 02:02:26 --- quit: topher ("Client Exiting") 04:23:31 --- quit: solar_angel ("*later*") 05:38:18 --- join: I440r (~FooBlah@168-215-246-243.gen.twtelecom.net) joined #forth 05:49:28 --- quit: slava (Read error: 54 (Connection reset by peer)) 05:50:04 --- join: slava (~slava@CPE00096ba44261-CM000e5cdfda14.cpe.net.cable.rogers.com) joined #forth 06:22:47 --- quit: slava (Read error: 104 (Connection reset by peer)) 06:23:29 --- join: slava (~slava@CPE00096ba44261-CM000e5cdfda14.cpe.net.cable.rogers.com) joined #forth 06:56:21 --- join: harm^kuvo (C00K13S@cp12172-a.roose1.nb.home.nl) joined #forth 07:02:30 --- quit: kuvos (Read error: 60 (Operation timed out)) 07:14:47 --- quit: qFox (Read error: 110 (Connection timed out)) 07:14:47 --- quit: madwork (Read error: 54 (Connection reset by peer)) 07:22:40 --- quit: arke (Read error: 104 (Connection reset by peer)) 07:23:33 --- join: arke (~arke@melrose-251-251.flexabit.net) joined #forth 08:30:13 --- quit: I440r (Read error: 104 (Connection reset by peer)) 08:30:25 --- join: I440r (~FooBlah@168-215-246-243.gen.twtelecom.net) joined #forth 08:40:23 --- quit: I440r (Read error: 60 (Operation timed out)) 08:46:44 --- join: I440r (~FooBlah@168-215-246-243.gen.twtelecom.net) joined #forth 08:56:01 --- join: qFox (C00K13S@cp12172-a.roose1.nb.home.nl) joined #forth 09:06:52 --- quit: Research (Client Quit) 09:54:52 --- join: onetom_ (~tom@novtan.bio.u-szeged.hu) joined #forth 09:54:53 --- quit: onetom (Read error: 54 (Connection reset by peer)) 10:06:08 --- join: kuvos (C00K13S@cp12172-a.roose1.nb.home.nl) joined #forth 10:06:13 --- quit: qFox (Read error: 54 (Connection reset by peer)) 10:06:49 --- quit: harm^kuvo (Read error: 54 (Connection reset by peer)) 10:08:42 --- quit: kuvos (Client Quit) 10:09:57 --- join: kuvos (C00K13S@cp12172-a.roose1.nb.home.nl) joined #forth 10:13:16 --- quit: kuvos (Client Quit) 10:16:26 --- quit: onetom_ (Read error: 101 (Network is unreachable)) 10:18:40 --- join: kuvos (C00K13S@cp12172-a.roose1.nb.home.nl) joined #forth 10:40:41 --- join: SolarFire| (SolarFire@pD9545EA0.dip.t-dialin.net) joined #forth 10:48:19 --- join: tathi (~josh@pcp02123722pcs.milfrd01.pa.comcast.net) joined #forth 10:55:27 --- quit: tathi ("messing with settings") 10:57:40 --- quit: SolarFire (Read error: 110 (Connection timed out)) 11:01:22 --- join: tathi (~josh@pcp02123722pcs.milfrd01.pa.comcast.net) joined #forth 11:37:30 --- join: topher (~chris@lsanca1-ar42-4-61-175-184.lsanca1.dsl-verizon.net) joined #forth 11:58:18 --- quit: jc ("Client exiting") 11:58:21 --- join: jc (~jcw@65.3.39.49) joined #forth 12:03:14 --- join: qFox (C00K13S@cp12172-a.roose1.nb.home.nl) joined #forth 12:20:36 --- quit: I440r ("Leaving") 12:36:06 --- join: madwork (~madgarden@derby.metrics.com) joined #forth 12:39:04 --- quit: Robert ("brb") 12:43:05 --- join: Robert (~snofs@c-bf5a71d5.17-1-64736c10.cust.bredbandsbolaget.se) joined #forth 13:19:05 --- join: I440r (~FooBlah@168-215-246-243.gen.twtelecom.net) joined #forth 13:20:05 --- join: Herkamire (~jason@h000094d30ba2.ne.client2.attbi.com) joined #forth 13:53:46 --- quit: qFox ("this.is.not a.real.netsplit") 15:05:22 --- join: SolarFire (SolarFire@pD9545EA0.dip.t-dialin.net) joined #forth 15:05:29 --- quit: SolarFire| (Read error: 54 (Connection reset by peer)) 15:07:54 --- join: crc (crc@0-1pool176-12.nas6.philadelphia1.pa.us.da.qwest.net) joined #forth 15:10:42 --- join: doublec (~doublec@coretech.co.nz) joined #forth 15:23:22 --- quit: madwork (Read error: 110 (Connection timed out)) 15:26:26 --- join: Topaz (~top@spc1-horn1-6-0-cust217.cosh.broadband.ntl.com) joined #forth 15:33:04 hmm 15:33:43 i'm not sure whether to make words such as + immediate, such that when executed they compile in a optimised assembly of themselves 15:35:40 I think that's a good idea. 15:35:57 Otherwise you might end up with a slower compiler. 15:36:22 Especially if you use hashed dictionaries or something like that for fast lookup 15:37:21 --- quit: crc ("Hacking...") 15:38:51 Well, you would want a version that didn't, so you can do an interpreted + as well... 15:39:30 currently my native-code : routine does all the optimisation 15:39:45 Either that or try playing with separate dictionaries. 15:40:42 there'll be a reasonable number of specific exceptions coded into : to handle various optimisations, but that's just to exploit the cpu instruction set 15:41:22 hi 15:41:46 hi slava 15:42:02 You could also do a run-time check inside the word. 15:42:05 I think I did that once 15:44:01 I just made it so my "immediates" are in a separate dictionary which isn't searched in interpret mode, only in compile mode. 15:52:49 i'm starting the long journey to making factor self-hosting. 15:52:57 i finally got pissed off at java performance and limitations 15:57:34 slava: how are you doing that? 16:00:10 tathi: writing a compiler in factor that converts a subset of the language into C 16:00:20 Ah 16:00:26 tathi: rewriting the interpreter, parser and other essential bits in this subset 16:00:33 Yup. 16:00:40 A la smalltalk or slate 16:00:43 yup. 16:00:59 very cool 16:04:29 --- quit: Topaz (Remote closed the connection) 16:05:52 hi slava 16:07:35 hey doublec 16:07:59 slava, I got a simple continuation based web example working. 16:08:49 slava, just a proof of concept really though. it allows showing a series of html pages but no form submission or expiry of continuations. 16:09:15 --- quit: I440r (Read error: 60 (Operation timed out)) 16:09:32 factor actually made it really easy. About 12 words worth. 16:12:18 wow 16:12:22 using the existing httpd? 16:12:30 yep. no changes to it required 16:12:37 you wrote a new responder? 16:12:42 yes 16:12:42 or .lhtml file? 16:12:46 A responder 16:12:49 ok 16:12:52 cool 16:12:59 i'd love to see it--can you send it to the conc list? 16:13:00 Acutally I developed it all in an .lhtml file so I could refresh that page to reload the new code. 16:13:19 Yep. Remember it's just a proof of concept. I'm going to flesh it out over the next few days. 16:14:17 too add a responder to the existing default ones I used code like: 16:14:45 "httpd-responders" get [ 16:14:45 [ 16:14:45 [ cont-responder ] "get" set 16:14:45 ] extend "cont" set 16:14:45 ] bind "httpd-responders" set 16:14:51 IS that an ok thing to do? 16:14:56 yeah 16:15:13 the "httpd-responders" set is redundant 16:15:19 namespaces are mutable 16:15:24 of course. thanks :) 16:16:07 I forgot that was the caes 16:17:38 I have a 'show' word that takes a quotation that returns the html string to display. That quotiation is executed with the a string on the stack which is an url that will resume from the end of the show call. 16:18:06 [ ...return-page1-string ] show [...return-page2-string...] show 16:18:12 ok 16:18:16 so it shows a sequence of pages? 16:18:25 will display two pages in a row when the user accesses the url on the first page 16:18:26 yes 16:18:42 And computations done between pages will be executed and state stored/restored as needed 16:19:05 Although not done yet, links can be added to other pages and sequences as required. 16:19:35 The back button will go back and forth between pages as expected and bookmarks can be used to remember where in the sequence you are. 16:20:12 So developing a web application becomes very much like writing standard applications. 16:21:58 cool. 16:26:50 What CRETIN didn't add support for Forth to etags? 16:40:37 ping doublec 16:41:46 slava, still here 16:41:57 slava, just getting ready to email the code to the list 16:42:13 doublec: i wrote an inner interpreter in C. 16:42:39 slava, cool! Faster I bet! 16:42:42 doublec: for one test its 2x as fast as the factor interpreter in java (and 2x as slow as compiled factor code) 16:43:11 doublec: i'm putting this project on hold for a while though. i'm not quite ready to dive into implementation of a self hosting language. 16:43:17 doublec: i'll post the source code for this though. 16:43:17 slava, interesting. Sounds promising. 16:43:28 slava: cool, I'd like to see it. 16:51:05 doublec: www.jedit.org/factor/CFactor.zip 16:51:11 doublec: its really almost nothing right now. 16:51:18 slava, thanks. 16:51:19 just a day's worth of C hacking by a complete C newbie 16:54:11 doublec: i have some comments on your coe 16:54:21 this is a bit more efficient: 16:54:33 : get-random-id ( -- id ) <% 16 [ random-digit % ] times %> ; 16:55:19 :) 16:55:19 hi 16:55:43 slava, thanks. Where is '<%' defined? 16:55:49 format 16:58:15 doublec: apart from that it looks very good! 16:58:16 ooh nice, I didn't know about that. Thanks. 16:58:50 also a note about the type system -- explicit >str is almost never needed, since each type has an implicit coercion to string 16:59:07 ok. thanks 16:59:29 I also need to make sure things like the 'exit' continuation are stored in a variable in a namespace pushed on the namespace stack I think 16:59:46 so that multiple 'flows' don't get in the way of each other 16:59:49 do you intend on developing this further? 17:00:19 the namestack is saved in continuations 17:00:19 I plan on making it more usable, definitely 17:00:19 so just handle each client in its own namespace 17:00:19 yep 17:00:19 each new client 17:00:37 what kind of web app would be a good sample to demonstrate this? 17:00:49 that would basically be the 'session' for the user (the namespace that is) 17:00:56 right. 17:01:08 Pretty much any 'wizard' style interaction where the user is led through steps. 17:01:30 When I do form submission and callbacks then any complex web application would work. 17:01:49 to do post requests just provide your responder with a "post" method 17:01:49 We use this style of server at work for business applications, database entry, point of sale, etc. 17:02:18 the post method takes the url like the get method, and you can also call read-post-request to get the request 17:02:23 how do I get to the post parameters? Do I need to extract them manually? 17:02:36 you get a url-decoded string 17:03:03 actually i think its broken with > 1 parameter right now. 17:03:10 ok. I plan to put the name/value pairs into a table and have that passed to the result of 'show'. 17:03:34 if you hack this up, can you do it at the responder level, so that read-post-request returns a namespace or alist of parameters? 17:03:36 This makes the code quite easy to read as you 'show' a page, then process the results of the form entry which are a onthe stack. 17:03:48 Yes, sure. 17:04:03 note that a table is a namespace that persists in the db 17:04:18 ok, just a namespace would be best for this then. 17:04:40 yeah. 17:04:47 Now if continuations could be stored in the db then the users session would survive server restarts. 17:05:00 a continuation is just a list 17:05:08 to persist, its elements must persist 17:05:10 Currently if the server is resarted only the initial entry point will work (I think). 17:05:11 which means stack instances 17:05:24 the problem is that often we have transient objects on the stack like network sockets. 17:06:02 yeah. It's not much of a problem as Seaside (a continuation based framework in Smalltalk) is the same. You can't persist continuations there either. 17:06:56 doublec: i have to go now. thanks for the hard work 17:07:13 slava, no problem, it was fun. cya layer. 19:12:04 --- join: kc5tja (~kc5tja@66-74-218-202.san.rr.com) joined #forth 19:12:09 --- mode: ChanServ set +o kc5tja 19:20:43 Hahaha 19:20:57 I love it when people walk by my drive way, and people just stare at my car as they go by. 19:21:04 It's like they've never seen an RX-7 before. 19:21:42 People stare at my pile of old computers. 19:33:54 self looks like a very interesting language 19:34:25 slava: Yeah, except for its GUI architecture, I think I like it a lot. 19:34:52 kc5tja: except for the GUI? the GUI is so deeply integrated with the language its almost the language 19:35:17 slava: Same with Smalltalk. Your point? 19:36:23 why don't you like the GUI? 19:36:31 i think the 'ideal' gui would be a mix of oberon and self. 19:36:34 hi 19:36:38 * arke is at a friends house 19:36:39 whats up? 19:37:11 slava: They should have stuck with a MVC GUI. 19:37:23 I think that the Self GUI is not at all very well factored. 19:37:26 kc5tja: why do they stare at the RX-7? looks like a sports car, nothing special .... 19:37:50 kc5tja: what's an example of a well factored GUI? classic smalltalk MVC? 19:37:55 slava: you should know about factoring, you wrote the languqage!@ :P 19:38:07 arke: Because it's a very unique looking sports car. 19:38:30 kc5tja: s/unique/sexy? :) 19:38:33 slava: That is the quintessential example of both good GUI design AND what factored code in a real-world environment looks like. 19:38:45 arke: If you interpret it that way... 19:39:06 kc5tja: what about gem? 19:39:45 kc5tja: I think it looks prettyn nice. 19:39:47 slava: GEM would make a good foundation for a GUI, but you still need things like widgets and the like. 19:40:06 oh 19:40:40 kc5tja: hrm... 19:40:43 you know what? 19:40:53 slava: As it stands, GEM alone is very basic, and you can make very basic GUI layouts with it. Functional, yes, but the application ends up being traditionally structured with your central event loop, and you responding to various events, etc. 19:40:54 * arke is considering writing a GUI for teh kestrel 19:41:06 maybe based off of RkG, but probablyh not, as RkG doesn't allow "Windows" 19:41:41 I'm planning a more or less PalmOS-like user environment for BoxForth when it's fully functional. 19:41:56 like, everything fullscreen except for modal weindows? 19:42:21 Yes, except I'm not planning on directly supporting modal windows. 19:42:41 good boy ;) 19:43:46 What do you mean "Good boy?" It's what I've been planning since day one. Read the back-logs. :D 19:46:57 ;) 19:47:32 I'm not too sure how possible it'd be to generalize the user interface into something resembling Ion though. 19:51:44 RkG is somewhat like Ion 19:51:48 A full blown pane/tab management interface would seem to me to require more traditional GUI-like architectures that I'm not 100% sure I'd like to have implemented at the ROM level just yet. 19:51:54 except ... bertter ;) 19:52:24 You're going to have to work really, really, really, really, really, really, really, really, really, really, raelly, really hard to beat Ion, dude...REALLY hard. 19:52:54 heh 19:53:04 completely 100% fullscreen, with a pad 19:53:07 ;) 19:53:31 (although I do plan to have _some_ window support, but it should be optional and nested if you want 19:53:38 because I find the idea of windows annoying as shit 19:53:38 With a "pad"? 19:53:44 yes, a pad :) 19:53:47 As in ColorForth style on-screen keypad? 19:53:50 I also hate the concept of mice 19:53:57 somewhat, yes, but not quite. 19:54:03 (you need to be specific; for all I know, a "pad" could be anything) 19:54:19 arke: You are aware that Ion can be used 100% without a mouse, right? 19:55:34 kc5tja: inde\ed. So can Rkg. So can evilwm 19:58:17 but yhou know what? 19:58:25 you know how they all have this accessibiility shit now? 19:58:32 like, onscreen keyboard foir the mouse? 19:58:38 a whole layher of bloat? 19:58:40 fuck them! 19:58:55 clikcking on the pad is the EXACT same as pressing the key 19:58:57 at the same level 19:59:00 without the bloat; 19:59:02 AND i 19:59:05 its much better 19:59:12 I have spoken. Hugh. 20:09:41 Without me having to read the manual, does gforth have a word level (high level) single-stepping debugger? 20:10:29 no idea 20:12:39 jc: Not that I'm aware of, no. 20:12:55 It does, it turns out. 20:12:59 dbg badword 20:13:19 However, since I needed it, it broke attempting to decompile a word. Foo. 20:13:24 http://www.public.iastate.edu/~forth/gforth_88.html 20:16:07 It does? 20:16:12 * kc5tja tries it. 20:17:03 It locked up my console!! 20:17:09 It don't work for me, that's for sure. 20:18:17 * slava is hacking on his C interpreter again. 20:18:25 experimenting with keeping 'top of data stack' in its own variable. 20:20:18 Kestrel 0.1.6 is available on the site now. No new features, but rather a code maintenance release. 20:21:06 I think I isolated all the big- versus little-endian code in the emu.fs file. So if you're compiling for PowerPC or 680x0 machines, it *ought* to work if you comment out the "include emu-little-endian.fs" file and uncomment "include emu-big-endian.fs". 20:21:22 But, alas, since I simply lack any sufficient hardware on which to test this out with, I won't know if this will work. 20:21:39 I suspect the single hardest part will be getting it to work with libSDL on a PPC box. 20:22:09 kc5tja: I'll try it out tomorrow, if Herkamire or someone else doesn't get to it first :) 20:22:30 tathi: Cool. 20:23:23 OK, the upgrade to Ion 2 was well worth it, despite the wonkiness of getting it running to start with. 20:23:33 slava, it'd be interesting to plug something like 'libjit' into the C interpreter and see what speedups could be gained from having the words jit'd to machine code. 20:23:45 kc5tja: That's good to hear...I've been thinking about upgrading Ion. 20:25:03 tathi: Yeah. It handles xmms almost flawlessly now. Which is really quite sweet, since that's the single biggest issue I had with it 20:26:19 doublec: the fact that code is stored in linked lists complicates the interpreter somewhat annoyingly. 20:26:52 slava, yes 20:27:10 tathi: What's interesting is that Ion 3 is already on the drawing board. :) 20:27:24 --- join: I440r (~FooBlah@216-110-82-1.gen.twtelecom.net) joined #forth 20:28:16 slava, is it consing and unconsing the main bottleneck? 20:29:37 doublec: there is no consing done in the inner interpreter 20:29:50 doublec: at the moment, the C interpreter uses conses for the stack though. soon it will use an array just like the java interpreter 20:41:50 slava, if you make the 'tag' for fixnums be '000' then you can do the primitive math and comparison operations without having to untag and retag the arguments. Since addition of the tagged numbers will 'just work' for example. 20:44:01 well at the moment conses are 000 20:44:13 its a tradeoff ;) 20:44:21 i'll try different approaches. 20:49:59 doublec: i'm not happy with my 'execute' function either. 20:50:43 slava, what don't you like about it? 20:52:52 the fact that one of the parameters to the XT is ignored by primitives 20:52:57 seems wasteful since everything is in terms of primitives 20:55:22 Is that the 'plist' parameter? 20:55:31 no the plist is not used by the interpreter. 20:55:43 the equivalent in the java code to the plist is the FactorWord object 20:55:51 ah, ok 20:55:51 it stores the word name and compiler flags 20:56:05 well in the C code its always null. 21:00:53 doublec: i'll have an array-stacks implementation ready in a bit. 21:03:41 kc5tja: hmm...I'm having trouble building gforth with the foreign function call interface. 21:03:50 Ah well, I'll leave it until tomorrow then. 21:04:12 --- quit: tathi ("work early tomorrow...") 21:16:21 http://www.voltsamps.com/pages/projects/railgun01/ slava == slava? 21:16:48 jc: no 21:16:51 i'm slava pestov :) 21:18:11 :) 21:30:49 slava, ahh, welcome to the Dark Side of C Forths. ;) 21:36:17 doublec: [ 30 fib ] executes 7 times faster in the C interpreter than the java interpreter. 21:36:37 doublec: same speed as jvm compiled almost! 21:36:38 slava, that's great! 21:36:44 oh sorry i measured it wrong 21:37:05 i was checking 28 fib in C and 30 fib in java :) 21:37:10 oops :) 21:37:31 C interp: 3.1 seconds 21:37:35 java interp: 7 seconds 21:37:41 jvm compiled: 1.2 seconds 21:37:59 The jvm is pretty good when compiled isn't it. 21:38:43 Over twice as fast as java interpreted is good. 21:38:55 considering that the java is jit'd. 21:39:04 the 'java interp' actually has + pred <= compiled 21:39:17 if those words are not compiled and do reflection calls, then it takes many minutes 21:47:11 i have to head off. talk to you later. 21:47:31 --- quit: doublec ("Leaving") 21:47:32 * arke should try Ion agian 21:47:47 * arke tried it a while ago for not toolong of a time 21:47:54 * arke doesn't quite remember .. lol 21:48:58 i tried gcc 3.4 with -O3 -march=pentium4 21:49:03 now my micro-benchmark runs in 2.3 seconds 21:49:09 that's almost as fast as the jvm compiled version 21:50:19 slava: -fomit-frame-poiunter 21:52:53 arke: seems to consistently improve it by 300 ms :) 21:52:56 ok this is good enough. 21:53:04 i have enough faith to continue tinkering with the C interpreter. 21:53:37 ;) 21:54:51 slava: basuically, all it does is not set up bp, and uses sp instead. 21:55:12 arke: i'd use -mregparams too but you have to recompile everything with it, and i'm not ready to give up libc just yet :) 21:55:17 slava: the latter is the same, the former is nicer, as it both uses less space, and avoids pipeline b0rk4g3 21:55:36 :) 21:55:44 -mregparams would be awesome. 21:56:07 thats the kind of thing I would use on a 486 or 386 ;) 22:01:29 I'd look to see if you're over-factoring code. There's no good reason the JVM should perform significantly better. 22:02:21 jc: the C interpreter is a simple indirect-threaded (sort of) stack machine, and it must perform dynamic type checks for each operand. 22:02:23 You should also see what happens with you statically link. If you're timing from startup, you may be getting bitten by link times. 22:02:37 the JVM is an incredibly complicated beast that optimizes and inlines code over time 22:04:20 :) 22:04:49 however, its not a good fit for factor -- it performs much better when static type info is given. 22:04:53 Also retry with -O2. Some people report better results with -O2 for some reason. 22:05:09 that benchmark i showed -- if you write it in java, with type declarations, it runs 100 times faster than my C interpreter, and faster than gforth etc 22:05:33 its a dumb benchmark 22:05:38 binary-recursive fibonacci :) 22:05:44 so its not really valid at all. 22:06:11 as soon as the C interpreter is a bit better, i'll be able to run more complex code in it 22:20:07 : putp push at pop swap ! ; 22:20:14 any siuggestions on how to make that better, maybe? 22:22:20 In particular, I'm trying to put stack mods to a minumum 22:24:43 nevermind, I just changed the order to make more sense :) 22:26:23 teehee yay 22:26:26 CF crashed again 23:03:38 --- join: snowrichard (richard@adsl-068-209-159-248.sip.shv.bellsouth.net) joined #forth 23:06:12 --- quit: snowrichard ("Leaving") 23:39:49 --- join: imaginator (~George@georgeps.dsl.xmission.com) joined #forth 23:59:59 --- log: ended forth/04.06.22