00:00:13
##forth
<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
00:01:27
##forth
<veltas>
e_type of ET_EXEC vs ET_DYN
00:21:11
##forth
<xentrac>
Zarutian_iPad: sort of, but most of them can't be executed on their own
00:28:51
##forth
<Zarutian_iPad>
mean in the sense of the format
01:31:01
##forth
<veltas>
Whoops just used a linked list
01:31:27
##forth
<veltas>
Don't tell Mr Munroe
01:36:24
##forth
<thrig>
.so are executable on linux but maybe not other OS
01:56:51
##forth
<xentrac>
right, I think we were implicitly limiting to Linux here
01:59:45
##forth
<MrMobius>
you may be able to run an .so compiled on one version of linux on another. this has bitten me
02:00:16
##forth
<MrMobius>
*may not
02:05:30
##forth
<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.
02:06:29
##forth
<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.
02:06:46
##forth
<thrig>
a user once upgraded libc so they could run some program, back in the redhat 4 days
02:10:52
##forth
* crc remembers having to install different libc versions to run programs before
02:41:37
##forth
<MrMobius>
xentrac: youre disagreeing to disagree again unless you really think different versions of linux dont have incompatible library forms
02:42:52
##forth
<amby>
isnt there a whole torvalds rant about "we do not break userspace"
02:48:20
##forth
<
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."
02:49:36
##forth
<thrig>
openbsd ships a kernel+userland, linux is a kernel from here and random userspace from there
02:50:53
##forth
<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)
02:50:53
##forth
<thrig>
so openbsd can update the kernel+ifconfig while on linux you need to invent a new userspace tool
02:52:38
##forth
<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.
02:53:27
##forth
<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.)
02:53:54
##forth
<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."
02:55:50
##forth
<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
02:56:48
##forth
<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.
02:58:57
##forth
<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.
02:59:55
##forth
<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.
03:01:17
##forth
<xentrac>
(If the current version of Linux is using a different architecture, you may need to install qemu-user.)
03:07:39
##forth
<MrMobius>
xentrac: you can have problems with the elf loader for one
03:10:02
##forth
<MrMobius>
xentrac: or a different version of a library on one linux
03:10:53
##forth
<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
03:11:13
##forth
<MrMobius>
where version may mean version number or distro like when ive compiled something on debian and it wont work on ubuntu
03:53:51
##forth
<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.
03:54:59
##forth
<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.
03:57:28
##forth
<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.
06:13:51
##forth
<vms14>
I have to stacks now, and rpn speak i
06:13:59
##forth
<vms14>
so now I'm welcome here :D
06:16:15
##forth
<vms14>
but it's not a return stack :/
06:16:27
##forth
<vms14>
it's just an auxiliar stack xd
06:16:54
##forth
<vms14>
also do loop does not push into that stack, but has an additional loop stack
06:18:14
##forth
<vms14>
well then I have like 5 stacks xd
06:18:26
##forth
<vms14>
and no one of them is a return stack
08:15:07
##forth
<veltas>
What goes in the aux stack?
11:38:40
##forth
<zelgomer>
auxiliaries
11:39:55
##forth
<zelgomer>
vms14: when control reaches the end of a word, how does it know where to go next?
15:19:12
##forth
<vms14>
zelgomer you mean like what happens after 'then'?
15:19:32
##forth
<vms14>
the code is appended to the colon word definition
15:20:44
##forth
<vms14>
when a colon word is executed I use a loop on the host language to iterate it
15:22:02
##forth
<vms14>
I have a half implementation in js that might be easier to read than perl
15:22:18
##forth
<vms14>
it's much shorter only implements ':' and ';'
15:23:09
##forth
<vms14>
there are no more words so you can only use numbers
15:23:22
##forth
<vms14>
but if will follow a similar process than ':'
15:23:48
##forth
<vms14>
the perl implementation is using the same principle than in the js version, but I guess will be harder to read
15:24:52
##forth
<vms14>
if then else are immediate, if pushes a true compiling flag, but actually instead of pushing '1' pushes 'if' which counts as true
15:25:56
##forth
<vms14>
the 'then' word does everything, taking the code from the last list on the compilation list of lists
15:26:39
##forth
<vms14>
I'm not sure about this way of having a list of lists for compiled code and a list of states
15:26:45
##forth
<vms14>
I guess it will bite me back later
15:31:21
##forth
<vms14>
I was considering into add a pfa and a cfa for words
15:32:05
##forth
<vms14>
I want to test this current approach because I'm not sure about it
15:32:16
##forth
<vms14>
if it ends breaking I will try a different path
15:32:52
##forth
<vms14>
my goal is to find a balance between forth and the fact that I'm using a high level lang to implement it
15:33:07
##forth
<vms14>
if I go near to forth I fight the host language
15:33:25
##forth
<vms14>
if I go away from forth I fear that I'll make a useless language
15:33:47
##forth
<vms14>
so I need a middle ground
15:34:40
##forth
<xentrac>
I'm sure that when you're using it you'll gain confidence in which direction to take it
15:42:54
##forth
<vms14>
that might help to see what happens, or might be more confusing even
15:43:05
##forth
<vms14>
[] is the stack which is empty
15:43:13
##forth
<vms14>
<> is the compilation states list
15:43:27
##forth
<vms14>
the rest is my input
15:44:14
##forth
<zelgomer>
vms14> zelgomer you mean like what happens after 'then'?
15:44:28
##forth
<zelgomer>
no, i said when control reaches the end of a word
15:44:55
##forth
<vms14>
it will read the next element from the source code
15:45:15
##forth
<vms14>
well I do not know what are you asking
15:45:22
##forth
<zelgomer>
i can tell
15:45:26
##forth
<vms14>
:D
15:46:02
##forth
<vms14>
a colon word is just a list of subroutines, so I just iterate on them
15:46:15
##forth
<zelgomer>
: 3* dup 2* + ; ( what happens after the '+' is executed?)
15:47:30
##forth
<vms14>
nothing actually. when I execute '3*' I just iterate on its code which will be a list of perl/js functions
15:48:03
##forth
<vms14>
after that I will read the next word
15:48:44
##forth
<zelgomer>
: 2* dup + ; : 3* dup 2* + ; ( what happens when control reaches the end of 2*?)
15:49:07
##forth
<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
15:49:37
##forth
<zelgomer>
so you're inlining everything?
15:49:45
##forth
<vms14>
yes
15:50:55
##forth
<zelgomer>
that's weird
15:50:55
##forth
<vms14>
I kind of like it because it means colon words have no effect in performance
15:50:57
##forth
<zelgomer>
did they have any effect on performance if you don't inline?
15:51:42
##forth
<vms14>
I was not compiling before, and when I 'compile' I always do that
15:51:59
##forth
<zelgomer>
that's not what i asked though
15:52:12
##forth
<vms14>
I guess they would
15:52:18
##forth
<zelgomer>
you guess?
15:52:25
##forth
<zelgomer>
which means you didn't measure it
15:52:26
##forth
<vms14>
depends on what way I would do it
15:52:44
##forth
<zelgomer>
do you know what we call this?
15:52:50
##forth
<vms14>
return stack?
15:52:58
##forth
<zelgomer>
no, premature optimization
22:00:00
##forth
<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
22:00:25
##forth
<user51>
code words?
22:00:43
##forth
<user51>
maybe 'builtin'?
22:01:09
##forth
<pgimeno>
builtin sounds pretty accurate, thanks
23:58:03
##forth
<xentrac>
usually it's "CODE words"