Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #25709 > unrolled thread

Advice requested on working with Forth and external editors

Back to article view | Back to comp.lang.forth

Contents

  Advice requested on working with Forth and external editors General Van Ryberg <vvdleun@hotmail.com> - 2013-09-16 12:15 -0700
    Re: Advice requested on working with Forth and external editors Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2013-09-16 20:39 +0100
    Re: Advice requested on working with Forth and external editors voidvolker@gmail.com - 2013-09-16 12:50 -0700
    Re: Advice requested on working with Forth and external editors "Elizabeth D. Rather" <erather@forth.com> - 2013-09-16 11:02 -1000
    Re: Advice requested on working with Forth and external editors Roelf Toxopeus <rt4all@notthis.hetnet.nl> - 2013-09-17 00:50 +0200
    Re: Advice requested on working with Forth and external editors hughaguilar96@yahoo.com - 2013-09-16 20:35 -0700
      Re: Advice requested on working with Forth and external editors rickman <gnuarm@gmail.com> - 2013-09-17 00:39 -0400
        Re: Advice requested on working with Forth and external editors josv@planet.nl - 2013-09-27 09:34 -0700
    Re: Advice requested on working with Forth and external editors anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-09-17 10:57 +0000
      Re: Advice requested on working with Forth and external editors Roelf Toxopeus <rt4all@notthis.hetnet.nl> - 2013-09-17 17:49 +0200
        Re: Advice requested on working with Forth and external editors anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-09-17 17:05 +0000
          Re: Advice requested on working with Forth and external editors Roelf Toxopeus <rt4all@notthis.hetnet.nl> - 2013-09-17 22:17 +0200
            Re: Advice requested on working with Forth and external editors albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-09-18 10:38 +0000
          Re: Advice requested on working with Forth and external editors Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-09-18 00:15 +0100
            Re: Advice requested on working with Forth and external editors Roelf Toxopeus <rt4all@notthis.hetnet.nl> - 2013-09-18 09:37 +0200
              Re: Advice requested on working with Forth and external editors anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-09-18 08:46 +0000
              Re: Advice requested on working with Forth and external editors Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-09-18 17:44 +0100
                Re: Advice requested on working with Forth and external editors Roelf Toxopeus <rt4all@notthis.hetnet.nl> - 2013-09-18 23:36 +0200
                  Re: Advice requested on working with Forth and external editors Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-09-19 11:53 +0100
            Re: Advice requested on working with Forth and external editors anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-09-18 08:54 +0000
              Re: Advice requested on working with Forth and external editors Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2013-09-18 13:19 +0100
              Re: Advice requested on working with Forth and external editors Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-09-19 11:41 +0100
                Re: Advice requested on working with Forth and external editors no.top.post@gmail.com - 2013-10-02 00:56 +0000
            Re: Advice requested on working with Forth and external editors albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-09-18 10:40 +0000
              Re: Advice requested on working with Forth and external editors Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-09-18 17:36 +0100
      Re: Advice requested on working with Forth and external editors hughaguilar96@yahoo.com - 2013-09-17 21:50 -0700
        Re: Advice requested on working with Forth and external editors anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-09-18 08:39 +0000
    Re: Advice requested on working with Forth and external editors humptydumpty <ouatubi@gmail.com> - 2013-09-18 10:39 -0700
      Re: Advice requested on working with Forth and external editors humptydumpty <ouatubi@gmail.com> - 2013-09-18 10:43 -0700
    Re: Advice requested on working with Forth and external editors General Van Ryberg <vvdleun@hotmail.com> - 2013-09-21 00:32 -0700

Page 1 of 2  [1] 2  Next page →

#25709 — Advice requested on working with Forth and external editors

Hello,

I am new here, and quite new to Forth in general. Like some others here, I'm also from The Netherlands (Utrecht). While I work as a Python (and Java, my favorite) developer, for my small personal pet projects I was looking for something "different". Forth got me hooked. Love the "low level" feeling. After careful evaluating of both MPE's Forth and Forth Inc's SwiftForth, I decided to buy the latter and their two books (thanks to co-author mrs. Rather, they were very helpful).

Now I'm working on my first small, but "real" program, I have some difficulty with the integration of Forth and an external editor (currently using Notepad++). 

