00:00:00 --- log: started forth/09.12.26 00:30:53 --- join: ygrek (i=user@gateway/gpg-tor/key-0x708D5A0C) joined #forth 00:34:35 --- join: qFox (n=C00K13S@5356B263.cable.casema.nl) joined #forth 00:44:25 --- quit: mathrick (Read error: 54 (Connection reset by peer)) 00:44:35 --- join: __mathrick (n=mathrick@83.1.168.198) joined #forth 00:51:05 --- quit: ygrek (Remote closed the connection) 00:52:46 --- join: ygrek (i=user@gateway/gpg-tor/key-0x708D5A0C) joined #forth 00:59:54 --- join: GeDaMo (n=gedamo@dyn-62-56-89-110.dslaccess.co.uk) joined #forth 01:04:23 --- join: TR2N` (i=email@89.180.129.192) joined #forth 01:05:55 --- quit: TR2N (Read error: 60 (Operation timed out)) 01:18:46 --- nick: TR2N` -> TR2N 01:30:20 --- quit: PoppaVic (Client Quit) 02:25:33 --- nick: __mathrick -> mathrick 03:43:38 --- quit: pgas ("/quit") 04:45:38 --- join: cadar (n=Mats@c-f2f3e555.05-98-73746f1.cust.bredbandsbolaget.se) joined #forth 04:45:42 --- part: cadar left #forth 04:47:04 --- join: cadar (n=Mats@c-f2f3e555.05-98-73746f1.cust.bredbandsbolaget.se) joined #forth 04:47:39 --- quit: GeDaMo ("Leaving.") 05:47:03 --- quit: Al2O3 () 05:47:20 --- join: Al2O3 (n=Al2O3@c-75-70-11-191.hsd1.co.comcast.net) joined #forth 05:52:40 Is it possible to replace the current colon compiler with one that understands the lisp-syntax? Then using an extra stack for function calls. 05:53:17 --- join: Al2O3_ (n=Al2O3@c-75-70-11-191.hsd1.co.comcast.net) joined #forth 05:53:35 Yes, but why do you need it? 05:54:55 I think it would be a nice way to get more people to use forth. 05:55:07 I don't think so. 05:56:21 If someone wants Lisp, he wants Lisp, not Forth. 05:58:34 Postfix notation is the biggest hurdle. The current implementations of lisp is only for rocket scientists. I want to have a small one so I can modify it. 05:59:48 Postfix notation is fundamental to Forth. 06:00:00 If you don't want it, you should use anything else. 06:02:01 Your approach is that of annoying newcomers who don't 06:02:01 understand the language, don't understand rationale around it 06:02:01 yet they want to change, modify or "modernize" it in some way. 06:03:00 Forth does have problems, but postfix notation isn't among them. 06:04:08 ok, my real rational for trying it was so I can try implementing a doubled linked lisp, without global garbage collection. :) So it was not to change forth, but to be able to research lisp. 06:04:42 But you are right, I'm a newcomer. 06:05:06 I work in that area. 06:05:15 But I use single-linked lists for now. 06:05:46 And I use explicit memory allocation. 06:08:03 ok, have you tried some strategy for moving memory. I we have doubled linked list, that would be possible...Or? 06:08:24 --- quit: Al2O3 (Read error: 110 (Connection timed out)) 06:08:24 --- nick: Al2O3_ -> Al2O3 06:09:31 No, I don't move memory. 06:17:51 It would be interesting to move cells into the hot-memory-area, but only 1/10 of the time. A loop will move the used cells together.. after ten loops, every cell is moved. Compressing the memory depending on what cells are being used. Possible? 07:36:42 --- join: pgas (n=user@pdpc/supporter/active/pgas) joined #forth 08:01:02 --- quit: cadar () 08:01:35 --- join: cadar (n=Mats@c-f2f3e555.05-98-73746f1.cust.bredbandsbolaget.se) joined #forth 08:05:28 --- join: GeDaMo (n=gedamo@dyn-62-56-89-110.dslaccess.co.uk) joined #forth 08:06:14 --- join: xpololz (n=xpololz@90.80-203-124.nextgentel.com) joined #forth 08:30:53 --- join: pgas` (n=user@ppp089210043071.dsl.hol.gr) joined #forth 08:31:04 --- quit: pgas (Read error: 113 (No route to host)) 08:32:35 --- nick: pgas` -> pgas 10:08:52 --- join: Maki (n=Maki@dynamic-109-121-73-52.adsl.eunet.rs) joined #forth 10:32:28 --- join: PoppaVic (n=pops@adsl-99-69-199-131.dsl.sfldmi.sbcglobal.net) joined #forth 12:06:03 --- quit: Al2O3 (Remote closed the connection) 12:06:18 --- join: Al2O3 (n=Al2O3@c-75-70-11-191.hsd1.co.comcast.net) joined #forth 12:26:35 --- join: haiworld (n=haiworld@219.89.222.147) joined #forth 12:28:50 anyone having any luck building pforth these days? 12:29:00 I get a Inclubing: system.fth and it segfaults for me. 12:29:03 Including even. 12:30:43 Yes. 12:30:59 uname -m, please? 12:31:06 Seems that file is missing. Pulled some http://pforth.googlecode.com/files/pforth_v24_090220.zip 12:31:11 x86_64 12:31:21 You're out of luck. 12:31:26 Use 32-bit compiler. 12:31:39 Ok. I'll see if that makes the file appear (: 12:33:09 * schme tries on a 32bit machine. 12:34:32 Just in case you didn't know it, you get your 32-bit compiler by 12:34:33 Is this system.fth generated during make or what? 12:34:45 ./build.sh -m 386 -T /usr/tools -O /usr/obj tools 12:34:58 I'll return in a bit. 12:35:18 I guess so. 12:45:20 No, it isn't generated. 12:46:45 Remind me about pforth after Q4. 12:48:30 ASau: Hmm. ok. build process said it was missing when I ran it on this x86_64 12:49:13 I don't remember details, but I modify pforth for some reason, 12:50:36 Ok. 12:50:43 Well my aim was to run it on arm, and it runs. 12:50:48 lack of gforth and all (: 12:51:01 now I just need tho stupid bell to actually bell 12:51:12 ? 12:51:18 * PoppaVic snicker 12:51:43 echo -e '\a' is not belling for me. 12:51:49 Ah. 12:51:53 uname -s? 12:52:00 is angstrom linux. 12:52:06 Hm. 12:52:19 There you're on your own. 12:52:23 yer using escapes, so you need the driver that knows them ;-) 12:52:38 ASau: there's a funny thing actually. Seems that in new fresh linux installs + X then xbell is just fuckered anyway. Good thing it works in netbsd. 12:53:01 PoppaVic: ? 12:53:42 now if I could run the netbsd on my terrier (: 12:54:05 the terminal needs to know those. ANSI escapes, or vt100+, or ecma, etc. Otherwise, it's just another character - as usual. 12:55:00 PoppaVic: I believe my terminal knows 'em. 12:55:11 OK. 12:55:37 But how would I check, eh? 12:55:50 TERM is the same as other places where it works. 12:56:13 you'd check the terminal manpage, xterm and such are primitive to extremes 12:56:36 I don't even have X running. so no xterm manpage :) 12:56:40 just vc 12:56:45 Does typing Ctrl-G get you a beep? 12:56:47 might even be an option to the terminal - same thing. 12:56:50 GeDaMo: no. 12:57:17 schme: why don't you use NetBSD if it works better? 12:58:23 ASau: It doesn't on this device. 12:58:24 schme: what about printf '\a' ? 12:58:28 no. 12:58:39 "No" what? 12:58:41 No printf? 12:58:47 printf '\a' doesn't beep for me. 12:58:52 Hm. 12:58:56 I'll just rewrite bell to spit stuff at /dev/audio 12:59:15 or maybe I'll openbsd the sucker and hope it works 12:59:25 What's wrong with evbarm? 13:01:03 Maybe the linux kernel is build with pcspkr disabled. That'd be funny. 13:01:05 evbarm? 13:01:29 last time I checked netbsd was pretty not working on the zaurii 13:01:39 zaurus? 13:01:45 c3200 13:01:57 Did you try on mailing lists? 13:02:23 long time ago. 13:02:38 oh I see it is supported since 2006 13:02:44 well that's excellent. 13:05:24 I wonder if it will need linux to boot it. 13:08:49 * ASau wonders if we'll see pkgsrc bulk builds for zaurus platform in future. 13:10:09 Does pkgsrc support some crosscompilation? 13:10:28 * schme is looking for netbsd on terrier install instructions. 13:11:30 "Some" cross-compilation support exists. 13:11:57 heh :) 13:12:04 It would be nice to have it anyway. 13:12:08 actually building stuff *on* the Z is hell on earth. 13:12:16 :D 13:12:36 I have been using scratchbox to do things. It has neat "remote execution" for things that qemu doesn't.. quite do. 13:12:51 like having clisp build its lisp bits 13:14:21 I think I will mail the port maintainer and ask where I find install instructions. 13:16:44 Sure. 13:17:47 installing obsd on it is a bit of long outdrawn pain. I guess netbsd will be much the same. (: 13:20:56 --- quit: GeDaMo ("Leaving.") 13:34:06 a 'tis troublesome. the netbsd port does not support the usb controller 13:54:47 --- quit: Maki ("Leaving") 14:30:21 --- quit: haiworld (Read error: 60 (Operation timed out)) 14:36:02 --- quit: pgas (Read error: 113 (No route to host)) 14:40:56 --- quit: qFox ("Time for cookies!") 14:58:25 --- quit: ygrek (Remote closed the connection) 15:31:14 --- quit: cadar () 15:36:43 --- join: segher_ (n=segher@84-105-60-153.cable.quicknet.nl) joined #forth 15:44:03 --- quit: segher (Read error: 110 (Connection timed out)) 15:48:14 --- join: alex4nder (n=alexande@209-188-124-175.taosnet.com) joined #forth 15:48:15 hey 16:00:05 evening 16:00:13 very late evening in fact 16:03:09 how's it going? 16:04:02 I've understood why there's so many "dynamic memory 16:04:02 allocation is bad" propaganda among forthers. 16:04:44 Hmm? 16:05:12 PoppaVic: You don't like the explanation. :p 16:05:31 Say on.. My code is makin' me nuts, and the bbq sauce is simmering. 16:06:29 Because writing generic memory allocator isn't trivial, 16:06:30 and forthers can't solve any non-trivial problems. 16:07:23 Interesting.. So.. Anyone using forth is trivial - as are their problems. 16:14:24 haha 16:17:03 I don't think a dynamic allocator is that necessary unless you're more disconnected from your machine. 16:17:10 e.g. Lisp 16:18:42 depends on wtf a "dynamic allocator" means, just like "generic memory allocator". 16:19:58 malloc/free is what I'm thinking. 16:20:27 for shame.. Evil C-speak. 16:20:47 These terms are common to all languages, if they're unknown 16:20:48 to forthers this means that forthers didn't ever encounter 16:20:48 problems of middle complexity. 16:21:17 Even Fortran programmers know dynamic memory allocation. 16:30:43 ASau: well, you carry on with the fantasy's.. Mail the std-commies. Write to Forth, Inc. and the others.. 16:30:58 *tansies 16:44:16 --- quit: garfield_ (Read error: 110 (Connection timed out)) 16:45:07 --- join: garfield_ (n=uwekloss@p548649ED.dip.t-dialin.net) joined #forth 16:51:57 The code from pre-dlmalloc times is damn awful. 17:12:49 asau: i think it has a lot to do with that dynamic memory allocation in any embedded app is always wrong 17:14:01 segher_: in fact that's because Doug Leary's work seems to pass unnoticed by Forth community. 17:14:43 segher_: notice that it is always argued that when you need 17:14:43 to allocate memory dynamically, you should write fixed-blocks allocator. 17:14:58 nah. it is simply *always wrong*. 17:14:59 Cf. what Rather repeats from time to time on clf. 17:15:12 You're wrong. 17:15:25 It shows again, that you don't write complex code. 17:15:32 --- nick: segher_ -> segher 17:15:48 erm. you haven't ever seen my code, i suppose. 17:16:10 --- quit: rotty (farmer.freenode.net irc.freenode.net) 17:16:13 If I were to follow general forther's advice, I'd have 5 or 17:16:13 6 different memory allocators for our embedded systems. 17:16:33 C programmers for embedded systems do the same 17:16:45 C programmers for *non*-embedded systems do the same 17:16:57 This is _proved_ inefficient. 17:17:00 Long time ago. 17:17:06 whatever. 17:17:47 That's what I say, you don't know the report and you argue against it. :) 17:18:31 you are saying that you have a program that can predict the future. i think i'm done talking 17:19:15 I say that if program cannot predict the future, it is better to use generic memory allocator. 17:19:43 If you have more than 3 different kinds of objects, 17:19:52 it is better to use generic memory allocator. 17:21:38 it is better to use an allocator that is a good fit for your allocations. which a custom one *by definition* is. 17:21:40 --- quit: yiyus (farmer.freenode.net irc.freenode.net) 17:21:42 --- join: rotty (n=rotty@nncmain.nicenamecrew.com) joined #forth 17:22:01 By definition it isn't. 17:22:05 --- join: yiyus (i=12427124@je.je.je) joined #forth 17:22:16 and you totally miss the point, anyway. you should *not have* dynamic allocations, if you can avoid it 17:22:28 It is you who totally miss the point. 17:22:32 no. *by definition* something that is better, is better. duh. 17:22:49 It is _not_ trivial task to write _good_ memory allocator. 17:23:04 Hand-written one is _bad_ in practice. 17:23:08 it is impossible. and you can prove that. 17:23:40 if you *know* what data you are going to get, it is easy to write an allocator that does much better than whatever *generic* allocator does 17:24:09 I fail to see the point to yer nonsense, ASau. I really don't. I want a magic memory inventor. Mem is infinite. 17:24:26 Even when you know what data you use, it is still _non-trivial_. 17:24:40 nonsense 17:25:20 Alright, write me efficient memory allocator for 13 different types of objects. 17:26:39 We'll see how you succede, if you do at all. 17:26:53 you're not listening. fine. whatever. 17:27:10 I do. 17:27:18 i'm sure you like arguing, but i have better things to do. mmmh, wine 17:27:21 It's you, who are ignorant of results of past. 17:27:52 As if folks who did measurements, are idiots. 17:37:26 BTW, sometimes it is really amusing to see stubborness, 17:37:26 when you tell forthers that there're evidences that their 17:37:26 beliefs are wrong, and they start calling their beliefs "definitions". :) 17:37:26 Somewhat reminiscent of Aristotlian 8-legged flies. 17:40:04 Dude. I think you've got head-trauma. I came to forth late. I tinker in it. I don't find it an insult. 17:40:43 What else do you think? :D 17:58:33 * madgarden is back (gone 77:19:25) 18:02:06 ASau: I've found that in professional development, there is no such thing as a perfect general dynamic memory allocator. Each system has problems. 18:02:40 for most of the carrier-grade email server software I worked on, we had different allocators depending on which part of the software you were working on. 18:02:53 e.g. the IMAP server had a different implementation of malloc/free than the message-object server. 18:03:13 malloc is already a "generic allocator". 18:03:23 malloc is a name, it can be whatever you want. 18:03:33 and we on a regular basis switched it out after profiling. 18:03:56 primarily because of 3rd party libraries that just called 'malloc' and 'free' 18:04:13 that if you used Solaris' libc implementation, your world sucked. 18:04:33 I am to support Solaris to some extent. 18:04:38 Yes, I know that it sucks. 18:04:58 also you may use a different allocator if you're debugging, vs. running in production. 18:05:12 such is life. 18:07:28 The problem I was talking about is that there _is_ result 18:07:28 of early 90s, when people did measure efficiency of using many 18:07:28 custom allocators vs. using generic one, and found gain either 18:07:28 insignificant or even loss in performance. 18:08:01 E.g. there's work of Doug Leary. 18:08:26 Note, that writing and maintaining a dozen of custom allocators is another issue. 18:09:25 Another interesting fact is that Forth implementations use libc malloc. 18:10:51 Even when there is use for the one specific to the language. 18:11:45 --- join: haiworld (n=haiworld@219.89.222.147) joined #forth 18:12:35 ASau: I don't know about his work, but I can say that even in my own work, I've seen a major improvement when using a custom allocator in certain circumstances 18:13:06 There're always certain circumstances. 18:14:30 I have two applications (embedded) that do garbage collection in real time. 18:14:42 Of course those are custom allocators. 18:15:25 --- quit: Frek (farmer.freenode.net irc.freenode.net) 18:17:06 what language is your garbae collector for? 18:17:08 Yet they are there because original developer failed to 18:17:08 write correct code at all, not only in memory management. 18:17:11 C 18:18:06 It was easier to collect garbage than to rework everything under time pressure. 18:18:14 --- join: Frek (n=nnnmacbo@81-225-142-146-no36.tbcn.telia.com) joined #forth 18:18:47 ah, damn. 18:19:37 It is the only useful feature of custom allocator used: 18:19:54 that you know data structure and can apply g/c techniques. :D 18:21:33 Other features used are horrible inflexibility and horrible adaptivity, 18:25:20 --- quit: Al2O3 () 18:25:53 --- join: Al2O3 (n=Al2O3@c-75-70-11-191.hsd1.co.comcast.net) joined #forth 18:27:08 --- quit: Al2O3 (Client Quit) 18:27:16 * alex4nder just figures out that ]] .. [[ exist. 18:27:25 --- join: Al2O3 (n=Al2O3@c-75-70-11-191.hsd1.co.comcast.net) joined #forth 18:27:45 some places 18:32:54 Yeah, those are nice things. 18:35:17 anyone have any good examples of a network Forth listener in gforth? 18:36:21 "Good" ha! 18:36:33 Wait, I may have it somewhere around. 18:41:38 I have some old test code here, 18:41:51 it uses _very_ old FFI from 0.5.0 times. 18:41:53 Do you need it? 18:42:43 Also it may be FreeBSD/i386 specific. 18:54:11 --- quit: xpololz ("Leaving") 18:59:29 --- quit: ASau (Read error: 54 (Connection reset by peer)) 19:07:34 --- join: TR2N` (i=email@89-180-198-214.net.novis.pt) joined #forth 19:11:59 --- quit: TR2N (Nick collision from services.) 19:12:02 --- nick: TR2N` -> TR2N 19:13:39 --- join: ASau (n=user@83.69.227.32) joined #forth 19:14:48 --- quit: segher ("This computer has gone to sleep") 19:58:25 hey 19:58:40 Ah! 19:58:45 So, do you need it? 19:59:14 Well... Basically, it is similar to what you do in C. 19:59:33 You do the same, only via FFI. 20:02:30 I've got some socket code working, I was mainly looking for how you handle the quit loop 20:30:52 --- join: _c_ (n=_c_@99-61-160-133.lightspeed.sntcca.sbcglobal.net) joined #forth 20:39:32 <_c_> hello 20:40:06 --- quit: _c_ ("Leaving") 22:03:08 --- join: Al2O3_ (n=Al2O3@c-75-70-11-191.hsd1.co.comcast.net) joined #forth 22:06:37 --- quit: Al2O3 (Read error: 110 (Connection timed out)) 22:06:37 --- nick: Al2O3_ -> Al2O3 22:11:09 --- join: xpololz (n=xpololz@90.80-203-124.nextgentel.com) joined #forth 23:10:22 --- quit: alex4nder ("leaving") 23:49:29 --- join: pgas (n=user@pdpc/supporter/active/pgas) joined #forth 23:59:59 --- log: ended forth/09.12.26