Thanks for the replies.
In the weekend I wrote that code running with dynamic objects.
If I do

     LISTWORKS
     DELETEWORKS
     LISTWORKS \ display again the list of objs

Why?

Thanks very much,
Alberto Santini

--------------------------------------------------------------
\ Object List example

EMPTY

CLASS WORK
PUBLIC
     16 BUFFER: NAME
     32 BUFFER: DESC
      7 BUFFER: COST1
      7 BUFFER: COST2
      7 BUFFER: EXPENSE
END-CLASS

0 VALUE WPTR \ pointer to the work
VARIABLE WORKLIST \ head of the list of works

: (NEWWORK) ( -- ) \ create an object work
     WORK NEW TO WPTR
     ;

: (>WORKNAME) ( addr -- )
     ZCOUNT WPTR USING WORK NAME ZPLACE
     ;

: (>WORK) ( -- ) \ add a work to the list
     WPTR WORKLIST >LINK ,
     ;

: +WORKNAME ( addr -- )
     (NEWWORK) (>WORKNAME) (>WORK)
     ;

: .WORKNAME ( -- ) \ display last work name
     WPTR USING WORK NAME ZCOUNT TYPE
     ;

: LISTWORKS ( -- ) \ list all the name of the works
     CR WORKLIST BEGIN
          @REL ?DUP WHILE \ while there are more links...
          DUP CELL+ @ \ fetch the object
          USING WORK NAME \ cast to work
          ZCOUNT TYPE CR \ display cell
     REPEAT
     ;

: DELETEWORKS ( -- ) \ delete works
     WORKLIST BEGIN
          @REL ?DUP WHILE \ while there are more links...
          DUP CELL+ @ \ fetch the object
          USING WORK \ cast to work
          TO WPTR \ in the pointer
        WPTR DESTROY \ delete work
        0 TO WPTR \ reset the pointer
     REPEAT
     ;

: TEST ( -- )
     Z" FOO1" +WORKNAME
     .WORKNAME
     Z" FOO2" +WORKNAME
     .WORKNAME
     Z" FOO3" +WORKNAME
     .WORKNAME
     LISTWORKS
     ;

SF Talk <sftalk_at_forth.com> on 05/05/2000 11:59:41 PM

Please respond to SF Talk <sftalk_at_forth.com>

To: SF Talk <sftalk_at_forth.com>
cc: (bcc: Alberto Santini/BPM)
Subject: Re: List of objects...

Date: Fri, 05 May 2000 14:57:23 -0700
From: "Rick VanNorman" <rvn_at_forth.com>
Subject: Re: [sftalk] List of objects...

>From: "Gene LeFave" <gene_at_tekdata.com>
>
>That works! I don't know why, but it does.

Well, hold on thar, podner! If you don't understand
it, I need to explain it better. Which part is unclear?

Rick

.

>From sftalk_at_forth.com Mon May 8 18:58:22 2000
To: sftalk_at_forth.com
Message-Id: <m0000854_at_gerd.forthinc.com>
Date: Mon, 8 May 2000 18:58:22 +0800
From: "WCS Connect" <wcs_connect_at_tpg.com.au>
Subject: Re: [sftalk] FAQ-O-MATIC questions & GL Demo

John,

If you jump to the following link

http://www.neverslow.com/fom/swiftforth/fom-serve/cache/19.html

It will take you straight to the graphics code.

Regards

Rob

----- Original Message -----
From: SF Talk <sftalk_at_forth.com>
To: SF Talk <sftalk_at_forth.com>
Sent: Sunday, May 07, 2000 9:48 PM
Subject: Re: [sftalk] FAQ-O-MATIC questions & GL Demo

