[bug #65331] `b` is not a good choice for a standard word name

Update of bug#65331 (group gforth): Status:None => Wont Fix Open/Closed:Open => Closed ___ Follow-up Comment #1: Gforth follows

Re: Using xt's

On Fri, Feb 16, 2024 at 11:48:19AM -0600, Patrick Fitzpatrick wrote: > Hi gang, > ; > > I haven't used execution tokens in many years (F-83 timeframe). > > What I want to do is build a jump table like this: > > create t 5 allot > > : t1 ." t1" cr > : t2 ." t2 " cr ; > > ' t1 t 0 + ! > ' t2

Re: GForth for Windows

On Wed, Feb 14, 2024 at 09:01:39PM +0300, �?нд�?ей �?и�?елев wrote: > Hi! > > Is it planned to develop a version of gforth for Windows? Yes. > Following the link "Bleeding Edge snapshot" on https://gforth.org/ I see > that the latest Windows version was released in 2020. Can we expect newer >

Re: Dynamic Superinstructions

On Tue, Feb 13, 2024 at 08:55:12PM +0100, Tomas Hlavaty wrote: > Hi Anton, > > On Tue 13 Feb 2024 at 10:21, Anton Ertl > wrote: > > SEE-CODE to see the result of dynamic native-code generations: > > thank you for all the information. > > How can I create

Re: Dynamic Superinstructions

On Tue, Feb 13, 2024 at 08:38:49AM +0100, Tomas Hlavaty wrote: > Hi, > > the manual describes Dynamic Superinstructions > >(info "(gforth) Dynamic Superinstructions") > > but I cannot make this work. You don't see the effect of dynamic superinstructions with SEE, which tries to produce a

[bug #65181] */ not working

Update of bug#65181 (group gforth): Status:None => Invalid Open/Closed:Open => Closed ___ Reply to this item at:

Re: Some documentation pages returning 502 Bad Gateway

On Tue, Nov 07, 2023 at 03:59:21PM -0700, S A wrote: > Hello, > > I'm able to visit some pages on the https://gforth.org/manual/, but other > pages gives me a 502 Bad Gateway. For example: > > https://gforth.org/manual/The-Input-Stream.html >

Re: How close is the current gforth multi-tasking to proposed standard(s) for multi-tasking?

On Thu, Oct 12, 2023 at 12:27:23AM +, M. Edward (Ed) Borasky via Gforth discussion and announcements wrote: > I'm not on the forth-standard mailing list so I can't ask there. I'm planning > to implement some applications using the "traditional, cooperative > round-robin multitasker" in

Re: etienne delacroix: Precisions on the forth SWIG architecture: return by value structs

On Mon, Jun 12, 2023 at 08:10:55PM +0200, Francois Gallois wrote: > On Mon, Jun 12, 2023 at 06:52:35PM +0200, etienne delacroix wrote: > > thanks for presenting this problem. I have been very much wanting to use > > gforth to do graphics, but since my intel Mac got stolen I have problems > >

Re: Bug ? error with include debug.fs in Debian11 64bits

On Tue, May 16, 2023 at 07:05:57PM +, Pascal Dag wrote: > with > include debug.fs > in prog.fth > > > "gforth prog.fth" output is > > > redefined naligned redefined nalign ... There is no need to include debug.fs, because it is already included in the Gforth image (the many "redefined"

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

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

[bug #63869] Missing test command in configure.ac

Follow-up Comment #3, bug #63869 (project gforth): Ah, yes. Strangely, I don't see the error message on my system. Anyway, it's fixed now. ___ Reply to this item at:

[bug #63869] Missing test command in configure.ac

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

Re: Embedding wishlist

On Mon, Feb 06, 2023 at 07:09:49PM -0600, Ulf Herrman wrote: > I'm considering embedding gforth in a C program that uses an event > loop. I need to be able to suspend the current forth task and return to > C. I *think* the right primitive for this is (bye), unless I'm > mistaken. But once it's

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

Update of bug #63730 (project gforth): Status:Works For Me => Confirmed ___ Follow-up Comment #2: Does not work for me. Yes, there is the workaround of using the Gforth disassemblers, but

Re: GFORTH on M68k 68030 System

On Wed, Nov 23, 2022 at 09:06:29PM -0500, Wolfgang Daum wrote: > Has anyone been successful in porting GFORTH to a m68k 68030 SBC? The > archive has only 3 messages on this topic. > > I already have a m68k-elf cross compiler installed. > > Any inputs would be appreciated. Gforth is pretty

[bug #63268] throw|catch behavior: unexpected items at data stack

Follow-up Comment #5, bug #63268 (project gforth): IIRC you can get similar effects with longjmp() in C. As for where to discuss these things, some questions may be appropriate at forth-standard.org. There is also a gforth mailing list for Gforth-specific questions, and the Usenet group

[bug #63274] abort 'n' -1 throw behavior

Update of bug #63274 (project gforth): Status:None => Invalid Open/Closed:Open => Closed ___ Follow-up Comment #1: The standard

[bug #63268] throw|catch behavior: unexpected items at data stack

Update of bug #63268 (project gforth): Severity: 3 - Normal => 1 - Wish Status:None => Invalid Open/Closed:Open => Closed

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

Update of bug #63201 (project gforth): Status:None => Confirmed Assigned to:None => anton ___ Follow-up Comment #1: This is not a bug,

[bug #63038] CONST-DOES> curry example fails

Follow-up Comment #5, bug #63038 (project gforth): Decompilation of 3+ works now, thanks mostly to Bernd Paysan. see 3+ : 3+ #3 ; ok Note that the word called by 3+ is nameless and therefore decompiled as an address. Decompiling r@ as i is normal. They are two names for the same word.

[bug #63038] CONST-DOES> curry example fails

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

[bug #63036] doc to \ comment

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

Re: Gforth BLOCK 0

On Tue, Aug 09, 2022 at 03:24:17PM +, shtps via Gforth discussion and announcements wrote: > Would this list be the right place to ask beginner Forth questions or would a > different list be more appropriate? I see that you found comp.lang.forth. That is what I use for general Forth

Re: turn off history

On Wed, Jul 27, 2022 at 01:00:37PM +0200, Bernd Paysan wrote: > Another question is: Should we open the history file later in the boot > process, > e.g. on entering interactive mode? There's no need to do that earlier. I have been thinking about having a word INTERACTIVE-COLD or somesuch, used

Re: turn off history

On Tue, Jul 26, 2022 at 09:12:28PM +0200, Tomas Hlavaty wrote: > Hi, > > is there a way to turn off history so that a script or server does not > open the history-file at all? Not easy without changing the source code of Gforth. This happens in 'cold, which is a big pile of various

Re: Building gforth 0.7.9 under macos with M1 chip

On Sat, Jul 09, 2022 at 06:26:11PM +0100, tristan wrote: > On 2022-07-08 09:39, Anton Ertl wrote: > > On Wed, Jul 06, 2022 at 08:53:50PM +0100, Tristan Williams wrote: > > > Hello, > > > > > > Has anyone successfully built and run gforth 0.7.9 on a mac wi

Re: vmgen examples don't build with install from snapshot tarball

On Thu, Jun 30, 2022 at 03:23:45AM +, M. Edward (Ed) Borasky via Gforth discussion and announcements wrote: > in file included from *the terminal*:0:-94105607416479: > in file included from *the terminal*:-1:1: > /usr/local/share/gforth/0.7.9_20220428/prims2x0.6.2.fs:64:12: error: >

Re: Why hasn't gforth made it to 1.0 ... yet?

On Wed, Jun 29, 2022 at 02:41:51AM -0400, John Chludzinski wrote: > I just installed it on Raspbian-64 and got: > > > *jski@raspberrypi ~> gforth --versiongforth 0.7.3* > > Gforth is what 20 years old? In July it will be 30 years since we started the project. If your question is: Why are we

Re: Hiw to use graphics in gforth?

On Fri, May 20, 2022 at 07:11:31PM +0200, paul.ort...@aida-sea.com wrote: > > Hello Anton, Joe, > > I wasn't the initiator of this request, but it directly relates to a concern > of mine. > Though I can live with just at-xy and and scarce polices, the lack of > graphics words in Gforth, and the

Re: Hiw to use graphics in gforth?

On Thu, May 19, 2022 at 08:15:55AM +0800, Joe Lin wrote: > Dear Sir, > > Would you please tell us the way to use graphics such as line or draw in > gforth? Development Gforth includes the GUI library MINOS2, but it is undocumented. Otherwise, you typically can use your OSs graphics facilities

Re: Trying to extend gforth's outer interpreter

On Fri, Apr 01, 2022 at 09:51:09AM +0100, Tristan Williams wrote: > Hello, > > I am trying to extend gforth's outer interpreter so that how numbers > are treated is dependent on which mode (indicated by the value of > mode?) my program is in. In the code below, if mode? is true the > number is

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

Follow-up Comment #1, bug #62214 (project gforth): When you build Gforth from the git sources, it uses an existing (outdated) Gforth in various places. That's why it's in the install dependencies. When you build Gforth from the tarball, you don't need an existing Gforth. Maybe we should

[bug #62037] doc error in description of until loop

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

[bug #62037] doc error in description of until loop

Update of bug #62037 (project gforth): Status:None => Fixed ___ Follow-up Comment #1: Thanks. Fixed in the development version since 2012 (we need to release more often:-).

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

Update of bug #62030 (project gforth): Status:None => Confirmed Assigned to:None => paysan ___ Follow-up Comment #1: I am not quite sure

Re: Immersion

On Fri, Dec 03, 2021 at 12:57:03AM +0100, Tomas Hlavaty wrote: > On Thu 02 Dec 2021 at 19:16, Anton Ertl > wrote: > > On Tue, Nov 30, 2021 at 09:35:28PM +0100, Tomas Hlavaty wrote: > >> How would a gforth beginner start with this kind of editing? > > > >

Re: Immersion

On Tue, Nov 30, 2021 at 09:35:28PM +0100, Tomas Hlavaty wrote: > On Tue 07 Sep 2021 at 20:59, Anton Ertl > wrote: > > On Tue, Sep 07, 2021 at 02:26:57PM -0400, Brian Tiffin wrote: > >> Drop after-l.  Don't wait for the next key > >> stroke to decide what state to p

Re: Immersion

On Tue, Sep 07, 2021 at 02:26:57PM -0400, Brian Tiffin wrote: > Drop after-l.  Don't wait for the next key > stroke to decide what state to put the console in.  It becomes a mental > mode breaking point, with a distracting screen paint out of order.  There is some truth to that. However, we

Re: Crash with local variables and EXIT

On Sun, Aug 01, 2021 at 06:57:45PM +0200, Bernd Paysan wrote: > Am Sonntag, 1. August 2021, 18:39:40 CEST schrieb Anton Ertl: > > Looks like a bug in locals handling to me. I'll look into it. > > Doesn't need the ?EXIT > > : test 1 { var } 2 { var } ; > > simple-se

Re: Crash with local variables and EXIT

On Sun, Aug 01, 2021 at 04:06:53PM +, David Kuehling wrote: > Hi, > > I just stumbled over a peculiar Gforth crash bug involving use of local > variables and ?EXIT: > > A condensed demonstration of the crash is this code: > > --8<-- > : test ( flag -- ) > 0 { var } > ?EXIT >

Re: Undocumented primitives

On Sun, Jul 25, 2021 at 06:00:04AM +, David Kuehling wrote: > Hi, > > I recently noticed a warning for my words DLSHIFT and DRSHIFT already > beeing defined in Gforth. I had re-implemented both words in plain > forth, as they were not mentioned in the manual. > > Now looking into "prim"

[bug #60250] Number conversion

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

Re: Pausing compilation in GForth

On Mon, Mar 22, 2021 at 01:11:28PM +0100, paul.ort...@aida-sea.com wrote: > Hello all, > > I am looking for any method to pause compilation, so that it goes on by > smaller chunks and I have the time to examine successes and errors, then > release it for one more screen etc. > > Tried to insert

Re: Cross compiling

On Mon, Mar 01, 2021 at 08:54:21PM +, Ethan Gardener wrote: > I was responding to Anton Ertl's comment, "Assembly language is not a > particularly nice way of writing Forth > code, though (and most of a Forth system is written in Forth);" particularly > with a view to what proportion of

Re: Cross compiling

On Sun, Feb 28, 2021 at 05:04:16PM +0100, Francesco Ariis wrote: > Hello forthers, > > I was reading the manual section on cross-compiling [1], but the > documentation seems a bit outdated (e.g. `kernl-8086.fi` target is not > present in my `gforth-0.7.3`). I think the 8086 files are not

Re: Attempt at implementing labeled loops

On Wed, Feb 03, 2021 at 05:01:28PM +0100, JFLF wrote: > > Hello all, > > Apologies if this is not the right place to ask. I have been attempting for a > few days to solve a specific problem with GForth 0.7.3, but so far I have > failed. Could anyone provide some advice? Disclaimer: I'm still

[gforth] use pfa as xt?

In the development version we have redesigned the header so that for most words nt=xt (i.e., NAME>INTERPRET does nothing for these words). We are now considering whether to use the PFA (body address) rather than the CFA as xt/nt. Now would be a good time for such a change, because the new header

Re: Building Gforth for Apple's new Arm-based Macs

On Wed, Jan 20, 2021 at 07:29:00PM +0300, Alexander Shpilkin wrote: > Incidentally, I looked at the corresponding branch in configure.ac[1] > and it seems to me that the check for arm_cacheflush there is... > technically correct, but extremely misleading: if the variable is > empty, `test -z

Re: Building Gforth for Apple's new Arm-based Macs

On Wed, Jan 20, 2021 at 07:29:00PM +0300, Alexander Shpilkin wrote: > Incidentally, I looked at the corresponding branch in configure.ac[1] > and it seems to me that the check for arm_cacheflush there is... > technically correct, but extremely misleading: if the variable is > empty, `test -z

Re: Building Gforth for Apple's new Arm-based Macs

On Wed, Jan 20, 2021 at 10:07:10AM -0500, Craig Treleaven wrote: > > > On Jan 19, 2021, at 6:08 PM, Anton Ertl > > wrote: > > > > On Tue, Jan 19, 2021 at 02:42:10PM -0500, Craig Treleaven wrote: > >> Hi: > >> > >> I contribute a l

Re: Building Gforth for Apple's new Arm-based Macs

On Tue, Jan 19, 2021 at 02:42:10PM -0500, Craig Treleaven wrote: > Hi: > > I contribute a little to the MacPorts project. MacPorts packages many, many > open source software titles for use on Macintosh. I noticed that Gforth > failed to build on our new buildbot running on an M1 machine(aka

Re: cset seems to override the next byte

On Mon, Dec 28, 2020 at 07:36:21PM +0100, Bernd Paysan wrote: > Am Montag, 28. Dezember 2020, 14:08:06 CET schrieb Anton Ertl: > > We use CSET internally, so we may add a word with its current > > functionality, but a different name. The convention would be to call > > it

Re: cset seems to override the next byte

On Mon, Dec 28, 2020 at 11:11:43AM +0100, hwj+gforth.gnu@mailbox.org wrote: > Good morning, > > "cset" in gforth seems to override the next byte: > > $ gforth -e 'variable a 0 a ! 0x0101 a cset a @ .' -e bye > 257 > > I know "cset" is not in the standard, but (given it's

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

Follow-up Comment #4, bug #59674 (project gforth): Yes, we should do it in "smart.". ~~ calls ..., and it should not matter whether the run-time happens to be in hex or decimal. Yes, we do not know what it is, and therefore guess it, but making the guess on BASE does not appear to be a good

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

Follow-up Comment #2, bug #59674 (project gforth): The status line (like ...) displays numbers that are (accessible) addresses outside the dictionary in hex with $ prefix (or as strings), and non-address numbers in decimal, by design. It also displays the base unless it is decimal. I agree that

Re: gforthmi instructions confused regarding relocatability

On Thu, Oct 01, 2020 at 12:22:16PM +0100, Ethan Gardener wrote: > In the gforth documentation, at the bottom of section 13.5.1, are some > confused statements. To quote: > > > A special doubly indirect threaded version of the gforth executable is used > > for creating the non-relocatable

[bug #58531] Analysis of (+loop)

Update of bug #58531 (project gforth): Open/Closed:Open => Closed ___ Follow-up Comment #2: Thanks for the analysis. The comment about gforth-native is still relevant, because it explains

[bug #54559] Remove support for obsolete Emacsen

Update of bug #54559 (project gforth): Open/Closed:Open => Closed ___ Follow-up Comment #7: Patch applied in commit d78d58ab7c924f08c5f6b89e3a7b516f84000c7e

Re: GNU/GForth.org-hosted F-Droid repository for freedom-reviewed Android applications written in GForth?

On Tue, Aug 04, 2020 at 02:57:16PM +0100, J. R. Haigh wrote: > Btw., in my previous emails, I was assuming that GForth is a GNU > project, but I'm not sure. It is. > Who controls https://GForth.org ? Gerald Wodni, who is part of the Gforth team. -

Re: How to contribute?

On Sun, Aug 02, 2020 at 01:42:05PM -0300, Geyslan G. Bem wrote: > Hello maintainers, > > How could I send patches? Through e-mail or git PR? Email will be fine. I am not that versed with pull requests, but I expect that we are also able to cope with that. Note that if the patch is significant

Re: Bug report

On Sat, Jul 04, 2020 at 05:21:47PM +0100, Ian Bell wrote: > Using Gforth 0.7.9_20200611 > > Type a single letter t or T followed by return > > Gforth freezes Works for me: Gforth 0.7.9_20200618 ... Type `help' for basic help t *the terminal*:1:1: error: Undefined word >>>t<<< Can you try

Re: Tutorial - Memory - is it correct?

On Sat, Jun 06, 2020 at 09:56:33PM +0200, Andrzej Rybczyﾅ?ski wrote: > Hello Gforth Team, > > I'm reading Gforth tutorial available from gforth.org. Forth is something > completely new for me, but I think there is a typo in section 3.23 Memory: > > "You can use ! (store) to store values into

Re: lshift bug

On Sun, May 17, 2020 at 10:22:03PM +0200, Klaus Schleisiek wrote: > Am 17.05.2020 um 18:10 schrieb Anton Ertl: > > > and this should work as you expect. But I would not call a result 0 > > "mathematically correct". > > Aber ja doch! Lshift ist doch so definier

Re: lshift bug

On Sun, May 17, 2020 at 05:52:29PM +0200, Klaus Schleisiek wrote: > Am 16.05.2020 um 18:06 schrieb Anton Ertl: > > In Gforth, LSHIFT does what unsigned << does in gcc (it's undefined in > > C, and AFAIK GNU C does not define it, either), which is typically > > what t

Re: lshift bug

On Sat, May 16, 2020 at 05:46:49PM +0200, Klaus Schleisiek wrote: > Hallo Bernd, > > on 64-bit gforth_0.7.9_20200305 I enter: > > 1 &64 lshift 1 ok > > hm > > I would expect 0 as you get with > > : lshift' ( u1 u2 -- u3 ) 0 ?DO 2* LOOP ; From:

Re: -infinity and REPRESENT

On Tue, May 05, 2020 at 01:03:31AM +0200, m...@iae.nl wrote: > On 2020-05-04 17:24, Anton Ertl wrote: > > One issue is how to deal with -infinity (e.g., the result of -1e 0e f/). > > Previously Gforth 0.7.2+glibc produced "-inf" and f1=0 (positive), > > f2=0 (not val

-infinity and REPRESENT

I just re-implemented REPRESENT. One issue is how to deal with -infinity (e.g., the result of -1e 0e f/). Previously Gforth 0.7.2+glibc produced "-inf" and f1=0 (positive), f2=0 (not valid); other libc implementations might lead to different results. gforth 0.7.9_20200423 uses an ecvt_r supplied

Re: problem with creating word

On Fri, Apr 10, 2020 at 08:40:24AM +0200, Robert Sander wrote: > Hello, > > I want to create a word and store a generated id and a string in the > datafield. > > I have the following words: > > variable ma# > 68 ma# ! \ just to find the value in the memoy > > : ma: ( -- ) > 1 ma# +! \

[bug #57741] Strange begin drop again ;

Update of bug #57741 (project gforth): Status: Confirmed => Fixed Open/Closed:Open => Closed ___ Follow-up Comment #5: fixed in the git

[bug #57741] Strange begin drop again ;

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

[bug #57741] Strange begin drop again ;

Update of bug #57741 (project gforth): Status:None => Confirmed Assigned to:None => anton ___ Follow-up Comment #1: The gforth engine

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

Follow-up Comment #9, bug #57340 (project gforth): twm does not catch alt-tab. LANC=C xterm produces 137 for alt-tab, while LANC=C.UTF-8 xterm produces 194 137 (i.e., the same code point). ___ Reply to this item at:

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

Update of bug #57340 (project gforth): Status: Need Info => Confirmed ___ Follow-up Comment #7: I can reproduce this (shift-tab) in gforth 0.7.2 on an xterm in Debian 8, and in gforth-0.7.3 on

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

Follow-up Comment #2, bug #57340 (project gforth): I also cannot reproduce this. I tried it with gforth 0.7.3 on an xterm on Ubuntu 18.04, and Shift-Backspace just produced 127 from EKEY, without any other noticable effects. My guess is that the terminal emulator used may play a role here. If

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

Follow-up Comment #2, bug #56406 (project gforth): Another way to express this: : a if begin repeat ; is a standard program, so Gforth as a standard system must accept it. Why is it standard? The standard says: IF ( C: -- orig ) BEGIN ( C: -- dest ) So after BEGIN the control-flow stack

[Bug-gforth] [bug #56352] Typo in vmgen manual

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

Re: [gforth] Classic or smart .S ?

On Thu, May 02, 2019 at 10:04:22PM +0200, Bernd Paysan wrote: > Am Dienstag, 30. April 2019, 17:12:34 CEST schrieb Anton Ertl: > > What do you think should be the default for .S and ~~: the classic or > > the smart .S ? > > The question on today's net2o chat resulted in 3 vo

[gforth] Classic or smart .S ?

In Gforth the classic .S produces just numbers in the current base, e.g.: <7> 140403976810720 0 140403977391576 140403977391576 0 11192792 140403976810872 Gforth also supports a smart .S that uses heuristics to determine what kind of data is on the stack and displays it appropriately; the same

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

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

[Bug-gforth] [bug #55867] Bug in forth-fill-paragraph, and fix

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

Re: [gforth] FOR...NEXT

On Sat, Feb 23, 2019 at 03:38:45PM +, dch wrote: > Why does FOR run n+1 times? It seems inane. `4 FOR ... NEXT` should not > run 5 times, that's absolutely ridiculous. Even Chuck's FOR loops ran n > times in Forth and n times in ColorForth. So there must be a good reason > for this.

Re: [gforth] NOT

On Fri, Feb 15, 2019 at 04:21:47PM -0500, J. David Boyd wrote: > > Any idea how to implement the word NOT in gforth to create a 1s complement? > I can find an assembler definition in SwiftForth, but no other luck anywhere. : not invert ; Or better use INVERT directly. > I also don't seem to be

Re: [gforth] x and y words exposed

On Tue, Feb 12, 2019 at 11:26:22AM -0700, David Smith wrote: > I have had a similar experience with the word g. Yesterday I meant g to be > a certain function I was graphing, but I had not yet implemented it when I > ran the program. It was quite a surprise to see VI opened and displaying > Gforth

[Bug-gforth] [bug #54559] Remove support for obsolete Emacsen

Follow-up Comment #4, bug #54559 (project gforth): We are currently not adding features to gforth.el, so we do not feel the pain of maintaining backwards compatibility at the moment. We have machines from the early 1990s that surely have not been upgraded to Emacs 21; but OTOH, they are turned

[Bug-gforth] [bug #55628] dictionary overflow if too many locals

Update of bug #55628 (project gforth): Status:None => Fixed Assigned to:None => anton ___ Reply to this item at:

[Bug-gforth] [bug #55628] dictionary overflow if too many locals

Follow-up Comment #1, bug #55628 (project gforth): Thank you. This is fixed (unlimited locals) in the current snapshot (). I don't think we will fix it in a 0.7 release, though.

Re: [gforth] GFORTHPATH alternative?

On Sat, Jul 28, 2018 at 04:14:16PM -0500, Reepca Russelstein wrote: > It seems that GFORTHPATH, if set, supersedes the install-time > configured places to search for forth source and image files, > including, for example, the current directory. But I just want to > specify additional places to

Re: [gforth] Configuring multiple libccdirs

On Tue, Jul 03, 2018 at 10:01:27PM +0200, Bernd Paysan wrote: > Am Dienstag, 3. Juli 2018, 18:05:21 CEST schrieb Anton Ertl: > > The question is if it makes sense. The files in these directories are > > cached intermediate results produced from Forth source files > > contain

Re: [gforth] Configuring multiple libccdirs

[This time for the whole mailing list] On Tue, Jul 03, 2018 at 08:54:42PM -0500, Reepca Russelstein wrote: > I suppose I should give a concrete example: > > I am attempting to write some interfaces to various C libraries - for > example, cpython and glfw. I've generated some interfaces with >

Re: [gforth] Configuring multiple libccdirs

On Tue, Jul 03, 2018 at 04:34:34PM +0200, Bernd Paysan wrote: > Am Dienstag, 3. Juli 2018, 12:03:57 CEST schrieb Reepca Russelstein: > > Currently there are two places gforth will check for already-existing > > compiled wrapper code: > > > > 1. ~/.gforth//libcc-named > > 2. $libccdir or, if that

Re: [gforth] Accented characters

On Thu, May 03, 2018 at 10:14:32PM -0400, Mario Beaulieu wrote: > Hi, > > The problem I'm having might not have anything to do with GForth, but let's > see. I'm running GForth on a Raspberry Pi (Linux). > > I have a GForth program (notification.fs) that sends notifications to my cell > phone.

Re: [gforth] Raspberry Pi/ARM performance

On Tue, May 01, 2018 at 06:49:51PM +, Aaron Krister Johnson wrote: > 4) using gforth as "glue", and dropping to C or Assembler for relief from > performance bottlenecks. (Even though interpreted Forth is second only to C > for speed) That can certainly help, if much of the time is spent in a

Re: [gforth] Open a file in Append mode

On Sun, Apr 29, 2018 at 10:52:29PM -0400, Mario Beaulieu wrote: > Hi, > > Is there such a thing as an Append mode when opening a file, so I can keep > adding to an existing file when I re-open it? Something like w/a or r/a? Currently Gforth does not have that. You can use FILE-SIZE and

Re: [gforth] Compile gforth on Cygwin

On Sat, Mar 31, 2018 at 05:21:01PM -0700, Dennis Ruffer wrote: > I also needed texlive, but it still seems to not be done. It installs now, so > it’s not a big deal, but I thought it used to end with some kind of message. What I see in the log is errors from chcon (I am surprised that there is a

Re: [gforth] Unexpected compiler error with Gforth 0.7.0 on Windows

On Sun, Dec 10, 2017 at 12:35:21AM +0100, Phillip Eaton wrote: > Before I start some heavy Gforth source code debugging, can anyone tell me > if there are any known differences in the way LOAD and INCLUDE behave with > the same (but converted) code? LOAD treats a whole screen like one line

Re: [gforth] Decompilation not working properly.

On Mon, Feb 13, 2017 at 06:37:23AM -0500, Stéphane Fillion wrote: > Hi. > > I'm using gforth 0.7.2 under lubuntu 16.04. Arch is AMD64. > > I installed it with this command: > > sudo apt-get install gforth > > > > The 'see' word works correctly when trying to decompile any user-defined > and

[Bug-gforth] [bug #50221] FP operations produce unexpected NaNs

Update of bug #50221 (project gforth): Status: Confirmed => Fixed ___ Follow-up Comment #5: fixed in the git repository. ___ Reply

[Bug-gforth] [bug #50221] FP operations produce unexpected NaNs

Update of bug #50221 (project gforth): Status:None => Need Info ___ Follow-up Comment #1: Please give more information on the platform and Gforth version to allow us to reproduce the

Re: [gforth] problems trying to run gfort on lubuntu 16.10

On Fri, Dec 30, 2016 at 04:44:22PM -0300, Cesar wrote: > Hello, i've just downloaded and installed gforth on lubuntu 16.10 en > when i try to run it i get the following message: > > gforth: cannot open image file gforth.fi in path >

  1   2   >