[bug #64436] Building from git on macOS Montery fails because install-deps.sh exports CC=gcc-11

Update of bug #64436 (project gforth): Status:None => Fixed Assigned to:None => paysan ___ Follow-up Comment #1: I added this code

[bug #64444] Building from git should NOT install swig in /usr/local!

Update of bug #6 (project gforth): Status:None => In Progress Assigned to:None => paysan ___ Follow-up Comment #1: I added code in git

Re: f-rot not working? prio-B issue since frot works

t development snapshot, as explained below. We will not implement features in 0.7.3. >= how to know (for example f-rot) is NOT in GFORTH with a command which will >list all GFORTH WORDS? (= the output will show the f-rot is missing in the >listing) > > >Am Dienstag, 23. Ma

Re: f-rot not working? prio-B issue since frot works

romDebian 11. The manual refers to the current development snapshot. The download section here explains in brief words how to add the Debian repository fur the current snapshot. If you have feature requests, please do not request features that are already in. https://gforth.org/ -- Bernd Paysan

[bug #63201] compilation: [ 1 ]L cells + => #8 +

Update of bug #63201 (project gforth): Open/Closed:Open => Closed ___ Reply to this item at: ___

[bug #63084] regexp-test.fs fails

Update of bug #63084 (project gforth): Open/Closed:Open => Closed ___ Reply to this item at: ___

[bug #63801] add FCLEARSTACK analagous to CLEARSTACK

Update of bug #63801 (project gforth): Status:None => Fixed Assigned to:None => paysan Open/Closed:Open => Closed

[bug #64068] configure: C99 compatibility fix for -export-dynamic, assembler skip checks

Follow-up Comment #3, bug #64068 (project gforth): [comment #2 comment #2:] > I believe this is rejected by Apple Xcode (for a few versions now), and Clang 16. I'm submitting this now because we want to make similar changes in GCC (version 14, I hope). Clang still has the problems GCC had

[bug #63525] >time : unexpected behavior

Update of bug #63525 (project gforth): Assigned to:None => paysan Open/Closed:Open => Closed ___ Reply to this item at:

[bug #63730] The "see" command hangs forever on a default Ubuntu installation

Update of bug #63730 (project gforth): Status:None => Works For Me Assigned to:None => paysan ___ Follow-up Comment #1: This is (mostly)

[bug #63084] regexp-test.fs fails

Update of bug #63084 (project gforth): Status:None => Fixed Assigned to:None => paysan ___ Follow-up Comment #1: Thanks for

[bug #62878] fork()'ed and then exit()'ing child procs are manipulating history file

Update of bug #62878 (project gforth): Open/Closed:Open => Closed ___ Reply to this item at: ___

[bug #62878] fork()'ed and then exit()'ing child procs are manipulating history file

Update of bug #62878 (project gforth): Status:None => Fixed Assigned to:None => paysan ___ Follow-up Comment #1: Needs to add a

Re: [bug #62030] 'Malformed xchar' error, if fork'ed child throws

Am Montag, 8. August 2022, 09:31:55 CEST schrieb Stephan Rudlof: > How to avoid exit'ing child procs manipulating history file? You need to do a history flush-file before forking. Or better just flush the history directly in history.fs, when you write something. -- Bernd Paysan "If

[bug #62214] Building from source on Debian auto-installs outdated version

Follow-up Comment #5, bug #62214 (project gforth): Did you read INSTALL.md, section “build from tarball”? It's right there. ___ Reply to this item at:

[bug #62214] Building from source on Debian auto-installs outdated version

Follow-up Comment #3, bug #62214 (project gforth): install-deps.sh does not install the outdated Gforth (nor the fork of Swig), if you set BUILD_FROM to "tarball" before sourcing install-deps.sh. ___ Reply to this item at:

[bug #62030] 'Malformed xchar' error, if fork'ed child throws

Follow-up Comment #7, bug #62030 (project gforth): bye and (bye) are for leaving Gforth gracefully (the difference is that (bye) is a primitive). This means restoring the terminal. The thing we don't want. So we want to leave the forked process right at that point, not graceful, not restoring

[bug #62030] 'Malformed xchar' error, if fork'ed child throws

Update of bug #62030 (project gforth): Status: Confirmed => Fixed ___ Follow-up Comment #4: I added a bit code for handling a closed stdin more gracefully. The recommended way to handle

[bug #62030] 'Malformed xchar' error, if fork'ed child throws

Follow-up Comment #3, bug #62030 (project gforth): The way to do this in the current Gforth development version is by: require unix/libc.fs : test fork() if ( ... ) else [: ( ... ) ;] catch ?dup-if DoError 1 else 0 then exit() then ; fork() and exit() as C functions have

[bug #61212] feature request: split out time to read and convert the time

Update of bug #61212 (project gforth): Status: In Progress => Fixed Open/Closed:Open => Closed ___ Follow-up Comment #3: I changed the

[bug #59674] Stack on Status Bar Does Not Change Radix

Update of bug #59674 (project gforth): Status: In Progress => Wont Fix Open/Closed:Open => Closed ___ Follow-up Comment #5: We added code that

Re: gforth-0.7.9_20211125 tasker.fs broken

CE3BAC0 '-error > kernel/int.fs:608:5: 2 $7FF15CE3BB00 (') > tasker.fs:48:12: 3 $7FF15CEBA850 ' > > It works in gforth 0.7.3. Ok, seems to be a victim of the section code. Fixed in git head. Preferred multitasker is unix/pthread.fs in the

[bug #61212] feature request: split out time to read and convert the time

Update of bug #61212 (project gforth): Status:None => In Progress Assigned to:None => paysan ___ Follow-up Comment #1: [comment #0

[bug #60642] [Feature request] Make possible long tap options

Update of bug #60642 (project gforth): Assigned to:None => paysan ___ Reply to this item at: ___

[bug #60642] [Feature request] Make possible long tap options

Update of bug #60642 (project gforth): Status:None => Confirmed ___ Follow-up Comment #1: [comment #0 original submission:] > On Android, it's impossible to use the standard long tap

[bug #59674] Stack on Status Bar Does Not Change Radix

Follow-up Comment #3, bug #59674 (project gforth): We don't know what kind of number something we didn't identify actually is (ASCII code? Bitmask? Count of something?). Therefore, smart. falls back to . if it doesn't know. . is printed in the current base. The user probably knows. I think

[bug #57340] ekey goes into strange mode when reading shift-backspace

Update of bug #57340 (project gforth): Open/Closed:Open => Closed ___ Reply to this item at: ___

[bug #59674] Stack on Status Bar Does Not Change Radix

Update of bug #59674 (project gforth): Status:None => In Progress Assigned to:None => paysan ___ Follow-up Comment #1: At the moment, this

[bug #48406] forth-block-mode marks buffer as modified when I visit a file

Update of bug #48406 (project gforth): Status: Confirmed => Fixed Assigned to:dvdkhlng => paysan Open/Closed:Open => Closed

[bug #58922] gforth 0.7.3 fails to build on Ubuntu 20.04 unless gdb is installed

Update of bug #58922 (project gforth): Status:None => Wont Fix Assigned to:None => paysan Open/Closed:Open => Closed

Re: [PATCH] arm: beagle: fix possible null dereferences

Am Sonntag, 2. August 2020, 23:28:04 CEST schrieb Geyslan G. Bem: > Make assertions before pointer dereference. Looks ok to me. I don't know if the beagle-board port of Gforth still compiles, though. Back then, I copied some code from Ti, to get it to work quickly. -- Bernd Paysan "If

Re: lshift bug

t auf allen Byte-Maschinen die Anzahl der Bits. In den Environmental Queries gibt es ADDRESS-UNIT-BITS, das + CELLS gibt die Anzahl Bits pro Zelle. Zuverlässig. Überall. Leider doof zu benutzen, weil die Environmental-Queries halt doof sind. Aber so für eine Konstante akzeptabel. -- Bernd Paysan "If

[bug #57741] Strange begin drop again ;

Follow-up Comment #4, bug #57741 (project gforth): [comment #3 comment #3:] > Ok, I'll fix it. 2DROP, FDROP and RDROP are also relevant, anything else? 2RDROP. All LP+ variants. ___ Reply to this item at:

[bug #57741] Strange begin drop again ;

Follow-up Comment #2, bug #57741 (project gforth): [comment #1 comment #1:] > We could fix this by adding a memory access in DROP (and some other words), but I am not sure if this is worth the effort and the slowdown. With the debugging engine (gforth), it's probably worth it. We don't do TOS

[bug #57340] ekey goes into strange mode when reading shift-backspace

Update of bug #57340 (project gforth): Status: Confirmed => Fixed ___ Follow-up Comment #8: I added a fix for both problems (not recognizing shift-tab, sticking in line-mode style when the

[bug #57340] ekey goes into strange mode when reading shift-backspace

Follow-up Comment #5, bug #57340 (project gforth): [comment #3 comment #3:] > On another machine (Ubuntu submodule of Windows 10) it is: > lrwxrwxrwx 1 root root 15 Jun 1 2019 /etc/alternatives/x-terminal-emulator -> /usr/bin/lxterm But you likely aren't using that in the WSL, because there's

[bug #57340] ekey goes into strange mode when reading shift-backspace

Update of bug #57340 (project gforth): Status:None => Need Info Assigned to:None => paysan ___ Follow-up Comment #1: Can't reproduce at

[bug #57324] does not install on Windows 10 LSM

Follow-up Comment #4, bug #57324 (project gforth): Can you do rm -rf lib make libcc and provide me with the output log if that fails? ___ Reply to this item at:

[bug #57324] does not install on Windows 10 LSM

Update of bug #57324 (project gforth): Status:None => Works For Me Assigned to:None => paysan ___ Follow-up Comment #1: Dependencies to

Re: [bug #57324] does not install on Windows 10 LSM

alid libtool archive > > The same error also flags libgfsocket.la libgfmmap.la libgfserial.la > libgffilestat.la libgftime.la libgflibffi.la > > > How can the libtool errors be resolved? The install script that works (and is used for continuous integration on a Debian image) is install-d

[Bug-gforth] [bug #56631] help does not print full example

Update of bug #56631 (project gforth): Open/Closed:Open => Closed ___ Reply to this item at: ___

[Bug-gforth] [bug #56406] Inconsistent Control structure mismatch reporting

Update of bug #56406 (project gforth): Open/Closed:Open => Closed ___ Reply to this item at: ___

[Bug-gforth] [bug #56631] help does not print full example

Update of bug #56631 (project gforth): Severity: 3 - Normal => 2 - Minor Status:None => Wont Fix Assigned to:None => paysan

Re: [Bug-gforth] [bug #55675] Cannot build from git commit d505b1be

a travic-ci setup on github, and that fails on their old Ubuntu every time, because the make they use has a bug I just don't want to work around. -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o id: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* https://net2o.de/

[Bug-gforth] [bug #55677] "make install" does not install gforth.fi

Update of bug #55677 (project gforth): Status: Need Info => Works For Me Open/Closed:Open => Closed ___ Reply to this item at:

[Bug-gforth] [bug #55677] "make install" does not install gforth.fi

Update of bug #55677 (project gforth): Status:None => Need Info Assigned to:None => paysan ___ Follow-up Comment #1: gforth.fi is

[Bug-gforth] [bug #55676] Typo in gforth.el

Update of bug #55676 (project gforth): Status:None => Fixed Assigned to:None => paysan ___ Follow-up Comment #1: Thanks, fixed.

[Bug-gforth] [bug #55675] Cannot build from git commit d505b1be

Update of bug #55675 (project gforth): Status:None => Fixed Assigned to:None => paysan Open/Closed:Open => Closed

Re: [Bug-gforth] [bug #55675] Cannot build from git commit d505b1be

l directory… I can reproduce this, it's likely that line 50 in mkdir.fs, where it deletes a parent directory if that is a file (and a symlink is a file). -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o id: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* https:

[Bug-gforth] [bug #50013] "file-size" returns three items on the stack when it should only return two

Update of bug #50013 (project gforth): Status:None => Invalid Open/Closed:Open => Closed ___ Follow-up Comment #1: The "ud" data type

[Bug-gforth] [bug #46989] libffi.fs, don't define MACOSX unconditionally

Update of bug #46989 (project gforth): Status:None => Fixed Assigned to:None => paysan Open/Closed:Open => Closed

[Bug-gforth] [bug #46988] Fix use of uninitalized memory

Follow-up Comment #1, bug #46988 (project gforth): Hm, all used xts and symbols are correctly initialized. There are these offsets which are used for helping relocation, this means that some parts of the array is not used, and thus also never initialized. Using calloc will remove any false

[Bug-gforth] [bug #46988] Fix use of uninitalized memory

Update of bug #46988 (project gforth): Status:None => Fixed Assigned to:None => paysan Open/Closed:Open => Closed

[Bug-gforth] [bug #46987] Unbreak MIPS backend on OpenBSD

Follow-up Comment #3, bug #46987 (project gforth): What about other BSDs? There are MIPS32 port for FreeBSD and NetBSD. I rather want to fix it for all BSD versions than just one. ___ Reply to this item at:

[Bug-gforth] [bug #37261] Several typing errors in cross.fs

Update of bug #37261 (project gforth): Open/Closed:Open => Closed ___ Reply to this item at: ___

[Bug-gforth] [bug #38736] Release information inconsistent

Update of bug #38736 (project gforth): Status:None => Fixed Assigned to:None => paysan Open/Closed:Open => Closed

Re: [Bug-gforth] [bug #40978] Failed to compile GForth on MACOSX 10.8.5

https://github.com/kennethreitz/osx-gcc-installer/ -- Bernd Paysan If you want it done right, you have to do it yourself http://bernd-paysan.de/ signature.asc Description: This is a digitally signed message part. ___ bug-gforth mailing list bug-gforth

[Bug-gforth] [bug #31339] Tried to configure for Mac OS X - unable to compile error

Update of bug #31339 (project gforth): Status:None = Invalid ___ Reply to this item at: http://savannah.gnu.org/bugs/?31339 ___

[Bug-gforth] [bug #31339] Tried to configure for Mac OS X - unable to compile error

Follow-up Comment #1, bug #31339 (project gforth): Hm, do you have an installed C compiler? Mac OS X doesn't come with one, you need to install XCode. ___ Reply to this item at: http://savannah.gnu.org/bugs/?31339

[Bug-gforth] [bug #26261] Seeing assembly code on Mac OS X robs me of my identity

Update of bug #26261 (project gforth): Status:Works For Me = Fixed ___ Follow-up Comment #4: The last round of updates on Mac OS X seem to fix this problem - while I could reproduce it

Re: [Bug-gforth] Crash on OS X

Am Sonntag 21 Februar 2010 21:44:53 schrieb Bernd Paysan: Am Sonntag 21 Februar 2010 21:22:16 schrieb Torbjorn Kristoffersen: I typed see drop in Gforth 0.7.0 on Mac OS X Snow Leopard (10.6.2 on a Mac Pro) and the OS started behaving completely erratically. For one, all the icons on my

[Bug-gforth] [bug #26652] disassembler spits out DO for 2r

Follow-up Comment #2, bug #26652 (project gforth): I've checked here with GCC 4.3.2 (x86_64 system), and can't reproduce the problem. What seems to be happening is that GCC combines the two identical operations in the primitive (do) and the primitive 2r to one code segment, which makes it