SwiftForth and Windows Vista/7 & more ...
Zuvuya
on the net and found out that some people have had trouble with it on
Vista and Windows 7. $400 is a steep investment for me - even if it
works perfectly - and so I've subscribed to this newsgroup to find out
the truth about it. One person said that he didn't find SwiftForth to be
so swift.
So before I sink my money into this I'd like to ask a few questions:
1. Is it Vista/ Windows 7 compatible?
2. Is it as fast as they claim?
3. Does it have libs for audio - MIDI, and video development?
4. Can someone rate it's performance compared to Ruby? I know Ruby is
interpreted, but it looks really cool.
I guess that's it. I only have experience coding in Basic and JForth,
but I need a compiled language in which I can develop high performance
multimedia applications. I love Forth and want to use it for developing
these applications if possible. I may have to use C++ or Java to do what
I want, but I'd rather stick to something I know.
Can anyone recommend a free Forth that is object-oriented and compiled?
I have looked at bigForth + minos (it runs well on Linux but crashes on
windows, as they warn of on the website), and gforth. I have JForth
running on a WinUAE virtual machine, but that helps me none toward
developing for Windows. I'd use bigForth if they did 3 things:
1. Offer a more modern-looking GUI developing environment. Theseus may
work really nice, but it designs GUIs that look like my old Amiga 1000
(oh nostalgia).
2. A fully translated manual.
3. Get rid of the bugs in the Windows version.
Didn't mean to be so long-winded but I'd appreciate any thoughts on
these things.
Thanks,
Zuvuya
Bernd Paysan
> Can anyone recommend a free Forth that is object-oriented and compiled?
> I have looked at bigForth + minos (it runs well on Linux but crashes on
> windows, as they warn of on the website), and gforth. I have JForth
> running on a WinUAE virtual machine, but that helps me none toward
> developing for Windows. I'd use bigForth if they did 3 things:
>
> 1. Offer a more modern-looking GUI developing environment. Theseus may
> work really nice, but it designs GUIs that look like my old Amiga 1000
> (oh nostalgia).
MINOS has styles. For Windows, there is this 95 style, no other style.
Switching over to Cairo as backend (planned) might change this situation, or
people who write other styles.
> 2. A fully translated manual.
Stephen Pelc works on that.
> 3. Get rid of the bugs in the Windows version.
Maybe the switch to Cairo will fix that, as well. Or you report the bugs,
as the main problem for fixing bugs in the Windows version is that nobody
bothers to report them. Come on, this is free software, and you are aware
that I'm not regularly using Windows, so if you want to help the project,
report the fucking bugs. If nobody bothers, they will stay. I'm not aware
of these bugs.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
Stephen Pelc
wrote:
>I am considering purchasing SwithForth but I've researched it somewhat
>on the net and found out that some people have had trouble with it on
>Vista and Windows 7. $400 is a steep investment for me - even if it
>works perfectly - and so I've subscribed to this newsgroup to find out
>the truth about it. One person said that he didn't find SwiftForth to be
>so swift.
There's a Forth benchmark suite with results for several CPU/OS
combinations at:
http://www.mpeforth.com/arena/benchmrk.fth
N.B. vendor warning - MPE produces VFX Forth.
I personally run VFX Forth for Windows on Vista Business.
>3. Does it have libs for audio - MIDI, and video development?
Hanno Schwalm's fJACK audio interface is part of the VFX Forth
distribution.
>1. Offer a more modern-looking GUI developing environment. Theseus may
>work really nice, but it designs GUIs that look like my old Amiga 1000
>(oh nostalgia).
VFX Forth for Windows has GUIgen and a resource script parser.
VFX Forth for Linux has Minos/Theseus with a first-cut manual.
There is also a framework for using GTK+ and Glade.
>2. A fully translated manual.
VFX Forth has a full English manual, currently 400+ pages for v4.4
on Windows. There are subsidiary manuals for other portions of the
package.
Stephen
--
Stephen Pelc, steph...@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads
Doug Hoffman
> Can anyone recommend a free Forth that is object-oriented and compiled?
By object-oriented I assume that you mean a standard Forth with object
extensions. There are several ANS compatible object extensions
available. The main substantive difference between them being do you
prefer duck typing (ala Smalltalk), or do you prefer to use
interfaces?
--
Doug Hoffman
http://idisk.mac.com/hoffman101-Public/?view=web
Elizabeth D Rather
> I am considering purchasing SwithForth but I've researched it somewhat
> on the net and found out that some people have had trouble with it on
> Vista and Windows 7. $400 is a steep investment for me - even if it
> works perfectly - and so I've subscribed to this newsgroup to find out
> the truth about it. One person said that he didn't find SwiftForth to be
> so swift.
>
> So before I sink my money into this I'd like to ask a few questions:
>
> 1. Is it Vista/ Windows 7 compatible?
Yes. Reported difficulties with Vista involved older versions that
hadn't followed the updates.
> 2. Is it as fast as they claim?
There are published benchmarks, and you are welcome to run your own on
the free evaluation version (which has the same performance
characteristics).
> 3. Does it have libs for audio - MIDI, and video development?
These things are best done via Windows calls or existing packages. It's
very straightforward to call external programs from SwiftForth.
> 4. Can someone rate it's performance compared to Ruby? I know Ruby is
> interpreted, but it looks really cool.
I am not familiar with Ruby. I suspect it's directed at a slightly
different application set. I believe there are some Ruby users here who
can comment.
As I mentioned above, there is a free evaluation version of SwiftForth
available from www.forth.com. It is fully compatible with the purchased
version, lacking only some source and the ability to make a
distributable turnkey. That should answer many of your questions.
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."
==================================================
Slava Pestov
> Can anyone recommend a free Forth that is object-oriented and compiled?
Factor is a Forth-like language you might want to try; its free (BSD
license) and available from http://factorcode.org (Full disclosure:
I'm the project lead, and this is basically a sales pitch and not an
unbiased review). Factor is stack-based and supports some key Forth
features (parsing words most importantly) together with some features
from higher-level languages (dynamic types, data structures, garbage
collection, etc).
It runs on Windows, Mac OS X and Linux and has a decent development
environment where you can test your code and browse documentation
(here's a screenshot: http://factorcode.org/factor-windows7.png). We
have a build farm that runs automated regression tests on Windows and
11 other platforms, with near-daily binary builds, so stability is
pretty good for the most part, however we have not made a 1.0 release
yet.
It supports object oriented programming (http://docs.factorcode.org/
content/article-objects.html) and is also quite fast. Since the
language is dynamically-typed so there is some additional overhead but
the compiler inlines definitions, infer types, perform constant
folding and common subexpression elimination, and even eliminates
object allocation in many cases. One major departure point from Forth
is that the Factor compiler statically infers stack effects of words
and checks that they match the declaration; this allows global
optimizations to be performed.
For example, here is a mandelbrot benchmark in several languages:
C++: http://paste.factorcode.org/paste?id=922
Factor: http://paste.factorcode.org/paste?id=950
Python: http://paste.factorcode.org/paste?id=920
Running times on my Mac Book Pro, measured in a quite unscientific
way :-)
- C++ is the clear winner of course:
$ g++ -O3 mandel.cc -o mandel; time ./mandel
real 0m0.060s
user 0m0.051s
sys 0m0.009s
- Factor is about twice as slow:
$ ./factor mandel.factor
== Running time ==
0.113808 seconds
- Python is interpreted and lags behind considerably:
$ time python mandel.py > out.ppm
real 0m8.708s
user 0m8.565s
sys 0m0.059s
If anyone wants to port this benchmark to Forth (should be easy, you
have the source in 3 languages) I'd love to see what kind of
performance it gets on the commercial implementations.
Finally Factor has an extensive and well-designed library. We've had
dozens of contributors writing vocabularies, and all code goes through
a stringent code review process, with frequent refactoring and cleanup
of older code. We have libraries for common programming tasks such as
non-blocking network I/O, working with Unicode text, parsing XML,
downloading data via HTTP, even high-level wrappers around OpenGL that
make it easy to use features such as shaders, vertex buffers, etc.
There is also much much more there, and if something is not available
you can very easily call out to C.
Slava
m_l_g3
for the reason that it correctly supports return address manipulations
(that may be used for backtracking and BNF parsing).
Return address manipulations are a VERY advanced topic,
and at second are NOT standard, but in the case of
VFX they work (and will always work because MPE delivers
a BNF parser based on them), whereas in Swift they are just
an ambiguous condition, may work or not work depending
on arbitrary factors.
For example, I have posted this sort of code to another thread.
\ execute the rest of a colon definition 4 times
: 4x R@ DUP DUP >R >R >R ;
\ manipulations with quadruples
\ q occupies four cells on the stack:
\ q == d1 d2 == x1 x2 x3 x4
: qdup 4x 3 pick ; ( q -- q q )
: qover 4x 7 pick ; ( q1 q2 -- q1 q2 q1 )
: qswap 4x 7 roll ; ( q1 q2 -- q2 q1 )
\ it works at least on gForth
The three above words are quadruple-precision analogs of dup, swap and
over.
The word 4x makes the rest of definition execute 4 times. Namely, when
the interpreter enters 4x, the address of that "rest of definition" is
on the return stack, and 4x makes three additional copies of that
address, and places them on the return stack. So after exiting 4x,
that "rest of definition" will execute 4 times. It's not a dirty
trick, it's a design pattern. (If you look at object-oriented design
patterns, you'll find that most of them violate the principles of
object orientation; my favourite one is an object without data fields
but with virtual functions operating on external data.)
My position is that systems with optimizing compilers must behave like
ones based on threaded code, and in particular generate correct code
for return address manipulations. But this is my personal position,
the choice is up to you.
(By the way, checking the return stack usage is not so much difficult.
And after finding out the return stack effect you may allow or
prohibit tail call optimization. To say more, I could do that. ;-)
Marcel Hendrix
[..]
> For example, here is a mandelbrot benchmark in several languages:
> C++: http://paste.factorcode.org/paste?id=3D922
> Factor: http://paste.factorcode.org/paste?id=3D950
> Python: http://paste.factorcode.org/paste?id=3D920
[..]
> If anyone wants to port this benchmark to Forth (should be easy, you
> have the source in 3 languages) I'd love to see what kind of
> performance it gets on the commercial implementations.
[..]
This Forth code seems to work (I get a Mandlebrot-like picture)
-marcel
-- ---------------
NEEDS -fsl_util
0e FVALUE hh
0e FVALUE ss
0e FVALUE vv
60e 1/F FCONSTANT 1/60
: HSV ( F: h s v -- ) TO vv TO ss TO hh ;
: hi ( -- n ) hh 1/60 F* F>S 6 MOD ;
: f() ( F: -- r ) hh 1/60 F* hi S>F F- ;
: p() ( F: -- r ) 1e ss F- vv F* ;
: q() ( F: -- r ) 1e f() ss F* F- vv F* ;
: t() ( F: -- r ) 1e 1e f() ss F* F- F- vv F* ;
CREATE 'rgb 0 C, 0 C, 0 C, CELL 3 - CHARS ALLOT
: makeRGB ( F: r g b -- )
255e F* F>S 'rgb 2+ C!
255e F* F>S 'rgb 1+ C!
255e F* F>S 'rgb C! ;
: RGB ( -- )
hi 0 OVER = IF DROP vv t() p() makeRGB EXIT ENDIF
1 OVER = IF DROP q() vv p() makeRGB EXIT ENDIF
2 OVER = IF DROP p() vv t() makeRGB EXIT ENDIF
3 OVER = IF DROP p() q() vv makeRGB EXIT ENDIF
4 = IF t() p() vv makeRGB EXIT ENDIF
vv p() q() makeRGB ;
#640 CONSTANT width
#480 CONSTANT height
#360 CONSTANT maxColor
#40 CONSTANT maxIterations
0.80e FCONSTANT zoomFact
-0.65e FCONSTANT center
width S>F 200000e zoomFact F* F/ FCONSTANT xInc
height S>F 150000e zoomFact F* F/ FCONSTANT yInc
0.85e FCONSTANT sat
0.85e FCONSTANT val
maxIterations maxColor MIN CONSTANT colorMap.size
CREATE colorMap colorMap.size 3 * CHARS ALLOT CELL 3 - CHARS ALLOT
: MAKE.colorMap ( -- )
colorMap.size
0 ?DO I S>F 360e F* colorMap.size 1+ S>F F/ sat val
HSV RGB 'rgb @ colorMap I 3 * + !
LOOP ;
MAKE.colorMap
: c(z) ( i j -- ) ( F: -- z )
SWAP
S>F xInc F* center F+ xInc width 2/ S>F F* F-
S>F yInc F* yInc height 2/ S>F F* F- ;
: pixel ( F: r i -- ) ( -- iterations )
ZLOCAL c
0+0i
0 maxIterations ?DO ZSQR c Z+ ZDUP ZABS^2 16e F>= IF ZDROP I UNLOOP EXIT ENDIF
-1 +LOOP ZDROP -1 ;
: black 'rgb C0! 'rgb 1+ C0! 'rgb 2+ C0! ;
: color ( iterations -- )
DUP -1 = IF DROP black EXIT ENDIF
colorMap.size MOD 3 * colorMap + @ 'rgb ! ;
: render ( out -- )
LOCAL out
height 0 ?DO
width 0 ?DO
J I c(z) pixel color
'rgb 3 out WRITE-FILE ?FILE
LOOP
LOOP ;
: writePPMHeader ( out -- )
>R S\" P6\n" width (.) $+ S" " $+ height (.) $+ S\" \n255\n" $+
R> WRITE-FILE ?FILE ;
: mandel ( -- )
S" out.ppm" R/W BIN CREATE-FILE ABORT" unable to open out.ppm" >R
R@ writePPMHeader
R@ render
R> CLOSE-FILE ABORT" unable to close open.ppm" ;
CR TIMER-RESET mandel .ELAPSED
\ CoreDuo : 0.4 seconds
\ PIV : 1.4 seconds
\ EOF
Marcel Hendrix
> Slava Pestov <sl...@jedit.org> writes Re: SwiftForth and Windows Vista/7 & more ...
[..]
>> If anyone wants to port this benchmark to Forth (should be easy, you
>> have the source in 3 languages) I'd love to see what kind of
>> performance it gets on the commercial implementations.
[..]
> This Forth code seems to work (I get a Mandlebrot-like picture)
[..]
> CR TIMER-RESET mandel .ELAPSED
> \ CoreDuo : 0.4 seconds
> \ PIV : 1.4 seconds
... apparently painfully slow in iForth. However, it proved the problem
was writing the file out.ppm on a (Windows) network drive. Adding some
buffering, and switching directories, yields
\ CoreDuo : 0.064 seconds
\ PIV : 0.104 seconds
.. which is as fast as the quoted C++ results. (Assuming my Pop&Mom store
no-name Intel box is slower than a vastly superior Macbook Pro costing five
times as much :-)
-marcel
Hugh Aguilar
> Zuvuya wrote:
> > 1. Is it Vista/ Windows 7 compatible?
>
> Yes. Reported difficulties with Vista involved older versions that
> hadn't followed the updates.
I was the one complaining about SwiftForth (ver 2) not working on
Vista, but Leon Wagner of Forth Inc. fixed the problem for me, so I
have no further complaints. SwiftForth is at ver 3 now anyway, which
was designed for Vista.
I have been using SwiftForth for years and like it a lot, and have
found it to be plenty fast.
> > 4. Can someone rate it's performance compared to Ruby? I know Ruby is
> > interpreted, but it looks really cool.
>
> I am not familiar with Ruby. I suspect it's directed at a slightly
> different application set. I believe there are some Ruby users here who
> can comment.
I don't use Ruby either, but I know that it is dynamically typed,
whereas SwiftForth is statically typed, so you're comparing apples and
oranges.
If you want a dynamically typed language that is Forth-like and BSD-
license, then I would recommend Factor. I haven't seen any direct
comparison with Ruby in terms of speed, but I suspect that Factor
blows away Ruby.
The creator of Factor, Slava Pestov, already posted a message here, so
read over what he says. One of the best things about Factor is error-
checking. For example, look at my program (www.rosycrew.org/
list.factor). Notice that the traverse function takes a quotation as
an input parameter and then calls it. This is very similar to how in
Forth a function can take a cfa as an input parameter and then EXECUTE
it. The difference is that in Factor, the call function includes
information about what the stack-frame of the quotation is supposed to
look like ( node -- ). If you pass in a quotation that does something
different, the compiler will tell you about this at compile-time.
Similarly, all functions have stack-frame information associated with
them. If they don't do what they are supposed to do (at least get the
number of parameters correct), the compiler will catch this problem at
compile-time. This error-checking really helps me a lot! In Forth, one
of the biggest sources of errors is getting the stack shufflers (sup,
swap, etc.) tangled up. This generally results in the wrong number of
parameters being on the stack, which Factor will catch at compile-
time.
You might consider starting with Factor. I guarantee that you'll like
it, or your money-back! ;-)
Only if you run into speed limitations or other problems with Factor
should you reach for your wallet and buy a commercial system.
BTW, who uses the Amiga anymore? I read that it is still used in
Germany and that they upgraded from the 68K to the PPC, but that was
several years ago. I know that it is dead here in America.
full name
<hugoa...@rosycrew.com> wrote:
>If you want a dynamically typed language that is Forth-like and BSD-
>license, then I would recommend Factor. I haven't seen any direct
>comparison with Ruby in terms of speed, but I suspect that Factor
>blows away Ruby.
Factor does not run on Windoze OS below XP (ie win98 etc)
Nor does it run on any X86 hardware using 32 bit AMD Athlon or similar
non SSE2 procecessors. That rules out all of my desktops.
Strange decision to exclude that vast market of hardware out there.
Pity - I would have looked at the Linux or windoze versions but the
SSE2 requirement rules it out.
Crash proofing forth seems to me to be a priority much higher
than internationalization. Strange that so few people seem to care
about that?
How does SwissForth VFX and the other big names do it?
-------------------------------------------------------------------------------------
joseph
-------------------------------------------------------------------------------------
Samuel Tardieu
Joseph> Nor does it [Factor] run on any X86 hardware using 32 bit AMD
Joseph> Athlon or similar non SSE2 procecessors. That rules out all of
Joseph> my desktops.
You are misinformed. Factor runs perfectly fine on processors with SSE1.
Sam
--
Samuel Tardieu -- s...@rfc1149.net -- http://www.rfc1149.net/
Bernd Paysan
> Factor does not run on Windoze OS below XP (ie win98 etc)
> Nor does it run on any X86 hardware using 32 bit AMD Athlon or similar
> non SSE2 procecessors. That rules out all of my desktops.
>
> Strange decision to exclude that vast market of hardware out there.
What kind of "vast market of hardware" do you think of? Do you acutally
use your computers? Mine break apart after some years, so even the
first Athlon64 generation I have is already trashed.
A coworker, who's also in this sort of "lazy retro-computing" mode just
yesterday asked for a Windows 2k CD at work (there are more than enough
spare W2K CDs with license around), because he wanted to reinstall W2K
on his home computer - which supposedly was infected by a virus, because
it rebooted without cause. It's one of those PCs you seem to have
around - my diagnosis is just hardware failure due to age. The diodes
down the left side hurt too much ;-).
Excluding anything before XP is a sane decision, since Microsoft does
the same: There is no supported Windows OS before XP.
> Crash proofing forth seems to me to be a priority much higher
> than internationalization.
Forthers rather do "crash early, crash hard, crash often" to fix the
bugs. We all know that bugs that don't crash early, hard and often
enough won't get fixed, because they don't cause enough pain. VFX
deliberately crashes way more often than ProForth for Windows once did,
and this is a good thing. Some bugs in MINOS and Theseus were only
discovered after moving to VFX, because bigForth didn't crash hard
enough on them ;-).
Elizabeth D Rather
> On Fri, 2 Oct 2009 19:16:46 -0700 (PDT), Hugh Aguilar
> <hugoa...@rosycrew.com> wrote:
>
>
>> If you want a dynamically typed language that is Forth-like and BSD-
>> license, then I would recommend Factor. I haven't seen any direct
>> comparison with Ruby in terms of speed, but I suspect that Factor
>> blows away Ruby.
>
>
> Factor does not run on Windoze OS below XP (ie win98 etc)
> Nor does it run on any X86 hardware using 32 bit AMD Athlon or similar
> non SSE2 procecessors. That rules out all of my desktops.
>
> Strange decision to exclude that vast market of hardware out there.
> Pity - I would have looked at the Linux or windoze versions but the
> SSE2 requirement rules it out.
>
> Crash proofing forth seems to me to be a priority much higher
> than internationalization. Strange that so few people seem to care
> about that?
>
> How does SwissForth VFX and the other big names do it?
A lot of different strategies to deal with a lot of situations. It's
possible to crash SwiftForth, but it's pretty hard. The complicated OSs
change the tradeoffs a lot from the early days of running on bare metal
or DOS.
Albert van der Horst
Bernd Paysan <bernd....@gmx.de> wrote:
>full name wrote:
>> Factor does not run on Windoze OS below XP (ie win98 etc)
>> Nor does it run on any X86 hardware using 32 bit AMD Athlon or similar
>> non SSE2 procecessors. That rules out all of my desktops.
>>
>> Strange decision to exclude that vast market of hardware out there.
>
>What kind of "vast market of hardware" do you think of? Do you acutally
>use your computers? Mine break apart after some years, so even the
>first Athlon64 generation I have is already trashed.
My main machine with all the source control archives is still
a Pentium 90, original Intel board. Power supply has been
replaced several times, but that is not difficult with a home brew.
Then my Dec Alpha. I expect it to last into the twentieth-second
century.
>--
>Bernd Paysan
Groetjes Albert
--
--
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
Stephen Pelc
wrote:
>VFX
>deliberately crashes way more often than ProForth for Windows once did,
>and this is a good thing. Some bugs in MINOS and Theseus were only
>discovered after moving to VFX, because bigForth didn't crash hard
>enough on them ;-).
Note however, that VFX includes a crash mechanism integrated
with CATCH and THROW that actually tells you where you crashed!
The real point of the "crash early and crash often" idea is that
bugs such as null pointers should be detected as soon as possible.
Bernd Paysan
> My main machine with all the source control archives is still
> a Pentium 90, original Intel board. Power supply has been
> replaced several times, but that is not difficult with a home brew.
> Then my Dec Alpha. I expect it to last into the twentieth-second
> century.
The Pentium 90 might still be a chip before electromigration started to
become critical. Basically, all copper-based processes are so sensitive
to electromigration that you can't expect the CPUs to last more than
several years of operation. Centuries completely impossible.
I don't know how long PCBs last, but I'd guess that a century is
difficult to reach.
full name
wrote:
>>>>>> "Joseph" == full name <a...@dummyadd.com> writes:
>
>Joseph> Nor does it [Factor] run on any X86 hardware using 32 bit AMD
>Joseph> Athlon or similar non SSE2 procecessors. That rules out all of
>Joseph> my desktops.
>
>You are misinformed. Factor runs perfectly fine on processors with SSE1.
>
> Sam
5 minutes before I posted that the Factor web site said perfectly
clearly and in no uncertain terms that it does not work without SSE2.
If you go to the minimum hardware required page right now you will
be sent to a wrong link and may be unable to find the correct one.
If you then go to the recent changes page you will find a notification
that the minimum hardware FAQ has been changed - After I posted the
message.
Mistakes I can handle - apparent subterfuge is a little less
comforting.
-------------------------------------------------------------------------------------
joseph
-------------------------------------------------------------------------------------
full name
wrote:
>
>What kind of "vast market of hardware" do you think of? Do you acutally
>use your computers? Mine break apart after some years, so even the
>first Athlon64 generation I have is already trashed.
>
>A coworker, who's also in this sort of "lazy retro-computing" mode just
>yesterday asked for a Windows 2k CD at work (there are more than enough
>spare W2K CDs with license around), because he wanted to reinstall W2K
>on his home computer - which supposedly was infected by a virus, because
>it rebooted without cause. It's one of those PCs you seem to have
>around - my diagnosis is just hardware failure due to age. The diodes
>down the left side hurt too much ;-).
>
Lets just say we agree to dissagree about some fundamental things and
avoid the flame war that would result otherwise.
I hope your diodes get better soon.
-------------------------------------------------------------------------------------
joseph
-------------------------------------------------------------------------------------
Bernd Paysan
> Lets just say we agree to dissagree about some fundamental things and
> avoid the flame war that would result otherwise.
Ok, so you stop complaining about unsupported obsolete hardware.
> I hope your diodes get better soon.
It's your Marvin who has the hurting diodes, because you don't replace them
regularly ;-). I do so, so my androids don't complain.
Doug Hoffman
> Factor does not run on Windoze OS below XP (ie win98 etc)
Nor do the latest versions of Factor (which is to say all versions
shown on the Factor website) run on Mac OS X 10.4 and earlier. 10.5+
required. Although after searching a bit on the web I found an old
2006 version of Factor that runs on 10.4 which is what I have.
Hugh Aguilar
> Strange decision to exclude that vast market of hardware out there.
> Pity - I would have looked at the Linux or windoze versions but the
> SSE2 requirement rules it out.
Factor has an active user group. If you can't get it to run on some
particular platform, then you should complain --- not here though ---
on the Factor mailing list.
Somebody will generally come to your aid --- usually faster when the
complaint is framed politely and you are an active participant in the
process --- you can't be like Capt. Pickard and tell Slava: "Make it
so." :-)
Krishna Myneni
...
> For example, I have posted this sort of code to another thread.
>
> \ execute the rest of a colon definition 4 times
> : 4x R@ DUP DUP >R >R >R ;
> \ manipulations with quadruples
> \ q occupies four cells on the stack:
> \ q == d1 d2 == x1 x2 x3 x4
> : qdup 4x 3 pick ; ( q -- q q )
> : qover 4x 7 pick ; ( q1 q2 -- q1 q2 q1 )
> : qswap 4x 7 roll ; ( q1 q2 -- q2 q1 )
> \ it works at least on gForth
Seems to work under kForth too.
Krishna
Brad Eckert
>
> I don't know how long PCBs last, but I'd guess that a century is
> difficult to reach.
>
stuff (pre-2006).
Also, the BIOS flash only has a retention of 20 years. Maybe less,
since the inside of a PC isn't room temperature.
-Brad
Albert van der Horst
Brad Eckert <bit...@gmail.com> wrote:
So it is about time to reflash my BIOS again.
I need not worry about the solder.
>
>-Brad
MarkWills
> Crash proofing forth seems to me to be a priority much higher
> than internationalization. Strange that so few people seem to care
> about that?
>
> How does SwissForth VFX and the other big names do it?
In my limited experience of Forth, it is not so much how the *systems*
themselves (VFX, Swift, GForth etc) handle crashes, but how the
*programmer* does.
Ok, I admit I have not developed any commercial or mission critical
applications (yet) in Forth, but my experience, based on the advice of
others here on the list, is that appropriate factoring of code and
isolated unit testing of code makes crashes (I mean, full on lights-
out-nobody-home-type-crashes) very rare indeed. Nothing new, I know,
but I thought I would say it anyway!
As we all know, the interactivity of Forth makes testing of individual
words a breeze. Actually a pleasure. Feed your word some stack
parameters and test it right there at the keyboard.
I guess things could get more complicated when one starts interacting
with the underlying OS. I guess feeding the wrong data to a Win API
call could potentially turn the lights off, but as I said, my
experience thus far is limited!
Regards
Mark.
Doug Hoffman
> Crash proofing forth seems to me to be a priority much higher
> than internationalization. Strange that so few people seem to care
> about that?
Bernd answered this correctly. I would add that there is crashing,
the kind that just stops your Forth program from continuing to execute
but your Forth is still running and may also have provided useful
information as to why and where the crash occurred; and then there is
*crashing* where your Forth itself abruptly quits running with no
messages and it may even bring down your whole computer. The higher
quality Forths will usually do the former, which is much less
disruptive to the interactive programming process, and of course far
more useful for debugging the cause of the crash because you can
inspect the state of variables and so forth.
Other programming languages go to great lengths to try to catch errors
at compile time. For example, type checking is done for all called
functions. This is antithetical to the Forth way of doing things (OK,
there is StongForth, another story). Type checking adds complexity
and having to declare types for each new function interferes with the
fluid and highly interactive Forth programming environment. Also, the
fact that plenty of bugs still infest with typed languages show that
type checking is not a panacea.
Having said that I will admit to using a few defensive programming
techniques with Forth. I like to insert a few input validity checks
just for development, and then remove them for the finished program
for increased performance. For example, I always develop using arrays
that perform indice(s) bounds checking because it is very easy to be
"off by one" on an index yet still have the program appear to function
correctly for awhile. Meaningful error messages are given. Same for
messages sent to objects. Validity checks are performed just during
development. These are just a couple of examples of "crash proofing"
Forth. It is left to the Forth programmer whether or not to use them.
Aleksej Saushev
> On Oct 3, 7:54О©╫am, full name <a...@dummyadd.com> wrote:
>
>> Crash proofing forth seems to me to be a priority much higher
>> than internationalization. Strange that so few people seem to care
>> about that?
>
> Bernd answered this correctly. I would add that there is crashing,
> the kind that just stops your Forth program from continuing to execute
> but your Forth is still running and may also have provided useful
> information as to why and where the crash occurred; and then there is
> *crashing* where your Forth itself abruptly quits running with no
> messages and it may even bring down your whole computer. The higher
> quality Forths will usually do the former, which is much less
> disruptive to the interactive programming process, and of course far
> more useful for debugging the cause of the crash because you can
> inspect the state of variables and so forth.
>
> Other programming languages go to great lengths to try to catch errors
> at compile time. For example, type checking is done for all called
> functions. This is antithetical to the Forth way of doing things (OK,
> there is StongForth, another story). Type checking adds complexity
> and having to declare types for each new function interferes with the
> fluid and highly interactive Forth programming environment. Also, the
> fact that plenty of bugs still infest with typed languages show that
> type checking is not a panacea.
This argument is repeated ad nauseam in Forth community.
Would you tell us which exactly languages are you talking about here?
Last time I checked neither Common Lisp, nor Scheme, nor Smalltalk,
nor Python, nor PERL, nor ECMAScript/JavaScript, nor great number of
other languages did that.
Will you tell me where do I have to declare types in those listed above?
When you realize that those languages are dynamically typed, turn to
Standard ML, you are to show where one has to declare function types for
common list or string processing tasks. You may choose O'Caml, if you
like it more.
--
HE CE3OH...
Doug Hoffman
> Doug Hoffman <dhoff...@talkamerica.net> writes:
> > On Oct 3, 7:54šam, full name <a...@dummyadd.com> wrote:
>
> >> Crash proofing forth seems to me to be a priority much higher
> >> than internationalization. Strange that so few people seem to care
> >> about that?
>
> > Bernd answered this correctly. I would add that there is crashing,
> > the kind that just stops your Forth program from continuing to execute
> > but your Forth is still running and may also have provided useful
> > information as to why and where the crash occurred; and then there is
> > *crashing* where your Forth itself abruptly quits running with no
> > messages and it may even bring down your whole computer. The higher
> > quality Forths will usually do the former, which is much less
> > disruptive to the interactive programming process, and of course far
> > more useful for debugging the cause of the crash because you can
> > inspect the state of variables and so forth.
>
> > Other programming languages go to great lengths to try to catch errors
> > at compile time. For example, type checking is done for all called
> > functions. This is antithetical to the Forth way of doing things (OK,
> > there is StongForth, another story). Type checking adds complexity
> > and having to declare types for each new function interferes with the
> > fluid and highly interactive Forth programming environment. Also, the
> > fact that plenty of bugs still infest with typed languages show that
> > type checking is not a panacea.
>
> This argument is repeated ad nauseam in Forth community.
Thank you. The better phrasing would be something like "many
programming languages require..."
> Would you tell us which exactly languages are you talking about here?
C, C++, C#, Java, Fortran, Haskell, Pascal, Perl, and some others.
> Last time I checked neither Common Lisp, nor Scheme, nor Smalltalk,
> nor Python, nor PERL, nor ECMAScript/JavaScript, nor great number of
> other languages did that.
> Will you tell me where do I have to declare types in those listed above?
But even with dynamic typing I have problems like this in, for example
Python. Probably if I knew more about Python I could fix this:
Python 2.6.3
======
>>> a=1+2
>>> b='heLlo'
>>> c=a+b
Traceback (most recent call last):
File "<pyshell#5>", line 1, in <module>
c=a+b
TypeError: unsupported operand type(s) for +: 'int' and 'str'
>>>
Forth
=====
1 2 + value a ok
create b ," heLlo" ok
a b + value c ok
c c@ emit L ok \ c points to the 3rd character in the string
Nonetheless, I take your point and thank you for correcting my
statement.
Aleksej Saushev
This is still too vague. Of course there're hordes of archaic languages,
compared to them new languages are rather rare. But nevertheless in a
new language type inference is a must. It is quite stupid to bring the
same argument again and again, while it is no longer valid. You start to
make impression of an old fart, who continues to live in his 1980s.
Wake up and look around, it isn't 1985, we have plenty of modern
programming languages, which do much of consistency checks for you.
>> Would you tell us which exactly languages are you talking about here?
>
> C, C++, C#, Java, Fortran, Haskell, Pascal, Perl, and some others.
Of these only Haskell is modern enough.
>> Last time I checked neither Common Lisp, nor Scheme, nor Smalltalk,
>> nor Python, nor PERL, nor ECMAScript/JavaScript, nor great number of
>> other languages did that.
>> Will you tell me where do I have to declare types in those listed above?
>
> But even with dynamic typing I have problems like this in, for example
> Python. Probably if I knew more about Python I could fix this:
>
> Python 2.6.3
> ======
>
>>>> a=1+2
>>>> b='heLlo'
>>>> c=a+b
>
> Traceback (most recent call last):
> File "<pyshell#5>", line 1, in <module>
> c=a+b
> TypeError: unsupported operand type(s) for +: 'int' and 'str'
This makes me laugh. Calling this a problem is really stupid.
> Forth
> =====
>
> 1 2 + value a ok
> create b ," heLlo" ok
> a b + value c ok
> c c@ emit L ok \ c points to the 3rd character in the string
(I'm skipping obvious argument that one byte may be 4 octets.)
create a 10 , 20 , 30 , 40 ,
a 3 + ?
It points to wrong place into the array, and you don't know it
'til you spend some time on searching where the problem hides.
That's what is called a problem.
And it is obvious that this is serious drawback in Forth,
because programmers still do stupid mistakes from time to time.
Not assisting programmer _is_ a drawback.
--
HE CE3OH...
Doug Hoffman
Or perhaps the programmer is aware of the details and simply adjusts
his code accordingly. Unit testing will immediately show if he got it
wrong.
> That's what is called a problem.
>
> And it is obvious that this is serious drawback in Forth,
> because programmers still do stupid mistakes from time to time.
> Not assisting programmer _is_ a drawback.
Interesting perspective. How would you suggest Forth be changed to
overcome this drawback?
-Doug
MarkWills
> And it is obvious that this is serious drawback in Forth,
> because programmers still do stupid mistakes from time to time.
> Not assisting programmer _is_ a drawback.
>
> --
> HE CE3OH...
I don't agree. Assembly language coders live with this day to day.
Moral? Learn your code, and don't make stupid mistakes!
If we accept (as I do) that Forth is basically a low-level language, a
kind of powerful Assembly Language, then I see no issue with this at
all. Forth is a low level, lean mean and clean language. To add type
checking and the like, whilst nice, would require a lot more
complexity in the the compiler. Of course, Forth is loved for being
such a low-level, simple language. To change it beyond this would be
to change the flavour of Forth, moving it away from what it has always
been famous for, loved for, and good at.
Just my opinion, of course ;-)
Mark
Aleksej Saushev
> On Oct 7, 3:42О©╫pm, Aleksej Saushev <a...@inbox.ru> wrote:
>> Doug Hoffman <dhoff...@talkamerica.net> writes:
>
>> > 1 2 + value a ok
>> > create b ," heLlo" ok
>> > a b + value c ok
>> > c c@ emit L ok О©╫\ c points to the 3rd character in the string
>>
>> (I'm skipping obvious argument that one byte may be 4 octets.)
>>
>> create a 10 , 20 , 30 , 40 ,
>> a 3 + ?
>>
>> It points to wrong place into the array, and you don't know it
>> 'til you spend some time on searching where the problem hides.
>
> Or perhaps the programmer is aware of the details and simply adjusts
> his code accordingly. Unit testing will immediately show if he got it
> wrong.
And if this particular place isn't covered by unit tests, you still have
to find it first.
>> That's what is called a problem.
>>
>> And it is obvious that this is serious drawback in Forth,
>> because programmers still do stupid mistakes from time to time.
>> Not assisting programmer _is_ a drawback.
>
> Interesting perspective. How would you suggest Forth be changed to
> overcome this drawback?
By introducing type inference. Of course, this will annoy old farts and
language purists to the highest pitch, but this is the modern state of
the field, it looks that you either have to adapt or to fade out.
Consider SBCL, it implements dynamically typed language, yet it still
does type inference and produces valuable warnings. E.g.
1. http://article.gmane.org/gmane.comp.mathematics.axiom.devel/17987/
2. http://article.gmane.org/gmane.comp.mathematics.axiom.devel/17999/
Cat programming language (http://www.cat-language.com/manual.html) gives
fine example of stack language experiments resembling KRC-to-ML line.
You're aware of StrongForth, aren't you?
(Here you can see one of reasons why I strongly oppose to CHARS removal,
in addition to quite restrictive "consensus" among Latin-only developers
it closes potentially valuable direction in research.)
--
HE CE3OH...
Bernd Paysan
> By introducing type inference. Of course, this will annoy old farts and
> language purists to the highest pitch, but this is the modern state of
> the field, it looks that you either have to adapt or to fade out.
Dynamic typing is no more modern or archaic than static typing. Lisp
originates in 1958. It is the second-oldest language still in use, it is
older than Algol, and only Fortran (which has a pretty weak static typing
system) is older. Forth-like language with dynamic typing have a long
tradition, as well, Postscript originates in 1984, and there have been
others; Factor is only the most recent one.
ken...@cix.compulink.co.uk
wrote:
> This is still too vague. Of course there're hordes of archaic
> languages, compared to them new languages are rather rare.
Try this then. The common languages used to write applications in no
particular order are Java, C++, C#, C, Ada and Object Pascal. All of
these have strong typing and the ability to limit the scope of
variables. All of them with the possible exception of C post date Lisp
(lots of irritating superfluous parentheses). All of them have both
compile time and run time checking. And like Lisp all of them are of
topic for this news group.
Forth was designed under different criteria than Ada. The idea of a
simple extensible system with interactive compiling was very different
from the Fortran and Cobol compilers that were being used for
application development at the time and much more suitable for real time
systems. In fact even having any kind of interactive system was an
innovation. Early Fortran and Cobol programs had to written on paper and
then converted to punched cards which is why something Fortran 77 had
the column limits in the source files. They were there to make the punch
card operator's life easier.
Ken Young
Aleksej Saushev
> Aleksej Saushev wrote:
>> By introducing type inference. Of course, this will annoy old farts and
>> language purists to the highest pitch, but this is the modern state of
>> the field, it looks that you either have to adapt or to fade out.
>
> Dynamic typing is no more modern or archaic than static typing. Lisp
> originates in 1958. It is the second-oldest language still in use, it is
> older than Algol, and only Fortran (which has a pretty weak static typing
> system) is older. Forth-like language with dynamic typing have a long
> tradition, as well, Postscript originates in 1984, and there have been
> others; Factor is only the most recent one.
I'm sorry to distress you, but the talk wasn't about static and dynamic
typing. It was about explicit type assignment and type inference, and
the latter renders your comment irrelevant.
Type inference didn't enter practice before late 1970s.
--
HE CE3OH...
Aleksej Saushev
>> And it is obvious that this is serious drawback in Forth,
>> because programmers still do stupid mistakes from time to time.
>> Not assisting programmer _is_ a drawback.
>
> I don't agree. Assembly language coders live with this day to day.
What do you disagree exactly? That it is a drawback?
This is simply stupid.
Yes, some coders live with the lack of good tools all their lives.
So what? Does it make them more capable? Better? Or what?
How does it help in anything?
> Moral? Learn your code, and don't make stupid mistakes!
"Learn" in what sense? Learn it by heart so that I remember the meaning
of each and other variable all 24 hours 365 days a year?
Sorry, I have more pleasant things to spend my efforts on.
> If we accept (as I do) that Forth is basically a low-level language, a
> kind of powerful Assembly Language, then I see no issue with this at
> all. Forth is a low level, lean mean and clean language. To add type
> checking and the like, whilst nice, would require a lot more
> complexity in the the compiler. Of course, Forth is loved for being
> such a low-level, simple language. To change it beyond this would be
> to change the flavour of Forth, moving it away from what it has always
> been famous for, loved for, and good at.
Of course this requires some work at compiler level. So what?
This is one-time investment. In return you get ability to prove
correctness and faster development cycle because you don't need to
handle risks of some kinds.
--
HE CE3OH...
Aleksej Saushev
> In article <87r5tfa...@inbox.ru>, as...@inbox.ru (Aleksej Saushev)
> wrote:
>
>> This is still too vague. Of course there're hordes of archaic
>> languages, compared to them new languages are rather rare.
>
> Try this then. The common languages used to write applications in no
> particular order are Java, C++, C#, C, Ada and Object Pascal. All of
> these have strong typing and the ability to limit the scope of
> variables.
Which of those have type inference?
Like I said, there're hordes of archaic languages, most of them have
explicit type declarations. Bringing them as example doesn't make you smarter.
> All of them with the possible exception of C post date Lisp
> (lots of irritating superfluous parentheses). All of them have both
> compile time and run time checking. And like Lisp all of them are of
> topic for this news group.
Sorry? Who are you? I don't remember you. Are you USENET police?
If you're so clueful, better stay away from this discussion, don't make
fool of yourself.
Lisp and other languages are on-topic to the extent they are referenced
in this thread.
> Forth was designed under different criteria than Ada. The idea of a
> simple extensible system with interactive compiling was very different
> from the Fortran and Cobol compilers that were being used for
> application development at the time and much more suitable for real time
> systems. In fact even having any kind of interactive system was an
> innovation. Early Fortran and Cobol programs had to written on paper and
> then converted to punched cards which is why something Fortran 77 had
> the column limits in the source files. They were there to make the punch
> card operator's life easier.
And Lisp was designed under the same criteria of simple extensible
system with interactive compiling _before_ Forth. And in its development
Lisp moved faster forward and it fluorishes: it is simpler, it provides
better interactive tools, it provides better compilers, it provides
more useful features, it provides more useful software.
It would do no harm, if forthers learn how their nominal goals are
achieved in other environments.
--
HE CE3OH...
Richard Owlett
You're confusing him with *FACTS* ;/
ken...@cix.compulink.co.uk
wrote:
> Like I said, there're hordes of archaic languages, most of them have
> explicit type declarations.
So java is an archaic language? There are 223 public java newsgroups
compared with about 30 for lisp and 18 for forth. Pascal has 80
newsgroups. Ada is mandated by the US Defence Department for large
projects. All of those languages have regularly updated commercial
compilers for sale. .net requires the use of C# IIRC. So what is your
definition of an archaic language. If it is by date of origin then lisp
is more archaic than any of them.
> Lisp and other languages are on-topic to the extent they are
> referenced in this thread.
Well you are entitled to your own opinion but I fail to see how
arguing that someone should be using lisp helps with solving a forth
problem
> It would do no harm, if forthers learn how their nominal goals are
> achieved in other environments.
I am aware of that, I have used Basic, assembler and Pascal as well as
forth. I am sure that most of the other people in this group have also
used multiple languages.
> it is simpler, it provides
> better interactive tools, it provides better compilers,
I am unsure how you can say it is simpler when you apparently have no
knowledge of forth, not that I can or would claim the lisp is more
complex as I have done no more than looked at lisp source. As for your
claim about development tools have you actually used all available forth
development systems. Besides development tools are not specific to a
language. Borland and Microsoft use the same IDE for multiple languages.
Ken Young
Aleksej Saushev
> In article <87skdua...@inbox.ru>, as...@inbox.ru (Aleksej Saushev)
> wrote:
>
>> Like I said, there're hordes of archaic languages, most of them have
>> explicit type declarations.
>
> So java is an archaic language? There are 223 public java newsgroups
> compared with about 30 for lisp and 18 for forth. Pascal has 80
> newsgroups. Ada is mandated by the US Defence Department for large
> projects. All of those languages have regularly updated commercial
> compilers for sale. .net requires the use of C# IIRC. So what is your
> definition of an archaic language. If it is by date of origin then lisp
> is more archaic than any of them.
So what? What is there in Java, that represents results of recent works?
If Java follows basically Oberon and Ada way (static object system), this
makes it 1980 technology, even if you consider it perfect.
Do you remember what year is out there?
>> Lisp and other languages are on-topic to the extent they are
>> referenced in this thread.
>
> Well you are entitled to your own opinion but I fail to see how
> arguing that someone should be using lisp helps with solving a forth
> problem
You could re-read the thread another time, instead you insist that
compile time warnings don't make good way to protect you from writing
your program incorrectly. Look at SBCL, it gives you hints that
something may be wrong, even though you're still allowed to continue
your way. Denying facts doesn't make you smart.
>> It would do no harm, if forthers learn how their nominal goals are
>> achieved in other environments.
>
> I am aware of that, I have used Basic, assembler and Pascal as well as
> forth. I am sure that most of the other people in this group have also
> used multiple languages.
The wide variety of used languages shows up. You've missed almost everything:
you've missed explicit type system of Ada with its separate integer types,
you've missed interactive systems of Lisp and Smalltalk, you don't know
what type inference is and how useful it may be. Of course, if your
experience is limited to teaching variant of FORTRAN, teaching variant
of Algol, and humanized representation of machine code, you're doomed to
repeat the same stupid argument that pops up again and again.
Get out of 1970s, the world has changed since then.
>> it is simpler, it provides
>> better interactive tools, it provides better compilers,
>
> I am unsure how you can say it is simpler when you apparently have no
> knowledge of forth, not that I can or would claim the lisp is more
> complex as I have done no more than looked at lisp source.
This made me laugh. The variety of languages you used shows up again.
Have you ever tried writing code?
> As for your
> claim about development tools have you actually used all available forth
> development systems. Besides development tools are not specific to a
> language. Borland and Microsoft use the same IDE for multiple languages.
All hail Emacs, the ultimate IDE for any and every language.
It is pretty hard to explain what interactivity really is and benefits of it
to a man, whose experience is bounded above by Borland-style environment.
--
HE CE3OH...