I can type definitions in Forth, test them and when I'm happy with them, copy code to clipboard + alt-tab to the editor + find the definitions + select existing code in the editor to overwrite + paste. This has the drawback that i must be quite careful. And if I changed more than 1 word at a time, I must not forget to copy and manually replace them one at a time. This works, but feels a bit clumsy.

I can also INCLUDE an existing file. Develop/test my words. And finally with LOCATE, EDIT commands try to keep my editor files up to date from time to time. And every now and again use EMPTY and ABORT and then INCLUDE the file to see if I missed anything. And if I did, try to find out what with SwiftForth's History function. This is the approach I try to follow now, but still feel I might be missing something obvious.

I would have liked if SwiftForth had a built-in editor (a basic one would do IMHO), so it would be a bit easier to have both open in the same program (have the same parent GUI window). Or to least a function to optionally automatically reload an include file if its contents changed (was saved in an external editor).

I was wondering how others are "syncing" their interactively developed definitions with files and vice-versa?

Best regards,
Vincent

[toc] | [next] | [standalone]

#25710

General Van Ryberg wrote:

> Hello,
> 
> I am new here, and quite new to Forth in general. Like some others here,
> I'm also from The Netherlands (Utrecht). While I work as a Python (and
> Java, my favorite) developer, for my small personal pet projects I was
> looking for something "different". Forth got me hooked. Love the "low
> level" feeling. After careful evaluating of both MPE's Forth and Forth
> Inc's SwiftForth, I decided to buy the latter and their two books (thanks
> to co-author mrs. Rather, they were very helpful).
> 
> Now I'm working on my first small, but "real" program, I have some
> difficulty with the integration of Forth and an external editor (currently
> using Notepad++).
> 
> I can type definitions in Forth, test them and when I'm happy with them,
> copy code to clipboard + alt-tab to the editor + find the definitions +
> select existing code in the editor to overwrite + paste. This has the
> drawback that i must be quite careful. And if I changed more than 1 word
> at a time, I must not forget to copy and manually replace them one at a
> time. This works, but feels a bit clumsy.
> 
> I can also INCLUDE an existing file. Develop/test my words. And finally
> with LOCATE, EDIT commands try to keep my editor files up to date from
> time to time. And every now and again use EMPTY and ABORT and then INCLUDE
> the file to see if I missed anything. And if I did, try to find out what
> with SwiftForth's History function. This is the approach I try to follow
> now, but still feel I might be missing something obvious.
> 
> I would have liked if SwiftForth had a built-in editor (a basic one would
> do IMHO), so it would be a bit easier to have both open in the same
> program (have the same parent GUI window). Or to least a function to
> optionally automatically reload an include file if its contents changed
> (was saved in an external editor).
> 
> I was wondering how others are "syncing" their interactively developed
> definitions with files and vice-versa?
> 
> Best regards,
> Vincent


I know in MPE's VxForth there is a way to attach your favourite text editor 
so that you can easily call it up when needed. I have mine permanently 
linked to Kwrite (as I run under Linux) but I would have to dig to find out 
(again) how that was done. Perhaps one of the vendors will advise soon.

-- 
********************************************************************
Paul E. Bennett IEng MIET.....<email://Paul_E.Bennett@topmail.co.uk>
Forth based HIDECS Consultancy.............<http://www.hidecs.co.uk>
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-510979
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************

[toc] | [prev] | [next] | [standalone]

#25711

General Van
> Hello,
> I am new here, and quite new to Forth in general. Like some others here, I'm also from The Netherlands (Utrecht). While I work as a Python (and Java, my favorite) developer, for my small personal pet projects I was looking for something "different". Forth got me hooked. Love the "low level" feeling. After careful evaluating of both MPE's Forth and Forth Inc's SwiftForth, I decided to buy the latter and their two books (thanks to co-author mrs. Rather, they were very helpful).
> 
> Now I'm working on my first small, but "real" program, I have some difficulty with the integration of Forth and an external editor (currently using Notepad++). 
> 
> I can type definitions in Forth, test them and when I'm happy with them, copy code to clipboard + alt-tab to the editor + find the definitions + select existing code in the editor to overwrite + paste. This has the drawback that i must be quite careful. And if I changed more than 1 word at a time, I must not forget to copy and manually replace them one at a time. This works, but feels a bit clumsy.
>
> I can also INCLUDE an existing file. Develop/test my words. And finally with LOCATE, EDIT commands try to keep my editor files up to date from time to time. And every now and again use EMPTY and ABORT and then INCLUDE the file to see if I missed anything. And if I did, try to find out what with SwiftForth's History function. This is the approach I try to follow now, but still feel I might be missing something obvious.
> 
> I would have liked if SwiftForth had a built-in editor (a basic one would do IMHO), so it would be a bit easier to have both open in the same program (have the same parent GUI window). Or to least a function to optionally automatically reload an include file if its contents changed (was saved in an external editor).
> 
> I was wondering how others are "syncing" their interactively developed definitions with files and vice-versa?
> 
> Best regards,
> 
> Vincent

