Re: [gforth] my vsum function is suspiciously non-local

On Sun, Mar 07, 2010 at 03:31:15PM -0500, Josh Grams wrote: Note also that global variables aren't frowned upon in Forth as they are in other languages. Certainly you need to be aware of when they are a problem (and vsum is probably one of these places). It also depends on the approach to

Re: [gforth] Doc Typo

On Tue, May 11, 2010 at 01:20:35PM -0400, Josh Grams wrote: kernel/require.fs, line 36: seesion Thank you. Fixed. - anton

Re: [gforth] #line directive?

On Sun, Jul 24, 2011 at 09:10:33PM -0400, Josh Grams wrote: I have been doing a bit of literate programming, and so of course then I want gforth to report errors relative to the original source and not the generated files. After a bit of poking around in the source, I came up with the

Re: [gforth] How to make executable binary applications?

On Sun, Nov 06, 2011 at 09:17:34PM +0100, Bernd Paysan wrote: Gforth is under GPL. If you plan to do that, you first of all need a GPL exception, you cannot do that with the license under which you have obtained Gforth - this is different from C, where the binary does not contain the C

Re: [gforth] ORDER bug

On Mon, Nov 14, 2011 at 01:18:56AM +0100, Bernd Paysan wrote: Am Sonntag, 13. November 2011, 18:41:54 schrieb Josh Grams: Hm, looking at head?, it really looks wrong. Try replacing it with this: : head? ( addr -- f ) \G heuristic check whether addr is a name token; may deliver false

Re: [gforth] common file paths for Linux and Windows?

On Tue, Jul 09, 2013 at 05:28:45PM +0200, Marcos Cruz wrote: Hi, I'm planning to distribute the sources of some programs written in Gforth (an interactive fiction framework and some demo games written with it). My OS is Debian, but I guess most of the (few) potential users run Windows (and

Re: [gforth] missing file included, error message corrupted

On Sat, Aug 17, 2013 at 06:51:06PM +0200, Marcos Cruz wrote: Some time ago I realized a strange issue (Gforth 0.7.0 on Raspberry Pi's Raspbian) when a missing file is included. I have just tried it with detail. When the command is given from the command line, include missing.fs

Re: [gforth] Gforth image files and shared c librarys! How to access?

On Mon, Sep 02, 2013 at 05:16:57PM -0600, Philip Smith wrote: I have done some testing to see the speed benefit of precompiled images and i find that there is up to 200 times speed benefit for some of my testing code. Could you make that testing code available. I find this difference

Re: [gforth] typo in Exception-Handling.html

On Thu, Nov 07, 2013 at 05:16:00PM +0100, Marcos Cruz wrote: I've just found a little typo in http://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Exception-Handling.html: base r hex \ actually the hex should be inside foo, or we h '@' is missing after 'base'; and the comment is

Re: [gforth] Performance anomality with dynamic superinstructions on MIPSel

On Mon, Mar 24, 2014 at 03:17:41AM +0100, Bernd Paysan wrote: What did the trick? Using FIRST_NEXT actually in after_last:, this is a dummy for getting the tail of the last address, we can put anything we like there. Doing FIRST_NEXT there makes it a noop, and since there's nothing to

Re: [gforth] After updating to Emacs 24.3, Source file `/usr/local/share/emacs/site-list/gforth.el' newer than byte-compiled file

On Mon, Mar 24, 2014 at 05:19:47AM -0600, Donald Winiecki wrote: I have recently updated my Emacs setup to Emacs 24.3 on Ubuntu 12.4. ... Source file `/usr/local/share/emacs/site-list/gforth.el' newer than byte-compiled file I recently read that Debian is disabling byte compilation for

Re: [gforth] Performance anomality with dynamic superinstructions on MIPSel

On Mon, Mar 24, 2014 at 01:32:13PM +0100, Bernd Paysan wrote: 2) Just like for checking for registers and long longs, try whether the engine works without the workaround mentioned above, and only employ the workaround if it doesn't. The workaround is for historical GCCs; we might also cut

Re: [gforth] setting up a linux system so to learn gfroth and GNU/linux