> Date: Sun, 07 May 2000 09:53:44 -0400
> From: John Whitt <j.whitt_at_home.com>
> Subject: Re: FAQ-O-MATIC questions & GL Demo
>
> How does one obtain the demo that are referred to?
>
> SF Talk wrote:
>
> > Date: Sun, 7 May 2000 18:38:36 +0800
> > From: "WCS Connect" <wcs_connect_at_tpg.com.au>
> > Subject: Re: FAQ-O-MATIC questions & GL Demo
> >
> > Thanks for that Elizabeth, the fpmath.f fixed the problem.
> >
> > Rob
> > ----- Original Message -----
> > From: SF Talk <sftalk_at_forth.com>
> > To: SF Talk <sftalk_at_forth.com>
> > Sent: Saturday, May 06, 2000 10:38 AM
> > Subject: Re: FAQ-O-MATIC questions & GL Demo
> >
> > > Date: Fri, 05 May 2000 19:25:22 -0700
> > > From: Elizabeth D Rather <erather_at_forth.com>
> > > Subject: Re: FAQ-O-MATIC questions & GL Demo
> > >
> > > At 07:07 PM 5/5/2000 -0700, you wrote:
> > > > >There was an initial problem running the original version of the 3d
> > demo in
> > > > >relation to the floating point, I can not remember the fix but the
> > error is
> > > > >that when compiling the numbers ending in 'e' are not being
recognised
> > and
> > > > >stopping compiling of the program. If the fix is still available it
> > would be
> > > > >nice to have once again - I had a machine crash a while ago and
lost
> > the
> > > > >original fix.
> > > >...
> > >
> > >
> > >
> > > >Floating point; I haven't got a clue about it. Anyone know or
> > > >remember this problem?
> > > >
> > > >Rick
> > >
> > > I don't remember what the problem was, but I do remember the remedy is
> > > replace your \Lib\Options\Fpmath.f file with the one from the ftp site
> > > (ftp.forth.com\pub\Swiftforth\Lib\Options\Fpmath.f).
> > >
> > > Cheers,
> > > Elizabeth
> > >
> > > ===============================================
> > > Elizabeth D. Rather (US & Canada) 800-55-FORTH
> > > FORTH Inc. +1 310-372-8493
> > > 111 N. Sepulveda Blvd. Fax: +1 310-318-7130
> > > Manhattan Beach, CA 90266
> > > http://www.forth.com
> > >
> > > "Forth-based products and Services for real-time
> > > applications since 1973."
> > > ===============================================
> > >
> > >
> > >
> >
>
>
>

.

>From mikek_at_metretek.com Mon May 8 09:26:10 2000
To: sftalk_at_forth.com
Message-Id: <m0000855_at_gerd.forthinc.com>
Date: Mon, 8 May 2000 09:26:10 -0500
From: "Michael Kemper" <mikek_at_metretek.com>
Subject: Binary question

Rick,
I was coding a crc algorithm and ran across this peculiarity. It may be
normal operation, but seems inconsistant to me:

If I do the following
$CEE1289A $100 / h.
>$FFCEE129

but if I perform the following:
$CEE1289A 2/ 2/ 2/ 2/ 2/ 2/ 2/ 2/ h.
>$FFCEE128
which is what I'd expect from both versions. Both versions bring the sign
bit into the result, but the first rounds the result, which I wouldn't
expect from the standard "/" word. Is this normal?

Mike

.

>From sftalk_at_forth.com Mon May 8 09:14:00 2000
To: sftalk_at_forth.com
Message-Id: <m0000856_at_gerd.forthinc.com>
Date: Mon, 8 May 2000 09:14:00 -0500
From: "Gene LeFave" <gene_at_tekdata.com>
Subject: Re: [sftalk] List of objects...

Rick,

I don't see how the defer: given the address of an object get to the
correct run time code.

You create a dummy WORK object W in .worker. Yet when you pass it an
object of the BOSS class it gets the BOSS version of .name. It seems
to me that W .name should always go to WORK .name.

Gene

Date sent: Fri, 5 May 2000 14:59:41 -0700
From: SF Talk <sftalk_at_forth.com>
To: SF Talk <sftalk_at_forth.com>
Send reply to: SF Talk <sftalk_at_forth.com>
Subject: Re: List of objects...

> Date: Fri, 05 May 2000 14:57:23 -0700
> From: "Rick VanNorman" <rvn_at_forth.com>
> Subject: Re: List of objects...
>
> >From: "Gene LeFave" <gene_at_tekdata.com>
> >
> >That works! I don't know why, but it does.
>
> Well, hold on thar, podner! If you don't understand
> it, I need to explain it better. Which part is unclear?
>
> Rick
>
>
>

.

>From sftalk_at_forth.com Mon May 8 23:08:56 2000
To: sftalk_at_forth.com
Message-Id: <m0000857_at_gerd.forthinc.com>
Date: Mon, 8 May 2000 23:08:56 +0800
From: "Howard Wayne" <howay_at_netease.com>
Subject: Re: [sftalk] Forth VS Java ?

Yes, I agree with you. But, Well, is there any compiler compiling C or C++
to Forth? And how to design it?

Howard Wayne