Hi!
I use "Sublime Text 2" with autosave option + VirtualBox with file sharing + nnCron for hotkeys build/run and other power options. In host OS I work with code, and run it in VirtualBox OS / Host OS with nnCron.
My previous text editor was SciTE-RU - but after new version, that cleared my sources to ZERO, I decide to use somthing more stable =)

[toc] | [prev] | [next] | [standalone]

#25713

On 9/16/13 9:15 AM, General Van Ryberg wrote:
> Hello,
>
> I am new here, and quite new to Forth in general. Like some others here, I'm also from The Netherlands (Utrecht). While I work as a Python (and Java, my favorite) developer, for my small personal pet projects I was looking for something "different". Forth got me hooked. Love the "low level" feeling. After careful evaluating of both MPE's Forth and Forth Inc's SwiftForth, I decided to buy the latter and their two books (thanks to co-author mrs. Rather, they were very helpful).
>
> Now I'm working on my first small, but "real" program, I have some difficulty with the integration of Forth and an external editor (currently using Notepad++).
>
> I can type definitions in Forth, test them and when I'm happy with them, copy code to clipboard + alt-tab to the editor + find the definitions + select existing code in the editor to overwrite + paste. This has the drawback that i must be quite careful. And if I changed more than 1 word at a time, I must not forget to copy and manually replace them one at a time. This works, but feels a bit clumsy.
>
> I can also INCLUDE an existing file. Develop/test my words. And finally with LOCATE, EDIT commands try to keep my editor files up to date from time to time. And every now and again use EMPTY and ABORT and then INCLUDE the file to see if I missed anything. And if I did, try to find out what with SwiftForth's History function. This is the approach I try to follow now, but still feel I might be missing something obvious.
>
> I would have liked if SwiftForth had a built-in editor (a basic one would do IMHO), so it would be a bit easier to have both open in the same program (have the same parent GUI window). Or to least a function to optionally automatically reload an include file if its contents changed (was saved in an external editor).
>
> I was wondering how others are "syncing" their interactively developed definitions with files and vice-versa?

SwiftForth is designed to link to any of a number of external editors, 
and Notepad is the default :-) If you want to look at others, the 
instructions are in Section 1.3.2 of the SwiftFort manual. General hints 
for working with program source may be found in Section 2.4.

Although it's occasionally convenient to type definitions directly in 
SwiftForth's command window, most of the time we work by editing a file 
and then INCLUDEing it. You can do this repeatedly, since the most 
recent versions of your words will be the ones you access when you test 
things. And that ensures that everything is always synced.

We do normally keep both SwiftForth and the editor open at the same 
time. Depending on the size of your screen, you may adjust their windows 
so they can sit side-by-side. Or, you can use two monitors! If both 
windows are visible, you can move from one to the other just by clicking.

Hope this helps!

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[toc] | [prev] | [next] | [standalone]

#25714

In article <b4714e4b-cce4-45f7-be94-4485bd68f206@googlegroups.com>,
 General Van Ryberg <vvdleun@hotmail.com> wrote:

> Hello,
> 
> I am new here, and quite new to Forth in general. Like some others here, I'm 
> also from The Netherlands (Utrecht). While I work as a Python (and Java, my 
> favorite) developer, for my small personal pet projects I was looking for 
> something "different". Forth got me hooked. Love the "low level" feeling. 
> After careful evaluating of both MPE's Forth and Forth Inc's SwiftForth, I 
> decided to buy the latter and their two books (thanks to co-author mrs. 
> Rather, they were very helpful).
> 
> Now I'm working on my first small, but "real" program, I have some difficulty 
> with the integration of Forth and an external editor (currently using 
> Notepad++). 
> 
> I can type definitions in Forth, test them and when I'm happy with them, copy 
> code to clipboard + alt-tab to the editor + find the definitions + select 
> existing code in the editor to overwrite + paste. This has the drawback that 
> i must be quite careful. And if I changed more than 1 word at a time, I must 
> not forget to copy and manually replace them one at a time. This works, but 
> feels a bit clumsy.
> 
> I can also INCLUDE an existing file. Develop/test my words. And finally with 
> LOCATE, EDIT commands try to keep my editor files up to date from time to 
> time. And every now and again use EMPTY and ABORT and then INCLUDE the file 
> to see if I missed anything. And if I did, try to find out what with 
> SwiftForth's History function. This is the approach I try to follow now, but 
> still feel I might be missing something obvious.
> 
> I would have liked if SwiftForth had a built-in editor (a basic one would do 
> IMHO), so it would be a bit easier to have both open in the same program 
> (have the same parent GUI window). Or to least a function to optionally 
> automatically reload an include file if its contents changed (was saved in an 
> external editor).
> 
> I was wondering how others are "syncing" their interactively developed 
> definitions with files and vice-versa?
> 
> Best regards,
> Vincent

Hi Vincent,

I use SwiftForth with an external editor on the Mac. Some stuff I added 
to the SF code to make live somewhat easier while using this combo. 
Don't know if I'm "syncing".

One of the things I can do is including the current (saved) file in the 
editor:   LOAD-EDIT
Another thing I can do is including from a given line number in a file 
in the editor: C  This allows for continuing including after fixing the 
issue which caused a throw during an include.
I can also include the paste/scrap/clip board: LOAD-SCRAP
Obviously this is all geared towards my way of working.

The stuff developed interactively in the terminal window is copied from 
that window to a file in an editor.

Alas, all this is not as good as the MacForth editor, which does away 
with all the clumsiness, but it suffices.

I don't think the code is OSX specific and it could be adaptable to the 
other SF versions. I live in Utrecht if you want to have a go or 
look-see.

Regards,
Roelf

[toc] | [prev] | [next] | [standalone]

#25715

On Monday, September 16, 2013 12:15:48 PM UTC-7, General Van Ryberg wrote:
> Now I'm working on my first small, but "real" program...

What is your program? Just curious.

> I can type definitions in Forth, test them and when I'm happy with them, copy code to clipboard + alt-tab to the editor + find the definitions + select existing code in the editor to overwrite + paste. This has the drawback that i must be quite careful. And if I changed more than 1 word at a time, I must not forget to copy and manually replace them one at a time. This works, but feels a bit clumsy.

Most of the time, when I write colon words on the command line, they are test functions --- they exercise the functions in the program to make sure they work, or they try out an idea --- but they don't get copied directly into the program.

> I can also INCLUDE an existing file. Develop/test my words. And finally with LOCATE, EDIT commands try to keep my editor files up to date from time to time. And every now and again use EMPTY and ABORT and then INCLUDE the file to see if I missed anything. And if I did, try to find out what with SwiftForth's History function. This is the approach I try to follow now, but still feel I might be missing something obvious.

Download my novice package: http://www.forth.org/novice.html

There is a word called TRY in there. This will INCLUDE a file --- but if the file is already included, it will first delete all of that code from the dictionary. The advantage of this, is that your dictionary doesn't get increasingly full, eventually requiring you to delete everything (btw: EMPTY is not ANS-Forth --- that is an artifact from Forth-83). Also, more importantly, you don't get all of those redefinition warnings, which really clutter up the screen and can conceal warnings that you do care about.

Just be sure that you save your file after editing it. That has messed me up several times --- I edit a file, then I TRY it and the code still doesn't work, because I never hit CTRL-S after making my changes.

> I would have liked if SwiftForth had a built-in editor (a basic one would do IMHO), so it would be a bit easier to have both open in the same program (have the same parent GUI window). Or to least a function to optionally automatically reload an include file if its contents changed (was saved in an external editor).

I've never needed anything like MAKE when programming in Forth, because I don't generally edit more than one file at a time. Forth is more interactive than most languages, so I generally just work on the latest file, and I have the lower-level files already tested, so I don't mess with them any more.

Having a lot of files and big complicated MAKE is mostly done in C programming, and is for team efforts, because this technique lends itself to use with those archivers where the programmers have to check out a file to modify it, then check it back in, and only one programmer can modify a file at one time. I've never heard of this being done in Forth.

[toc] | [prev] | [next] | [standalone]

#25716

