2023-11-28 06:21:38 <olle        > Word of the day: nextname?
2023-11-28 06:30:36 <crc         > nextname is not a standard word :)
2023-11-28 06:31:35 <olle        > Awww
2023-11-28 06:31:44 <olle        > Is struct standard?
2023-11-28 06:32:45 <crc         > no
2023-11-28 06:33:42 <crc         > forth2012 adds structures: https://forth-standard.org/standard/facility/BEGIN-STRUCTURE
2023-11-28 06:33:48 <GeDaMo      > This is the index for the standard https://forth.sourceforge.net/standard/dpans/dpansf.htm
2023-11-28 06:35:20 <GeDaMo      > Huh, I didn't even know there was a Forth 2012 :|
2023-11-28 06:36:17 <crc         > forth2012 is part of an ongoing update to the forth standard (outside the ANS standards body, but following a similar overall process)
2023-11-28 06:39:22 <olle        > Hm
2023-11-28 06:42:05 <olle        > I'd like to create an example of nested structs in Forth
2023-11-28 06:42:55 <user51      > olle: I've written a few simple words for working with structures, I don't know how useful they are, take a look anyway:
2023-11-28 06:43:23 <olle        > Yea? Cool :)
2023-11-28 06:43:23 <user51      > olle: http://0x0.st/HwXH.forth
2023-11-28 06:44:12 <user51      > It's pretty simple tbh, I thought of something "better" but I'm not sure about it at all.
2023-11-28 06:44:34 <olle        > +1
2023-11-28 06:45:30 <user51      > I'm not sure what nested struct means, but maybe this fits the bill http://0x0.st/HwDX.forth
2023-11-28 06:47:03 <olle        > Nested, as in employee record with user, address, etc inside
2023-11-28 06:49:38 <olle        > That's how you achieve code reuse on data level, no?
2023-11-28 07:12:04 <veltas      > olle: https://news.ycombinator.com/item?id=34183533
2023-11-28 07:14:36 <veltas      > As for 'reuse', the story is complicated, the usualy reuse techniques can be quite misguided in Forth
2023-11-28 07:14:50 <veltas      > s/usualy/usual
2023-11-28 07:15:38 <olle        > Neat
2023-11-28 07:17:32 <veltas      > I personally believe that Forth works better with the kind of code you saw in weaker high level languages like VB6, where you'd have multiple associated arrays rather than an array containing structs of associated items
2023-11-28 07:18:21 <veltas      > So you might have an array for each 'field'. A 'record' isn't contiguous then, but does that matter?
2023-11-28 07:20:50 <veltas      > An example of where this works better is sorting an array. If an 'array' is always an array of CELL's, then a generic sort word is easier to write. The only thing that needs tweaking is the comparison XT. Keeping track of the *size* of an element of an array as well would be even more tedious.
2023-11-28 07:24:59 <olle        > Assoc array? Is this PHP? ^^'
2023-11-28 07:25:20 <veltas      > Not an associative array, associated array
2023-11-28 07:25:26 <olle        > Oh
2023-11-28 07:25:38 <veltas      > An associative array is a 'hash table'
2023-11-28 07:25:54 <veltas      > Associated array just means an array associated/related with another array
2023-11-28 07:26:32 <veltas      > For example   CREATE SHAPE-WIDTHS 1 , 2,  CREATE SHAPE-HEIGHTS 2 , 2 ,
2023-11-28 07:26:59 <veltas      > Those arrays are associated, index 0 of SHAPE-WIDTHS refers to same 'shape' as index 0 of SHAPE-HEIGHTS
2023-11-28 07:27:21 <veltas      > This is one way of having associated data, without using structures
2023-11-28 07:27:52 <veltas      > Is this a good idea? Well that really depends!
2023-11-28 07:27:56 <veltas      > Like everything in Forth
2023-11-28 07:28:10 <veltas      > But it's good to be aware of the alternatives
2023-11-28 07:29:33 <veltas      > I'm interested if anyone else has an opinion on this. I know it's gross but I think you have to get your hands dirty in Forth
2023-11-28 07:36:57 <user51      > veltas: is the dot in SHAPE.{AREA HEIGHT WIDTH} supposed to like C's dot operator?
2023-11-28 07:37:30 <veltas      > Yes, why?
2023-11-28 07:37:40 <KipIngram   > I think you make some good points.  One thing to note is that you lose locality doing it that way.  With an array of structs you likely get everything into a cache line in one go (for a particular indexed entry).
2023-11-28 07:37:58 <KipIngram   > I think in terms of ease of coding, though, you may be onto something.
2023-11-28 07:38:01 <GeDaMo      > On the other hand, arrays ofmachine types open up the possibility of vectorizing
2023-11-28 07:38:09 <veltas      > Exactly
2023-11-28 07:38:16 <veltas      > Also in some situations you can gain locality
2023-11-28 07:38:26 <veltas      > If the struct would have been very large and full of often-unrelated info
2023-11-28 07:38:37 <KipIngram   > Yes.
2023-11-28 07:38:51 <KipIngram   > Kind of depends on whether you need "most" of the record or not.
2023-11-28 07:38:57 <veltas      > But I think we assume nobody here cares that much about locality, as long as it's not dire
2023-11-28 07:39:31 <user51      > veltas: I'm not sure how it's treated in C but to me it returns a member, while the words return an offset. Basically there would be an implicit load there.
2023-11-28 07:40:51 <veltas      > Actually in C you get an lvalue, and depending on what expression you use it in that's either going to be an address only (getting pointer off it, using first array element etc, assigning to it) or fetching the value for use
2023-11-28 07:41:22 <veltas      > The difference is that you get the lvalue in Forth every time and either fetch it with @ or use the lvalue as an address e.g. !
2023-11-28 07:41:36 <veltas      > Sorry I know that's philosophical pedantry but I view the two as similar
2023-11-28 07:41:44 <veltas      > It can't be exactly the same anyway because Forth isn't C
2023-11-28 07:43:01 <veltas      > I'm biased from reading the BCPL manual
2023-11-28 07:43:11 <veltas      > Which is very explicit about this lvalue/rvalue business
2023-11-28 07:46:02 <veltas      > It's more like -> anyway because we have no way of referring to "the struct itself" in Forth, only its address
2023-11-28 07:46:21 <veltas      > The dot is just quite a universal syntax to roughly mean "get a member"
2023-11-28 08:03:16 <user51      > veltas: Pedantry can be pretty useful sometimes. But trying to narrow it down is pretty pedantic :P
2023-11-28 08:04:48 <veltas      > I do get that some people would prefer a word to just 'get' the value, similar to VARIABLE vs VALUE
2023-11-28 08:05:25 <veltas      > Really depends what you want to do, but the aim of that library was something that works and is really short (at two lines) to demonstrate Forth's flexibility to the hackernews audience
2023-11-28 09:30:17 <KipIngram   > I hardly ever find myself "wishing I didn't have to use @."  In the relaively infrequent cases where i use a Forth variable, I just put the @ where it's needed without thinking about it very much.
2023-11-28 09:30:58 <KipIngram   > If a quantity tried to be "friendly" and give me its value instead of its address, then I'd immediately be faced with having to jump some sort of hoop in order to update its value, whereas when it gives me its address then I just use !.
2023-11-28 09:31:23 <KipIngram   > I'm just so used to doing thins the "typical Forth way" that I don't really think about alternatives.
2023-11-28 09:34:43 <KipIngram   > Most often I'll be referencing something in a block-resident structure or in the dictionary, and it's just automatic for me to think in terms of calculating an address and then using that address "however."
2023-11-28 09:36:32 <KipIngram   > In this sense I think I bring the mind set over from assembly.  In assembly the only way to deal with something in memory is to somehow generate its address.  That address is really always "visible" and pretty much in the "foreground" of the thinking.
2023-11-28 09:38:11 <KipIngram   > The only time I'd even think about wanting something to directly deposit a value on the stack would be when I'm basically never going to need to change it (i.e., CONSTANT).
2023-11-28 09:39:01 <KipIngram   > And if for any reason I did want to be able to directly reference the value, then I'd add a convenience word like : here  dp @ ;
2023-11-28 10:02:22 <veltas      > Yeah I think VARIABLE and CONSTANT are more Forthy than VALUE
2023-11-28 10:03:06 <veltas      > But I'm mostly just happy to read new Forth at all so you won't catch me complaining about it
2023-11-28 10:05:11 <olle        > :)
2023-11-28 10:08:44 <KipIngram   > I think some modern languages try to "hide" the underlying machinery and let the programmer work more in terms of logical concepts.  But that's really not something I expect from Forth in its most basic form.  I see Forth as providing pretty much the opposite - it exposes the machines resources as directly as possible so you can do anything you want with them.
2023-11-28 10:08:51 <KipIngram   > machine's
2023-11-28 10:09:17 <veltas      > That's pretty much all languages, old and new
2023-11-28 10:10:21 <KipIngram   > That's fair, but I think some "try to go further" than others.
2023-11-28 10:11:11 <KipIngram   > And of course you can write Forth code to reach up for a higher level of abstraction if you want to.
2023-11-28 10:12:18 <veltas      > BCPL hid this and it was a barebones bootstrapping concept
2023-11-28 10:12:49 <veltas      > So I enjoy that Forth doesn't
2023-11-28 10:13:41 <olle        > Kinda the whole point :) Remove concerns from the brain of the developer. Less cognitive load.
2023-11-28 10:14:12 <veltas      > I think if you don't have a practical use for Forth you really have to just find restrictive low level programming fun
2023-11-28 10:14:45 <thrig       > some have said that low level is more fun than nannying kubenetes javascript blah
2023-11-28 10:15:35 <veltas      > I don't think Forth has a low cognitive load most of the time
2023-11-28 10:16:16 <KipIngram   > I agree - especially if you want your Forth to be GOOD Forth.  it can take a lot of work to find that "best solution."
2023-11-28 10:16:42 <veltas      > It can have a low cognitive load, but it's rarely achieved, makes it more sweet when it is
2023-11-28 10:17:41 <KipIngram   > Yes, when the solution is achieved, then understanding it can be a low cognitive load, and those solutions really do "feel good."  Nice "Ah..." feeling.
2023-11-28 10:18:46 <KipIngram   > I think the work, when you've done something fairly right, isn't so much in writing the words as it is in choosing the words in the first place.
2023-11-28 10:19:00 <KipIngram   > Kind of the whole idea is that the individual words should be nice and simple.
2023-11-28 10:20:01 <KipIngram   > I have run into a couple of problems where it's really easy to wind up with something very cumbersome, but if you really stay at it you can eventually find a very "sweet" solution where everything just seems to fall into place.
2023-11-28 10:20:17 <KipIngram   > The one that comes to mind right now is operating on doubly linked lists.
2023-11-28 10:20:17 <veltas      > I have been spending time recently trying to make sorting simpler
2023-11-28 10:20:33 <KipIngram   > That can get messy fast if you're not careful, but there is a nice way and I have found it a couple of times.
2023-11-28 10:21:09 <veltas      > Interested in what you've got if you're willing to share
2023-11-28 10:22:07 <veltas      > I am trying to find a simple program for merge sort
2023-11-28 10:22:43 <KipIngram   > I've found that singly linked lists don't seem to get you into the crud so much - there's a fairly obvious way to go about it and not many options.
2023-11-28 10:22:44 <KipIngram   > But add those back links and there are more moving parts, and you can really get things into a jumble.
2023-11-28 10:23:21 <veltas      > Sentinel nodes make lists easier
2023-11-28 10:24:22 <veltas      > If you're not just inserting to the front with pre-existing elements
2023-11-28 10:24:39 <KipIngram   > The doubly linked lists?  I'll look and see if I have it lying around.  I'm not horribly good at archiving all my old stuff.  :-(
2023-11-28 10:25:03 <veltas      > Sentinels work with single and double
2023-11-28 10:25:10 <KipIngram   > It's another thing I haven't had to do on the current system yet, but I did use it in a prior system, in my memory management code.
2023-11-28 10:25:55 <veltas      > Sentinels allow insert/remove to be unconditional
2023-11-28 10:26:02 <veltas      > No branches
2023-11-28 10:26:21 <veltas      > Or less conditions anyway
2023-11-28 10:26:46 <veltas      > I find it just makes lists easier
2023-11-28 10:28:09 <veltas      > I remember when I first learned about them I thought 'why wasn't I taught about this before?'
2023-11-28 10:28:33 <KipIngram   > Sentinel node - that's an "always there" first "dummy" node?
2023-11-28 10:28:43 <veltas      > Yes
2023-11-28 10:28:43 <KipIngram   > So that you're never actually working on the real "first" node?
2023-11-28 10:28:50 <KipIngram   > That definitely does help.
2023-11-28 10:29:40 <KipIngram   > The code I was speaking of specifically, though, was for inserting to / deleting from the middle of the list.
2023-11-28 10:30:13 <KipIngram   > You're dealing with three nodes; the one you're inserting and the ones on either side, so the stack gets kind of busy.
2023-11-28 10:30:30 <veltas      > Have you got a nice sort program?
2023-11-28 10:30:45 <KipIngram   > No, I don't often need to sort anything.
2023-11-28 10:31:24 <veltas      > It's probably going to make Advent of Code easier to have one in advance
2023-11-28 10:31:30 <veltas      > For me
2023-11-28 10:31:48 <KipIngram   > It's a classic problem, so it's good to work on.
2023-11-28 10:31:54 <veltas      > Yup
2023-11-28 10:56:52 <olle        > veltas: https://news.ycombinator.com/item?id=34183533 For this technique, can it be generalized to compose structures? E.g. a shape that consists of points, or one point and radius.
2023-11-28 11:15:32 <KipIngram   > I want to say probably not, though I don't have it fully picked apart yet.  It may depend on "how much trouble" you're willing to go to.  If you wanted to make a new structure that consisted of a pair of existing structures, I guess you'd have to make sure you called out all the right sizes and so on.  But if the first level of structure access leaves you with the address of a component structure, then you
2023-11-28 11:15:34 <KipIngram   > could apply a second level of structure access to that to get to a field within it, right?
2023-11-28 11:15:53 <KipIngram   > I'm betting you'd need to manually compute the sizes required in your second level structure declaration.
2023-11-28 11:17:34 <olle        > :d
2023-11-28 11:18:31 <GeDaMo      > Maybe create a table, fields and number of records
2023-11-28 11:19:07 <olle        > Gonna check gforth support for this
2023-11-28 11:23:15 <KipIngram   > Maybe an example is in order.  Say you have POINT with X, Y, and Z values.  Each of those is one cell, so POINT is size 3 cells.
2023-11-28 11:23:51 <KipIngram   > If you then want LINE to consist of two POINTs, you just have to make sure that when you declare line you somehow tell it that each of the component points occupies three cells.
2023-11-28 11:24:24 <KipIngram   > Then when you start with LINE you first select one of its two components, and then you'd select one of that point's three components.
2023-11-28 11:25:08 <crc         > olle: https://forth.works/share/e2a39a047fdd4ead2acd2dbfc948effc.txt is an example of a triangle structure using a point structure and the field: and +field words
2023-11-28 11:26:10 <olle        > crc: cool!
2023-11-28 11:28:58 <KipIngram   > I think what I'd be more prone to do in a case like this is to just use the fact that I knew how the higher level structure was laid out to write words that regarded it as one flat structure; I've got a pointer to it and I know what offset every different thing is at - I'd go straight for the offset I needed without digging iteratively down through a hierarchy of structure.
2023-11-28 11:29:24 <KipIngram   > I.e., I'd do the structure resolution at programming time rather than runtime.
2023-11-28 11:41:30 <olle        > KipIngram: Well. You might need your shapes to become 3D. :)
2023-11-28 11:41:37 <olle        > What's easiest to change?
2023-11-28 11:42:02 <user51      > Speaking of shapes https://github.com/chmykh/apl-life
2023-11-28 11:42:15 <crc         > I'd write a new set of words for 3d shapes
2023-11-28 11:43:36 <KipIngram   > olle: Yes, in which case I'd have to modify my code.
2023-11-28 11:43:56 <KipIngram   > But my code would run faster since it wasn't having to all those intermediate computations every time.
2023-11-28 11:44:08 <olle        > Classic dev time vs cpu time tradeoff.
2023-11-28 11:44:43 <KipIngram   > Yeah, and which is better really depends on how much it's going to be run.
2023-11-28 11:44:58 <KipIngram   > If it's a throw-away tool you're going to run once, you'd like to minimize dev time.
2023-11-28 11:45:12 <KipIngram   > If it's going to be run a gerzillion times, then making it faster is a win.
2023-11-28 11:45:43 <olle        > Depends - on how much electricity costs :)
2023-11-28 11:45:43 <olle        > And how much a dev hourly rate costs.
2023-11-28 11:45:47 <olle        > But yes, in general that.
2023-11-28 11:47:35 <olle        > Oh and also how much a piece of code is expected to change.
2023-11-28 11:48:00 <KipIngram   > Which is something no one is very good at estimating.
2023-11-28 11:48:37 <KipIngram   > In fact, Chuck would say don't think about that.  Write the code for the problem as it is right now.  If you get a new problem later, then write the code for that.
2023-11-28 11:48:49 <KipIngram   > He eschews any attempt at all to "anticipate future needs."
2023-11-28 11:49:12 <olle        > Yea, everyone else basically makes the opposite assumption. Code should be changeable above all.
2023-11-28 11:49:31 <KipIngram   > He states in strongly, in an all or nothing way, and it's probably more of a gray area thing.  But that's just Chuck's style these days.
2023-11-28 11:49:41 <olle        > Mm
2023-11-28 11:50:12 <KipIngram   > I can at least imagine cases where you know pretty darn well what's coming at least in the near term.
2023-11-28 11:50:25 <KipIngram   > and also cases where you have no idea.
2023-11-28 11:50:31 <olle        > CEO's tends to change their minds
2023-11-28 11:50:38 <olle        > As do other clients/customers.
2023-11-28 11:51:09 <KipIngram   > I've never really worked in an environment where we were hired by a customer to do a customer-specified job.
2023-11-28 11:51:22 <KipIngram   > I've only worked in environments where we developed products for general sale.
2023-11-28 11:51:34 <KipIngram   > WE decided how to make them.  and they either got bought or didn't.
2023-11-28 11:52:35 <KipIngram   > Well, that's not entirely true.  I guess when I was consulting I did work specified by clients.  But even then I was given a lot of latitude to craft the solution.
2023-11-28 11:52:41 <KipIngram   > That was part of what I was being hired to do.
2023-11-28 11:54:53 <olle        > Have to go \o
2023-11-28 11:55:00 <KipIngram   > Stay safe!
2023-11-28 11:55:06 <olle        > Thanks!
2023-11-28 12:00:32 <veltas      > Oh just missed him
2023-11-28 12:00:37 <veltas      > You can compose structures with it
2023-11-28 12:00:58 <veltas      > Just do %MY-STRUCT +FIELD PARENT.MY-MEMBER
2023-11-28 12:01:14 <veltas      > I'll point him at logs tomorrow
2023-11-28 12:03:03 <veltas      > Or ALIGNED %MY-STRUCT +FIELD PARENT.MY-MEMBER etc as necessary
2023-11-28 12:04:50 <veltas      > KipIngram: I've found you need one team per customer, if they have regular contact
2023-11-28 12:05:46 <veltas      > Because one can't diplomatically tell a customer 'OK this simple thing that should take under a day will take a week because you're not a priority'
2023-11-28 12:07:11 <veltas      > And nobody wants to invest loads of money to get support-ticket-style responses... unless they're just paying for support
2023-11-28 12:07:42 <veltas      > Although I'm generalising a fair amount, there are good and bad customers...
2023-11-28 12:07:56 <veltas      > I'm sure crc knows a bit about this
2023-11-28 12:17:10 <crc         > I'm only doing programming for myself and my employer's in-house tools now, but I've had a variety of both good and bad customers over the years
2023-11-28 12:18:57 <KipIngram   > But if you're a one-man house there's no alternative.
2023-11-28 12:19:08 <KipIngram   > Of course it was fairly rare for me to have more than one client at a time.
2023-11-28 12:19:24 <KipIngram   > If things had gone well enough for that to be a common problem I wouldn't have stopped doing it.
2023-11-28 12:21:38 <veltas      > Were you a contractor for a while KipIngram?
2023-11-28 12:27:36 <KipIngram   > Yes, from August 2002 to early 2007.
2023-11-28 12:27:51 <veltas      > Wow so you started doing that in a tough period?
2023-11-28 12:27:59 <KipIngram   > Never "rivaled" my "regular employment" income.
2023-11-28 12:28:10 <KipIngram   > Yes, right on the heels of the tech meltdown.
2023-11-28 12:28:30 <veltas      > I'm trying to refactor things and thinking it would be good to name a word ALLOC+SORT to mean "ALLOC and SORT" or "ALLOCATE then SORT"
2023-11-28 12:28:32 <KipIngram   > But it was that meltdown that changed the situation at my previous employer, where I'd been VERY happy.
2023-11-28 12:28:39 <veltas      > What sort of notation would be best there
2023-11-28 12:29:04 <KipIngram   > But our revenues cratered in 2001, and I'm quite sure if I hadn't quit when I did I'd have been laid off before much longer - at that time mine was the highest salary in the company, and the owner was hurting financially.
2023-11-28 12:29:11 <KipIngram   > And he was perfectly capable of doing my job.
2023-11-28 12:29:29 <veltas      > A very difficult time
2023-11-28 12:30:04 <KipIngram   > I was "just successful enough" to stay at it for those years.
2023-11-28 12:30:24 <KipIngram   > But then we started to want to move into a new home, and it needed to be bigger, so I figured I better go find a real job again.
2023-11-28 12:30:41 <veltas      > Sounds about right
2023-11-28 12:30:46 <KipIngram   > Got a gig with an outfit called Data I/O, in their offshore seismic team.
2023-11-28 12:30:51 <veltas      > Any opinion on my notation question?
2023-11-28 12:31:00 <KipIngram   > Oh, hang on.
2023-11-28 12:31:32 <KipIngram   > Well, I guess it's ok.  Kind of a long name.
2023-11-28 12:32:14 <KipIngram   > You're going to sort something existing into the newly allocated zone?
2023-11-28 12:32:28 <veltas      > I've got no good name for it, I'm just trying to split some work up
2023-11-28 12:32:42 <veltas      > It allocates a secondary buffer for merge sort and does the sort
2023-11-28 12:32:53 <veltas      > The outer word saves and restores HERE
2023-11-28 12:32:55 <KipIngram   > I might consider SORTED
2023-11-28 12:33:07 <KipIngram   > then you could just say <thing> SORTED
2023-11-28 12:33:31 <KipIngram   > Assuming there's some way to figure out how much space you need to allocate from <thing>
2023-11-28 12:33:38 <veltas      > The outer word is called SORT
2023-11-28 12:33:54 <KipIngram   > I see.
2023-11-28 12:34:29 <veltas      > I have  : SORT ( au)   HERE >R  ALLOT+SORT  R> HERE - ALLOT ;
2023-11-28 12:34:31 <veltas      > So far
2023-11-28 12:34:35 <KipIngram   > I often wind up with <word> calling a temporary word .<word>
2023-11-28 12:35:03 <KipIngram   > Usually when .<word> is really doing the work but requires some init and setup.
2023-11-28 12:36:06 <thrig       > recursive things often have a "head" that sets stuff up
2023-11-28 12:36:08 <KipIngram   > Oh, you're 'unallocating" when done?
2023-11-28 12:36:31 <KipIngram   > thrig: Right - I might write something like this:
2023-11-28 12:36:37 <KipIngram   > : foo  <setup>
2023-11-28 12:37:10 <veltas      > KipIngram: Yeah
2023-11-28 12:37:13 <KipIngram   > .: .foo  <task> 0=me;
2023-11-28 12:37:28 <KipIngram   > The "me" words loop back to the latest label, which would be .foo in this case.
2023-11-28 12:37:28 <veltas      > Or trying to anyway, I think it does that.....
2023-11-28 12:37:38 <KipIngram   > I hope it does.
2023-11-28 12:37:52 <KipIngram   > Seems like what it should do with a negative number.
2023-11-28 12:38:32 <veltas      > I'm tempted to do stuff like SORT' but this program actually needs a few levels
2023-11-28 12:38:41 <veltas      > And by SORT'''' or SORT4 it gets a bit old
2023-11-28 12:38:48 <veltas      > But I can do that for lack of better ideas
2023-11-28 12:39:20 <veltas      > I'm going to share it when it's done because I probably need feedback
2023-11-28 12:41:19 <veltas      > Wait, am I being stupid? Is there any point ALLOT'ing all this space to free it?
2023-11-28 12:42:05 <veltas      > Might as well just write to dictionary beyond HERE right(?)
2023-11-28 12:43:02 <GeDaMo      > You could use PAD :P
2023-11-28 12:45:41 <veltas      > Maybe I should use PAD
2023-11-28 12:46:11 <veltas      > There's obviously no safe ANS option but I don't really care about strict adherance, just whatever works for most forths
2023-11-28 12:46:52 <KipIngram   > Yeah, when you need more than one level it gets a lot harder to have "lovely" names.
2023-11-28 12:49:30 <KipIngram   > I'm sorry - I mean more than two.
2023-11-28 12:49:41 <KipIngram   > I just try to avoid that.
2023-11-28 12:50:34 <KipIngram   > In my system there's good justification for a second level, since I'm only able to "loop back" to the BEGINNING of words.  But there's not an equally compelling case for creating third levels.
2023-11-28 12:50:51 <KipIngram   > In the next system I plan to change how that loopback works.
2023-11-28 12:51:14 <KipIngram   > There's going to be a register that holds the beginning address of the current definition, and the jump back will just use that registers to target.
2023-11-28 12:51:31 <KipIngram   > Which means I can have an instruction that "slides it forward" if I want to.
2023-11-28 12:51:52 <KipIngram   > I'll probably call that :~ or something like that.
2023-11-28 12:52:07 <KipIngram   > Start it with a : to indicate that it's "like" having a label there, without really creating a label.
2023-11-28 12:52:12 <KipIngram   > So that code above would become
2023-11-28 12:52:24 <KipIngram   > : foo  <init> :~ <task> 0=me ;
2023-11-28 12:53:06 <KipIngram   > What I don't like about that is it's something else that has to be saved on the return stack on calls.
2023-11-28 12:53:33 <KipIngram   > That's actually why I was asking about the cache related issue on that - I figure once I've stored one thing on the return stack, storing another will be "fast."
2023-11-28 12:53:42 <KipIngram   > Since they're likely going to the same cache line.
2023-11-28 12:53:58 <KipIngram   > And of course it's just as fast to allocate several slots as it is to allocate one.
2023-11-28 12:55:09 <veltas      > The return stack is probably 'hot' usually yeah
2023-11-28 12:55:15 <KipIngram   > But this means that those "within word" jump instructions won't have to have any offset compiled after them.
2023-11-28 12:55:18 <veltas      > Given your return addresses are on there
2023-11-28 12:57:33 <KipIngram   > Yeah, I'm using that to "not let it bother me too much.'
2023-11-28 13:39:40 <veltas      > The issue I have with putting offsets on return stack when they could go in code is the return stack can be small in principle
2023-11-28 13:40:36 <KipIngram   > Yes, that is a consideration.
2023-11-28 13:42:19 <veltas      > And also it just feels wrong
2023-11-28 13:43:40 <KipIngram   > :-)
2023-11-28 13:44:30 <KipIngram   > I first thought of the idea in the context of a Verilog hardware Forth - there it was particularly interesting because it can all be done in parallel.
2023-11-28 13:45:18 <KipIngram   > Part of me just wants to see how it works out, also.  It's something to experiment with.
2023-11-28 13:45:30 <KipIngram   > "just feels wrong" generally means "just feels unfamiliar."
2023-11-28 13:45:55 <KipIngram   > I think i have the same feeling.  It feels "odd."
2023-11-28 13:46:06 <KipIngram   > But I can't see that that means it won't turn out to work well.
2023-11-28 13:51:10 <veltas      > I think it's 'wrong' because of how I think about how code is usually generated and how I'd always trade a little code space for memory space
2023-11-28 13:51:58 <veltas      > This reminds me of the LEAVE controvery
2023-11-28 13:52:04 <veltas      > controversy*
2023-11-28 13:54:08 <KipIngram   > I'm not familiar wit that one.  It's hard to say what the real full tradeoff is.  I use those "me" words quite a lot - having all of them be 7 bits instead of 7 bits + variable size offset (it would be "the rest of the cell", which can vary) would like add up to quite a lot of saved code space.
2023-11-28 13:54:57 <KipIngram   > I'd need to know "average" calls stack depth to figure out how much memory would move on the other side.
2023-11-28 13:55:12 <KipIngram   > But I don't think it's "obvious" that it would increase overall RAM usage to do this.
2023-11-28 13:55:45 <KipIngram   > If I were expecting to have some ungodly large number of threads it likely would, but while I expect to have more than one thread I'm not expecting it to be a huge number.
2023-11-28 13:56:38 <KipIngram   > I'm more nervous about the fact that it consumes a register than anything else.
2023-11-28 13:57:05 <veltas      > KipIngram: The controversy is LEAVE used to set I to I' (so loop would end at next LOOP)
2023-11-28 13:57:38 <KipIngram   > Ah, I see.  Isn't that exactly the POINT of LEAVE, though?
2023-11-28 13:57:44 <KipIngram   > Why was it controversial?
2023-11-28 13:57:56 <veltas      > And at some point standard opted for LEAVE to actually leave the loop as well, jump past LOOP
2023-11-28 13:58:05 <KipIngram   > Aha.
2023-11-28 13:58:22 <KipIngram   > That seems like more of a debate over functionality than over implementation.
2023-11-28 13:58:25 <veltas      > At the time the only easy way to implement that was to add the exit address for loop to the return stack
2023-11-28 13:58:34 <KipIngram   > I see.
2023-11-28 13:58:35 <veltas      > That's still the easy way actually
2023-11-28 13:58:40 <KipIngram   > Ok, that makes sense.
2023-11-28 13:58:48 <veltas      > But that broke assumptions for many forths and much code
2023-11-28 13:58:58 <veltas      > Because forever it was just I and I' then J and J'
2023-11-28 13:59:04 <KipIngram   > Right.
2023-11-28 13:59:11 <KipIngram   > And Forth invites you to tinker with such things.
2023-11-28 13:59:26 <veltas      > IMO they should have kept the old LEAVE, it's usually no difference to code
2023-11-28 13:59:53 <veltas      > There *is* a workaround to generate the exit code but it's ugly, you have to be able to handle any number of LEAVE's in a loop
2023-11-28 13:59:56 <PoppaVic    > Tinkering is good, but I am not a big fan of the "Professionals" vetting the non-standards
2023-11-28 14:00:19 <KipIngram   > Oh, I wasn't criticizing tinkering.
2023-11-28 14:00:36 <KipIngram   > I just meant that Forth exposes the return stack and basically doesn't prohibit you doing anything to it you want.
2023-11-28 14:00:41 <PoppaVic    > KipIngram, I know, I was criticizing the supposed professionals
2023-11-28 14:00:53 <PoppaVic    > right.
2023-11-28 14:00:57 <KipIngram   > And suddenly having a new item show up in your return stack frame would definitely wreak havoc with past work of that sort.
2023-11-28 14:01:04 <PoppaVic    > We just want shit consistent and DOCUMENTED
2023-11-28 14:01:28 <veltas      > Yeah if you assume J is the third return stack item for instance
2023-11-28 14:01:40 <veltas      > It's quite convenient if it's true to be able to name the return stack items
2023-11-28 14:01:45 <KipIngram   > Yes.
2023-11-28 14:03:39 <veltas      > PoppaVic: I'm not sure what you mean by 'professionals' vetting non-standards
2023-11-28 14:03:45 <PoppaVic    > This all tends to make me miss the "stack frame", kip
2023-11-28 14:04:14 <PoppaVic    > veltas, don't sweat it - kip knows my feelings on this , and the ANS, etc
2023-11-28 14:07:25 <veltas      > Was just wondering what you meant, I don't know how to parse that
2023-11-28 14:07:54 <veltas      > I'm not a huge fan of the standard personally, but at same time I gravitate towards it to allow writing code I can run on the most forths
2023-11-28 14:08:17 <veltas      > Well I'm quite critical of the standard on here
2023-11-28 14:08:32 <PoppaVic    > well, yeah - all we can do is settle on one and try to follow it - which is why i cheer kip from the stands ;-)
2023-11-28 14:10:47 <KipIngram   > Shouldn't J be coded to "know" what to do given the implemENTATION?
2023-11-28 14:11:04 <veltas      > Not sure what you mean
2023-11-28 14:11:21 <KipIngram   > Well, J isn't where it used to be - but J is a primitive, right?
2023-11-28 14:11:28 <KipIngram   > It should be aware of the change too.
2023-11-28 14:11:29 <user51      > Wrote a simple array and an array loop http://0x0.st/Hxzq.forth
2023-11-28 14:11:57 <veltas      > KipIngram: That's not the issue, the issue is people used to be able to reliably assume J was the outer loop index *and* the third return stack item
2023-11-28 14:12:06 <veltas      > J is still the outer loop index
2023-11-28 14:12:07 <KipIngram   > One really shouldn't make "assumptions" about where J is - it should the word J to get it.
2023-11-28 14:12:22 <KipIngram   > I'm  not sure I see why that latter is necessary.
2023-11-28 14:12:30 <veltas      > It's not necessary it was just handy
2023-11-28 14:12:35 <KipIngram   > Ok.
2023-11-28 14:12:42 <veltas      > It's almost like having registers
2023-11-28 14:12:50 <KipIngram   > PoppaVic: I definitely like the stack frames I've added to my system.
2023-11-28 14:14:13 <veltas      > I know for sure if I was around in the fig days I would have used it
2023-11-28 14:14:36 <veltas      > But now the fig tree has withered
2023-11-28 14:19:06 <PoppaVic    > well, the FIG could is still allllllll over - and easy to implement.
2023-11-28 14:19:23 <PoppaVic    > BUT, I think kip has a Better Idea, and I keep hoping to see it working
2023-11-28 14:19:49 <veltas      > If I pull my thumb out and finish a desktop forth I'll definitely support most of the fig words
2023-11-28 14:20:00 <veltas      > Including I I' J J' etc
2023-11-28 19:50:32 <zelgomer    > : pad ( u ) .pad @ tuck tuck + fff and swap -1000 and or .pad ! ;  is there a better way to do that?
2023-11-28 19:51:07 <zelgomer    > oops stack effect should be ( u -- a )
2023-11-28 20:08:02 <KipIngram   > Obviously that doesn't support any sort of concurrent multiple use cases.
2023-11-28 20:08:29 <KipIngram   > Nor can it be used in a way that preserves something across compilation actions.
2023-11-28 20:14:29 <KipIngram   > What is that doing?  It looks like it's making copies of something, choosing the bottom 12 bits of a copy, clearing the bottom 12 bits of another, and then oring them together - does it actually do something significant?
2023-11-28 20:15:16 <KipIngram   > Oh, well, that + happens in there, so the copies aren't all the same.
2023-11-28 20:28:25 <zelgomer    > it's just wrapping at the 4k boundary
2023-11-28 20:28:50 <zelgomer    > u is an unsigned integer
2023-11-28 22:32:55 <KipIngram   > Ah, ok.
2023-11-28 22:33:00 <KipIngram   > This is fun:
2023-11-28 22:33:02 <KipIngram   > https://www.youtube.com/watch?v=kFYKyZvu2Bo
2023-11-28 22:33:31 <KipIngram   > It's about StuxNet, and asserts it was a directed attack against Iranian uraninum enrichment facilities.
2023-11-28 22:33:50 <KipIngram   > took over the centrefuge controllers and caused them to damage themselves.
2023-11-28 22:34:07 <KipIngram   > centrifuge
2023-11-28 22:34:33 <KipIngram   > All while tricking out the monitoring systems so that the human keepers thought everything was fine.
2023-11-28 22:35:15 <thrig       > aws dashboard shows green because the red can't be loaded from aws
2023-11-28 22:36:06 <KipIngram   > Apparently the US, the UK, and Israel have collaborated on an even more thorough system (according to NSA leaks) called "Nitro Zeus," again targeted largely at Iran.
2023-11-28 22:37:20 <KipIngram   > That was all kind of an eye opener for me.  That's not just hackng - that's actual cyber WAR in the full sense of the term.
2023-11-28 22:37:44 <KipIngram   > In 2010.
2023-11-28 23:08:02 <KipIngram   > Anyway, I find it rather hilarious that Iran has an off switch, and even more hilarious that it's in Washington D.C.