----- Original Message -----
From: "SF Talk" <sftalk_at_forth.com>
To: "SF Talk" <sftalk_at_forth.com>
Sent: Monday, May 08, 2000 9:07 AM
Subject: Re: [sftalk] Forth VS Java ?

> Date: Sun, 7 May 2000 17:44:18 -0700
> From: "Ed Borasky" <znmeb_at_teleport.com>
> Subject: RE: Forth VS Java ?
>
> Well, I'm glad the moderators are engaging in this conversation, not me.
> I've seen lots of heat and very little light on similar subjects in
> "comp.lang.forth" :-)
>
> I have not had time to really run SwiftForth through any major speed hoops
> yet, but rest assured that I will soon, and I expect that, at least for
the
> parabolic PDEs and queueing network models that I need to solve, it will
be
> vastly faster than Java or Visual Basic and a boatload easier to use than
> C++. And if by some chance I should need to drive the FPUs harder than
> SwiftForth can, I can go to assembler quite easily. I know I'm paying a
> portability price; until there is a reasonable (SwiftForth compatible :-)
> Forth for, say, generic UNIX/X-windows platforms, I am willing to
sacrifice
> the portability of C++ for the ease of use of Forth.
>
>
>

.

>From sftalk_at_forth.com Mon May 8 23:17:57 2000
To: sftalk_at_forth.com
Message-Id: <m0000858_at_gerd.forthinc.com>
Date: Mon, 8 May 2000 23:17:57 +0800
From: "Howard Wayne" <howay_at_netease.com>
Subject: Re: [sftalk] Forth VS Java ?

Thank you for your help.
And you means that SwiftForth runs faster than Java ? Forth is very good,
even excellent computer language, but it is difficult to understand. There
are many programmers know C, C++ and Java, but they know little about Forth.
If we can compile C++ to Forth, more and more programmers will know what's
Forth and how to work with it.

Howard Wayne

----- Original Message -----
From: "SF Talk" <sftalk_at_forth.com>
To: "SF Talk" <sftalk_at_forth.com>
Sent: Monday, May 08, 2000 4:28 AM
Subject: Re: [sftalk] Forth VS Java ?

> Date: Sun, 7 May 2000 13:24:33 -0700
> From: "Elizabeth D. Rather" <erather_at_forth.com>
> Subject: RE: Forth VS Java ?
>
> Some general comments on this question:
>
> As has been observed, much depends upon implementation. The classic Java
> implementation strategy is a Virtual Machine running on your computer,
which
> interprets platform-independent Java byte codes produced by the Java
> compiler. This is inevitably slower than executing machine code; how much
> slower depends on the mechanism for processing the byte codes. We have
> implemented similar VM/bytecode schemes, and can make them reasonably
fast,
> but never even approaching the speed of executing machine code.
>
> Java further complicates things by requiring run-time initialization of
> static data and extensive run-time type checking and other validations.
> This is reasonable for the intended use, which is applets distributed over
> the internet for execution on a variety of hosts, but is fairly costly in
> performance.
>
> An alternative Java strategy is called "just-in-time" (JIT) compilation,
in
> which the applet is actually translated to executable machine code. When
> Java's being used as a programming language for local use (as opposed to
> distributed applets) this mechanism is often used, and can produce very
good
> performance, comparable to a good C++ compiler.
>
> The "classic" Forth implementation is often likened to the Java
VM/bytecode
> strategy, but that's incorrect. "Classical" Forths compiled absolute
> addresses, not platform-independent bytecodes. The advantage is much
faster
> execution, at the cost of platform independence. In addition, Forth
doesn't
> typically do much if any run-time checking. So this kind of Forth will
> typically be faster than Java (except JIT), but slower than C.
>
> In the last few years, however, most commercial Forths (including
SwiftForth
> and SwiftX from FORTH, Inc.) actually compile directly executable code.
> This gives performance comparable with all compiled languages (C, C++,
etc.)
> and much faster than "classical" Forth.
>
> Yet another dimension is introduced by Object Oriented Programming. This
is
> a very useful technique, which is supported in varying degrees by C++,
Java,
> and some modern Forths, including SwiftForth. All of these languages can
be
> used to develop "flat" sequential programs; however, as you use more
deeply
> nested object class structures there is some additional overhead involved
in
> accessing objects. We have managed to minimize this in SwiftForth,
> especially when you avoid "late binding" strategies, which are the most
> costly (but the most flexible).
>
> Hope this helps clarify things.
>
> Cheers,
> Elizabeth
>
>
>

.
Received on Fri May 05 2000 - 14:57:23 PDT