00:00:00 --- log: started forth/21.05.29 00:44:41 --- join: Glider_IRC__ joined #forth 00:47:50 --- quit: Glider_IRC_ (Ping timeout: 252 seconds) 01:36:26 --- quit: proteus-guy (Ping timeout: 246 seconds) 01:49:12 --- join: proteus-guy joined #forth 04:42:09 --- join: andrei-n joined #forth 04:53:24 --- quit: andrei-n (Quit: Leaving) 05:05:12 Asau really drove away anyone interested in forth. He used to be a quite brilliant valuable resource for #forth and then he went super sour on it. Was unfortunately. Only person I ever had to ban. 05:10:39 --- mode: ChanServ set +o proteusguy 05:10:46 hey - still works. ;-) 05:11:04 who wants to be #2? :-) I have the power.... 05:11:25 (how do I turn this off btw...?) 05:13:11 /msg chanserv deop #channel nick 05:14:46 --- mode: ChanServ set -o proteusguy 05:15:02 hexagon5un - thanks. 05:15:10 --- mode: ChanServ set +o proteusguy 05:15:14 --- mode: ChanServ set -o proteusguy 05:15:25 but also /msg chanserv help :) 05:15:43 banning across the bridge might be a problem 05:15:53 hexagon5un - er... not so much. 05:15:55 but as long as we have OPs on both sides, it shouldn't be much of an issue. 05:16:27 siraben - we've really never had such a problem in #forth and I don't anticipate it starting any time soon. 05:17:06 proteusguy: not so much what? 05:17:41 hexagon5un - the following is the entire response I got: ">chanserv< help" :-) 05:17:55 ChanServ, probably 05:18:56 It's ok - I prefer to depend on the kindness of hexagon5un rather than an irc bot anyhow... 05:19:00 case sensitive? 05:19:09 :) 05:20:39 help works for me 05:20:58 (on both libera.chat and freenode) 05:22:16 --- quit: Zarutian_HTC1 (Ping timeout: 272 seconds) 05:26:00 Aw, they changed MOTD recently for Freenode so you can't see the number of regged nicks 05:56:54 --- join: Zarutian_HTC joined #forth 06:06:48 re: bans; we never had to ban many so I'm not too worried about this. If the need arises, I can ensure a ban exists on both networks 06:08:28 re: ops; anyone w/ops in freenode that's also registered on libera should have ops. 06:09:05 At the moment I think that's just me and KipIngram 06:42:46 --- quit: MrMobius (Remote host closed the connection) 06:44:21 --- join: MrMobius joined #forth 07:12:13 --- quit: proteus-guy (Ping timeout: 260 seconds) 07:24:18 --- join: proteus-guy joined #forth 08:01:15 --- join: iv4nshm4k0v joined #forth 08:19:36 --- quit: Zarutian_HTC (Ping timeout: 272 seconds) 08:50:36 --- join: Zarutian_HTC joined #forth 08:51:42 crc just you and kip what? :) 08:51:56 oooh right 08:52:15 dont need to op me in liberia, im never going over there :) 08:54:39 enjoy being freenode's final user :P 08:54:59 if it comes down to that ill either leave irc or move to a different network 08:55:21 i will never go to liberia. they deliberatey sabotaged the community because their collective pussy hurt 08:55:46 the old staff i mean 08:55:49 not the people who left 08:55:53 well.. some of them too 09:13:01 i hope we transition to turning the bridge off eventually 09:13:50 so people can pick one or log into both 09:29:33 the bridge is a "bad" solution to a much worse problem. being "bad" does not mean being objectionable, it keeps us togehter and thats important :0 09:29:47 and we did not cause the worse problem 09:32:12 it's a good solution in the short term 09:32:24 so thanks for putting it together 10:14:52 --- quit: wineroots (Remote host closed the connection) 10:15:28 --- join: wineroots joined #forth 11:00:33 --- quit: Zarutian_HTC (Ping timeout: 265 seconds) 11:19:49 by "bad" i meant "the only one available to us" lol 11:20:00 it IS a good solution, it keeps us in the same room when were not in the same room :) 11:20:05 its like a little intercom 11:20:26 i think bots should be voiced so we know who they are lol 11:20:53 --- mode: ChanServ set +o mark4 11:20:57 I have no objection to that 11:20:57 --- mode: mark4 set +v clog 11:21:06 im not instituting a rule lol 11:21:08 just an idea 11:21:29 i think a serious number of idlers in here are just bots :P 11:21:50 i just manually voiced clog because he is a long time member of the channel :) 11:22:25 --- mode: crc set +v cbridge-freenode 11:22:55 There should be a mode for bots 11:23:02 ya 11:23:05 +b lol 11:26:16 FWIW, at least ngircd has +B for botsâ¦ 11:26:31 https://ircv3.net/specs/extensions/bot-mode 11:26:38 ooh i just went into channel services here and suggested +B for bots lol 11:26:48 i never even knew it was an actual thing elsewhere 11:27:21 if i do /mode #forth +B clog will it make it +b instead lol 11:27:28 lets try 11:27:59 nothing happend 12:00:27 --- quit: Bogen85 (Quit: Leaving) 12:01:52 --- join: Bogen85 joined #forth 12:01:53 --- mode: ChanServ set +v Bogen85 12:02:30 --- quit: Bogen85 (Client Quit) 12:03:40 --- join: Bogen85 joined #forth 12:03:40 --- mode: ChanServ set +v Bogen85 12:34:51 --- join: Zarutian_HTC joined #forth 12:44:40 --- join: Glider_IRC_ joined #forth 12:44:44 --- quit: Bogen85 (Quit: Leaving) 12:45:24 --- join: Bogen85 joined #forth 12:45:24 --- mode: ChanServ set +v Bogen85 12:46:04 --- quit: Bogen85 (Client Quit) 12:46:37 --- join: Bogen85 joined #forth 12:46:37 --- mode: ChanServ set +v Bogen85 12:47:45 --- quit: Glider_IRC__ (Ping timeout: 246 seconds) 15:14:03 --- quit: Zarutian_HTC (Ping timeout: 260 seconds) 15:22:15 If I want to use a resizable (or rather growing) memory buffer, I guess I'll have to go with ALLOCATE/FREE and not ALLOT, right? 15:22:54 Well, does the standard say anything about ALLOT? 15:23:25 The main problem you'll run into there is that most systems are going to put stuff immediately after the ALLOTed buffer, when you define stuff after the ALLOT. 15:23:27 yea allot is not intended to be deallocated later 15:23:33 x4 has a memory manager built in 15:24:00 A fixed page size memory manager is pretty simple to whip up. 15:24:08 if you are using linux you can also just call the mmap and munmap system calls directly 15:24:17 Yes, I might allot other things later, and when I want to grow the previous buffer, I would have to move everything else up (and fix their pointers, which sounds hairy). 15:24:18 In my last Forth I had HEAP to give me a page and -HEAP to free it. 15:24:24 But - it was fixed size. 15:24:31 efficiency is the problem lol 15:24:42 Memory management gets a lot more involved when you want variable size. 15:24:47 if you want to have a chess program evaluating 2874965923546929845629346592734524 positions a second... :) 15:25:10 I was just writing a simple code editor, and I need to grow the buffer that holds the text as user inserts more characters :) 15:25:23 --- join: Zarutian_HTC joined #forth 15:25:45 Ah, so it's not a "block" editor? 15:26:00 I guess I'll go with ALLOCATE/RESIZE, and not dictionary as I wanted it to be. 15:26:03 I've only implemented block editors in Forth, but I think I'll eventually support the concept of a file in this one. 15:27:07 My simple block editor regards each 4 kB block as 64 lines of 64 characters each. 15:27:12 There is no notion of "newline." 15:32:52 People complain that that wastes space, but we're beginning to see SSD's that have built in hardware compression - that solves that problem. 15:36:22 64 lines... only block editor I was was 1K blocks... 16 lines x 64 columns 15:36:29 I used... 15:36:48 it had shadow blocks for documentation 15:36:52 Right - I've done that in the past, but the last few Forths I've written I've opted for 4kB blocks instead of 1kB. 15:37:28 I thought about shadow screens, but instead I'm going to implement a "link" capability that lets me link comments and other documentation to points in the source. 15:37:54 I typically undercomment, because I don't like how the inline comments make my source look. So I'm arranging to put the comments somewhere else. 15:38:05 yeah, 4k is much better. plus that is the standard sector size on drives now 15:38:15 Shadow blocks would be a more minimal approach to that, but I'm going to be a little fancier. 15:38:30 You can get a surprising amount of functionality in a 4kB block. 15:38:41 My whole source editor is almost exactly one block of source. 15:39:06 This time it will be bigger, to support these links and so on, but it was a perfect size for the last one. 15:39:09 if your word can't fit in 16x64... you are doing something very wrong... 15:39:28 Oh, that's not one word. 15:39:39 It's a collection of words supporting an application. 15:40:01 Ultimately I guess I do have a word "edit," but none of my definitions are more than one line. 15:40:15 These days my defs average 35-45 characters each. 15:40:30 Amd ot 15:40:35 yes, but what I mean is, if you have a word that needs to be be bigger than a block, you are doing something wrong.... (not you, but whoever would do that..) 15:40:45 And it's more probable that one outside that range is shorter rather than longer. 15:41:29 I agree with you - I think having larger amount of space than that would be more to group a collection of related words together. 15:41:44 yeah 15:41:52 But I'd regard that as a frill - 4kB blocks are very adequate. 15:42:21 I've gotten pretty intensely into the "factor, factor, factor" philosophy. 15:42:59 if you unit test then factored like that is much easier 15:43:02 Very intolerant of long definitions, and I imagine I've reached the point where I'll just refuse to accept one that doesn't fit on a 64 char line. 15:43:06 I'll think some more. 15:43:13 Yes. 15:43:50 I'm already disliking a definition if it goes over 50 or so. 15:44:20 It's like a ugly wart sitting there poking out past the end of all of its 35-45 char neighbors. 15:47:49 Bogen85: In the last Forth I implemented, and the one I'm doing now, I've invested in a rather large set of conditional return words. I don't even have IF ... THEN; instead I factor ... into a word and put a conditional return at the beginning. Etc. 15:47:55 --- join: Keshl joined #forth 15:48:02 It has definitely shortened my defs. 15:48:41 yeah 15:48:48 I've got a similar set of conditional recurse words, and between those two facilities I have none of the conventional control structures. 15:49:15 The only place I ever "loop back" to is the beginning of the definition. 15:49:45 But I can put entry points within a defintion, like 15:49:52 : foo ... : bar ... ; 15:50:07 And the "loop back" inside that second ... would go to bar, not foo. 15:50:15 Just whatever is most recent. 15:50:25 --- quit: Zarutian_HTC (Read error: Connection reset by peer) 15:50:38 --- join: Zarutian_HTC joined #forth 15:50:51 And I can do "temporary" definitions using .: instead of : 15:51:10 They get created as normal defs, but there's a word .wipe that will go back and unlink them all from the dictionary. 15:51:29 So if I do need a recursion target in the middle of a word I can have one. 15:51:44 I usually write that kind of stuff on two lines, though. 15:51:59 Generally have only one word name per line, at the beginning. 15:54:31 So .: just sets an additional bit in the header, and .wipe just traverses the CURRENT vocabulary and cuts out words with that bit set. 15:55:06 Some of my facilities, like NUMBER and FIND, have just one permanent word and a whole slew of "helper words" that I get rid of after getting the main word defined. 15:55:48 I regard an ability like that (somehow) as necessary support for the "factor factor factor" philosophy. Otherwise factoring generates a lot of noise. 15:59:31 I agree on hiding helper words to avoid noise :) 16:04:58 I usually only write in MUF and this is the first time I've seen anyone write in a syntax that looks even vaguely familiar and I'm so happy. o_o 16:17:10 :-) 16:20:46 --- quit: Keshl (Quit: Konversation terminated!) 16:58:30 maw 17:04:24 --- quit: wineroots (Read error: Connection reset by peer) 17:20:36 Hey dave0. 17:21:04 Good evening dave0 17:22:38 maw KipIngram, crc 17:24:38 --- quit: cbridge-freenode (Remote host closed the connection) 17:24:50 --- join: cbridge-freenode joined #forth 17:42:58 --- join: wineroots joined #forth 17:58:46 --- join: Keshl joined #forth 19:10:40 --- quit: sts-q (Ping timeout: 272 seconds) 19:17:02 --- join: sts-q joined #forth 19:34:39

