02:09:15 --- log: started forth/21.02.22 02:09:15 --- join: clog joined #forth 02:09:15 --- topic: 'Forth Programming | logged by clog at http://bit.ly/91toWN backup at http://forthworks.com/forth/irc-logs/ | If you have two (or more) stacks and speak RPN then you're welcome here! | https://github.com/mark4th' 02:09:15 --- topic: set by proteusguy!~proteusgu@cm-58-10-208-146.revip7.asianet.co.th on [Mon Dec 30 10:43:28 2019] 02:09:15 --- names: list (clog xek dys hosewiejacke _whitelogger djinni proteus-guy sts-q dave0 X-Scale boru Lord_Nightmare Zarutian_HTC Keshl mjl yunfan iyzsong jedb +proteusguy cantstanya actuallybatman lispmacs[work] lonjil dzho ornxka_ nitrix remexre neuro_sys klys rpcope- Gromboli ovf mstevens patrickg siraben jevinskie[m] jimt[m] joe9 a3f TangentDelta shmorgle crc scoofy dnm crest veltas pareidolia inode Vedran fiddlerwoaroof_ irsol nihilazo Wojciech_K dddddd APic crc- routeveg cp-) 02:09:15 --- names: list (koisoke Chobbes cmtptr tabemann bluekelp tangentstorm krjst ecraven phadthai guan rprimus +KipIngram tolja jn__ rann MrMobius cheers rixard spoofer astrid) 02:17:51 patrickg, oh right i forgot all about that. I should consider adopting it. 02:35:29 --- quit: proteus-guy (Ping timeout: 260 seconds) 02:52:05 --- join: proteus-guy joined #forth 03:02:52 Also interested to know what's good about Mercurial 03:03:24 But unlikely to change because git works fine for me, and I like GitHub despite all its flaws 03:04:28 Interested to know exactly what's so *bad* about git, for one thing 03:06:07 Yeah 03:07:27 to me git is just confusing to use 03:07:37 git is somewhat more open about its internals than most other VCSes, which both allows for more power but also adds confusion when all you want to do is manage the history of a few files. 03:07:52 nihilazo: how so? 03:08:01 as soon as I want to do something more complex than just add, commit, push, I have to spend a while looking through manpages and searching stackoverflow for how 03:08:10 once you used git in anger for a year or so these things become second nature, but that's not a typical learning curve for a tool ;-) 03:08:24 --- quit: dave0 (Quit: dave's not here) 03:08:31 I've been using it for longer than that lol 03:08:36 BTW magit makes working with Git pretty painless 03:08:43 --- quit: iyzsong (Quit: ZNC 1.7.5 - https://znc.in) 03:08:49 the downside is that magit requires emacs ;-) 03:09:11 but yes, there are alternative user interfaces, but the main entry point remains the git cli 03:09:17 within a few weeks of actually using it beyond push/pull/commit I felt proficient with Git, so I guess it depends 03:10:00 rebase, cherry-pick, bisect are some pretty nice features, and Git is very careful about not deleting unreachable objects/commits 03:11:03 I've never sat down and tried to "learn git properly", and instead just try and understand the commands I need when I google for them, if it's not very basic management. I've never used a VCS I haven't had to google help with, and git at least has the most help online for it. 03:11:04 I have no issues with git myself (and was surprised when I recently used monotone again after ~10 years of non-use how much I adapted to git), but I remember being confused by its differences to ~everything else (and I used a lot of different VCS over the years) 03:11:43 Like with perforce you'll google for help and get nothing, if you're lucky someone will explain a cryptic addressing mechanism that lets you do half of what you need and that suffices most times 03:14:22 Should I bother learning other VCS? Sounds like the switching cost is high 03:14:25 patrickg: The thing is that mercurial seems to be quite similar to git in its model, the main difference I see from trying to look online is git has more control over how you stage stuff, and the way that merges are handled in branch logs 03:14:45 siraben: I don't think the switching cost would be high, the reason I don't bother is what do I gain? 03:14:50 It seems like it's for nothing 03:15:06 right. exactly 0 projects I've contributed to used something other than git 03:15:48 The only other thing I see people use is subversion, if the project is old enough to have been started before git was mainstream 03:16:01 In open source, anyway. In companies you see a lot of perforce 03:20:16 my main project (coreboot) migrated from subversion to git 10 years ago, and it started before git was a thing (we started with CVS). On the way I made some collaborators also try gnu arch (before it was gnu), monotone, svk (some subversion extension for distributed work) and a few other things, but it became clear early-on that git will win out. That's a huge argument 03:21:45 it was the only argument in its favor though ;-) 03:47:29 --- join: f-a joined #forth 03:58:32 --- join: gravicappa joined #forth 04:50:38 --- quit: proteus-guy (Ping timeout: 240 seconds) 05:18:43 siraben, there's really not much reason to learn another SCS once you know git. Most are pretty bad anyway and git is universal nowadays. 05:19:41 there is a good reason: some of them offer a more pleasant UX than git 05:20:00 I am always amazed at how painless darcs is, cherrypicking for everything 05:20:13 sadly, git is the only one which is battle tested for gigantic software 05:22:18 --- quit: f-a (Quit: bb) 05:27:38 f-a outside of mercurial, which one outside of git do you think that a pleasant UX? And mercurial actually scales better than git. 05:29:25 --- join: elioat joined #forth 05:35:49 * crc uses fossil, but is providing read-only git mirrors of his public repos 05:36:32 crc, I'm not familiar at all with fossil. This something new? 05:38:32 https://fossil-scm.org/ 05:39:15 repo is stored in an sqlite3 database; has a single binary that handles everything 05:43:12 I'm also a fan of fossil 05:43:35 never used it on a collaborative project, but for my hobby stuff it is my go-to choice typically 05:46:07 crc, yikes! sqlite is the opposite of fixed and never to be deleted forever! dunno that I'd trust that for VCS. 05:46:28 sqlite is a good project and it is actually very stable 05:47:00 If I had to choose between a btrfs driver and sqlite for integrity I'd choose sqlite 05:47:14 veltas, no arugument there - but it's designed to allow updates and deletions of data. Also, it can lose data in a process failure. 05:48:14 News to me 05:49:54 I've used perforce commercially and always liked it. I've never heard anything bad about mercurial. 05:49:55 Ah - I just checked and sqlite does now have a writeahead log. So I guess if you have that going a process failure is still recoverable.If you don't have that going then you can lose data. 05:50:01 https://www.sqlite.org/howtocorrupt.html 05:50:38 mstevens, I used perforce years ago before good open source tools were available. I liked it. But I prefer distributed models now. 05:50:55 I hate the way it makes files read-only by default 05:51:11 proteusguy: This is where my experience is a bit limited, I used it pre-git, I believe they've tried to compete and come out with a distributed product, but I don't know anything about it. 05:51:47 mstevens, it was definitely one of if not these best commercial ones. 05:52:13 I'd use (and do) git over perforce in a commercial setting 05:52:16 veltas, re:read-only by default - you talking about perforce? 05:52:22 Yes 05:52:50 veltas, yes that's because it follows the pvcs model of locking files before modifying them. totally old school. :-) 05:52:56 These days I use git because it's good enough and it's nearly universal, but I don't actually like it. 05:53:42 mstevens, yep agreed - git has pretty much just won. resistance isn't worth it. it's not that hard to get it but it is entirely unnatural, alas. But it certainly is powerful and works. 05:54:00 proteusguy: It's for old-school performance reasons that don't apply anymore, meanwhile it performs worse in practice than basic operations than git does. 05:54:44 veltas, oh yeah - the pessimistic locking model is obsolete. very "enterprisey". But it was a strong tool in its day. 05:55:45 proteusguy: A friend works with mercurial and uses the git extension to interface with the rest of the world, I've not tried it but that might give you the best of both worlds. 05:56:38 mstevens, yes I need to give that a shot. 06:12:09 veltas, interesting that two examples of how sqlite can lose data were actually using fossil as their examples.... yipes! ;-) 06:15:58 --- quit: Zarutian_HTC (Read error: Connection reset by peer) 06:16:19 --- join: Zarutian_HTC joined #forth 06:21:07 I find it trustworthy that they document how they have failed, give examples, and also it seems unlikely any of those issues will ever affect me. 06:21:30 Nothing should ever cause serious data loss, because you should *never* use a VCS without backups 06:22:18 But obviously data integrity is important to the extent I don't ever expect to have to deal with data integrity issues from my VCS, and with fossil it appears I am still unlikely to experience it myself 07:34:32 --- quit: Zarutian_HTC (Ping timeout: 260 seconds) 08:09:09 --- join: Zarutian_HTC joined #forth 08:15:14 --- join: f-a joined #forth 08:58:58 proteusguy: which aspects of mercurial scale better than git? 09:14:51 --- quit: Zarutian_HTC (Read error: Connection reset by peer) 09:15:09 --- join: Zarutian_HTC joined #forth 09:18:52 --- quit: elioat (Quit: elioat) 09:27:17 --- quit: hosewiejacke (Ping timeout: 256 seconds) 09:34:16 --- quit: gravicappa (Read error: Connection reset by peer) 09:34:51 --- quit: f-a (Quit: leaving) 09:41:00 --- join: elioat joined #forth 09:42:06 --- join: gravicappa joined #forth 10:08:26 --- quit: Keshl (Read error: Connection reset by peer) 10:09:17 --- join: Keshl joined #forth 10:18:27 --- join: f-a joined #forth 10:38:20 --- join: hosewiejacke joined #forth 10:38:29 --- quit: hosewiejacke (Remote host closed the connection) 10:58:10 --- quit: dys (Remote host closed the connection) 10:59:23 --- join: dys joined #forth 11:04:24 --- join: kiedtl\x1b joined #forth 11:40:07 --- quit: gravicappa (Ping timeout: 240 seconds) 11:50:42 --- quit: f-a (Ping timeout: 256 seconds) 11:51:47 --- join: f-a joined #forth 12:22:06 --- quit: elioat (Quit: elioat) 12:26:52 --- join: elioat joined #forth 12:49:08 --- quit: elioat (Quit: elioat) 12:59:03 --- quit: inode (Quit: ) 13:06:49 see interpret 13:06:50 : interpret useraddr <64> @ >r 140465469356744 catch r> useraddr <64> ! throw ; ok 13:06:55 what is <64> ? 13:19:03 --- quit: xek (Ping timeout: 256 seconds) 14:18:38 f-a: I don't quite have the full answer to your question, but in gforth source, useraddr is definied in the `prim' file as ( #u -- a_addr ). My guess is that <64> is definied at gforth compile time as user address space memory localation or something similar, and useraddr turns that into an address in a word 14:20:20 its not saying useraddr is a 64 bit address? 14:21:26 oh 14:21:28 ohhhhhh 14:21:48 I see, effective behaviour 14:32:33 --- quit: f-a (Quit: leaving) 14:36:38 --- quit: sts-q (Quit: ) 14:37:13 --- join: sts-q joined #forth 15:26:24 --- quit: scoofy (Ping timeout: 265 seconds) 15:38:10 --- join: scoofy joined #forth 16:07:44 --- join: dave0 joined #forth 16:33:55 --- quit: a3f (Ping timeout: 258 seconds) 16:43:25 --- join: a3f joined #forth 17:06:23 --- quit: lispmacs[work] (Remote host closed the connection) 17:14:26 --- join: lispmacs[work] joined #forth 17:45:24 --- quit: _whitelogger (Remote host closed the connection) 17:48:23 --- join: _whitelogger joined #forth 18:32:32 --- join: boru` joined #forth 18:32:35 --- quit: boru (Disconnected by services) 18:32:37 --- nick: boru` -> boru 19:13:07 --- join: X-Scale` joined #forth 19:13:31 --- quit: X-Scale (Ping timeout: 264 seconds) 19:13:48 --- nick: X-Scale` -> X-Scale 19:19:49 siraben, hg has a far more intuitive workflow and you generally want the default arguments. Also it scales better when you're talking about projects with large histories and lots of branches. 19:20:50 hmm 19:34:31 --- join: gravicappa joined #forth 20:22:00 --- join: proteus-guy joined #forth 20:27:32 --- quit: dave0 (Quit: dave's not here) 20:42:19 --- join: X-Scale` joined #forth 20:43:04 --- quit: X-Scale (Ping timeout: 246 seconds) 20:43:04 --- nick: X-Scale` -> X-Scale 20:54:19 --- quit: sts-q (Ping timeout: 264 seconds) 21:02:06 --- join: sts-q joined #forth 21:33:18 --- join: lispmacs joined #forth 21:34:13 is anybody here using jonesforth? I wanted to work through the literate code tutorial, but jonesforth crashes with a segfault when I try to start it 21:37:17 --- quit: lispmacs (Remote host closed the connection) 21:39:01 --- join: lispmacs joined #forth 21:45:14 yikes - I haven't run it in ages. Have you run pdb against it to see where it traps? (Compile with debugging symbols on.) 21:45:27 Sorry gdb 21:50:18 proteus-guy: I tried, but it actually crashes sometime so early that there is no stack yet to examine. I think something must have bit-rotted in the assembly code 21:55:18 lispmacs: jonesforth works fine for me on x86_64-linux running NixOS 21:57:13 siraben: hmm, maybe something about my environment 21:57:18 or the gcc version 21:57:20 What OS are you running? 21:57:30 what gcc/gas version do you use to build 21:57:56 Guix System 1.2.0-13.a53f711 x86_64 21:58:07 let me check (it's the one in Nixpkg's stdenv) 21:58:58 nix-repl> stdenv.cc.version 21:58:58 "10.2.0" 21:59:39 If you enter your Guix build environment, which version of gcc does it use? 21:59:53 Also my derivation is just using the makefile 22:00:12 http://ix.io/2Qsy 22:00:16 10.2.0 22:01:21 guix does not have a package for jonesforth yet, unfortunately 22:01:30 Perhaps Guix is stripping the binaries? I know Nix always strips. 22:02:01 yeah that's just my personal expression, not planning to upstream it (unless jonesforth adds a free software license) 22:02:40 I was just setting up an environment with `guix environment --ad-hoc gcc-toolchain gdb make' and running the makefile. 22:04:26 well, actually, no I wasn't running the makefile, I was using the build instructions in the jonesforth.S tutorial 22:05:31 Ok looks like the call to gcc differs slightly from the makefile 22:05:39 https://github.com/nornagon/jonesforth/commit/4f853252f715132e7716cbd44e5306cefb6a6fec#diff-76ed074a9305c04054cdebb9e9aad2d818052b07091de1f20cad0bbac34ffb52 22:06:31 I seem to be getting the same result with the makefile 22:08:30 hmm, maybe something related to 32 bit libraries...? 22:08:42 (am on a different OS right now, starting up a NixOS docker image) 22:10:45 works for me, hm. 22:10:53 lispmacs: what 32 bit libraries? 22:11:28 just thinking out loud... from my debian days I recall there was compatibility libraries for 32 bit software on 64 machine 22:12:25 also works for me on GCC 9.3.0 22:12:34 jonesforth.S is all 32 bit assembly code 22:12:41 to be clear, you're on the latest commit of the jonesforth repo? 22:12:57 yeah I think you have to build it as 32bit executable. 22:13:05 I cloned it a few days ago 22:13:11 but -m32 should do that right? 22:13:20 oh re: licensing the header says it's public domain, nice. 22:13:37 doesn't it use nasm rather than gas? 22:13:57 the build command in the makefile is `gcc -m32 -nostdlib -static $(BUILD_ID_NONE) -o $@ $<` 22:14:05 the tutorial says gas 22:14:08 I'm totally going from memory here - it's been years. hmm.. guess not. :-) 22:14:17 but doesn't it use intel syntax? 22:14:47 proteus-guy: no, tutorial gives a few paragraphs on the quirks of gas syntax 22:14:55 lispmacs: what happens when you do `cat jonesforth.f - | ./jonesforth` ? 22:14:59 wow. 22:15:05 or me, 22:15:07 * siraben sent a long message: < https://matrix.org/_matrix/media/r0/download/matrix.org/JMRdcNAqpAuADKdPDXnFURnI/message.txt > 22:15:22 s/or/for/ 22:15:30 cat: write error: Broken pipe 22:15:30 Segmentation fault 22:16:03 that is very strange, hm. maybe we should compare the hashes of jonesforth? 22:16:45 commit 66c56998125f3ac265a3a1df9821fd52cfeee8cc 22:17:32 ah, that's an old commit 22:17:44 4f853252f715132e7716cbd44e5306cefb6a6fec fixes the crash on modern gcc 22:17:50 I think that's it then 22:18:30 when I run git pull it says I'm up to date 22:18:56 what's your upstream? 22:18:58 git://git.annexia.org/jonesforth.git 22:19:20 ah. I'm using the one from GitHub 22:19:21 https://github.com/nornagon/jonesforth 22:19:42 okay, I'll try that 22:21:10 that worked 22:21:44 nice 22:22:14 siraben: okay thanks. I have to go to bed now 22:22:22 good night! 22:22:44 * lispmacs dreams of electric sheep 22:29:56 --- join: xek joined #forth 22:50:54 --- join: dave0 joined #forth 23:31:06 --- quit: remexre (Ping timeout: 256 seconds) 23:33:08 --- join: remexre joined #forth 23:51:39 --- join: hosewiejacke joined #forth 23:59:59 --- log: ended forth/21.02.22