00:00:00 --- log: started forth/12.02.27 00:01:57 --- join: ttmrichter (~ttmrichte@61.184.206.85) joined #forth 00:01:57 --- mode: ChanServ set +v ttmrichter 01:41:59 --- quit: ttmrichter (Quit: Leaving) 02:00:39 --- join: DGASAU (~user@91.218.144.129) joined #forth 02:00:40 --- mode: ChanServ set +v DGASAU 02:04:42 --- join: ttmrichter (~ttmrichte@61.184.205.202) joined #forth 02:04:42 --- mode: ChanServ set +v ttmrichter 05:18:14 --- join: Backz (~backz@187.38.69.78) joined #forth 05:18:14 --- mode: ChanServ set +v Backz 05:20:59 can I run jonesforth or isforth on windows? 05:22:03 isforth is totally linux-specific 05:22:17 I dunno if anyone has ported jonesforth to Windows 05:22:41 The original was pretty unix-specific. 05:22:52 yes, gas 05:23:12 so where can I find a forth to run in windows? gforth? 05:23:23 or Win32Forth 05:24:01 Be careful if you're reading Jonesforth -- the author doesn't really know much about Forth so a lot of the things he says are inaccurate or just plain wrong. 05:24:02 thanks 05:25:28 I mean, it works, and it gives a good general idea of how a Forth system works. 05:25:50 so after it can I create my own? 05:26:41 Or you could just use an existing system. :) 05:27:35 Unless you have a particular niche where nothing exists, there's no real reason to write your own (not that that stops anyone). 05:28:09 forth on top of php 05:28:25 Huh. 05:28:42 OK. 05:29:55 I'd recommend that you use an existing system for a while before writing your own. Writing a Forth system doesn't teach you much of anything about using the language effectively. 05:30:14 And for all its simplicity, Forth has a lot of subtleties. 05:30:59 That's my two cents, anyway. 05:33:15 np, so you think I need start programming in forth first 05:34:33 Well, if you're trying to expand your horizons as a programmer, I think you'll get more out of it that way. 05:35:13 If you're just interested in learning how to write really trivial interpreters, then go ahead and dive into writing one. 05:35:56 where can I find a good tutorial to start in forth ? 05:36:50 Hrm...that's always the question. 05:37:37 Stephen pelc has a book at http://www.mpeforth.com/arena/ProgramForth.pdf 05:38:16 Starting Forth is available online as well. 05:38:46 That's dated, but if you skip over the bits about the internals and the editor and stuff, it's not a bad intro. 05:39:20 And there are some lessons on Forth and OpenFirmware on the OLPC wiki: http://wiki.laptop.org/go/Forth_Lessons 05:40:59 segher recently suggested "write something that you would do in a bash script, or Perl script, or small one-file C code, as Forth." 05:41:39 That's probably a good way to start -- pick some small things and write them in Forth, then ask for help/critique. 05:42:27 OK, I should get back to work. Good luck! 05:42:37 me too, thank you 06:10:07 --- join: nighty- (~nighty@static-68-179-124-161.ptr.terago.net) joined #forth 06:10:07 --- mode: ChanServ set +v nighty- 07:43:15 tathi: to be clear, i am suggesting writing something _you need_ in Forth, but something that would normally take you a few minutes to write 07:50:05 --- quit: ttmrichter (Quit: Leaving) 08:02:04 --- quit: nighty- (Ping timeout: 252 seconds) 08:18:58 --- join: nighty- (~nighty@static-68-179-124-161.ptr.terago.net) joined #forth 08:18:58 --- mode: ChanServ set +v nighty- 08:48:05 CREATE MINE 1 CELLS ALLOT 08:48:17 is this created on heap? 09:13:49 yup 09:18:18 huhuhu, Leo Brodie plays piano 09:18:23 --- part: href left #forth 09:35:41 --- quit: nighty- (Ping timeout: 252 seconds) 10:04:21 --- join: Kumul (~Kumul@67.224.230.59) joined #forth 10:04:22 --- mode: ChanServ set +v Kumul 10:12:53 --- join: nighty- (~nighty@static-68-179-124-161.ptr.terago.net) joined #forth 10:13:02 --- mode: ChanServ set +v nighty- 10:30:42 --- join: KipIngram (~kip@85.17.255.186) joined #forth 10:30:42 --- mode: ChanServ set +v KipIngram 10:32:04 How's life here these days? 10:33:01 Deformative been around lately? 10:36:56 --- join: MayDaniel (~MayDaniel@unaffiliated/maydaniel) joined #forth 10:36:57 --- mode: ChanServ set +v MayDaniel 10:47:04 * Backz slaps crc around a bit with a large trout 10:47:40 --- quit: Backz () 11:00:43 --- quit: MayDaniel () 11:06:23 backz: not on the heap no; in data space. 11:06:34 (there _is_ no heap in general) 11:07:27 That's strange assertion. 11:07:41 Where does "allocate" take memory then? 11:10:45 I thought it was "ALLOT". It just advances "HERE" (the next compile point) by the requisite amount and returns a pointer. At least on traditional systems. 11:12:09 "allot" doesn't return pointer on traditional systems. 11:12:31 (It is awful multiprocessing unfriendly interface.) 11:14:30 Well, you're right about that. You had to fetch HERE ahead of time and then ALLOT. 11:14:41 I agree - it wasn't envisioned as a multi-processing interface. 11:15:08 But the point, in the context of the discussion, is that there was no heap - there was a linear array of space that got used "straight through." 11:15:20 The simple modification like returning a pointer would make it much friendlier. 11:15:21 If you needed to clean up you just FORGOT and started over. 11:15:40 But sometimes CREATE had already done that, right? 11:15:53 These words were meant to be used as components of user-defined words. 11:16:02 So if you wanted what you described you built it. 11:16:02 "allot"? 11:16:42 I don't see reason to create a separate word to allocate cells. 11:16:48 What does that mean? Are you complaining about the word choice? 11:16:59 Once again - provide the low level tools needed to build anything. 11:17:07 allocating cells is al ow level function... 11:17:26 I mean that "allot" is horrible multiprocessing-unfriendly interface, 11:17:36 which could be easily fixed if anyone cared of it. 11:17:52 So fix it. This stuff is wide open for anyone to play with. 11:18:26 You need a multi-processing Forth, make one. 11:20:51 That's actually a good idea to go over my source and replace remaining "allot" invocations. 11:21:02 I do allocate memory differently already. 11:21:09 Ok - I noodled around a little. CREATE and ALLOT were definitely intended to work together, it seems. CREATE handled the pointer part and ALLOT handled the allocation. So your complaint becomes that in a multiprocessing environtment those would need to be atomic. 11:21:40 So, in the spirit of Forth "basic toolmanship" maybe the right answer would be to provide words to start and end an atomic block. 11:21:41 No. 11:21:46 Then you would get what you wanted like this: 11:21:55 They can be made athomic, but it doesn't help anything. 11:22:02 ATOMIC_ON CREATE ALLOT ATOMIC_OFF 11:22:15 Sure it does - it makes them function as one word from a multi-processing perspective. 11:22:18 The problem is that you need to lock memory between "here" and "allot". 11:22:35 That's what I meant by atomic, but I see your point. 11:22:54 Sorry - I was thinking multi-TASK - you are talking about multi-PROCESSING. 11:22:56 Fair enough. 11:23:21 The solution is easy, make another "allocate" that allocates memory like "here swap allot 0". 11:23:33 (And checks limits if necessary.) 11:23:58 What you want is for HERE to be modified before any other processor can access it, right? 11:24:30 Of course, the whole expression should be wrapped into mutex. 11:24:49 Here even simple spinlock should suffice. 11:24:57 Right. I'm with you. Yes, in a shared memory multi-processor something like that would be necessary. 11:25:55 In fact, that should be the primitive, "allot" being kicked out of standard. 11:25:56 However, the difficulties of implementing a really efficient shared memory (at least for more than maybe two processors) usually puts me off - when I consider parallel processing I usually give them each their own memory and some sort of nearest neighbors comm links. 11:26:00 Just like gets was kicked out. 11:26:07 (At last.) 11:27:03 Share-nothing architecture is actually not good option for Forth. 11:27:04 I don't worry too much over the standards. I just figure I'll build what I want whenever I want it. But I do understand that standards are important when one looks at the world in certain ways. 11:27:09 --- join: Backz (~backz@187.38.69.78) joined #forth 11:27:10 --- mode: ChanServ set +v Backz 11:27:11 Well... 11:27:20 http://home.iae.nl/users/mhx/sf2/sf2.html what do you think ? 11:27:33 SF is obsolete. 11:27:39 A shared read-only memory might be interesting. With local caches. Maybe. 11:28:10 Share-nothing architecture raises questions how you're going to spawn processes. 11:28:32 ASau: what was changed ? 11:28:38 You don't. 11:28:39 Backz: the world has changed. 11:28:47 You may end with fork and likes. 11:28:54 And it isn't particularly efficient. 11:29:18 Or you need to reify address spaces and provide access to those. 11:29:40 In my world one generally writes a superloop controller that just does everything the application needs. So it's really about raw processing power. How fast can you grind out opcodes? 11:30:00 so I'll keep reading Simple Forth 11:30:07 Handling unexpected stuff that requires sudden process spawning j isn't part of the picture. 11:30:41 This rules out fork/join parallelism. 11:30:53 --- join: MayDaniel (~MayDaniel@unaffiliated/maydaniel) joined #forth 11:30:53 --- mode: ChanServ set +v MayDaniel 11:31:24 One of few remaining potentially good parallelism models. 11:31:40 That's ok. In my applications one would use multiple processors in a very planned way - deciding ahead of time what each would do, balancing their loads, etc. Each would tend to what they were designed to tend to and that would be that. 11:32:30 One of the few remaining potentially good parallelism models for "arbitrary, unplanned" parallelism. What I mean by that is parallelism wheere you can't predict the distribution of workloads in advance. 11:33:00 I do real-time systems, and knowing exactly what to expect and planning for its coverage is a very important part of good design. 11:33:02 It is exceptional situation if you can predict. 11:33:20 Most situations in my world are predictable. 11:33:27 I think we just work in very different worlds, that's all. 11:33:44 I'm not claiming my glove fits everyone. 11:35:01 --- quit: Kumul (Quit: gone) 12:09:59 --- join: sunwukong (~vukung@catv-80-98-247-63.catv.broadband.hu) joined #forth 12:09:59 --- mode: ChanServ set +v sunwukong 12:22:48 --- join: Snoopy_1611 (Snoopy_161@dslb-178-004-030-045.pools.arcor-ip.net) joined #forth 12:23:02 --- mode: ChanServ set +v Snoopy_1611 13:54:29 --- quit: Backz () 14:00:34 --- quit: MayDaniel (Read error: Connection reset by peer) 15:58:56 --- quit: nighty- (Quit: Disappears in a puff of smoke) 16:12:13 --- quit: sunwukong (Remote host closed the connection) 16:56:27 --- join: Nisstyre (~yours@c-208-90-102-250.netflash.net) joined #forth 16:56:28 --- mode: ChanServ set +v Nisstyre 17:40:44 --- join: Kumul (~Kumul@67.224.230.59) joined #forth 17:40:44 --- mode: ChanServ set +v Kumul 18:49:48 --- join: nighty- (~nighty@69-165-220-105.dsl.teksavvy.com) joined #forth 18:49:48 --- mode: ChanServ set +v nighty- 20:31:53 --- quit: Kumul (Quit: gone) 21:07:34 --- join: ttmrichter (~ttmrichte@113.106.101.42) joined #forth 21:07:35 --- mode: ChanServ set +v ttmrichter 21:40:09 --- quit: ttmrichter (Quit: Leaving) 21:40:47 --- join: I440r (~zhiming@24-183-5-217.dhcp.fdul.wi.charter.com) joined #forth 21:40:47 --- mode: ChanServ set +v I440r 23:59:59 --- log: ended forth/12.02.27