• 1. Locals again
    Anton Ertl < XXXX@XXXXX.COM > wrote: > XXXX@XXXXX.COM writes: >>My opposition to the use of locals isn't based on some sort of Central >>Party Dogma, but on the observation that Forth words using locals are >>often badly factored. I don't know why this might be, but my guess is >>that locals allow programmers to avoid factoring decisions, so >>programmers who don't like to factor reach for locals. > Other explanations are: > B) Programmers use locals in words that are hard to factor. > C) Words where locals are used are harder to factor than words that > use only the data stack. > D) Longer words are less painful to write and read when locals are > used. I think these are minor variations on the same explanation, apart from B), which is perhaps some sort of appeal to intrinsic complexity. (I'm ignoring calls to externally defined routines here, BTW. It's a tricky one, and may well lead to difficult design decisions.) >>I guess the same is also true, to some extent, about PICK and ROLL. > For all four explanations. The same holds for the use of the return > stack. I don't think that's true. There is nothing like the same unbounded opportunity to complicate things with a simple stack where you can only access the top item(s). > Is that also harmful for Forth? Andrew.
  • 2. [win32for] Bug in number?
    \ bug in win32forth version 0671 : new-NUMBER? ( addr len -- d1 f1 ) DUP 0= if 2DROP 0 0 FALSE _EXIT THEN FALSE TO DOUBLE? \ initially not a double # -1 TO DP-LOCATION OVER C@ [CHAR] - = OVER 0> AND DUP>R IF 1 /STRING THEN DUP 0= IF R>DROP 2DROP 0 0 FALSE _EXIT \ always return zero on failure THEN 0 0 2SWAP >NUMBER OVER C@ [CHAR] . = \ next char is a '.' OVER 0> AND \ more chars to look at IF DUP 1- TO DP-LOCATION 1 /STRING >NUMBER DUP 0= IF TRUE TO DOUBLE? \ mark as a double number THEN THEN NIP 0= R> IF >R DNEGATE R> THEN ; : test ( -- ) ." new-number?: " -1 0 new-number? 3drop ." ok" ." number?: " -1 0 number? 3drop ." ok" ; --


Postby MarkWills » Wed, 16 Jun 2010 07:08:06 GMT

What's the stack signature for EDIT (to invoke the built in block

I'm basically working to Forth-83 standards, but EDIT is of course not
part of the standard.

I guess it could be either:

EDIT ( address -- )
EDIT ( block -- )

Currently, my version is the former, and partners with BLOCK:


I'd kind of prefer just 50 EDIT

I guess I could just make a new word?

: ED ( block -- ) BLOCK EDIT ;



Postby Elizabeth D Rather » Wed, 16 Jun 2010 13:32:48 GMT

FWIW, in the days when many systems used blocks, <blk#> EDIT was the 
most common (preferred) usage, at least in my experience.


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

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


Postby doc » Wed, 16 Jun 2010 21:53:16 GMT



I'll cheerfully agree that stand-alone 4ths that utilize blocks
and don't have their own file system - or the use of the underlying
OS's toolbox (because 4th IS the OS) - are old(er) and rarely used
days.  However, that doesn't mean lessons learned 30+ years ago have
forgotten or abandoned.

IMHO, <address> EDIT - where <address> implies the buffer address
returned by BLOCK - is workable on a single-user single-task system.
But this practice is not suitable in a multi-user or multi-tasking
implementation as the contents of block buffers cannot be assumed
to remain static.

Once, I went through a prototype effort to lock a buffer in a
multi-tasking environment so that its contents could be directly
edited, also permitting real-time data to be written directly to
a block buffer by an interrupt service routine.  Abandoned it for
of reasons which I can recount if asked, in favor of moving the
contents of the block to an editing buffer.  This had two pleasant
side affects:
a) Easy to abort and even restart the editor without affecting the
original contents of the block.
b) if the edit buffer is longer than a block, I found it easier
to implement cut and paste operations into the editor.

I know the value of unsolicited opinions - generally zero - but
FWIW I thought I'd respond.



Postby Coos Haak » Thu, 17 Jun 2010 00:33:51 GMT

But buffers tend to be reused. There is no guarantee that <address> at 
the beginning of the session is the same an hour later. In particular 
after loading a lot of blocks. <blk> is hardly likely to change.


CHForth, 16 bit DOS applications


Postby Elizabeth D Rather » Thu, 17 Jun 2010 05:29:28 GMT


Only up to a point.  As Coos points out, many words use BLOCK, and BLOCK 
will cheerfully reuse the oldest buffer (writing it if the UPDATE bit is 
set), so next time you call BLOCK for the block you're editing it might 
be in a different buffer.

The most convenient approach, IMO, is to have words like EDIT and LIST 
store the block# you're editing in BLK, and have all the actual editing 
commands (L, I, D, etc.) do a BLK @ BLOCK to get the address to work on. 
  That's perfectly safe, and doesn't tie up memory or a buffer. 
Remember, calling BLOCK is very cheap if the block is already in memory.

I think it's helpful to everyone to hear about various implementtion 


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

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


Postby MarkWills » Thu, 17 Jun 2010 05:53:54 GMT

All, thanks for the responses. Some useful info.

FWIW, I implemented BLK too, which makes it quite simple.




Postby Jonah Thomas » Thu, 17 Jun 2010 08:45:34 GMT


t does look fascinating, although I found nothing new in the first 10 


Postby Albert van der Horst » Thu, 17 Jun 2010 09:19:34 GMT

In article < XXXX@XXXXX.COM >,

I've been reading Susan Blackmore's website yesterday.
This is the way consciousness seems to work. You think you have things
in your head, but you just pop them in when you care to look.
There is a lot more fascinating stuff there.