can forth work as a web language? for dynamic website? 19:36:09 yes, I've heard of it before 19:37:57 https://github.com/urlysses/1991 19:38:16 http://www.1-9-9-1.com/ 19:40:53 aha 19:41:13 I cannot find any documentation whatsoever for gforth's tasker.fs 19:42:42 and I am unfortunately not knowledgeable enough in forth to look at it and understand how it works 19:45:35 I see code in there that looks like linked list management. When I was thinking about task management I envisioned a ring of tasks - that may be what they are establishing there. 19:45:52 I'll keep looking it over and see if I can glean anything; that was just a vague first impression. 19:46:23 ah, thanks 19:56:29 Yeah, it looks like a lot of the words move a task from its "current" linked list into a different linked list. Looks like there's a list called "sleepers" that has all the tasks that are not getting immediate attention. 19:57:10 sleep put a task into that list. wake puts it on an active task ist, that seems to be called "next-task." 19:57:42 --- quit: Bogen85 (Remote host closed the connection) 19:58:08 --- join: Bogen85 joined #forth 19:58:08 --- mode: ChanServ set +v Bogen85 19:58:24 concrete-houses: I've done web apps in Forth 19:59:56 It looks like the first cell of a task data structure holds the link to the next task in whatever list it's in. 20:00:26 Down near the bottom there's a word to check if only one task is running, and it does that by saying next-task dup @ = 20:00:55 oh, I see 20:01:08 Picture that for a minute. next-task puts the address of the task descriptor on the stack. we duplicate it, fetch its first cell, and see if the contents is equal to the address (i.e., does it point to itself). 20:01:39 NewTask I'm sure allocates a sort of structure. Looks like there are slots for all the stack pointers to be stowed. 20:02:24 I'm not clear yet on the overall memory allocation. Somewhere there has to be memory allocated for those stack pointers to POINT AT for each task. 20:02:35 Since they all have to have their own stacks. 20:02:56 I think that's all I can get from a cursory examination. 20:03:00 Maybe I'll have more later. 20:03:23 isn't it allocated where it says 20:03:40 well, it seems that you pass a stack size to 20:03:44 NewTask 20:03:48 and then it allocates it right there 20:05:45 Ah, ok - that makes sense - that's where you'd want to do it, isn't it? 20:06:06 And there must just be an "understanding" in the code as to where the various stacks are in that region. 20:06:46 Anyway, I've written linked list code for Forth from scratch several times over the years, and I've long been of the belief that there's just one "nice" way to do it, and a whole lot of ugly ways to do it. 20:06:46 http://rosettacode.org/wiki/Concurrent_computing#Forth has an example using tasker.fs 20:06:54 I am trying to write a TCP server program in forth. to get my bearings, though I am writing a simple echo server. I was wondering if I could use tasker.fs to allow it to serve multiple clients at once 20:06:58 I just saw some stuff there that reminded me of that "right" code. 20:06:58 ah, interesting 20:07:21 That seems like exactly the kind of thing it would be meant for. 20:07:32 That's a nice training problem. 20:07:49 I still have not addressed, however, the bug where it will serve only one client and then not accept any more 20:08:04 I'm working on a Forth now that I eventually want to run on bare metal, so it's highly likely I'll have a similar task to deal with at some point. 20:08:15 ah, interesting 20:08:15 It's a long way from actually BEING bare metal right now, though. 20:08:22 I want to do that at some point 20:08:41 I have heard that the best way to understand forth completely is to implement it 20:08:41 It's amazing how little code it takes to "get started." 20:08:56 I remember having some fairly significant things running with only around 200 lines of assembly code. 20:09:00 It grows, of course. 20:09:12 yes, forth can be very impressive 20:09:23 Right now it's right around 16k total image size (that's not counting stacks - just counting headers and definitions). 20:09:31 And it's mostly complete. 20:09:34 nice 20:09:58 That feels about right to me - it's normal for an efficient 16-bit Forth to come in around 8kB, and this one is 32-bit so a lot of pieces are twice the size. 20:10:21 Makes me feel not like I've accomplished some miracle, but rather that I've done a reasonably competent job. 20:10:39 well, that is a nice feeling in itself 20:10:51 can I send my echo server code here? 20:11:03 It is. Formatted numeric output and disk I/O are really the only significant functions currently missing. 20:11:26 Just finished : and ; and friends and started actually being able to write and test some definitions. 20:12:13 Very soon now I'm going to go back and start re-implementing the pieces using the Forth itself, and establish an ability for it to re-compile itself. 20:12:29 Then I'll move on from there totally stand al one - won't need the assembler anymore. 20:14:00 Many of the pieces are already written in Forth, but I had to hand-compile them in assembly code. The Forth is in there for each of those words as a comment. When I start doing that recompile stuff I should just need to copy those comments into compilable blocks. 20:14:14 I've been very careful going back and checking the hand compiled "real code" against the code in the comments. 20:15:41 I'm working right now on the disk words. BLOCK and so on, with the associated buffer management. 20:16:13 --- quit: proteus-guy (Ping timeout: 260 seconds) 20:17:34 here is the program that I am having an issue with http://0x0.st/-290.f 20:17:54 it accepts one client and then does not accept any more afterwards 20:18:10 well, the problem is that 20:18:30 it makes sense that it would not exit 20:18:51 because I have not programmed it to 20:19:11 the real problem is that nothing happens when the client terminates the connection 20:19:15 no error or anything 20:19:55 an error would be nice, so that I could catch it and move on 20:21:04 I don't know a lot about TCP protocol. 20:21:23 It seems like sometimes one end might not have any way of knowing what the other end has done. 20:22:04 When the client closes the connection, does that involve it sending a notification of some kind? 20:22:12 it does 20:22:16 Ok. 20:22:16 there are also timeouts 20:22:25 that makes sense. 20:22:42 Well, I guess you need code that acts on that notification. 20:23:02 well, unix handles that 20:23:02 but 20:23:12 Oh I see - ok, sure. 20:23:38 you are supposed to encounter an error when reading/writing the socket 20:23:53 hm. maybe I need to set a timeout 20:25:46 I see. So the OS knows that the client has disconnected, but it doesn't tell you until you try to work with the connection again. 20:26:40 I assume you're responding to client needs? E.g., you might get a request for some particular resource, which you go get and write to the socket? 20:26:59 So if the client asked for something and disconnected before you responded, you'd get notified when you tried to respond. 20:27:07 well, I have defined two words 20:27:11 get-char and write-char 20:27:28 Yeah, you did say you're just echoing right now. 20:27:36 I guess what I said would be later on down the road. 20:28:10 from the socket.fs code 20:28:14 --- join: proteus-guy joined #forth 20:28:28 it seems like it is supposed to error-check the read/write calls 20:28:41 and then throw an actual error if they return an error 20:29:19 I am trying it after inserting a set-socket-timeout, and it still is not erroring 20:50:23 --- quit: proteus-guy (Ping timeout: 246 seconds) 20:51:05 Do you have a link to socket.fs? 20:51:27 https://github.com/forthy42/gforth/blob/master/unix/socket.fs 20:52:21 (I can't do any testing on this since I don't have a gforth with working ffi) 20:52:43 Heh. There's rather more material there... 20:54:26 IIRC, a while back there was discussion on CLF about timeouts for sockets not working in gforth, but I don't have a link to that 20:54:57 it should be possible to detect a closed connection though 21:03:14 --- join: proteus-guy joined #forth 21:04:23 hm. it appears that gforth may not have TCO 21:09:02