http://members.talkamerica.net/douglas...@talkamerica.net/
Download file: neon+.zip
If you have difficulty accessing the file send me an e-mail and I will
provide it directly.
Neon+ is a "minimalist" implementation of the Neon-like ANS Forth
objects extensions. It is the simplest Neon-like extension yet with only
eleven user words. It is also the fastest ANS object extension available
due to an improved method dispatch mechanism.
Many Forth programmers prefer extensions that provide just the basic
building blocks rather than extra support definitions and syntactic
sugar. It is that recognition and philosophy that led to the creation of
Neon+. Advantages of the simplification include code that is more easily
understood and thus easier to customize, and is smaller. Also, when
simplifying this extension it became apparent that a further significant
speedup could be achieved and that has been incorporated.
How fast is it? Using an example snippet of test code:
17.8 sec Objects vs 3.78 sec Neon+ Gforth 0.6.2 P4 Win XP
7.30 sec Objects vs 1.17 sec Neon+ VFX demo v4.10 P4 Win XP
11.3 sec Objects vs 4.02 sec Neon+ Carbon MacForth v6.05 PPC OSX
22.3 sec SWOOP SwiftForth demo v2.2.2.9 P4 Win XP
Using just a late binding test:
3.32 sec Objects vs 1.41 sec Neon+ Gforth
0.84 sec Objects vs 0.45 sec Neon+ VFX
2.46 sec Objects vs 1.93 sec Neon+ Carbon MacForth
4.66 sec SWOOP SwiftForth
Using just an early binding test:
2.46 sec Objects vs 1.03 sec Neon+ Gforth
0.25 sec Objects vs 0.26 sec Neon+ VFX
1.49 sec Objects vs 1.61 sec Neon+ Carbon MacForth
0.53 sec SWOOP SwiftForth
All test code used is supplied in the download.
-Doug
Cool, I think I'm gonna look into adopting this. Though I have my
doubts about the syntax of the instance variable accessor 'addr:' ...
I am curious about trying out a different syntax of '->' ...
But you still have my vote for "definitely an improvement over
Objects"... thank you for contributing this.
Thanks,
-- Trey
> Unfortunately, Google has mangled what looks to it like an email
> address, making the address unusable. Can you re-post it, perhaps
> with a little mangling of your own?
The "..." has to be replaced with the rest of his last name -- that
makes it work for me.
> -- Trey
-Wm
Billy has it right. Replace "..." with "man"
For me Google will unmangle an address or URL only when I sign in to
Google with my Google userID and pw. Or something like that.
-Doug
> Cool, I think I'm gonna look into adopting this. Though I have my
> doubts about the syntax of the instance variable accessor 'addr:' ...
There are alternatives. One could also use an embedded object instead of
the ivar primitive. e.g.:
:class var <super object
cell bytes data
:m !: ( n -- ) self ! ;m
:m +: ( n -- ) self +! ;m
:m @: ( -- n ) self @ ;m
;class
Then declare the ivar n as "var n" instead of "cell bytes n". So instead
of sending the addr: message one could send the @: and +: messages
directly to n. The speed change will be imperceptible or very small.
> I am curious about trying out a different syntax of '->' ...
That could likely be made to work just fine.
> But you still have my vote for "definitely an improvement over
> Objects"... thank you for contributing this.
You're welcome.
-Doug
Doug, what would you suggest is the best way to go about querying the
ivars of objects during debugging? Are accessors the ONLY legal way
from the factory?
I actually presumed addr: was the way to go about it but after
learning how this really works, I see you did a great job in securing
the blackbox-ness of things ... but, now I feel a '->' would be nice,
even if it were only to be used during interpret mode to debug. (I'd
write one myself already but I have no idea how to go about it ...
clue maybe?)
Roger
>
> Doug, what would you suggest is the best way to go about querying the
> ivars of objects during debugging? Are accessors the ONLY legal way
> from the factory?
Short answer is yes.
But there is a technique I often use just during the debugging phase of
writing a new class. Ivars can be declared outside of a class
definition and they become public objects. For example:
var a
var b
var c
:class test <super object
...
;class
When done just cut and paste a, b, and c back inside the class
definition and they become ivars.
> I actually presumed addr: was the way to go about it but after
> learning how this really works, I see you did a great job in securing
> the blackbox-ness of things ... but, now I feel a '->' would be nice,
> even if it were only to be used during interpret mode to debug. (I'd
> write one myself already but I have no idea how to go about it ...
> clue maybe?)
I think the simplest/easiest way is what I show above. But often I have
accessor methods already defined as a permanent part of the class, in
which case access is a moot point. But hey, this is Forth and anything
can be done. Without getting into the details, something like your
arrow has already been implemented in PowerMops (that required a slight
change to the compiler/interpreter).
-Doug
Huh?? I would have never guessed!
I'm a little confused now!
How do they know where they are in the object's structure??? I mean,
without knowing the superclass's size ...?
You recompile.
Let's make sure you understand what I am saying.
Consider:
var a
var b
var c
:class test <super object
:m foo: ( -- n) @: a @: b @: c + + ;m
;class
test myobj
foo: myobj .
\ myobj works as it should and you can easily access a, b, and c
independently for debugging:
@: a .
25 !: a
@: b .
@: c .
Once satisfied that class test works as it should, then simply cut and
paste:
:class test <super object
var a
var b
var c
:m foo: ( -- n) @: a @: b @: c + + ;m
;class
Now a, b, and c are "protected" ivar data inside objects of class test.
e.g., @: a will result in an error "a undef object"
This is a toy example for illustration only. It does nothing useful.
-Doug
oh. I think I see. They are not actually in the class at all,
therefore you can't really query ivars but just isolated vars. When
you said you can define *I*vars, I thought "instance"vars, but really
they are just disembodied "vars".
very very interesting... I may give it a trial before I resort to '-
>'.
Roger
I am very interrested by your neon+.zip but neither Safari nor Firefox are
abble to find
your http://members.talkamerica.net/douglas...@talkamerica.net/
Thanks for help. Jean.
Le 13/01/09 16:06, dans 811e5$496cae16$c4b2b95$42...@DIALUPUSA.NET, « Doug
Hoffman » <dhof...@talkamerica.net> a écrit :
> oh. I think I see. They are not actually in the class at all,
> therefore you can't really query ivars but just isolated vars.
Precisely!
> When you said you can define *I*vars, I thought "instance"vars, but
> really they are just disembodied "vars".
Yes, or normal (public) objects of class var. Sorry that I confused
you, but I see you've got it figured out now.
-Doug
getting a network error using network 3 mobile internet uk. E-mail
jackokring -at- gmail.com
Would it be ok to include this in a gforth ec port?
cheers jacko
> getting a network error using network 3 mobile internet uk. E-mail
> jackokring -at- gmail.com
It's on its way.
> Would it be ok to include this in a gforth ec port?
Sure. No problem. I intended this for wide distribution. That way I
get more useful feedback.
-Doug
> cheers jacko
Hi Doug, I agree, Firefox is giving a network error, saying:
-------
Firefox can't establish a connection to the server at
members.talkamerica.net.
Though the site seems valid, the browser was unable to establish a
connection.
-------
Cheers, Mike.
---------------------------------------------------------------
Mike Hore mike_h...@OVE.invalid.aapt.net.au
---------------------------------------------------------------
Whereas my Firefox 3.0.5 (Macintosh OS X 10.5.6) connects just
fine!
Was something fixed in the meantime?
-- David
No:
$ ftp -o - http://members.talkamerica.net/douglas...@talkamerica.net/
ftp: Can't connect to `216.126.205.3:80': Connection refused
ftp: Can't connect to `members.talkamerica.net:http'
$ nmap -sT members.talkamerica.net
Starting Nmap 4.76 ( http://nmap.org ) at 2009-01-22 20:45 MSK
Interesting ports on members.safepages.com (216.126.205.3):
Not shown: 996 closed ports
PORT STATE SERVICE
25/tcp filtered smtp
53/tcp filtered domain
445/tcp filtered microsoft-ds
1720/tcp filtered H.323/Q.931
Nmap done: 1 IP address (1 host up) scanned in 30.69 seconds
--
HE CE3OH...
Another couple of data points:
I have no trouble reaching it with either Iceweasel 3.05 (the Debian
version of Firefox [don't ask]) or Konqueror 3.59 (the KDE 3.5 browser).
cgm