00:00:00 --- log: started forth/18.06.05 00:14:12 --- quit: mnemnion (Remote host closed the connection) 00:14:55 --- join: mnemnion (~mnemnion@2601:643:8102:7c95:bc51:5376:bb52:521f) joined #forth 00:20:00 --- quit: mnemnion (Ping timeout: 276 seconds) 00:38:35 --- join: proteusguy (~proteus-g@180.183.133.242) joined #forth 00:38:35 --- mode: ChanServ set +v proteusguy 00:55:51 --- join: mnemnion (~mnemnion@2601:643:8102:7c95:bc51:5376:bb52:521f) joined #forth 01:37:30 --- join: ncv (~neceve@79.114.72.194) joined #forth 01:37:30 --- quit: ncv (Changing host) 01:37:30 --- join: ncv (~neceve@unaffiliated/neceve) joined #forth 01:53:12 --- quit: ncv (Ping timeout: 240 seconds) 02:20:44 --- quit: epony (Read error: Connection reset by peer) 02:25:46 --- join: epony (~nym@77-85-143-102.ip.btc-net.bg) joined #forth 03:01:30 --- quit: nighty- (Quit: Disappears in a puff of smoke) 03:50:08 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth 04:09:07 --- quit: ThirtyOne32nds (Ping timeout: 264 seconds) 04:21:47 --- quit: karswell_ (Remote host closed the connection) 05:16:34 --- join: karswell (~user@cust125-dsl91-135-5.idnet.net) joined #forth 05:38:19 --- quit: proteusguy (Ping timeout: 256 seconds) 05:56:50 --- quit: pierpal (Quit: Poof) 05:57:10 --- join: pierpal (~pierpal@host23-9-dynamic.16-87-r.retail.telecomitalia.it) joined #forth 06:07:38 --- join: proteusguy (~proteus-g@cm-134-196-84-135.revip18.asianet.co.th) joined #forth 06:07:38 --- mode: ChanServ set +v proteusguy 06:37:15 --- quit: pierpal (Quit: Poof) 06:37:36 --- join: pierpal (~pierpal@host23-9-dynamic.16-87-r.retail.telecomitalia.it) joined #forth 06:45:43 KipIngram: macOS 10.14 will be the last to support 32-bit apps. 06:49:35 thanks god I have my powerg4 with 9 & morphos 06:50:24 --- join: nighty- (~nighty@s229123.ppp.asahi-net.or.jp) joined #forth 06:56:07 Hmmm. I wonder what I have on here that's 32 bits and I don't know... 06:56:57 I'm not worried re: my Forth work - over the weekend I got all the kinks worked out of a proper 64-bit approach. 06:57:35 you were saying something about position-independent code before 06:57:41 is your forth PIC? 07:00:13 https://support.apple.com/en-us/HT208436 has instructions to see if applications are 64-bit 07:08:26 Yes, it is PIC. 07:09:12 All of the "pointer" information that's stored in various places is expressed as an offset from the base address of the particular region involved. 07:09:44 At start up I use PIC-compatible instructions (the LEA instruction) to load the base addresses of those regions into R13-R15. 07:10:00 Then the code does the necessary arithmetic to produce the right absolute address. 07:10:45 So a definition, for example, isn't a list of *addresses* - it's a list of offsets. 07:11:32 NEXT scoops up the next offset and then adds a register value to it to turn it into an address that can be used for further processing. 07:12:03 That makes NEXT, and docol, and so on slightly more expensive than they otherwise would be, but it's not TOO awful. 07:14:07 oh right, I remember you describing this now with your next making use of r13-15 07:18:22 Yes. NEXT actually only needs r13 and r15, but docol needs r14. 07:19:29 When I first set it up I had everything in one region and just used r15, but I decided I wanted to be able to move the regions around independently. 07:21:16 The header region will need a base address as well, but I'll probably keep that one in a variable - performance won't be as critical, I think. 07:22:09 I've thought about some performance tricks for the block/buffer mass storage access stuff, and I'll need a couple of registers for that. So I don't want to be too spendthrift with them. :-) 07:27:01 I want to regard disk data as "rows in database tables." 07:27:40 So to "connect" to a table, I'd need to specify where on the disk the table started and the row size (a power of 2) - I'll load that info into registers for fast access. 07:28:02 Then I'll write the database code using virtual "on-disk" addresses. 07:28:41 The bit that determines whether a desired row is resident in RAM already or not needs to be very fast - if it is already resident the conversion from disk-based row # to a RAM address should be super-fast. 07:28:56 if it's not resident we don't care as much - we're going to have to spend time bringing it in anyway. 07:29:21 So similar to what we already do with BLOCK and BUFFER, but taken a bit further to let me work efficiently with individual table rows. 07:30:03 If I have enough registers to let me have two or three such connections open at the same time, I think I can get some pretty efficient database stuff. 07:30:59 I think this is an area where Forth can kick mainstream tools in the teeth, since it provides a way to entirely avoid os filesystem overhead. 07:32:33 I also want to have my block size configurable. Small blocks like 1 kB give us very efficient space utilization on disk, but poor performance. Using 64 kB, if your application can do that without wasting tons of space, lets you get on up toward the full bandwidth of your storage system. 07:33:06 So I want to be able to choose that on an app-by-app basis. 07:40:50 And I plan a large number of buffers, so it's rare for me to thrash the disk. 07:41:08 Seems like a great place to exploit the "memory is cheap" truism. 08:14:19 --- quit: proteusguy (Ping timeout: 240 seconds) 08:24:29 --- quit: mnemnion (Remote host closed the connection) 08:24:43 --- join: mnemnion (~mnemnion@2601:643:8102:7c95:bc51:5376:bb52:521f) joined #forth 08:27:09 --- join: proteusguy (~proteus-g@cm-134-196-84-135.revip18.asianet.co.th) joined #forth 08:27:09 --- mode: ChanServ set +v proteusguy 09:22:44 --- quit: pierpal (Quit: Poof) 09:23:01 --- join: pierpal (~pierpal@host23-9-dynamic.16-87-r.retail.telecomitalia.it) joined #forth 09:28:41 --- quit: dddddd (Ping timeout: 276 seconds) 09:38:26 --- join: Labu (~Labu@labu.pck.nerim.net) joined #forth 09:38:54 --- join: ncv (~neceve@unaffiliated/neceve) joined #forth 09:41:17 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth 09:47:42 --- quit: ncv (Ping timeout: 240 seconds) 09:56:43 --- join: dys (~dys@tmo-108-43.customers.d1-online.com) joined #forth 10:19:16 --- join: yuiope (9f7f20fe@gateway/web/freenode/ip.159.127.32.254) joined #forth 10:44:07 Hello 10:45:03 What is the leave word purpose in ANS Forth ? 10:46:03 ?leave ( flag -- ) Exits from a DO .. LOOP if flag is nonzero 10:46:16 http://astro.pas.rochester.edu/Forth/forth-words.html 10:46:32 yuiope: thx 10:46:53 I don't undertand this error I have 10:46:57 thx 10:47:31 on my implementation I have leave and ?leave 10:48:31 leave do loop it's what I expect but I get an error 10:48:58 I'm still new to Forth; maybe someone will chime in. 10:49:18 me too yuiope 10:50:10 whath implementation do you use ? 10:51:35 figforth 10:53:24 ok 10:57:08 I haven't used an ANS forth but I thought leave was just a cleanup word you use before exiting from the middle of a do..loop 11:01:27 hi zy]x[yz my problem is elsewhere, so. It's exactly what I want to do 11:02:16 --- part: yuiope left #forth 11:06:28 this "start i + c@ 0=" fails on the last word. I don't understand. 11:06:58 the word definition https://pastebin.com/qimMgC62 11:08:50 don't understand what I missed 12:00:00 Labu: That's a... really *long* definition. Did you translate a C function or something? 12:00:48 That start i + c@ 0= looks like it's looking for a null terminator. 12:00:58 Except it looks backwards. 12:01:17 You'd think you'd 1+ if the character was NOT 0, and leave if it was. 12:01:25 Or maybe it's supposed to be skipping over null bytes? 12:01:31 I guess it looks right for that. 12:01:43 Hi KipIngram I just want remove trimming zero a char array 12:01:51 from the left 12:02:05 Ok, so that part is trying to hop over zeroes? 12:02:14 yes 12:02:39 How are you retaining that information after the loop? 12:02:48 i will no longer be defined outside the loop, right? 12:03:01 I'm unfamiliar with u+do 12:03:13 just assuming it's some variant of do 12:03:25 In my paste I made an error I fixe that 12:03:41 Oh, but I still see - you're incrementing a counter. 12:03:45 For each zero byte. 12:03:58 yes 12:04:20 after I substract this to size and I get new size 12:04:49 after I move char one by one and reallocate memory 12:05:40 with resize 12:06:22 So you're copying the nonzero bytes back to the beginning? 12:06:49 --- quit: dys (Ping timeout: 240 seconds) 12:06:49 yes but I think the error comes from I test this from an allocation in dictionnary 12:07:13 I must do that with allocated memory 12:07:44 Seems like this is a good opportunity to figure out the right parameters and then use cmove. 12:08:14 I don't know cmove 12:08:21 I am looking this 12:08:24 a b n cmove 12:08:29 moves n bytes from a to b. 12:08:45 interesting 12:08:52 A problem you have here, though, is that you have a null-terminated string instead of a counted string. 12:09:13 If it were a counted string you could figure out the cmove parameters much more easily. 12:09:28 it's not a string in fact 12:09:33 But with null termination you have to find that null, looking at each character, in order to figure out how many characters to move. 12:09:49 I try to make an arythmetic system for big number 12:10:06 Oh - an arbitrary precision arithmetic thing. 12:10:08 Very cool. 12:10:37 yes it's my goal but I am far away 12:10:51 --- join: dys (~dys@tmo-108-43.customers.d1-online.com) joined #forth 12:11:04 Are you new to Forth? 12:11:18 totally new 12:11:38 I highly recommend the book "Thinking Forth" by Leo Brodie. It's available as a free pdf online if you search around a little. 12:11:39 I began couple months ago 12:11:52 yes I have it 12:12:09 Oh good. Ok - then you will "get there" - keep chugging. 12:12:13 I must find the time to read it 12:12:21 Yes - it's very worth it. 12:13:35 yes I liked the first chapter about programmation 12:13:51 it's right for all language 12:14:45 Forth is thinked for a bottom-up approach but it's a really good concept 12:16:51 I do recommend that you give the numbers in your system count bytes. Use two bytes for the count if 256 isn't enough. If you use null termination you're going to spend tons of runtime seeking the end of things. 12:16:56 Big things. 12:17:18 If things have sizes then you can KNOW where they end without having to search. 12:22:01 yes you are right. I didn't give a model to my data just do this on memory. I have this words to resize a result after an operation, but I should determine this if I have the size of the two numbers before the operation an allocate in consequence 12:25:15 KipIngram: I have to leave for this evening but thnks a lot for taking the time to read me and your advice 12:30:25 --- quit: dys (Read error: Connection reset by peer) 12:31:40 --- join: dys (~dys@tmo-108-43.customers.d1-online.com) joined #forth 12:31:40 --- quit: pierpal (Read error: Connection reset by peer) 12:31:56 --- join: pierpal (~pierpal@host23-9-dynamic.16-87-r.retail.telecomitalia.it) joined #forth 12:40:02 --- quit: pierpal (Read error: Connection reset by peer) 12:40:14 --- join: pierpal (~pierpal@host23-9-dynamic.16-87-r.retail.telecomitalia.it) joined #forth 13:00:02 --- quit: dys (Remote host closed the connection) 13:10:48 --- join: dys (~dys@tmo-108-43.customers.d1-online.com) joined #forth 13:22:19 --- quit: dys (Ping timeout: 240 seconds) 13:31:06 --- join: dys (~dys@tmo-108-43.customers.d1-online.com) joined #forth 13:34:31 KipIngram: the ( addr count ) convention also allows one to work with sub section of strings without moving or copying them 13:38:42 Ah yes - great point. 13:39:32 So that's why you have COUNT that moves you from the in-place count to the on-stack count and the text-only address underneath. 13:39:41 So that can be applied anywhere in the string. 13:39:51 I'd never explicitly taken note of that, but it makes perfect sense. 13:40:40 --- quit: pierpal (Quit: Poof) 13:41:00 --- join: pierpal (~pierpal@host23-9-dynamic.16-87-r.retail.telecomitalia.it) joined #forth 14:26:08 --- join: pierpa (57100917@gateway/web/freenode/ip.87.16.9.23) joined #forth 14:34:34 --- join: ThirtyOne32nds (~rtmanpage@80.sub-174-204-11.myvzw.com) joined #forth 15:01:42 --- quit: karswell (Remote host closed the connection) 15:03:04 --- join: karswell (~user@cust125-dsl91-135-5.idnet.net) joined #forth 15:25:32 --- quit: dys (Ping timeout: 265 seconds) 15:45:51 --- quit: mnemnion (Read error: Connection reset by peer) 15:46:25 --- join: mnemnion (~mnemnion@2601:643:8102:7c95:bc51:5376:bb52:521f) joined #forth 15:48:39 --- join: karswell_ (~user@cust125-dsl91-135-5.idnet.net) joined #forth 15:48:45 --- quit: karswell (Remote host closed the connection) 15:50:28 --- quit: karswell_ (Remote host closed the connection) 15:51:09 --- quit: mnemnion (Ping timeout: 265 seconds) 15:51:48 --- join: karswell_ (~user@cust125-dsl91-135-5.idnet.net) joined #forth 16:10:24 --- quit: cheater (Ping timeout: 256 seconds) 16:15:29 --- join: cheater (~cheater@unaffiliated/cheater) joined #forth 16:16:08 --- quit: nighty- (Quit: Disappears in a puff of smoke) 16:34:12 --- quit: cheater (Ping timeout: 256 seconds) 16:45:58 --- quit: johnmark (Quit: Leaving) 16:46:36 So, my plans have run into a snag. I had it in mind that I was going to implement CM's "tokenized source" stuff like he did in ColorForth, and like Fox did in Aha. 16:46:57 But I also envisioned a system that supported multiple processes, each of which could extend the dictionary privately. 16:47:06 I've realized today that those two concepts don't work together. 16:47:57 Rolled around some very complex ideas about how to shoehorn them both in, but the more I work that out the less "right" it feels. 16:48:53 On the other hand, multiple processes with a traditional dictionary structure just looks easy as pie. 16:50:19 --- join: mnemnion (~mnemnion@2601:643:8102:7c95:bc51:5376:bb52:521f) joined #forth 17:06:46 --- quit: dddddd (Remote host closed the connection) 17:14:10 --- join: cheater (~cheater@unaffiliated/cheater) joined #forth 17:44:11 --- join: nighty- (~nighty@kyotolabs.asahinet.com) joined #forth 18:37:13 --- quit: karswell_ (Ping timeout: 245 seconds) 18:50:00 --- join: smokeink (~smokeink@59-125-28-152.HINET-IP.hinet.net) joined #forth 19:41:02 --- quit: mnemnion (Remote host closed the connection) 19:41:04 hi 19:44:57 hello 19:45:53 hi pierpa 19:50:31 where does the names "@" and "!" come from for dereferencing a pointer? in C it's * 19:56:38 hmmm @ seems self-explanatory 19:57:09 given an address, @ fetches what's AT that address 19:58:53 !, I don't know, but if I can make a guess, I suppose Charles Moore was thinking "make that cell contain this value!!!!" 19:59:00 ! was once named = 19:59:14 aha! didn't knew 19:59:40 See http://forth.org/POL.pdf page 27 (1970) 20:00:39 dave0: i think @ is much similiar with basic's peek 20:01:08 it's a clever name :-) 20:01:22 peek/poke 20:01:36 i mean @ for "at" :-) 20:01:39 @crc: thanks. I had missed that book. Will read it. 20:01:42 that's what i remember from learning basic language on a editonary 20:02:30 but basic didn't use the symbol @, for this, ot am I misremembering? 20:02:37 *or 20:03:31 dave0: @ IS "at", is not an invention of forth 20:06:08 here http://www.atsymbol.com/history.htm 20:06:28 yeah, even before I knew forth I always thought it would have made sense for C's * to have been @ instead 20:09:17 well i just always thought about peekl 20:12:34 "I'm making minimal changes to the text; just enough to fit HTML. The language remains quaint, ungrammatical or unclear. " :D 20:20:39 --- join: mnemnion (~mnemnion@2601:643:8102:7c95:2079:4824:7221:5cbc) joined #forth 20:47:11 --- quit: pierpa (Quit: Page closed) 21:01:17 --- quit: reepca (Read error: Connection reset by peer) 21:04:48 --- quit: pierpal (Quit: Poof) 21:05:06 --- join: pierpal (~pierpal@host23-9-dynamic.16-87-r.retail.telecomitalia.it) joined #forth 21:06:23 --- join: reepca (~user@208.89.170.230) joined #forth 21:24:52 --- join: johnmark (~johnmark@64.53.247.121) joined #forth 21:29:01 --- quit: mnemnion (Remote host closed the connection) 21:29:16 --- join: mnemnion (~mnemnion@2601:643:8102:7c95:2079:4824:7221:5cbc) joined #forth 23:05:16 --- quit: Labu (Quit: WeeChat 2.0.1) 23:21:20 --- quit: mnemnion (Remote host closed the connection) 23:27:32 --- join: mnemnion (~mnemnion@2601:643:8102:7c95:2079:4824:7221:5cbc) joined #forth 23:47:57 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth 23:50:24 --- join: dys (~dys@tmo-099-89.customers.d1-online.com) joined #forth 23:59:59 --- log: ended forth/18.06.05