On 9/16/2013 11:35 PM, hughaguilar96@yahoo.com wrote:
>
> Having a lot of files and big complicated MAKE is mostly done in C programming, and is for team efforts, because this technique lends itself to use with those archivers where the programmers have to check out a file to modify it, then check it back in, and only one programmer can modify a file at one time. I've never heard of this being done in Forth.

That's not actually how version control is used in most companies that 
I've been with.  Most of them allow more than one programmer to check 
out a file, but when it is checked in the programmer is responsible for 
folding their changes into any changes have have been checked in while 
they were making their changes.  Not that it makes much difference to 
you point.

I have had trouble with the Forth edit, compile, run cycle.  I am 
working with Win32Forth and load telnet_ansi.f as part of my program. 
For some reason when I try to use MARKER and reload my file, it craps 
out loading telnet_ansi.f.  So I always have to restart Win32Forth.  Not 
a big deal, it takes all of 5 seconds.  But I also have to start the 
telnet program to display the data, another 3 seconds... lol

Most of my testing doesn't actually require reloading the code so it's 
not such a big deal, but it would have been nice to not have to do this 
each time.

Oh, I shouldn't have said "I am working"... I *was* working with this 
setup.  It is finished now and saves me a *lot* of time in testing the 
boards I build.  In fact it works so well that I was able to turn the 
testing over to the board fab house and they are very happy with how it 
works.  I want to say I got some excellent help and support from the 
Win32Forth Yahoo group including Jos Ven who gave a lot of help with 
some of the Windows interfacing for error handling.  Thanks to all the 
guys at Win32Forth.

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#26052

9/17/2013 06:39:52 UTC+2 rickman wrote:
 
> I have had trouble with the Forth edit, compile, run cycle.  I am  
> working with Win32Forth and load telnet_ansi.f as part of my program. 
> For some reason when I try to use MARKER and reload my file, it craps 
> out loading telnet_ansi.f.  So I always have to restart Win32Forth.  Not 
> a big deal, it takes all of 5 seconds.  But I also have to start the 
> telnet program to display the data, another 3 seconds... lol

Note: The Edit compile run cycle can be reduced to 2 times pressing <F12> in the win32forthIDE and something like the following code in the win32forthIDE:

[DEFINED] JukeboxIn4Th  [IF]  100 ms bye [then]  

Anew JukeboxIn4Th

beep \ your code

\s Jos

[toc] | [prev] | [next] | [standalone]

#25722

General Van Ryberg <vvdleun@hotmail.com> writes:
>I was wondering how others are "syncing" their interactively developed defi=
>nitions with files and vice-versa?

Others have described how they do it from within the Forth system.  My
usual way of working is different:

I have an editor window and a shell window.  In the shell window, I
have my command line for running the Forth system, loading the Forth
program(s) and possibly test definitions, running a test, and possibly leaving the Forth system, e.g.:

gforth program.fs test.fs -e "3 4 test bye"

After a run, I look at the output, edit the program and/or tests
and/or the command line and run it again.  The fact that the shell has
a command-line history is very helpful for this.

If I want to examine the state after the test interactively, I leave
the BYE away and then do the examining and maybe additional testing
interactively.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2013: http://www.euroforth.org/ef13/

[toc] | [prev] | [next] | [standalone]

#25725

In article <2013Sep17.125734@mips.complang.tuwien.ac.at>,
 anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:

> General Van Ryberg <vvdleun@hotmail.com> writes:
> >I was wondering how others are "syncing" their interactively developed defi=
> >nitions with files and vice-versa?
> 
> Others have described how they do it from within the Forth system.  My
> usual way of working is different:
> 
> I have an editor window and a shell window.  In the shell window, I
> have my command line for running the Forth system, loading the Forth
> program(s) and possibly test definitions, running a test, and possibly 
> leaving the Forth system, e.g.:
> 
> gforth program.fs test.fs -e "3 4 test bye"
> 
> After a run, I look at the output, edit the program and/or tests
> and/or the command line and run it again.  The fact that the shell has
> a command-line history is very helpful for this.
> 
> If I want to examine the state after the test interactively, I leave
> the BYE away and then do the examining and maybe additional testing
> interactively.
> 
> - anton

Actually nowadays I do something similar to you. Especially since I 
discovered that quitting and rebooting (6 key presses) these type of 
Forths is faster than an eyeblink. The OS takes care of most cleaning up.
I hardly ever use the conveniences added over the years. Once it made a 
difference, but not anymore. Still, they can be useful when quitting 
Forth during development is a no no. Granted, it's rare.

