2025-02-12 00:00:13 <veltas      > Yeah I think they've got a different tag or something but if you have an entry point maybe it doesn't matter to Linux's loader
2025-02-12 00:01:27 <veltas      > e_type of ET_EXEC vs ET_DYN
2025-02-12 00:21:11 <xentrac     > Zarutian_iPad: sort of, but most of them can't be executed on their own
2025-02-12 00:28:51 <Zarutian_iPad> mean in the sense of the format
2025-02-12 01:31:01 <veltas      > Whoops just used a linked list
2025-02-12 01:31:27 <veltas      > Don't tell Mr Munroe
2025-02-12 01:36:24 <thrig       > .so are executable on linux but maybe not other OS
2025-02-12 01:40:13 <thrig       > https://unix.stackexchange.com/questions/223385 or some linux
2025-02-12 01:56:51 <xentrac     > right, I think we were implicitly limiting to Linux here
2025-02-12 01:59:45 <MrMobius    > you may be able to run an .so compiled on one version of linux on another. this has bitten me
2025-02-12 02:00:16 <MrMobius    > *may not
2025-02-12 02:05:30 <xentrac     > that's pretty unlikely.  what does happen pretty often is that your .so is linked with libraries that are not present on the other machine, or present only in incompatible forms.  The version of Linux is almost never the problem; it's the versions of the other .sos.
2025-02-12 02:06:29 <xentrac     > there *are* cases where a system call is removed or some restriction is added, but that's pretty rare.  I only know of two cases: uselib() and the lowest allowable load address.
2025-02-12 02:06:46 <thrig       > a user once upgraded libc so they could run some program, back in the redhat 4 days
2025-02-12 02:10:52 <crc         > 
ACTION remembers having to install different libc versions to run programs before

