00:00:00 --- log: started forth/17.04.27 01:33:33 --- quit: ACE_Recliner (Remote host closed the connection) 01:46:49 --- join: GeDaMo (~GeDaMo@212.225.127.213) joined #forth 01:53:58 Perhaps I'm a bit unfamiliar with dealing with apple, but why would you need permission from them to release software? 01:55:10 Apple has a walled garden for iOS, have they implemented the same for MacOS? 02:05:26 --- join: true-grue (~true-grue@176.14.219.178) joined #forth 03:07:11 --- join: bedah (~bedah@dyndsl-091-248-160-027.ewe-ip-backbone.de) joined #forth 03:11:08 GeDaMo: I don't think so 03:11:29 you can install software on OSX outside the Apple store 03:11:44 ... for now >:-D 03:11:55 heh 03:12:16 I know I've seen suggestions that Apple are considering it 03:17:45 I will never understand people willingly subjecting themselves to tyranny... 03:19:35 Many don't understand that there's a choice 03:20:18 well, then people will just "jailbreak" OSX 03:31:30 --- quit: John[Lisbeth] (Quit: ERC (IRC client for Emacs 24.5.1)) 03:31:55 --- join: John[Lisbeth] (~user@2601:601:8f01:a6a0:ad0b:afa2:dcf7:84c5) joined #forth 03:34:07 many people don't understand that tyranny can be not only from governmetn 03:34:30 even worse, corporate tyranny is sometimes way worse than gov 03:37:55 at work i've seen some pretty extreme examples of that in form of completely fine specialized hardware that's basically no longer usable thanks to vendor support being ridiculously expensive and hardware documentation non-existing 03:45:44 --- quit: nighty-- (Quit: Disappears in a puff of smoke) 04:11:59 yeah 04:15:40 On macOS there is an optional walled garde (then. 04:16:37 Iirc, apps distributed through the App Store get access to some APIs related to iCloud that aren't supported in apps distributed independently 04:38:51 --- quit: dys (Read error: Connection reset by peer) 04:43:16 --- join: nighty-- (~nighty@s229123.ppp.asahi-net.or.jp) joined #forth 05:07:17 --- quit: wa5qjh (Remote host closed the connection) 05:10:20 --- join: wa5qjh (~Thunderbi@121.54.90.153) joined #forth 05:24:26 --- quit: wa5qjh (Remote host closed the connection) 05:33:53 --- join: wa5qjh (~Thunderbi@121.54.90.153) joined #forth 06:03:05 whenever i'm away from forth for a couple years and then return to it, i end up taking a week or so to factor and order arguments so as not to paint myself into stack gymnastic corners 06:03:15 not sure why those instincts seem to decay fairly quickly 06:44:16 the solution is too not stop using forth :) 06:46:24 never gonna give forth up 06:53:31 --- quit: wa5qjh (Ping timeout: 260 seconds) 06:54:55 never gonna ROT TUCK drown. never gonna tell a lie and DEFER you 07:08:06 so far my experience with forth is: I don't know how you ever actually stop refactoring everything and actually make progress 07:08:36 I feel like every time I make a little step forward, I realize I've done everything terribly inefficiently and so I stop and reiterate 07:09:35 yeah, i run into that for awhile whenever i have not written much forth for some time 07:16:22 wish i could find the mandelbrot renderer i wrote awhile back. complex numbers on the stack are a bit hairy, and i factored it sensibly .. somehow 07:16:41 s/on the stack/on the floating point stack/ 07:52:03 are there any Forths left that have a unified stack with floats and integers on the same stack? 07:57:20 Almost any Forth which is written in a dynamic language. 08:01:51 DocPlatypus: not sure, but i keep meaning to implement such, since with 64-bit cell size one can just have double-precision floats directly on the data stack 08:02:16 the only forth i've used much for floating point is bigforth, which is 32-bit and has a separate float stack 08:08:43 otoh it is often convenient to have a separate stack for math and program logic+pointer arithmetic 08:08:58 s/a separate stack/separate stacks/ 08:15:51 --- join: neceve (~ncv@86.125.247.109) joined #forth 08:15:51 --- quit: neceve (Changing host) 08:15:51 --- join: neceve (~ncv@unaffiliated/neceve) joined #forth 08:28:12 I'm planning to write an "array Forth" where elements on the data stack are arrays (or pointers to arrays) with whole-array-operations as primitives 08:39:46 A stack with just one element -- array? :) 08:40:47 Each stack element is a pointer to an array, yes 08:42:39 so every word is a vector operator 08:43:35 Either an elementwise operation or reducing/folding 08:45:47 so no bare atoms on the stack at all? 08:46:14 I'm not sure yet, I may encounter problems during implementation :P 08:47:11 then simple binary arithmetic operators become either an array concatenation or iteration through two arrays 08:47:17 Yes 08:48:32 kind of curious what the use case is 08:49:38 "apl would be nice if the syntax wasn't horrid?" 08:49:41 GeDaMo, My point is that with an array you don't need a stack and you'll get APL/J/K/FP instead of Forth :) 08:49:41 It's inspired by array languages like APL, J, K but I find those difficult to read 08:50:24 *nod* 08:50:36 have read about apl but never actually tried to use it 08:50:54 Also whole-array-operations are superinstructions, they remove a lot of interpreter overhead 08:51:03 And make it easier to use vector units 08:51:10 right 08:51:21 true-grue: you still have to pass parameters to words / functions 08:52:29 They'll also remove a lot of explicit loops, possibly conditionals and hopefully some stack shuffling 08:52:38 GeDaMo, Or you can just transform the same array. Have you seen FP/FL languages? 08:52:57 Yes 09:17:18 --- quit: DocPlatypus (Ping timeout: 260 seconds) 09:35:17 --- join: DocPlatypus (~skquinn@2601:2c2:c300:ff70:20c5:925f:c41:93ca) joined #forth 09:43:40 --- join: John[Lis` (~user@2601:601:8f01:a6a0:ad0b:afa2:dcf7:84c5) joined #forth 09:47:44 --- quit: John[Lisbeth] (Ping timeout: 246 seconds) 09:48:14 --- join: mark4 (~mark4@cpe-76-182-218-46.tx.res.rr.com) joined #forth 09:57:49 it's mark4! 09:58:51 lol 09:59:04 I've been wanting to ask you a thing about x4 09:59:05 i dont have interwebs at home, im at a buddies office running gentoo updates 09:59:09 sure 09:59:15 ask away :) 09:59:33 I mean, it's a rather insignificant thing, probably 10:00:05 but if I read it correctly, you don't have an also word, but instead vocabulary words push themselves onto the search order stack rather than the traditional behavior of replacing the top item? 10:00:27 correct. and if the vocab is already there it rotates out to top 10:00:48 so you cant add the same vocab to the context stack more than once 10:00:59 but what you CAN do is create a new context stack 10:01:18 i have a stack of context stacks and top context of this stack is the current search order 10:01:57 ah, okay. I was going to say, that would create unpredictable situations because some code might push a vocab without knowing some other code already had it on the stack, but I guess the multi-context-stack thing might provide a way to avoid that 10:02:53 so you can leave a search order intact and add/remove anything you want 10:06:06 okay, so I guess that explains why you didn't opt for the also pattern I normally see. that would directly conflict with your appear-only-once-in-the-stack behavior 10:14:06 yea this way is slightly more complex but to my mind is a neater solution 10:14:09 i like it better 10:14:20 if you look in src/ext/vocabs.f i think its all in there 10:14:43 im going to mcdonnalds round the corner for a cofffee. not had a cup of coffeeeeee in a month lol 10:14:46 bad mojo 10:14:47 brb 10:21:45 thanks! 10:42:23 back 10:42:31 coffee wasnt great but its better than nothing lol 10:43:07 so are you using x4 at all? 10:43:20 --- join: bandrami (~weldon@wsip-70-183-4-87.dc.dc.cox.net) joined #forth 10:43:21 there are some neat things in there that are not standard but i think the standard sucks anyway 10:43:46 --- part: bandrami left #forth 10:46:36 --- join: Zarutian (~zarutian@168-110-22-46.fiber.hringdu.is) joined #forth 10:48:02 no, I'm not actually using it. to be honest, I was using it for a while as a cheat sheet to see a sane implementation of a few things 10:49:37 and I don't mind standard nonconformance; I try to be careful to use words like "canonical" or "traditional," and not "standard," to make it clear I'm talking about how classical forth words generally work, and not necessarily ans 10:52:25 yea isforth is sort of based on the 83 standard sort of :P 10:52:33 x4 now 10:53:09 would love to create an FFI ext to allow loading of c libs 10:53:36 my android version (not released) can link to libs at build time but not for ext's 10:53:39 yet 11:06:21 --- join: dys (~dys@109.40.2.254) joined #forth 11:07:10 mark4: Something I've been wondering about for awhile - how exactly does one go about loading C libraries, in general? Does it vary a lot by OS? 11:08:21 On Linux, you have dlopen 11:08:36 which is itself a C library thing, right? 11:08:40 Yes 11:10:07 So the kernel would have to be built with dlopen available, then? 11:10:55 "kernel" as in the Forth? Yes 11:11:33 you could do that, or you could implement what dlopen does in forth: you mmap the library's appropriate sections into your process space and resolve dynamic symbols 11:11:39 dlopen is a system call no? 11:11:43 no 11:11:48 well, mmap and friends are 11:11:48 No, it's a library 11:12:59 zy]x[yz: reasons for C approach vs manual loading? 11:13:09 linux & bsd: dlopen()/dlsym(), windows LoadLibrary()/GetProcAddress() 11:13:29 reepca, "manual loading?" 11:13:44 what you described, the mmap and resolving dynamic symbols stuff 11:14:04 dlopen is posix; it abstracts all of that stuff 11:14:05 It's a lot of work to do it manually 11:14:12 --- quit: neceve (Quit: Konversation terminated!) 11:14:13 and it's a lot of work 11:21:05 So for example for a self-hosting forth, the way it would get... "access", I guess, to dlopen() and such would be to dynamically link to the relevant C library? And setting that up is part of the process of building the executable, right? 11:21:28 if you statically link it in, yes 11:22:18 if you dynamically link, you're basically looking at reimplementing what dlopen()/etc and ld do 11:22:53 I thought there was a difference between linking and loading 11:22:56 admittedly I don't know a whole lot about the details myself; that's all on my bucket list of things I'd like to dig more into some day 11:24:19 dynamic-linking versus static-linking are similar, it's just that the former does stuff at runtime and in memory, and the latter does stuff at compile time and in the target binary image 11:24:58 Use strace and watch the syscalls, you'll see it searching for libraries and mmaping them 11:25:36 I thought it went static-linking => at build-time, dynamic-linking => at program-start-time, dynamic-loading => at any time during program's execution 11:25:45 which, if you statically link, that mmapping still happens, it just happens in ld before your program ever starts 11:25:46 --- join: gravicappa (~gravicapp@ppp83-237-173-252.pppoe.mtu-net.ru) joined #forth 11:26:30 and it's mmapping parts of your program image, not searching for libraries in the system 11:29:27 maybe I should stop talking now before I make it too obvious that I don't really know what I'm talking about 11:29:40 I don't really know what I'm talking about either 11:30:07 static linking physically links the library to the binary of your executable 11:30:18 static linking causes the library to be loaded when your app is loaded 11:30:59 but I *think* dlopen and dynamic-linking are at least closely related, it's just that when you dynamically link it arranges for tables to be compiled into your binary so that ld knows to search for and dlopen (or something similar) libraries when your program starts up 11:31:17 the problem with dynamic linking in forth is that it would literally need one extension per FUNCTION you wanted to use in a given library (rather per .o file within the .a) 11:31:48 there would be a master dlopen extension and then one include file per symbol you wanted to use in what ever library you wanted to use 11:32:15 could you explain what you mean by "extension"? 11:32:41 forth has a kernel. the kernel is the CORE of the forth. an extension is an addition to the kernel 11:32:49 oh, okay 11:32:52 usually a compiler has the compiler read sources and create a new executable 11:33:10 in forth when the kernel compiles sources it appends the executable code of the extension onto the end of itself 11:33:32 [SINGLE EXECUTABLE[kernel][extensions]] 11:33:48 you can compile an extension onto the kernel. then another. then another. then save out the result as a new executable 11:33:56 every forth executable will have the forth kernel built in 11:34:23 that complicates things, since you then need to maintain records of the imports and adjust the relocations on each startup 11:34:31 in order to link to dynamic libs at run time a forth will need an extension that allows you to import symbols from a library 11:34:38 tada 11:35:42 dlopen just opens the library. you need to determine the run time address of a given symbol and have a doorway between forth and the library call 11:36:02 and a way of something like "LIBC:foo() ?" 11:36:16 Something which calls the symbol address with the right number of parameters according to the calling convention 11:37:32 forth puts params on the stack. sometimes C does so too. other times its stack and registers. other times its just registers 11:38:00 but basically a library function call SHOULD seem as trivial to the end user as any other system call 11:38:28 isforth does not provide gateways for every linux system call but you can create one EASY for anything thats not built in 11:38:39 xxx yyy syscall: blah 11:38:55 creates a system call handler for a blah system call that takes xxx parameters and is system call number yyy 11:39:17 after this you can do a b c d blah 11:39:28 for however many parameters the blah system call takes 11:40:11 src/kernel/syscall.f has the code that performs the system calls and has some "coded" built in calls. i only build in calls that the kernel itself uses 11:40:29 for an example of creating a new handler in an extension look at the time/timer extensions 11:41:07 i should be able to dlopen ANY library but i think i need to put in some compile time checks 11:41:33 dlopen "libfoo" - compile the code to open this library at run time - but check at compile time that the library exists 11:41:53 https://gist.github.com/crcx/fb3256cee3c56e9adfe31db248477c28 was the the code needed to use dlopen()/dlsym() in retro8 (back when it was still written in x86 assembly) 11:42:12 xxx dlsym: some-symbol should add a forth word called some-symbol to reference something in the lib 11:42:32 oooh ill bookmark that lol 11:43:02 but again i think there should be a compile time check that that sym actually exists 11:47:04 you'd still have to tell it how to call the symbol 11:47:13 which could get pretty complicated with some abis 11:48:43 would be different for x86 and arm for example 11:48:58 maybe even different between x86_32 and 64 and arm32 and arm64 11:52:15 even on x86_32 there are a couple of options. (my code handled cdecl and pascal conventions; which was enough for linux/freebsd/netbsd/openbsd/beos and windows) 11:56:54 --- quit: Zarutian (Ping timeout: 260 seconds) 13:09:12 --- quit: mark4 (Ping timeout: 255 seconds) 13:10:20 --- join: vsg1990 (~vsg1990@static-72-88-80-103.bflony.fios.verizon.net) joined #forth 13:24:12 --- quit: GeDaMo (Remote host closed the connection) 14:11:03 --- quit: gravicappa (Ping timeout: 258 seconds) 14:39:02 --- quit: dys (Ping timeout: 240 seconds) 14:40:33 --- join: ACE_Recliner (~ACE_Recli@c-50-165-178-74.hsd1.in.comcast.net) joined #forth 14:51:52 --- quit: ACE_Recliner (Ping timeout: 245 seconds) 14:53:17 --- join: ACE_Recliner (~ACE_Recli@c-50-165-178-74.hsd1.in.comcast.net) joined #forth 15:03:21 --- join: wa5qjh (~Thunderbi@121.54.90.144) joined #forth 15:10:42 --- join: MrBismuth (~ArcMrBism@2602:306:8325:a300:c801:d7f:77e1:92be) joined #forth 15:14:17 --- quit: nerfur (Ping timeout: 246 seconds) 15:15:20 --- quit: MrBusiness (Read error: Connection reset by peer) 15:17:02 --- join: nerfur (~nerfur@mail.freeside.ru) joined #forth 15:17:14 --- quit: koisoke (Ping timeout: 268 seconds) 15:17:33 --- quit: newcup (Ping timeout: 240 seconds) 15:18:21 --- join: koisoke (xef4@epilogue.org) joined #forth 15:24:59 --- join: dys (~dys@ip-109-40-3-76.web.vodafone.de) joined #forth 16:12:46 --- quit: John[Lis` (Remote host closed the connection) 16:23:57 --- quit: nighty-- (Quit: Disappears in a puff of smoke) 16:31:15 --- mode: crc set +o koisoke 16:57:53 --- quit: true-grue (Read error: Connection reset by peer) 17:45:18 --- join: nighty-- (~nighty@d246113.ppp.asahi-net.or.jp) joined #forth 17:48:56 --- join: Zarutian (~zarutian@168-110-22-46.fiber.hringdu.is) joined #forth 17:49:26 --- quit: Zarutian (Read error: Connection reset by peer) 17:50:06 --- join: Zarutian (~zarutian@168-110-22-46.fiber.hringdu.is) joined #forth 17:57:34 --- join: bedah2 (~bedah@dyndsl-037-138-056-150.ewe-ip-backbone.de) joined #forth 18:00:54 --- quit: bedah (Ping timeout: 260 seconds) 18:03:39 --- join: neceve (~ncv@unaffiliated/neceve) joined #forth 18:39:31 --- join: hellcode (~sigma@189.180.110.142) joined #forth 19:07:46 --- quit: wa5qjh (Read error: Connection reset by peer) 19:09:00 --- join: wa5qjh (~Thunderbi@121.54.90.144) joined #forth 19:29:15 --- quit: hellcode (Quit: Lost terminal) 19:42:11 --- quit: Zarutian (Quit: Zarutian) 22:36:54 --- quit: vsg1990 (Quit: Leaving) 22:45:04 --- quit: bedah2 (Quit: Ex-Chat) 22:45:18 --- join: bedah (~bedah@dyndsl-037-138-056-150.ewe-ip-backbone.de) joined #forth 23:16:24 --- join: larsb (~lars@molnjunk.nocrew.org) joined #forth 23:40:02 --- quit: neceve (Quit: Konversation terminated!) 23:55:36 --- quit: ACE_Recliner (Ping timeout: 252 seconds) 23:59:05 --- join: ACE_Recliner (~ACE_Recli@c-50-165-178-74.hsd1.in.comcast.net) joined #forth 23:59:59 --- log: ended forth/17.04.27