-r

[toc] | [prev] | [next] | [standalone]

#25728

Roelf Toxopeus <rt4all@notthis.hetnet.nl> writes:
>Especially since I 
>discovered that quitting and rebooting (6 key presses) these type of 
>Forths is faster than an eyeblink.

So many?  For me it's 4 key presses:

Ctrl-D Cursor-up Enter

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2013: http://www.euroforth.org/ef13/

[toc] | [prev] | [next] | [standalone]

#25731

In article <2013Sep17.190514@mips.complang.tuwien.ac.at>,
 anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:

> Roelf Toxopeus <rt4all@notthis.hetnet.nl> writes:
> >Especially since I 
> >discovered that quitting and rebooting (6 key presses) these type of 
> >Forths is faster than an eyeblink.
> 
> So many?  For me it's 4 key presses:
> 
> Ctrl-D Cursor-up Enter
> 
> - anton

Ctrl-D instead of BYE
Great that works here as well (as you expected of course).
Always forget to use those ctrl shortcuts.
Thank you Anton!

[toc] | [prev] | [next] | [standalone]

#25756

In article <rt4all-11899C.22175917092013@news.kpn.nl>,
Roelf Toxopeus  <rt4all@notthis.hetnet.nl> wrote:
>In article <2013Sep17.190514@mips.complang.tuwien.ac.at>,
> anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
>
>> Roelf Toxopeus <rt4all@notthis.hetnet.nl> writes:
>> >Especially since I
>> >discovered that quitting and rebooting (6 key presses) these type of
>> >Forths is faster than an eyeblink.
>>
>> So many?  For me it's 4 key presses:
>>
>> Ctrl-D Cursor-up Enter
>>
>> - anton
>
>Ctrl-D instead of BYE
>Great that works here as well (as you expected of course).
>Always forget to use those ctrl shortcuts.

I can't say that I it is much of an advantage as I type BYE in
an eye-blink. I hardly ever need it as my Forth crashes easily.

The best sequence from this point of view, in a bash shell
with fake emacs cursor control:
^d ^p <ENTER>
This saves straying from the blind type position to the
keypad.

>Thank you Anton!
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

#25737

On 17/09/2013 18:05, Anton Ertl wrote:
> Roelf Toxopeus <rt4all@notthis.hetnet.nl> writes:
>> Especially since I
>> discovered that quitting and rebooting (6 key presses) these type of
>> Forths is faster than an eyeblink.
>
> So many?  For me it's 4 key presses:
>
> Ctrl-D Cursor-up Enter
>

How laborious, using Eclipse a double mouse click suffices to run 
whichever Forth is being used, compiling source code file(s) and running 
associated test file(s).

-- 
Gerry

[toc] | [prev] | [next] | [standalone]

#25750

In article <l1anql$je0$1@dont-email.me>,
 Gerry Jackson <gerry@jackson9000.fsnet.co.uk> wrote:

> On 17/09/2013 18:05, Anton Ertl wrote:
> > Roelf Toxopeus <rt4all@notthis.hetnet.nl> writes:
> >> Especially since I
> >> discovered that quitting and rebooting (6 key presses) these type of
> >> Forths is faster than an eyeblink.
> >
> > So many?  For me it's 4 key presses:
> >
> > Ctrl-D Cursor-up Enter
> >
> 
> How laborious, using Eclipse a double mouse click suffices to run 
> whichever Forth is being used, compiling source code file(s) and running 
> associated test file(s).

Java not allowed on this machine ;-)

A bit more seriously: words like BYE cost nothing. Your fingers know 
what to do, after typing it a gazillion times. It's like a one button 
press. Similar how your fingers remember telephone numbers...
Being brought up with GUI Forth systems, I know all to well what to do 
with double click. But my fingers started to protest after 20+ years.

-r

[toc] | [prev] | [next] | [standalone]

#25754

Roelf Toxopeus <rt4all@notthis.hetnet.nl> writes:
>A bit more seriously: words like BYE cost nothing. Your fingers know 
>what to do, after typing it a gazillion times.