On Sat, Aug 16, 2014 at 12:52:00AM +0200, Bernd Paysan wrote: FSF's issue with OpenSuSE are the firmware blobs. I'm not convinced of that issue: This is just technical, the manufacturers of these chips use RAMs to store the firmware so that they can develop that stuff without many long

Re: [gforth] setting up a linux system so to learn gfroth and GNU/linux

On Sun, Aug 17, 2014 at 09:16:52PM +0200, Bernd Paysan wrote: Am Samstag, 16. August 2014, 13:28:22 schrieb Anton Ertl: On Sat, Aug 16, 2014 at 12:52:00AM +0200, Bernd Paysan wrote: FSF's issue with OpenSuSE are the firmware blobs. I'm not convinced of that issue: This is just technical

Re: [gforth] [feature request] literate programming support

On Sun, Oct 12, 2014 at 03:31:40PM +0300, Jay Pinkman wrote: \ [[ ## Title Some *markdown* `maybe`? ]][[ : some ( forth -- ) code ; : and ( a -- little ) more ; ]] what you think? ]] ... [[ is used for postpone mode, e.g.: : repeat ]] again then [[ ; immediate instead of :

Re: [gforth] `name-too-long?` in `input-stream-header`

On Mon, Nov 16, 2015 at 07:08:34PM +0100, Bernd Paysan wrote: > Am Sonntag, 15. November 2015, 09:18:36 schrieb Anton Ertl: > > On Sat, Nov 14, 2015 at 03:50:42PM +0100, Marcos Cruz wrote: > > > I just realized (Gforth 0.7.3) that `name-too-long?` is called in > > > `

Re: [gforth] `name-too-long?` in `input-stream-header`

On Sat, Nov 14, 2015 at 03:50:42PM +0100, Marcos Cruz wrote: > I just realized (Gforth 0.7.3) that `name-too-long?` is called in > `input-stream-header`, while it's also the first word called in > `header,`: > > : input-stream-header ( "name" -- ) > parse-name name-too-short? header, ; >

Re: [gforth] Invalid memory address

On Tue, Mar 22, 2016 at 10:27:33PM -0400, Mario Beaulieu wrote: > Hi, > > Is there a maximum number of items that can be passed on the data stack as > parameters to a c-function? I'm calling a function with 13 parameters and, at > execution time I get an "Invalid memory address" message and the

Re: [gforth] Floats in gforth?

On Wed, May 25, 2016 at 08:43:26AM -0400, John Chludzinski wrote: > IEEE 754 double precision. Check out: > http://steve.hollasch.net/cgindex/coding/ieeefloat.html I have once come across an ARM softfloat implementation that did not behave like IEEE doubles. Certainly for now Gforth uses C

Re: [gforth] Just curious

On Mon, Jul 04, 2016 at 09:45:21AM -0400, Mario Beaulieu wrote: > Hi, > > I'm just curious. Why does GForth have a version number 0.7.3 and not > 1.something? It seems to me that GForth is stable and very complete. Do you > have an objective in mind to achieve before you consider it version 1?

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

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 >

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] 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] 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] 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

[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 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

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] 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] 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] 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

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

[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

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

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# +! \

-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: -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

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

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: 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: 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

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: 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 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

[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 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: 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

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 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: 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: 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 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: 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: 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 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: 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"

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

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: 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: 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: 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: 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: 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: 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: 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: 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

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

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: 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: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

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: 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

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

Update of bug #26652 (project gforth): Assigned to:None = paysan ___ Follow-up Comment #4: If the code for the primitives is the same, then it does not matter if they are at different

Re: [Bug-gforth] Can't compile Gforth 0.7.0 on Solaris (sparc)

On Thu, Feb 18, 2010 at 05:12:29PM +0200, Torbjorn Kristoffersen wrote: I tried compiling Gforth 0.7.0 on Solaris. $ uname -a SunOS battlestar 5.11 snv_127 sun4u sparc SUNW,Sun-Blade-1000 I tested before release on SunOS t1000 5.10 Generic_118833-17 sun4v sparc SUNW,Sun-Fire-T1000 with

[Bug-gforth] [bug #35540] confusing doc description

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

[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

[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

[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 #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

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.

[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 #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

[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 #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 #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: Confirmed => Fixed Open/Closed:Open => Closed ___ Follow-up Comment #5: fixed in the git

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: 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 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: 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

  1   2   >