Other strategies:

Copy the block to the screen $000B,0000
and then edit on the screen. Only copy back if you're satisfied.

For a blocks-in-file system I make sure blocks can be edited
with My Favorite Editor ( Edwin's Editor : ee ).
There is a macro invoked by <ESC>FORTH that trims all lines
to 63 char's plus ^J.

I actually use blocks, have done so today. Not only loading,
but I have added the MEMORY wordset to my block library.

Groetjes Albert

Similar Threads:

1.treectrl <Edit-*> binding problems - inplace editing

> You'll want to call one of these procedures:
>     TreeCtrl::EntryOpen
>     TreeCtrl::EntryExpanderOpen
>     TreeCtrl::TextOpen
>     TreeCtrl::TextExpanderOpen
> The "entry" versions are single line, "text" versions are multi-line.
> The "expander" versions cause the edit widget to change size as
> you type.
> In your example add this line to your buildTree procedure:
>     bind $tree <ButtonPress-1> "ButtonPress1 %W %x %y"
> Add this new procedure to handle the mouse button press:
> ============================
> proc ButtonPress1 {T x y} {
>     set id [$T identify $x $y]
>     lassign $id where item arg1 arg2 arg3 arg4
>     if {$where eq "item" && [llength $id] == 6} {
>         TreeCtrl::EntryExpanderOpen $T $item $arg2 $arg4
>         return -code break
>     }
> }

Thank you Tim so much.
I will give it a try tomorrow.

If everything works out, I'll set up a wiki page for that.
The docs should contain some of that information IMHO.

But anyway, thank again.

2.treectrl <Edit-*> binding problems - inplace editing

Could anybody help me with that?
I'm missing something, but I have no idea what.

Actually I'm not sure how much is provided by treectrl, and how much
of that I have to do on my own.
I looked over the demos (explorer and imovie), but that does not
These demos go into the ::TreeCtrl namespace which is not documented
and for that reason I do not like that so much.

- make the events at least occur (puts something)!?
- do I have to build the "cell-entry" myself to get inplace editing?

Here is a working example:

package require treectrl 2.1

proc buildGUI {} {

    set top .tree_test
    catch {destroy $top}
    toplevel $top

    set treeFrame [frame $top.treeFrame]
    set tree [buildTree $treeFrame]

    grid $treeFrame -row 0 -column 0 -sticky news
    grid rowconfigure $treeFrame 0 -weight 1
    grid columnconfigure $treeFrame 0 -weight 1

    grid rowconfigure $top 0 -weight 1
    grid columnconfigure $top 0 -weight 1

proc buildTree {t} {

    set tree [treectrl $t.tree \
            -xscrollcommand "$t.sx set" \
            -yscrollcommand "$t.sy set" \
            -highlightthickness 0 \
            -selectmode extended]

    grid $tree -row 0 -column 0 -sticky news

    scrollbar $t.sx -orient h -command "$tree xview"
    scrollbar $t.sy -orient v -command "$tree yview"
    grid $t.sx -row 1 -column 0 -sticky new -padx 0 -pady 0
    grid $t.sy -row 0 -column 1 -sticky nes -padx 0 -pady 0

    $tree element create textElem text \
            -fill [list #FFFFFF { selected focus } ]
    $tree element create selectionRect rect \
            -fill [list #00008B { selected focus } #BFBFBF { selected !
focus } ] \
            -showfocus no

    $tree style create textStyle
    $tree style elements textStyle {selectionRect textElem}
    $tree style layout textStyle textElem \
            -padx { 0 4 } -expand ns -iexpand ns -sticky s
    $tree style layout textStyle selectionRect \
            -union {textElem} -padx { 0 4 } -expand ns -iexpand ns -
sticky s

    for {set column 0} {$column < 4} {incr column} {

        $tree column create
        $tree column configure $column \
                -text "Column $column" \
                -expand yes -button no

    $tree notify install <Edit-begin>
    $tree notify install <Edit-end>
    $tree notify install <Edit-accept>

    $tree notify bind $tree <Edit-begin> "EditCallback %I %C %E"
    $tree notify bind $tree <Edit-end> "EditCallback %I %C %E"
    $tree notify bind $tree <Edit-accept> "EditCallback %I %C %E"

    FillTable $tree
    return $tree

proc FillTable {tree} {

    for {set row 0} {$row < 4} {incr row} {
        set newItem [$tree item create]
        for {set column 0} {$column < 4} {incr column} {
            $tree item style set $newItem $column textStyle
            $tree item element configure $newItem $column textElem \
                    -text "test"
        $tree item lastchild root $newItem

proc EditCallback {args} {
    puts "$args"


Thanks for any help!


3.ISPF Edit/View HILITE to HTML macros

4.Edit in Place (CW5.0 - Clarion Templates)

I use Clarion 5.0 for Windows and the Clarion Templates (not the ABC).
I want in Browse to use the "Edit in Place" or something like that.
Any ideas will be welcome.

5.C55: browse database: edit + backup = File vanished


I used Browse database to delete a record and to the question do you 
want to make a backup, I replied "yes".

Result the TPS file plain vanished.

So what you got a backup, right?

Not so!

My file was called Add:Rubr.TPS

Bad surprise number one Win2K can't find that file, although I can 
access it through clarion (till it got crapped out by Browse Database).

I was able to recover an older file using the convert utility.

1) Why can't NT see that file?
2) Where did the backup file end up?  What name is it supposed to have 
so I can attempt to recover it using the convert.clw trick.


6. Edit in place help needed !

7. Edit in place listbox based on queue

8. Launch browseless edit from splash screen

Return to forth


Who is online

Users browsing this forum: No registered users and 10 guest