If the only thing you use is Forth, then yes.  But I tend to use other
interactive command-line tools, and I can leave every one of them with
Ctrl-D, whereas the command for leaving varies (e.g., "exit" works in
bash, whereas it's "quit" in bc).  And on high-quality Forth systems
like SwiftForth and Gforth Ctrl-D works, too.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2013: http://www.euroforth.org/ef13/

[toc] | [prev] | [next] | [standalone]

#25771

On 18/09/2013 08:37, Roelf Toxopeus wrote:
> In article <l1anql$je0$1@dont-email.me>,
>   Gerry Jackson <gerry@jackson9000.fsnet.co.uk> wrote:
>
>> On 17/09/2013 18:05, Anton Ertl wrote:
>>> Roelf Toxopeus <rt4all@notthis.hetnet.nl> writes:
>>>> Especially since I
>>>> discovered that quitting and rebooting (6 key presses) these type of
>>>> Forths is faster than an eyeblink.
>>>
>>> So many?  For me it's 4 key presses:
>>>
>>> Ctrl-D Cursor-up Enter
>>>
>>
>> How laborious, using Eclipse a double mouse click suffices to run
>> whichever Forth is being used, compiling source code file(s) and running
>> associated test file(s).
>
> Java not allowed on this machine ;-)

The Java runs behind the scenes, I'm not programming in Java

>
> A bit more seriously: words like BYE cost nothing. Your fingers know
> what to do, after typing it a gazillion times. It's like a one button
> press. Similar how your fingers remember telephone numbers...
> Being brought up with GUI Forth systems, I know all to well what to do
> with double click. But my fingers started to protest after 20+ years.
>

I know what you mean but I'm not sure what BYE has to do with it, at the 
end of a test run either I leave the Forth window running or put a BYE 
at the end of the test file (or maybe something like KEY BYE so that I 
can see what happened before the window disappears as silent crashes are 
not unknown).


-- 
Gerry

[toc] | [prev] | [next] | [standalone]

#25780

In article <l1cl8e$5a1$1@dont-email.me>,
 Gerry Jackson <gerry@jackson9000.fsnet.co.uk> wrote:

> On 18/09/2013 08:37, Roelf Toxopeus wrote:
> > In article <l1anql$je0$1@dont-email.me>,
> >   Gerry Jackson <gerry@jackson9000.fsnet.co.uk> wrote:
> >
> >> On 17/09/2013 18:05, Anton Ertl wrote:
> >>> Roelf Toxopeus <rt4all@notthis.hetnet.nl> writes:
> >>>> Especially since I
> >>>> discovered that quitting and rebooting (6 key presses) these type of
> >>>> Forths is faster than an eyeblink.
> >>>
> >>> So many?  For me it's 4 key presses:
> >>>
> >>> Ctrl-D Cursor-up Enter
> >>>
> >>
> >> How laborious, using Eclipse a double mouse click suffices to run
> >> whichever Forth is being used, compiling source code file(s) and running
> >> associated test file(s).
> >
> > Java not allowed on this machine ;-)
> 
> The Java runs behind the scenes, I'm not programming in Java

Ah, sorrry. I thought you understood.
Mac users are advised by Apple to disable Java.
I'm not against Java or any other way to coax a computer to do what you 
want it to do. Apologies.

> 
> >
> > A bit more seriously: words like BYE cost nothing. Your fingers know
> > what to do, after typing it a gazillion times. It's like a one button
> > press. Similar how your fingers remember telephone numbers...
> > Being brought up with GUI Forth systems, I know all to well what to do
> > with double click. But my fingers started to protest after 20+ years.
> >
> 
> I know what you mean but I'm not sure what BYE has to do with it, at the 
> end of a test run either I leave the Forth window running or put a BYE 
> at the end of the test file (or maybe something like KEY BYE so that I 
> can see what happened before the window disappears as silent crashes are 
> not unknown).

NoTE: it's not BYE alone, also rebooting is included. It's a sequence:
BYE<return><uparrow><return>
quit Forth and reboot, perhaps sometimes called COLD.
I used to have a word HELLO which did this in MacForth. For the non Mac 
users: HELLO is a pun on BYE of course, but also on the Mac ad "Hello 
Again" which introduced the first iMac and en passant Steve Jobs return 
at Apple. Forth is words and spaces and I like play with words. My 
mistake.
Right, when am I using this? During development after many re-includes,
and I don't trust the state my system is in. Start fresh.
On the older 68000 and PPC machines this takes a few seconds. So EMPTY 
is preferred where I can. But I discovered that on the Mac Intel 
machines the Darwin/Unix Forth systems where so blindingly fast in 
booting that I used the above mentioned key sequence for re-including 
files. With the advantage of including in fresh, uncorrupted systems. I 
weaned myself of EMPTY, like I weaned myself from FORGET. Both words 
very dear to me, but not needed anymore, they served their time. The 
more I can prune from a system, the better.
Unlike Anton Ertle, I do not put a BYE in the commandline sequence. I 
like to start Forth and work from there. Unlike you I don't put BYE at 
the end of a file. Exception during creation of new Forth turnkeys.
For those cases where it's very inconvenient to quit Forth during 
development I have a bag of extra's which make live a little easier.