2025-02-12 02:41:37 <MrMobius    > xentrac: youre disagreeing to disagree again unless you really think different versions of linux dont have incompatible library forms
2025-02-12 02:42:52 <amby        > isnt there a whole torvalds rant about "we do not break userspace"
2025-02-12 02:44:54 <crc         > amby: yes; https://lkml.org/lkml/2012/12/23/75
2025-02-12 02:48:20 <crc         > contrasting with theo de raadt's approach on openbsd; https://marc.info/?l=openbsd-tech&m=157489277318829&w=2 "Program to the API rather than the ABI. When we see benefits, we change the ABI more often than the API. I have altered the ABI. Pray I do not alter it further."
2025-02-12 02:49:36 <thrig       > openbsd ships a kernel+userland, linux is a kernel from here and random userspace from there
2025-02-12 02:50:53 <crc         > I've seen a lot more ABI breakage on the various BSD systems I've used than on Linux, but this makes sense in considering the development models (as thrig just mentioned)
2025-02-12 02:50:53 <thrig       > so openbsd can update the kernel+ifconfig while on linux you need to invent a new userspace tool
2025-02-12 02:52:38 <xentrac     > MrMobius: different versions of Linux *did* support different kinds of shared library, yes.  In like 01998.  That's the uselib() thing I mentioned.  It hasn't happened since then to my knowledge.
2025-02-12 02:53:27 <xentrac     > (In theory the load address change could have broken existing code but I think I've personally written most of the code that it broke.)
2025-02-12 02:53:54 <MrMobius    > xentrac: youre missing the point. its the same nonsense youve done in here before where someone says "He was shot to death" and you say "No, no, not so. Not at all. It was in fact the bullet that killed him. You're wrong."
2025-02-12 02:55:50 <MrMobius    > it's annoying when you disagree just to disagree. sometimes .sos dont work on another version of linux and yes it is because of the libraries. saying it's not the version of linux but instead the libraries is nonsense. you cant honestly think when I say it doesnt work on other versions of linux that I cant have meant it had anything to do with libraries
2025-02-12 02:56:48 <xentrac     > I think you'll have to be a little bit clearer about what you're saying in order for me to be able to agree or disagree with you; right now it sounds like you're just blathering nonsense.
2025-02-12 02:58:57 <xentrac     > Linux maintains a stable ABI.  You can take a (non-a.out) Linux shared library from 30 years ago and, in almost all cases, run it on any current version of Linux.
2025-02-12 02:59:55 <xentrac     > The other way around doesn't always work because current Linux supports some system calls that Linux didn't support 30 years ago.  Possibly that's what you meant.
2025-02-12 03:01:17 <xentrac     > (If the current version of Linux is using a different architecture, you may need to install qemu-user.)
2025-02-12 03:07:39 <MrMobius    > xentrac: you can have problems with the elf loader for one
2025-02-12 03:10:02 <MrMobius    > xentrac: or a different version of a library on one linux
2025-02-12 03:10:53 <MrMobius    > what I mean is both of these things qualify as problems you may have when you compile a .so on one version and try to run it on another
2025-02-12 03:11:13 <MrMobius    > where version may mean version number or distro like when ive compiled something on debian and it wont work on ubuntu
2025-02-12 03:53:51 <xentrac     > The only problem I've had with the ELF loader was the change in the lowest allowable load address, but maybe there have been others.  I haven't run into them.
2025-02-12 03:54:59 <xentrac     > It's true that different distributions often have different sets of libraries, but that's only very loosely related to the version of Linux they're using.  It can happen even when both distros use the same version of Linux.
2025-02-12 03:57:28 <xentrac     > But avoiding that problem is just a matter of avoiding runtime dependencies on other libraries, either by compiling them in or by not using them.  And fixing it doesn't require using a different version of Linux; it just requires making available a compatible version of the library in question, potentially with hacks like LD_PRELOAD, LD_LIBRARY_PATH, or chroot.
2025-02-12 06:13:51 <vms14       > I have to stacks now, and rpn speak i
2025-02-12 06:13:59 <vms14       > so now I'm welcome here :D
2025-02-12 06:16:15 <vms14       > but it's not a return stack :/
2025-02-12 06:16:27 <vms14       > it's just an auxiliar stack xd
2025-02-12 06:16:54 <vms14       > also do loop does not push into that stack, but has an additional loop stack
2025-02-12 06:18:14 <vms14       > well then I have like 5 stacks xd
2025-02-12 06:18:26 <vms14       > and no one of them is a return stack
2025-02-12 08:15:07 <veltas      > What goes in the aux stack?
2025-02-12 11:38:40 <zelgomer    > auxiliaries
2025-02-12 11:39:55 <zelgomer    > vms14: when control reaches the end of a word, how does it know where to go next?
2025-02-12 15:19:12 <vms14       > zelgomer you mean like what happens after 'then'?
2025-02-12 15:19:32 <vms14       > the code is appended to the colon word definition
2025-02-12 15:20:44 <vms14       > when a colon word is executed I use a loop on the host language to iterate it
2025-02-12 15:22:02 <vms14       > I have a half implementation in js that might be easier to read than perl
2025-02-12 15:22:18 <vms14       > it's much shorter only implements ':' and ';'
2025-02-12 15:22:49 <vms14       > https://dpaste.com/8CRWPQNFY.txt
2025-02-12 15:23:09 <vms14       > there are no more words so you can only use numbers
2025-02-12 15:23:22 <vms14       > but if will follow a similar process than ':'
2025-02-12 15:23:48 <vms14       > the perl implementation is using the same principle than in the js version, but I guess will be harder to read
2025-02-12 15:24:12 <vms14       > https://dpaste.com/BHY222GSJ.txt
2025-02-12 15:24:52 <vms14       > if then else are immediate, if pushes a true compiling flag, but actually instead of pushing '1' pushes 'if' which counts as true
2025-02-12 15:25:56 <vms14       > the 'then' word does everything, taking the code from the last list on the compilation list of lists
2025-02-12 15:26:39 <vms14       > I'm not sure about this way of having a list of lists for compiled code and a list of states
2025-02-12 15:26:45 <vms14       > I guess it will bite me back later
2025-02-12 15:31:21 <vms14       > I was considering into add a pfa and a cfa for words
2025-02-12 15:32:05 <vms14       > I want to test this current approach because I'm not sure about it
2025-02-12 15:32:16 <vms14       > if it ends breaking I will try a different path
2025-02-12 15:32:52 <vms14       > my goal is to find a balance between forth and the fact that I'm using a high level lang to implement it
2025-02-12 15:33:07 <vms14       > if I go near to forth I fight the host language
2025-02-12 15:33:25 <vms14       > if I go away from forth I fear that I'll make a useless language
2025-02-12 15:33:47 <vms14       > so I need a middle ground
2025-02-12 15:34:40 <xentrac     > I'm sure that when you're using it you'll gain confidence in which direction to take it
2025-02-12 15:42:54 <vms14       > that might help to see what happens, or might be more confusing even
2025-02-12 15:42:55 <vms14       > https://i.imgur.com/7pJH4Vz.png
2025-02-12 15:43:05 <vms14       > [] is the stack which is empty
2025-02-12 15:43:13 <vms14       > <> is the compilation states list
2025-02-12 15:43:27 <vms14       > the rest is my input
2025-02-12 15:44:14 <zelgomer    > vms14> zelgomer you mean like what happens after 'then'?
2025-02-12 15:44:28 <zelgomer    > no, i said when control reaches the end of a word
2025-02-12 15:44:55 <vms14       > it will read the next element from the source code
2025-02-12 15:45:15 <vms14       > well I do not know what are you asking
2025-02-12 15:45:22 <zelgomer    > i can tell
2025-02-12 15:45:26 <vms14       > :D
2025-02-12 15:46:02 <vms14       > a colon word is just a list of subroutines, so I just iterate on them
2025-02-12 15:46:15 <zelgomer    > : 3*  dup 2* + ;  ( what happens after the '+' is executed?)
2025-02-12 15:47:30 <vms14       > nothing actually. when I execute '3*' I just iterate on its code which will be a list of perl/js functions
2025-02-12 15:48:03 <vms14       > after that I will read the next word
2025-02-12 15:48:44 <zelgomer    > : 2*  dup + ;  : 3*  dup 2* + ;  ( what happens when control reaches the end of 2*?)
2025-02-12 15:49:07 <vms14       > : oh 1 2 3 ; : meh oh 4 5 6 ;   oh gets appended into 'meh' so the code of 'meh' is actually 1 2 3 4 5 6
2025-02-12 15:49:37 <zelgomer    > so you're inlining everything?
2025-02-12 15:49:45 <vms14       > yes
2025-02-12 15:50:55 <zelgomer    > that's weird
2025-02-12 15:50:55 <vms14       > I kind of like it because it means colon words have no effect in performance
2025-02-12 15:50:57 <zelgomer    > did they have any effect on performance if you don't inline?
2025-02-12 15:51:42 <vms14       > I was not compiling before, and when I 'compile' I always do that
2025-02-12 15:51:59 <zelgomer    > that's not what i asked though
2025-02-12 15:52:12 <vms14       > I guess they would
2025-02-12 15:52:18 <zelgomer    > you guess?
2025-02-12 15:52:25 <zelgomer    > which means you didn't measure it
2025-02-12 15:52:26 <vms14       > depends on what way I would do it
2025-02-12 15:52:44 <zelgomer    > do you know what we call this?
2025-02-12 15:52:50 <vms14       > return stack?
2025-02-12 15:52:58 <zelgomer    > no, premature optimization
2025-02-12 22:00:00 <pgimeno     > I see that in Forth jargon, there's a bit of relaxation of the word 'primitives', because very often they aren't. Is there a word for actual "primitive primitives"? that is, words that aren't implemented from other words
2025-02-12 22:00:25 <user51      > code words?
2025-02-12 22:00:43 <user51      > maybe 'builtin'?
2025-02-12 22:01:09 <pgimeno     > builtin sounds pretty accurate, thanks
2025-02-12 23:58:03 <xentrac     > usually it's "CODE words"