00:00:00 --- log: started forth/08.12.16 00:01:19 stop using IE :P 00:01:38 no IE here 00:04:39 i dont think the colors are ugly but it would look better if i could drop shadow some text 00:04:46 cept u cant reliably 00:04:54 unless you use gfx and i wont use gfx 00:07:36 ;p 00:07:45 never mind 00:16:47 Asau: hi - just to let you know, recanted on my implementation of the parse-word logic :-) - decided on a simpler mechanism (essentially, the outer shell of parse words which are derived in terms of an inner set of prefixed words) and a more consistent parse-word implementation (the only time i don't defer to the shell for the next token is when i'm parsing a file) 00:23:45 Not sure what you mean. 00:23:58 PARSE-WORD is pretty simple. 00:25:08 It is zero copy equivalent to "bl word count". 00:26:37 well, keep in mind that i'm implementing my own forth-like language, so i have to work it in to the existing code base :-) - the only case where i've identified the need to acquire the next word from somewhere other than the shell is when i'm parsing a file (containing my forth like programs and word definitions) 00:27:03 I think it is stupid. 00:27:10 :-) 00:27:24 have my reasons 00:27:31 --- quit: xjrn (Read error: 113 (No route to host)) 00:27:34 Reinventing wheels isn't practical, unless you know exactly, why you need another wheels. 00:30:02 --- quit: proteusguy (Read error: 110 (Connection timed out)) 00:30:12 well, it's either this approach or i have to wrap an existing forth implementation into my plugins which provide the nodes in my graph 00:30:50 and i'm not really keen on embedding something which actually compiles things - so it would need to be an interpreter of some sort 00:31:11 Use FICL and be happy. 00:31:18 Or pForth. 00:31:22 --- join: proteusguy (n=proteusg@61.7.144.97) joined #forth 00:32:48 am happy with what i have tbh :-) - it's pretty flexible - it's by no means a reimplementation of forth either, which frees me from a lot of low level considerations (like how a string is represented on a forth stack, and how i interpret strings) 00:33:57 --- quit: nighty__ (Remote closed the connection) 00:33:58 it's just forth like and i use forth as a guide line for introducing new functionality 00:34:00 ? 00:34:09 There's nothing that low level. 00:35:07 You just reimplement part of Forth functionality, which is already there. 00:35:28 is pretty low level 00:35:54 What isn't? 00:36:07 Pointer to "len--data" block? 00:36:25 Pointer to NUL-terminated block? 00:36:44 i just have a sting object - no pointers 00:36:54 What is "string object"? 00:37:06 a wrapped c++ string object 00:37:11 Pointer--length _IS_ string object. 00:37:50 Hm. 00:38:20 So, how is it "Forth-like", if it is a) wrapped; b) c++ object? 00:40:04 probably not 'forth-like' enough to appease the purists :-), but forth like enough such that many forth definitions will work with little to no modification 00:40:19 I'm not purist. 00:40:27 But this isn't even close to Forth. 00:41:30 Sure, you can represent string with opaque values, 00:41:51 but this isn't canonical. 00:42:59 And it doesn't differ essentially from pointer to length-data or nul-terminated block. 00:43:20 Same level of inconvenience. 00:43:53 this is a domain specific approach for a domain specific problem - basically, providing a means to serialise, deserialise and manipulate media graphs and a playout mechanism [actually, playout is abstracted - the 'user' of the graphs can be reimplemented to do other things like say say maintain a queue of graphs as transcoding jobs] 00:45:49 Well... 00:45:58 You're parsing and interpreting text. 00:46:11 yup 00:46:19 The domain is precisely that: text parsing and interpreting. 00:46:34 Which way abstracting strings away helps that? 00:47:08 Instead of working in-place with zero-copy tools 00:47:18 you're creating useless wrappers. 00:47:51 Which require you some kind of memory management, 00:48:11 neither of implicit or explicit is easy. 00:48:42 Unless you use PL with GC. 00:49:22 well, i do make extensive use of boost::shared_ptr 00:50:07 This isn't even close to Forth in all ways: 00:50:33 a) conceptions (you use heavy wrappers); 00:50:59 b) simplicity of abstractions and implementation (boost). 00:51:55 You have pretty simple protocol, which _is_ easily implemented in Forth. 00:52:06 Which itself is rare. 00:52:37 What you do is overcomplexification of original problem. 00:53:00 ah - the protocol is not the goal - just a by product - and yes, i saw that it was doable in forth directly - as a are many of the other things i'm doing here 00:56:29 think you're over estimating the effort involved in handling the parsing here - the code is not complex - pretty trivial really - the interface consists of two methods (unsurprisingly) with push( ) and push( string ) [for convenience] and pop( ) forming the interface (which is currently used by python) 00:57:46 internally, it provides a primitive grammar and word definitions (and the loop logic) 00:59:18 the only thing which i've needed to add is a parse like callback to the interface 01:00:31 (actually, there's push( int ) and push( double ) as well - a pop will always return the wrapped form though) 01:16:54 oh yeah - one of the guiding factors was in exposing the interpreter via a client/server mechanism - each client has its own stack and can customise its grammar for its own requirements but shares a common object (which again, has a stack based interface - so results of a pop can be passed to/from these stacks) 01:19:52 and the only advantage of the wrapping thing that i can think of is that . works universally for displaying strings, ints, doubles and playing the media at the top of the stack (the play thing was a loose interpretation :-) - it could have perhaps been more consistent if it simply serialised/printed the graph... but ho hum) 01:21:51 --- quit: sunwukong (Connection timed out) 01:24:05 and to finish this (cos obviously you're unconvinced or bored :-)) - the filter graph components provide arrays/trees and collections for all of the data types 01:40:14 --- join: xjrn (n=jim@c-24-7-31-66.hsd1.ca.comcast.net) joined #forth 01:48:05 --- quit: segher (Nick collision from services.) 01:48:22 --- join: segher (n=segher@84-105-61-45.cable.quicknet.nl) joined #forth 02:22:44 --- quit: ASau` (Read error: 113 (No route to host)) 02:36:42 --- quit: ASau (Read error: 60 (Operation timed out)) 02:49:38 --- join: ASau (n=user@77.246.230.238) joined #forth 03:11:10 --- join: GeDaMo (n=gedamo@dyn-62-56-77-42.dslaccess.co.uk) joined #forth 03:12:16 --- quit: tathi ("leaving") 04:32:59 --- quit: GeDaMo ("Leaving.") 04:51:55 --- quit: proteusguy (Read error: 110 (Connection timed out)) 04:52:37 --- join: proteusguy (n=proteusg@61.7.144.97) joined #forth 06:29:29 --- quit: proteusguy (Read error: 110 (Connection timed out)) 06:34:36 --- join: proteusguy (n=proteusg@61.7.144.97) joined #forth 06:40:58 --- nick: xjrn -> [off] 06:45:20 --- join: JasonWoof (n=jason@c-66-31-44-71.hsd1.ma.comcast.net) joined #forth 06:45:23 --- mode: ChanServ set +o JasonWoof 06:45:57 --- quit: grub_booter (Remote closed the connection) 07:05:18 --- nick: ASau -> ASau` 07:13:26 --- quit: mathrick (Read error: 110 (Connection timed out)) 07:23:19 --- quit: [off] (Read error: 54 (Connection reset by peer)) 07:25:01 --- join: grub_booter (n=charlie@d515301E0.access.telenet.be) joined #forth 07:59:35 --- join: ASau (n=user@193.138.70.52) joined #forth 08:02:15 --- quit: grub_booter (Connection timed out) 08:02:48 --- join: grub_booter (n=charlie@d515301E0.access.telenet.be) joined #forth 08:30:19 --- quit: ASau` (Read error: 110 (Connection timed out)) 08:41:41 --- join: GeDaMo (n=gedamo@dyn-62-56-77-42.dslaccess.co.uk) joined #forth 09:47:27 --- quit: proteusguy (Read error: 110 (Connection timed out)) 09:49:54 --- join: proteusguy (n=proteusg@61.7.144.97) joined #forth 10:15:31 --- join: pierre- (n=pierre@95-28-64-72.broadband.corbina.ru) joined #forth 11:02:15 --- quit: I440r ("Leaving") 11:04:04 --- join: I440r (n=mark4@ip70-190-70-22.ph.ph.cox.net) joined #forth 11:19:36 --- quit: I440r ("Leaving") 11:22:39 --- join: I440r (n=mark4@ip70-190-70-22.ph.ph.cox.net) joined #forth 11:36:03 --- quit: proteusguy (Remote closed the connection) 11:45:35 --- quit: ramkrsna ("Leaving") 12:50:07 --- quit: neceve (Read error: 104 (Connection reset by peer)) 13:24:30 --- quit: pierre- (Read error: 110 (Connection timed out)) 14:43:44 --- join: tathi (n=josh@dsl-216-227-91-166.fairpoint.net) joined #forth 14:43:44 --- mode: ChanServ set +o tathi 15:02:47 --- quit: GeDaMo ("Leaving.") 15:34:34 --- quit: qFox ("Time for cookies!") 15:52:34 --- join: domino14 (n=cdelsola@mail.nextgenaero.com) joined #forth 15:52:49 does anyone know how to get the address where a constant is stored? 15:52:58 i have a constant named EFP for example 16:06:55 what Forth system? 16:07:24 You can't do it in a standard way; there may not even be such an address. 16:10:23 using this thing called Roboforth 16:10:44 it stores variables/constants in memory somewhere 16:10:55 because when i reset it, these constants exist somewhere 16:11:14 i thought there was soem standard way, i'll just ask the vendor 16:12:14 Nope 16:12:31 For instance, a constant could just be a sequence of machine code to put the number on the stack. 16:12:45 On PPC, it would take two instructions (or 4 on a 64-bit machine) 16:12:59 so there wouldn't be any "address where the constant is stored." 16:14:13 aha 16:14:47 But often there is such an address, of course. Depends on your implementation. 16:14:57 Can I ask why you need it? 16:17:04 it seems the way to change the constants is (value) ' (name) ! 16:17:08 like EFP ' 63 ! 16:17:09 Yeah, looks like it. 16:17:17 so it's changing something 16:17:27 i just want to know where it resides in memory, so i know which "save" command to use 16:17:36 PSAVE or USAVE, which writes the RAM to flash 16:17:39 Ah. 16:17:53 it turns out i just used one and it worked, so it's just curiosity at this point... 16:18:32 From a manual I found online, it looks like roboforth is a pretty old-school traditional Forth, so I'd guess that constants' values are in with all the other data. 16:18:57 yep.. i can view a lot of "variables" by just doing variable DUMP 16:19:12 when i type in variable, it just puts the address on the stack 16:19:18 so then i can query by doing variable ? 16:19:29 and that ? apparently finds out what is at that variable 16:19:51 but for "constants", when i type in the constant it puts the VALUE on the stack 16:19:52 yeah, that's traditional. It's equivalent to "@ ." (fetch, display number) 16:20:02 aha 16:20:21 And constants are traditionally just a variable that fetch the value by default. 16:20:22 see when i do EFP . i get 63 16:20:27 yup 16:20:32 if i do EFP @ . i get -12986 16:20:38 --- join: nighty__ (n=nighty@210.188.173.245) joined #forth 16:20:41 does that number mean anything? 16:20:57 It's the number that's stored at address 63... 16:21:10 oh thats right 16:21:22 @ takes and address and fetches the number there. A 16-bit number, I'd guess. 16:21:24 yes, EFP DUMP prints out what's at address 63 16:22:12 ! is ( value addr -- ) and stores value to address, but you probably already know that... 16:22:19 yes 16:22:48 maybe it's the (tick) then 16:22:58 because to change EFP, i do EFP ' 30 ! 16:23:08 tick looks up a name 16:23:28 usually it returns an "execution token" that you can EXECUTE 16:23:45 but apparently in roboforth it gives you the address of the data associated with the word 16:23:48 or something. 16:24:09 Usually in forth you have to do ' (name) >BODY to get the data address 16:25:45 i did 'VLIST EFP and it prints out a bunch of dictionary words 16:25:55 and it found EFP at 5183, it seems 16:26:20 I just found this: "The code field (CFA) of a word is executable and can be found using FIND (or using ' (tick) minus two), e.g. FIND GRIP EXECUTE is the same as GRIP." 16:29:02 cool.. then FIND EFP . gives me 20875, which in hex is 518B, close to 5183 16:29:25 still the value at it is wrong, but i see the correct value only two addresses away (tick minus two?) this is odd 16:30:47 hmmm, ok i think i'm starting to track this down 16:30:53 Yeah. There's a header 16:30:55 a forth word has several bytes 16:30:56 yes 16:30:58 followed by the code 16:31:00 followed by the data 16:31:03 probably. 16:31:22 so those first two bytes are a pointer to code which puts the contents of the parameter field on the stack 16:31:36 I would think so. 16:31:39 and then the parameter field, which is two bytes away(at the right location), is the value 16:31:41 thanks! 16:31:56 no problem 16:47:13 --- part: domino14 left #forth 17:27:33 --- quit: tathi ("leaving") 17:37:03 --- join: proteusguy (n=proteusg@61.7.144.97) joined #forth 17:40:10 --- quit: proteusguy (Remote closed the connection) 17:44:05 --- join: proteusguy (n=proteusg@61.7.144.97) joined #forth 18:57:11 --- quit: proteusguy (Read error: 60 (Operation timed out)) 19:10:53 --- join: proteusguy (n=proteusg@ppp-124-120-228-57.revip2.asianet.co.th) joined #forth 21:18:17 --- quit: Quartus` (Read error: 104 (Connection reset by peer)) 21:46:27 --- quit: JasonWoof ("off to bed") 21:49:52 --- quit: proteusguy (Read error: 60 (Operation timed out)) 21:52:33 --- join: ramkrsna (n=ramkrsna@unaffiliated/ramkrsna) joined #forth 22:05:12 --- join: proteusguy (n=proteusg@61.7.144.97) joined #forth 22:12:19 --- join: ASau` (n=user@host95-231-msk.microtest.ru) joined #forth 22:24:51 --- join: Quartus` (n=Quartus`@74.198.12.3) joined #forth 22:30:36 --- quit: proteusguy (Read error: 60 (Operation timed out)) 22:42:34 --- quit: Quartus` (Read error: 145 (Connection timed out)) 22:44:11 --- join: proteusguy (n=proteusg@61.7.144.97) joined #forth 23:52:07 --- mode: ChanServ set +o I440r 23:59:59 --- log: ended forth/08.12.16