That's all, I hope I clarified.

-r

[toc] | [prev] | [next] | [standalone]

#25808

On 18/09/2013 22:36, Roelf Toxopeus wrote:
> In article <l1cl8e$5a1$1@dont-email.me>,
>   Gerry Jackson <gerry@jackson9000.fsnet.co.uk> wrote:
>
> Ah, sorrry. I thought you understood.
> Mac users are advised by Apple to disable Java.

No I wasn't aware of that. It may seem odd but I do my best to ignore Apple.

> I'm not against Java or any other way to coax a computer to do what you
> want it to do. Apologies.
>
>>
>>>
>>> A bit more seriously: words like BYE cost nothing. Your fingers know
>>> what to do, after typing it a gazillion times. It's like a one button
>>> press. Similar how your fingers remember telephone numbers...
>>> Being brought up with GUI Forth systems, I know all to well what to do
>>> with double click. But my fingers started to protest after 20+ years.
>>>
>>
>> I know what you mean but I'm not sure what BYE has to do with it, at the
>> end of a test run either I leave the Forth window running or put a BYE
>> at the end of the test file (or maybe something like KEY BYE so that I
>> can see what happened before the window disappears as silent crashes are
>> not unknown).
>
> NoTE: it's not BYE alone, also rebooting is included. It's a sequence:
> BYE<return><uparrow><return>
> quit Forth and reboot, perhaps sometimes called COLD.
> I used to have a word HELLO which did this in MacForth. For the non Mac
> users: HELLO is a pun on BYE of course, but also on the Mac ad "Hello
> Again" which introduced the first iMac and en passant Steve Jobs return
> at Apple. Forth is words and spaces and I like play with words. My
> mistake.
> Right, when am I using this? During development after many re-includes,
> and I don't trust the state my system is in. Start fresh.
> On the older 68000 and PPC machines this takes a few seconds. So EMPTY
> is preferred where I can. But I discovered that on the Mac Intel
> machines the Darwin/Unix Forth systems where so blindingly fast in
> booting that I used the above mentioned key sequence for re-including
> files. With the advantage of including in fresh, uncorrupted systems. I
> weaned myself of EMPTY, like I weaned myself from FORGET. Both words
> very dear to me, but not needed anymore, they served their time. The
> more I can prune from a system, the better.
> Unlike Anton Ertle, I do not put a BYE in the commandline sequence. I
> like to start Forth and work from there. Unlike you I don't put BYE at
> the end of a file. Exception during creation of new Forth turnkeys.
> For those cases where it's very inconvenient to quit Forth during
> development I have a bag of extra's which make live a little easier.
>
> That's all, I hope I clarified.
>

Yes, thank you. I think we all evolve a way of working to suit ourselves 
and it's interesting to know what others do because they often have 
better ideas. I don't always put BYE at the end of a file, in fact it's 
probably rare during development - it's a simple matter to comment it 
out anyway.

-- 
Gerry

[toc] | [prev] | [next] | [standalone]

#25755

Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
>On 17/09/2013 18:05, Anton Ertl wrote:
>> Ctrl-D Cursor-up Enter
>>
>
>How laborious, using Eclipse a double mouse click suffices to run 
>whichever Forth is being used, compiling source code file(s) and running 
>associated test file(s).

I tried Eclipse when wanting to demonstrate an IDE when teaching a
Java course last semester.  After spending a quarter-hour without
getting anywhere, I gave up and demonstrated an IDE with Java Beans.

Anyway, the Emacs Forth mode by Goran Rydquist (on which gforth.el is
based) has such a feature, and it works (or worked) without taking the
hands off the keyboard, but I found having a shell in a separate
window preferable (even though it means that I have to grab the mouse
to switch windows).

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2013: http://www.euroforth.org/ef13/

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.forth

csiph-web