Strange look&feel of DNG.
HandleX
Why icons draws without alpha and text goes out of tab borders?
DNG takes the job of control's drawing to himself? Why not to give
this hard work to windows himself?
Strange way...
![Frank Lesser [LSW]'s profile photo](http://lh3.googleusercontent.com/a-/ALV-UjUIqZkqFlNkSue6wOJ5mUFxwgueezZ76YrkIgDe-KTG8h7jBg=s40-c)
Frank Lesser [LSW]
it is done by windows.
DNG as Dolphin uses Windows & do not bitblt as some other Smalltalks.
There is still a glitch in adjusting the thing.
"HandleX" <ale...@mail.ru> schrieb im Newsbeitrag
news:592279a0-b609-41e7...@l13g2000yqb.googlegroups.com...
Udo Schneider
> DNG as Dolphin uses Windows & do not bitblt as some other Smalltalks.
> There is still a glitch in adjusting the thing.
[...]
License-Holders of DNG round 0 will receive a one year support of the
DNG-VM & updates of the Dolphin compatibililty environment & the
expresso framework
[...]
and
[...]
Our DNG-Beta is available to start migration.
[...]
So who do I have to bribe/pay to get that? :-)
CU,
Udo
Dmitry Zamotkin
I'm interesting in DNG too, but not ready to buy a pig in a poke yet.
Travis Kay
wrote:
I would be nice, I for one feel alienated .. with several unanswered
questions, both public and private. I do want to know what my options
are.
>
> CU,
>
> Udo
Travis Kay
Agreed.
Christopher J. Demers
I am certainly not in a position to begin migrating to DNG at this
point. I would have loved to have had a chance to participate in some
beta program where I may have gained enough confidence in DNG to want to
migrate to it. It does not seem like that is an option. I also see no
price or purchase link on the website. Why?
I feel like Dolphin Smalltalk was very well marketed, and had a lot of
community involvement and support. Unfortunately it was not a
commercially viable endeavor, hence the situation we are now in. If DNG
is going to be marketed poorly, and tend to avoid community involvement
in its evolution then I can't see how it will be any more commercially
successful.
This isn't _just_ about the technology. Sure, the technology needs to
work well. But, I also need to believe that the product I would be
migrating to will be commercially viable in the future. Dolphin still
runs fine. I need to believe that DNG will really have a better future
than Dolphin before I can consider migrating to it.
I still really hope that DNG can overcome my concerns and become a great
and successful platform.
Chris
Shaping
When can we expect a 64-bit VM for DNG?
Shaping
Frank Lesser [LSW]
we cant give a date yet - we plan to resume that work after DNG has been
released.
There was a demo 64 Bit VM a few years back for LSWVST.
Frank
And to all others - we are working on DNG. Starting to port today with the
restrictions we have in the current beta ( by purchasing the current beta )
is possible.
"Shaping" <sha...@bigfoot.com> schrieb im Newsbeitrag
news:SK6Lm.114$kY...@newsfe01.iad...
Udo Schneider
> And to all others - we are working on DNG. Starting to port today with the
> restrictions we have in the current beta ( by purchasing the current beta )
> is possible.
How to purchase?
Best Regards,
Udo
Snorik
How about pricing?
How about getting access to bugfixes and updates?
Travis Kay
software.com> wrote:
> Hi Shaping,
>
> we cant give a date yet - we plan to resume that work after DNG has been
> released.
> There was a demo 64 Bit VM a few years back for LSWVST.
>
> Frank
>
> And to all others - we are working on DNG. Starting to port today with the
> restrictions we have in the current beta ( by purchasing the current beta )
> is possible.
Frank, please, you have to be much more prepared and transparent in
this process.
Where is DNG roadmap?
What does your pricing model look like?
What does the current beta consist of?
How can we purchase the current beta?
By the way Alejandro's DNG portal / wiki has been down for days and
dng.st site hasn't been updated with information or content from the
workshop. Help us out here, you are losing credibility. I am also
suprised we've heard very little from Andy. I can understand it has
been long and hard work, I also want to see DNG and Dolphin be a
commercial success.
>
> "Shaping" <shap...@bigfoot.com> schrieb im Newsbeitragnews:SK6Lm.114$kY...@newsfe01.iad...
>
>
>
> > Hi Frank.
>
> > When can we expect a 64-bit VM for DNG?
>
> > Shaping- Hide quoted text -
>
> - Show quoted text -
Andy Bower
> By the way Alejandro's DNG portal / wiki has been down for days and
> dng.st site hasn't been updated with information or content from the
> workshop. Help us out here, you are losing credibility.
> I am also
> suprised we've heard very little from Andy. I can understand it has
> been long and hard work, I also want to see DNG and Dolphin be a
> commercial success.
Please understand that Object Arts is not actually involved with the
development of DNG. This is why I was not at the recent seminar in
Italy. We have an option to sell the final system when it becomes
available but it is really a Lesser Software product running Dolphin
frameworks and incorporating some innovative pieces of the VM.
> Where is DNG roadmap?
> What does your pricing model look like?
> What does the current beta consist of?
> How can we purchase the current beta?
I do know that Frank and Ale made the decision early on to conduct
alpha/beta testing of DNG under NDA with their prospective customers. I
must admit that I disagreed with this approach (mainly because it causes
the sort of frustration being vented here and in other forums). However,
I believe there are already a number of alpha testers of the product and
they have been there since the early days; it's just that they are not
allowed to talk about it! I suspect this is also why there are no
customer reports published from the recent workshop.
If you genuinely want to purchase the DNG beta and are willing to sign
an NDA not to discuss the product or pricing with others then I think
that sending an e-mail to Frank should be enough to get the ball rolling.
Best regards
Andy Bower
dcoro...@gmail.com
it works great. Working many years on it I can say it is my own
Smalltalk and is not important what OA do, my Smalltalk is better than
theirs :-). In the middle or long term what I would like to have form
OA is a 64bits VM, with a bigger OT, that's all. I think that Andy
could recompile current version for 64 bits and some of us will pay
again the license. Please consider having a D6-64 bits version before
DNG release.
I think OA closed Dolphin with the wrong perception that Microsoft
would succeded in forcing the community to CLR. It never happened, and
like Vista, Microsoft went back to its roots. It can be seen in the
current SDKs, they where intended for .NET and latter there are COM or
winapi. CLR will still alive for many years, but wont be the only way
to build software, it is clear now, and it wasnt clear last year. It
remembers me when Microsoft pretended to compite with Internet with
MicrosoftNetwork, and they finally understood it. Windows7 is more
like WinXP, security where redefined and it seems that the managed
code is going to be less important in the future. We all got scared
with Microsoft plans, but they failed, and now plans are others. There
is a long way ahead for Dolphin6, like it was with VS, and in this
case, luckily nobody wants to kill Dolphin. And even better, there is
a site to buy it!
Knowing that Ale, Frank and Andy are working together es great. I only
know Ale and IMHO is the best man I know to write a great Smalltalk
image, and I'am sure he is doing exactly that. Prices, versions, dates
and all that is important but I prefer to consider the good facts:
- The best Smalltalk ever produced is yet to come.
- A great product like Dolphin is still alive, and at least in my PC,
very healthy.
Travis Kay
> If you genuinely want to purchase the DNG beta and are willing to sign
> an NDA not to discuss the product or pricing with others then I think
> that sending an e-mail to Frank should be enough to get the ball rolling.
I signed the NDA and asked questions back in September. I understand
Object Arts position, and it's clear that DNG is intended for Frank's
existing customers. Thank you for responding Andy.
>
> Andy Bower
Travis Kay
wrote:
I agree with your general sentiment and I'm happy to continue using
Dolphin, where I am, as is. I'm still very grateful to have it as an
option.
Andy Bower
> In the middle or long term what I would like to have form
> OA is a 64bits VM, with a bigger OT, that's all. I think that Andy
> could recompile current version for 64 bits and some of us will pay
> again the license. Please consider having a D6-64 bits version before
> DNG release.
Okay, this is a good idea. I don't think it is simply a matter of a
recompile since much of the VM is coded in assembler. However, it might
be possible to persuade Blair to "come out of retirement" on a contract
basis to create a 64 bit Dolphin VM.
So the question to all Dolphin Users is, how many people would be
interested in paying for such a version and at what cost? If you are
interested in a 64 bit release of Dolphin 6.1 (final) please e-mail me
with the following:
DPRO->Dolphin64, I would be prepared to pay an upgrade price of:
(a) $200
(b) $500
(c) $1000
Don't just check one price but all that you would be prepared to pay if
D64 was available at that price. That way I can work out what demand
there is and what price could be charged and what to offer Blair for the
work. I'll let you know the results in a week or so.
Best regards
Andy Bower
Object Arts Ltd
Louis Sumberg
It's so good to see your postings -- as always, thoughtful, reflective,
informative.
Just yesterday, I spent hours trying to figure out a problem I was
having with another product that has its own scripting language. I
finally started up Dolphin, wrote some code in a workspace, looked
around the image for some methods that might help, found a method
written by Steve Waring (I swear his code will live forever), and voila,
I found the problem and figured out the solution. Just one example of
how Dolphin is still very much alive in this house. And that is along
with many Dolphin apps I regularly use (on a daily basis), and others I
am still working on.
It's unclear to me what a 64-bit version would offer, other than being
able to deal with larger amounts of data (in files or memory) and
possibly more speed. For me, those are not an issue, and as for
compatibility with a 64-bit OS, I've been running D6 Pro under Vista
(excuse me for a moment while I barf), it runs great, and I have every
reason to think it works fine on Windows 7.
I realize that Frank said the initial DNG will be 32-bit, but still,
there's the issue of paying for this upgrade being considered AND paying
for DNG, if it offers anything useful above that currently provided by
D6. While Frank's postings have been nice to see, they have been very
technical, essentially Greek to me so I don't understand how I would
benefit, and the whole project could have been managed/marketed better,
without these occasional glimpses into the shroud of secrecy. The
recent comment about DNG being targeted at Lesser Software's existing
base certainly makes me feel disenfranchised.
Warm regards,
-- Louis
IanB
>It's unclear to me what a 64-bit version would offer, other than being
>able to deal with larger amounts of data (in files or memory) and
>possibly more speed.
I was wondering the same thing.
I moved over to 64-bit with Windows 7 (yes Louis, Dolphin 6 runs with
no problems) but it's difficult for me (from a users point of view) to
see any major advantages it might bring to Dolphin.
I suppose the increase in addressable memory might mean a larger
number of objects can be created, and less GC. I can't think of much
else though....
Ian
--
The From address is valid
Andreas Wacknitz
> Hi Andy,
>
> It's so good to see your postings -- as always, thoughtful, reflective,
> informative.
>
> Just yesterday, I spent hours trying to figure out a problem I was
> having with another product that has its own scripting language. I
> finally started up Dolphin, wrote some code in a workspace, looked
> around the image for some methods that might help, found a method
> written by Steve Waring (I swear his code will live forever), and voila,
> I found the problem and figured out the solution. Just one example of
> how Dolphin is still very much alive in this house. And that is along
> with many Dolphin apps I regularly use (on a daily basis), and others I
> am still working on.
>
> It's unclear to me what a 64-bit version would offer, other than being
> able to deal with larger amounts of data (in files or memory) and
> possibly more speed. For me, those are not an issue, and as for
> compatibility with a 64-bit OS, I've been running D6 Pro under Vista
> (excuse me for a moment while I barf), it runs great, and I have every
> reason to think it works fine on Windows 7.
>
> I realize that Frank said the initial DNG will be 32-bit, but still,
> there's the issue of paying for this upgrade being considered AND paying
> for DNG, if it offers anything useful above that currently provided by
> D6. While Frank's postings have been nice to see, they have been very
> technical, essentially Greek to me so I don't understand how I would
> benefit, and the whole project could have been managed/marketed better,
talks IMO a lot about the price you will have to expect.
DNG seems to focus on old VSE customers and and not old Dolphin customers.
So a 64 Bit version of Dolphin 6.1 would be a modernization for an
affordable price.
But as the DNG prices aren't open (yet?) many might be reluctant to go
for Andy's offer and expect to buy DNG instead.
> without these occasional glimpses into the shroud of secrecy. The
> recent comment about DNG being targeted at Lesser Software's existing
> base certainly makes me feel disenfranchised.
>
> Warm regards,
>
> -- Louis
Andreas
Guido Stepken
64 Bit means much more memory consumption, memory pumping effects
(allocation - garbagecollecting) and waste of RAM bandwidth, CPU time.
On the other side ... to program smalltalk applications, which don't fit
into 4 gig ... you either should give up your profession or you haven't
really understood persistence and OO-databases ;-)
Compared to JAVA applications ... hmmm ... there a "function point" uses
a much bigger memory footprint, that you run out of adress space very
quickly!
Have fun, regards, Guido Stepken
rush
benefit of 64bit VM over short term, let's say a year or two. But in
short term, I woul _REALY_ like to see Seaside port finished with
continuations, and whole seaside set of web utils (class browser,
inspectro hallo's etc).
geoff
> able to deal with larger amounts of data (in files or memory) and possibly
> more speed.
If the VM has to garbage collect on a 64-bit address space, I doubt one
would see a speed increase.
--g
HandleX
> Okay, this is a good idea. I don't think it is simply a matter of a
> recompile since much of the VM is coded in assembler. However, it might
> be possible to persuade Blair to "come out of retirement" on a contract
> basis to create a 64 bit Dolphin VM.
bit platform.
How about using LLVM (http://llvm.org)?
There is some good things doing so:
1) LLVM can execute its Intermidiate Representation in interpreting
mode;
2) LLVM can compile Intermidiate Representation into native processor
instruction sets -- 32 or 64 bit;
4) LLVM can use vectors (SIMD operations);
3) LLVM can optimize instructions better than human.
VM build using LLVM can:
1) execute first run of the method in interpereting mode, doing job of
native compiling in background;
2) be much faster executing native processor instructions;
3) have code base for 32- and 64-bit platforms with minimal changes.
4) can execute old images (old Smalltalk bytecodes) frough some
compativility layer giving these omages all benefits of native code
executing.
Andy Bower
>> I realize that Frank said the initial DNG will be 32-bit, but still,
>> there's the issue of paying for this upgrade being considered AND
>> paying for DNG, if it offers anything useful above that currently
>> provided by D6. While Frank's postings have been nice to see, they
>> have been very technical, essentially Greek to me so I don't
>> understand how I would benefit, and the whole project could have been
>> managed/marketed better,
> Frank and Ale are quite silent about prices and ask for an NDA - that
> talks IMO a lot about the price you will have to expect.
> DNG seems to focus on old VSE customers and and not old Dolphin customers.
> So a 64 Bit version of Dolphin 6.1 would be a modernization for an
> affordable price.
I think this is essentially the point. I can't really tell you about
prices for DNG, partly because I am also under NDA and partly because
last time talked to Frank and Ale about it no final decision had been taken.
One thing I should mention (and this follows on from Andreas' reply) is
that DNG has always been seen as a commercial project where minimal risk
would be taken, i.e. it must be initially sold at a price that at least
covers development costs. If you do some simple maths as to how much
development effort has so far been expended and what the likely take up
might be you might arrive at a ball-park figure for license costs.
Regarding the benefits of 64 bit, from the Cincom VisualWorks roadmap:
"64 bit addressability gives the ability to support many more objects in
memory is the primary benefit. Other benefits include much larger
SmallIntegers...".
http://www.cincomsmalltalk.com/userblogs/cincom/blogView?content=roadmap
So, in terms of practical benefit, I think the memory addressability is
probably the major plus. Speed is probably likely to be better in some
areas (integer arithmetic) and worse in others (garbage collection) so
I'm not sure what the overall gain would be, at least initially.
But I think the real key point is, as Andreas points out, modernization.
Windows 7 is really the first Windows OS where 64 bit versions are
liable to be installed en mass. After a time, 64 bit will become the de
facto installation and eventually I suspect that 32 bit apps will start
to be seen as rather old fashioned and quirky. The worry is that lack of
64 bit will become another check box left empty on some management
comparison of potential development tools.
For example a comparison to 16 bit Smalltalk Express and 32 bit Visual
Smalltalk Enterprise might be helpful. The former disappeared from
common a long time ago but VSE is only now starting to look too tired to
continue with even though it has not received an update for over ten years.
Best regards
Andy Bower
Andy Bower
> How about using LLVM (http://llvm.org)?
Whilst that link to LLVM looks interesting I think you have to take on
board that we are talking about a minimal port to update the current VM
rather than a complete rewrite.
Best regards
Andy Bower
Shaping
> Regarding the benefits of 64 bit, from the Cincom VisualWorks roadmap: "64
> bit addressability gives the ability to support many more objects in
> memory is the primary benefit. Other benefits include much larger
> SmallIntegers...".
Yes, and Double floating-point, as well.
>
> http://www.cincomsmalltalk.com/userblogs/cincom/blogView?content=roadmap
>
> So, in terms of practical benefit, I think the memory addressability is
> probably the major plus. Speed is probably likely to be better in some
> areas (integer arithmetic) and worse in others (garbage collection) so I'm
> not sure what the overall gain would be, at least initially.
>
> But I think the real key point is, as Andreas points out, modernization.
> Windows 7 is really the first Windows OS where 64 bit versions are liable
> to be installed en mass. After a time, 64 bit will become the de facto
> installation and eventually I suspect that 32 bit apps will start to be
> seen as rather old fashioned and quirky. The worry is that lack of 64 bit
> will become another check box left empty on some management comparison of
> potential development tools.
Exactly. Those "check boxes" really matter to those in management, making
or breaking the purchase decision.
Deliver the 64-bit VM now.
My application can easily use all of the 16 GB I have in my current machine.
I will be getting another machine with 32 GB, in the next six months. I
intend to use all of this memory, too. A database would be too slow, except
for cold persistence of the app's model following shutdown of the app. All
objects must be live for the application run at acceptable speeds.
Shaping
dcoro...@gmail.com
it could have, I can image some others than the ones described. But in
5 or 10 years it will be a must. I went from 8 to 16 bits, then form
16 to 32 and it always seems to be enough until is not.
The fact here is that there is an uncertain future about Dolphin
today, we don't know if Andy and Blair will be responding emails in
five years. My projects will be alive in five years and one of the
most important things about Smalltalk is that time doesnt pass in the
same way than in others development tools. Today there are excellent
systems made in VisualSmalltalk, decades ago, they don't look old and
they could not be constructed today with Java/.NET/Ruby/whatever.
I beleive DNG will be "the Smalltalk of the future" but we don't know
yet if we are the comercial target for that project (I guess we will).
I will like to have more options in the future, more VMs is better for
everyone. I also beleive (only beleive) the OA is not full convinced
to discontinue Dolphin, so if we give OA some financial motivation
(small I guess) I think we all have benefits. It will be good to know
that Andy and/or Blair have their hands on Dolphin again.
I also think that Dolphin could still be a sucesfull project some day
if OA doesnt repeat Digitalk errors. As users we can't ask OA to
invest time, but I would ask them to keep the product in the current
state many years more. Selling it, avoiding negative announcement that
scares our clients and possible new users. There is an active
community that is going to update the product at its own times, and
that will be enough.
Diego Coronel
Louis Sumberg
and compelling arguments for action and patience.
-- Louis
Guido Stepken
> My application can easily use all of the 16 GB I have in my current
> machine. I will be getting another machine with 32 GB, in the next six
> months. I intend to use all of this memory, too. A database would be
> too slow, except for cold persistence of the app's model following
> shutdown of the app. All objects must be live for the application run
> at acceptable speeds.
>
>
> Shaping
What the hell are you doing? Controlling all traffic lights in NY realtime?
regards, Guido Stepken
Gavin Scott
> Please understand that Object Arts is not actually involved with the
> development of DNG.
Dang, sorry to hear that.
I've been a casual user of D6 (Pro) for almost three years now and have
greatly enjoyed it as probably the nicest ST implementaiton I've used.
I've been following the progress with the hope that DNG might turn
into a useful tool that I could make use of somewhere, but at the
moment everything suggests that whatever the market for DNG is, I
probably won't fit into it.
So, one less group to follow.
Thanks to andy & company for a really cool tool, and best of luck to
DNG and you all in the future.
Fortunately Pharo is actually starting to look like it might turn
into something worthwhile.
Cheers,
G.
Shaping
news:hdsoa0$tl0$01$1...@news.t-online.com...
...scalable discrete math-modeling. The limiting resource is actually the
number of cores, not memory, but lots of memory is necessary too. A better
balance of resources will likely turn out to involve Infiniband-networked
boxes, each with lots of cores, and considerably less than the maximum
amount of system memory installed (but still lots).
Just as importantly and more immediately, I'm looking forward to being able
to start several OS processes, each with only one thread (for now), in a
single image. If I understand what Frank has done, this is possible now
with the 32-bit VM. I very much want to see more details on how to set-up
asynchronously communicating Smalltalk processes running on separate OS
processes (not the traditional, time-slice-allocated green threads that we
currently associate with a Smalltalk process).
Shaping
Andy Bower
> So the question to all Dolphin Users is, how many people would be
> interested in paying for such a version and at what cost? If you are
> interested in a 64 bit release of Dolphin 6.1 (final) please e-mail me
> with the following:
>
> DPRO->Dolphin64, I would be prepared to pay an upgrade price of:
>
> (a) $200
> (b) $500
> (c) $1000
>
> Don't just check one price but all that you would be prepared to pay if
> D64 was available at that price. That way I can work out what demand
> there is and what price could be charged and what to offer Blair for the
> work. I'll let you know the results in a week or so.
I had been rather disappointed at the low response to this poll so I
decided to check my spam box. I pass the OA mail box through GMail to
use their spam filter, which normally works really well (removing over
100 junk e-mails a day on average). Anyway, imagine my surprise when I
found a further 6 e-mails on this subject had been consumed by the GMail
spam filter.
I don't know whether there is something porno about the phrase "64 bit
VM" which is causing these e-mails to be targetted but, if anyone wants
to add their reply to the list, perhaps you should choose a different
subject line, say "New Version of Dolphin Smalltalk".
Best regards
Andy Bower
Udo Schneider
> DPRO->Dolphin64, I would be prepared to pay an upgrade price of:
>
> (a) $200
> (b) $500
> (c) $1000
Let's make a deal:
* Provide a (Windows 7 compatible) 32 and 64 bit VM
* Include the essential goodies within the distribution (not
neccesarily in the image - simply in the folder(s) would be enough)
* Host a public OA STS Server
* Call the whole package Dolphin 7 and sell it for (at least) the
regular price. You could even split it into two packages
- 32bit only for �500
- 32+64 bit for �750
The numbers (475 vs 500) didn't really change - however having the
prices in � might give you some uplift as well ;-)
Just some thoughts.
CU,
Udo
Udo Schneider
> - 32bit only for �500
> - 32+64 bit for �750
I forgot: These are of course (at least) the price I'd be willing to pay.
CU,
Udo
Andreas Wacknitz
a 64 Bit version would justify a new major version number. On the other
hand version numbers seem to be arbitrary anyways...
I think a public STS server hosting open source goodies is desparately
needed for Dolphin. Error corrections and enhancements would also be
nice on this repository.
I have the impression that many Dolphin customers are disappointed about
how Dolphin Smalltalk evolves. It's mostly not about functionality but
the uncertain future that prevents it from being considered as an
environment for (new) development. In my case I have real difficulties
to convince a friend to buy a license. He always states: it's a nice
product but it is dead.
Producing a 64 Bit version would be helpful but probably not enough: He
also complains that Dolphin is a one-man-show. So an open repository and
an re-vitalized community would be really good...
Andreas
Shaping
it carefully. I see that you mean the entire price of the new DNG. I
thought we were talking about only the cost the 64-bit version after we have
paid for the normal price for the 32-bit version (whatever that is). In any
case, I will pay as much as $1000.
Shaping
"Andreas Wacknitz" <a.wac...@gmx.de> wrote in message
news:7mgao4F...@mid.individual.net...
ZuLuuuuuu
wrote:
> - 32bit only for €500
Why increase the price of classic 32-bit version, especially after a -
somewhat- competitor product comes out?
Udo Schneider
>
> Why increase the price of classic 32-bit version, especially after a -
> somewhat- competitor product comes out?
even with DNG in place. But you're right - changing the number from 475
to 500 and the currency is quite a step.
I'm not so sure about competition: Yes, in some regards DNG will be a
competitor (as VW and VAST are today) ... however I have the feeling
that the associated price will be in a totally different ballpark than
what we are used to today.
CU,
Udo
Udo Schneider
> Andy, I recently responded to this, and just now realize that I did not
> read it carefully. I see that you mean the entire price of the new
> DNG. I thought we were talking about only the cost the 64-bit version
> after we have paid for the normal price for the 32-bit version (whatever
> that is). In any case, I will pay as much as $1000.
just with a 64bit VM.
@Andy: Could you please clarify? Otherwise this thread might not be
usefull at all :-(
CU,
Udo
Guido Stepken
http://www.refactory.com/Software/SharpSmalltalk/Implementation.html
As one can see, .NET till version 3 does not fully support dynamic
languages, like S#, F#, Python# Ruby# ..., so the developers have
stopped their effords, like Frank Lesser did with his LSWST and .NET 1.0
bindings.
Strange enough, Microsoft has hired some Smalltalk freaks, who - i am
quite sure about that - had their influence on .NET V 4.0:
http://www.microsoft.com/germany/net/Microsoft%20.NET%20Roadmap.aspx
S# on .NET 4.0, full integration into microsofts .NET language park,
full support for dynamic languages, 64 Bit, Jitter, well known framework ...
And with Windows 8 Microsoft will kill all win32 libraries ... as they
are still in Windows 7 ... Why? One strike kills them all! Linux/Wine,
Cincom, ...
When that happens, decision makers will perhaps switch over to S# ...
regards, Guido Stepken
Andy Bower
Okay, sorry for the confusion, I'll attempt to clarify things here.
First of all, the 64 bit VM version of Dolphin we are talking about here
is nothing to do with DNG. Let me explain:
DNG
DNG is not an Object Arts product although it is endorsed by us. At some
point DNG *may* be sold by us as an addition to the current product
line. As I understand it DNG will be a high performance, cutting edge
Smalltalk running Dolphin frameworks. Initially, DNG will be offered as
32 bit only but the capability is there to produce a 64 bit version in
future (and possibly even Linux/Mac versions too).
However, there are a number of reasons why existing (and new) Dolphin
users might wish to stay with the current (OA) products rather than
moving to DNG. One of these reasons *may* be price. It is difficult to
speak in exact terms about this due to Frank's and Alejandro's decision
to only discuss DNG pricing and features under the cloak of an NDA. I
understand why they have chosen this route but, personally, I think it's
a mistake as it creates confusion and suspicion in the minds of
potential customers.
If you are curious as to whether you should stick with OA Dolphin in
future or plan for DNG then I urge you to contact Frank Lesser and
discuss the possibilities that DNG will offer. He will ask that you sign
an NDA but, after that, you should learn about pricing and projected
timescales.
D32 & D64
Let's call the existing product line using the OA interpretive VM, D32.
What we are talking about in this thread is an attempt to revitalize
this line by adding a 64 bit version, which we can call D64. Then OA
would have two products, D32 and D64. The new version will likely be
similar to the 6.1 beta with a few other features (along the lines that
Udo suggested earlier) and the twin 32/64 bit VMs. I think we'd call it
Dolphin 7.
What I am asking in this thread is how many people are interested in
such a move forward and how much are they willing to "pledge" to make it
happen. Since I am mostly likely "preaching to the choir" in that most
people reading this are already DPRO customers, the amounts we are
talking about are upgrade fees from the existing D6PRO32.
So I have asked existing users to choose the maximum amount you would
pledge to upgrade from D6PRO32 to a new package comprising D7PRO32 *and*
D7PRO64. To make it easier, I gave three possible options: $200, $500
and $1000. Some people may want to use the 64 bit version straightaway
but others may just be happy to pay an upgrade fee and use D7PRO32. That
way they would get some new features and bug fixes in D7 with the
additional security of knowing that a 64 bit VM is available when needed
in the future.
HOW THE PLEDGING WILL WORK
Note that, even if you "pledge" a maximum of $1000 for the upgrade, that
may not be the final amount you end up having to pay. The important
thing will be for us to find an amount that has sufficient respondents
to make the development worthwhile (in effect, to pay for the work).
Let's say that Blair judged that the 64 bit VM work should cost in the
region of $10,000 (as yet, I have no idea of this amount). If we have 30
pledges of $200, 20 of $500 and 12 of $1000 this would mean we could
finance the development work at either of the latter two price points.
We would then choose the lower ($500) and start development.
Pledgers would not be asked for the $500 upgrade fee until the new
version is complete (although perhaps a small "beta registration" fee to
join the beta programme might be requested to show good faith).
Once the final release is available it would then be offered to other
(non-pledging) users for at least the original pledgers upgrade fee
(i.e. at least $500). The intention is that there would be no
disadvantage to being an early adopter/pledger.
My aim was to makes thing clearer, however this post has turned out
rather longer than I'd expected, so I hope it hasn't ending up
increasing the confusion.
Andy Bower
> The biggest competitor of Dolphin IMHO will be:
> http://www.refactory.com/Software/SharpSmalltalk/Implementation.html
It's possible but you do realize that those S# pages are over 4 years
old. I'm not even sure whether The Refactory are working on S# any more.
> As one can see, .NET till version 3 does not fully support dynamic
> languages, like S#, F#, Python# Ruby# ..., so the developers have
> stopped their effords, like Frank Lesser did with his LSWST and .NET 1.0
> bindings.
>
> Strange enough, Microsoft has hired some Smalltalk freaks, who - i am
> quite sure about that - had their influence on .NET V 4.0:
>
> http://www.microsoft.com/germany/net/Microsoft%20.NET%20Roadmap.aspx
>
> S# on .NET 4.0, full integration into microsofts .NET language park,
> full support for dynamic languages, 64 Bit, Jitter, well known framework
> ...
To be honest this would be great. If (and I mean *if*) a performant S#
was made available under the existing license then we would be able to
port the Dolphin frameworks to this platform (hurrah!).
> And with Windows 8 Microsoft will kill all win32 libraries ... as they
> are still in Windows 7 ... Why? One strike kills them all! Linux/Wine,
> Cincom, ...
It's possible but unlikely. MS would have to be damn sure that at least
80% of existing Windows apps were written in .NET before trashing
Win32/64 (including Office, Direct3D, games etc). They are already
losing swathes of users to Mac and Linux and the only thing that really
keeps people on Windows is the existing application lock-in. If they
remove that then one-strike *frees* rather than kills all.
In any case, why would MS have any interest in killing Cincom? They have
a development tool that runs on Windows for heavens sake. And what's
worse, because of the portability aspect of VW, all of Cincom's
customers would have a direct, easy and forced route to Mac/Linux if
Windows was no longer an option.
To be honest, with Windows 7, I actually see a progression away from the
prospective dominance of .NET. I think MS have come to a realization
that there are still a lot of developers using raw (unmanaged) C++ and
they need to be supported rather than hindered. Take the recently
announced Direct2D for example:
http://msdn.microsoft.com/en-us/magazine/dd861344.aspx
Guido Stepken
> Guido,
>
>> The biggest competitor of Dolphin IMHO will be:
>> http://www.refactory.com/Software/SharpSmalltalk/Implementation.html
>
> It's possible but you do realize that those S# pages are over 4 years
> old. I'm not even sure whether The Refactory are working on S# any more.
They *had to stop* development after they realized, that the .NET VM
didn't fully support *full dynamic languages*. We'll wait, see, what
happens then after 4 years now ... from the strategic point of view it
fits perfect to Microsofts .NET 4.0
>> S# on .NET 4.0, full integration into microsofts .NET language park,
>> full support for dynamic languages, 64 Bit, Jitter, well known
>> framework ...
>
> To be honest this would be great. If (and I mean *if*) a performant S#
> was made available under the existing license then we would be able to
> port the Dolphin frameworks to this platform (hurrah!).
To be honest: Managers think in categories of PLM (product lifecycle
management) and strategic options. Performance, well ... who really
cares? Moore's law will compensate that ... the question a manager
interests, is: "Does it scale?". And thinking in "Business Process
Logica" ... Databases have to scale, they are the bottleneck.
Who ask for performance in the interpreter of e.g. SAP?
>> And with Windows 8 Microsoft will kill all win32 libraries ... as they
>> are still in Windows 7 ... Why? One strike kills them all! Linux/Wine,
>> Cincom, ...
>
> It's possible but unlikely. MS would have to be damn sure that at least
> 80% of existing Windows apps were written in .NET before trashing
> Win32/64 (including Office, Direct3D, games etc). They are already
> losing swathes of users to Mac and Linux and the only thing that really
> keeps people on Windows is the existing application lock-in. If they
> remove that then one-strike *frees* rather than kills all.
"Oops, i did it again!" Do you remember that day, when Microsoft dropped
ALPHA, PPC ... Windows NT support? This was a desaster for many, many
companies, who had just invested in DEC ALPHA Servers ...
From the strategic point of view, they will have to do that trick
again, soon, IMHO. Why? Microsoft is about to loose market shares
against OpenOffice. MS Office made the biggest part of MS income. And -
OpenOffice Framework compiles one source for Win32, Linux AND Mac. This
is a big threat! Nobody really noticed yet, how nice that framework is ;-)
> In any case, why would MS have any interest in killing Cincom? They have
> a development tool that runs on Windows for heavens sake. And what's
> worse, because of the portability aspect of VW, all of Cincom's
> customers would have a direct, easy and forced route to Mac/Linux if
> Windows was no longer an option.
No, of course MS is not interested in killing Cincom. Cincom and other
win32 - supporting companies will simply become a collateral damage in a
bigger war, Microsoft has to fight ...
> To be honest, with Windows 7, I actually see a progression away from the
> prospective dominance of .NET. I think MS have come to a realization
> that there are still a lot of developers using raw (unmanaged) C++ and
> they need to be supported rather than hindered. Take the recently
> announced Direct2D for example:
>
> http://msdn.microsoft.com/en-us/magazine/dd861344.aspx
Well, yes, i also see that. This trend will stop soon, IMHO. MS has
changed very much its strategy. They try now to consider more the
wishes/needs of smaller companies.
Regards, Guido Stepken
Don Rylander
We'd be willing to pay up to $1000. Of course, we're even more willing to
pay less. ;-)
> My aim was to makes thing clearer, however this post has turned out rather
> longer than I'd expected, so I hope it hasn't ending up increasing the
> confusion.
I for one am no more confused than usual for a Wednesday morning. I think
you've clarified it well. And if DNG ends up anywhere near as good as
Dolphin (and in our price range), we'll get that, too.
Thanks,
Don R
Andy Bower
>>> The biggest competitor of Dolphin IMHO will be:
>>> http://www.refactory.com/Software/SharpSmalltalk/Implementation.html
>>
>> It's possible but you do realize that those S# pages are over 4 years
>> old. I'm not even sure whether The Refactory are working on S# any more.
>
> They *had to stop* development after they realized, that the .NET VM
> didn't fully support *full dynamic languages*.
Hmmm... IIRC S# was created by Don Roberts and John Brant of Refactory
Inc. As witnessed by the fact that these are the same guys who created
the Refactoring Browser, they are quite obviously smart cookies. Do you
*really* think they didn't realize that the .NET VM didn't properly
support full dynamic languages until they were half way through the
development? I think you do them a disservice by even suggesting it. I
can't speak for them of course but it is more likely is that they
created S# purely as an experiment.
<much snipped>
> Well, yes, i also see that. This trend will stop soon, IMHO. MS has
> changed very much its strategy. They try now to consider more the
> wishes/needs of smaller companies.
I must admit I find some of your posts quite hard to follow, both here
and on c.l.s. What does helping small companies have to do with
scratching support for Win32/64?
I'm also confused as to your overall motivation. Are you a Smalltalk
advocate or not? I thought I remembered that at one point you were
working with Frank Lesser to promote LSWVST and DNG (I apologize if I
have got this wrong). If so, then surely spreading FUD (Fear,
Uncertainty and Doubt) about what Microsoft may or may not do is helping
no one in the various Smalltalk communities except possibly those that
run on non-Windows computers.
I'm not saying that anyone should bury their heads in the sand about
this but until Microsoft actually do what you say (or announce that they
are going to do this) the there is little point doom mongering about it.
Not only are you likely to be wrong but you just risk irrationally
pushing more Smalltalk users (potential or existing) into the sad world
of C#/Java etc.
Regards
Andy Bower
Udo Schneider
> I for one am no more confused than usual for a Wednesday morning. I
> think you've clarified it well. And if DNG ends up anywhere near as
> good as Dolphin (and in our price range), we'll get that, too.
I can only agree on the last point ("... get that, too."). I have
several apps "out in the field" (primarily in-house use based on DST6.1
- and yes, I do use the beta for regular deployments now :-) ). For me
the route to go would be to get DST7 which is as compatible as possible
to DST6 and use it to deploy apps w/o much thinking about compatibility.
And at the same time get DNG as well (if it's affordable) for new
versions/projects.
CU,
Udo
Don Rylander
"Udo Schneider" <Udo.Sc...@homeaddress.de> wrote in message
news:G6-dnRZJ25kjk5nW...@totallyobjects.com...
point (considering it's dependent on 2 not-quite-existent products!), but
Andy's always been good at doing what he's said he would do, and Dolphin
32/64 would be sufficient for the foreseeable future.
And, of course, having a supporting community that includes folks like you,
Ian Bartholomew, etc., helps immensely, especially for dilettantes like me.
Don R
>
> CU,
>
> Udo
John Brant
> Andy Bower schrieb:
>> Guido,
>>
>>> The biggest competitor of Dolphin IMHO will be:
>>> http://www.refactory.com/Software/SharpSmalltalk/Implementation.html
>>
>> It's possible but you do realize that those S# pages are over 4 years
>> old. I'm not even sure whether The Refactory are working on S# any more.
>
> They *had to stop* development after they realized, that the .NET VM
> didn't fully support *full dynamic languages*. We'll wait, see, what
> happens then after 4 years now ... from the strategic point of view it
> fits perfect to Microsofts .NET 4.0
There is some confusion here. S# and #Smalltalk are two different items.
S# was written by David Simmons. I wrote #Smalltalk (listed in the link
above). I haven't worked on it in several years. It was a project that I
worked on for a few months in my free time. Over the past several years,
I've had paying work, so I haven't done anything with it. While I can't
comment on S#, I can say that development on #Smalltalk wasn't stopped
due to .NET lack of support for dynamic languages.
From the little I've seen about the dynamic language support, I doubt
that it would help #Smalltalk much if any. The biggest problems with
#Smalltalk are: (1) no tag bit support in .NET so integers are really
slow, (2) non-local returns from blocks are even slower since they are
simulated with exceptions, and (3) it doesn't support the normal
Smalltalk incremental development model. With (1) and (2), #Smalltalk
times for larger benchmarks was similar Dolphin (faster than Squeak, but
slower than VW & VA). (3) could be fixed by adding some more execution
overhead, but I never got around to trying anything.
John Brant
Guido Stepken
I think the discussion here is not about proofing sb. either right or wrong.
The trick is to find out, out of what point of view a potential customer
might look on the strategies (mainly product lifecycle management) of
different software companies and their software development products.
The customer always has a choice, for or against a product.
I do not tend to oversee e.g. Andreas Wacker's article here from the
17th., where he writes:
"I have the impression that many Dolphin customers are disappointed
about how Dolphin Smalltalk evolves. It's mostly not about functionality
but the uncertain future that prevents it from being considered as an
environment for (new) development. In my case I have real difficulties
to convince a friend to buy a license. He always states: it's a nice
product but it is dead.
Producing a 64 Bit version would be helpful but probably not enough: He
also complains that Dolphin is a one-man-show. So an open repository and
an re-vitalized community would be really good..."
IMHO you don't take that serious enough. But perhaps you should. These
are your (probably former and perhaps future) customers.
regards, Guido Stepken
Andy Bower
> There is some confusion here. S# and #Smalltalk are two different items.
> S# was written by David Simmons.
Yes, sorry it was a momentary aberation to confuse the two.
Best regards
Andy Bower
Andy Bower
> The trick is to find out, out of what point of view a potential customer
> might look on the strategies (mainly product lifecycle management) of
> different software companies and their software development products.
> The customer always has a choice, for or against a product.
Of course, and the issue of "lifecycle management" has been one of
Smalltalk's (and I don't just mean Dolphin's) bugbears for over 10
years. That doesn't stop a dedicated band of followers who *know* how
productive it is and *know* it's technically the right thing to do from
continuing to use it.
Personally, I don't expect Smalltalk to to ever "win" over C# or Java or
whatever and, since 1997, I never did. Even in 1998 when, in one of our
baser moments, we scrawled "Java: you can't polish a turd" on the OOPSLA
noticeboard (in response to all the papers being presented on improving
Java with Smalltalk features), I never expected a majority revolt. It's
almost inconceivable this could have ever happened.
No, for Smalltalk developers the current holy grail must simply be that
we can continue to use our tool of choice to build great software. We
just need to maintain enough critical mass to allow Smalltalk to be
accepted in those companies where it can actually be allowed to realize
its potential.
> I do not tend to oversee e.g. Andreas Wacker's article here from the
> 17th., where he writes:
>
> "I have the impression that many Dolphin customers are disappointed
> about how Dolphin Smalltalk evolves. It's mostly not about functionality
> but the uncertain future that prevents it from being considered as an
> environment for (new) development. In my case I have real difficulties
> to convince a friend to buy a license. He always states: it's a nice
> product but it is dead.
> Producing a 64 Bit version would be helpful but probably not enough: He
> also complains that Dolphin is a one-man-show. So an open repository and
> an re-vitalized community would be really good..."
>
> IMHO you don't take that serious enough. But perhaps you should. These
> are your (probably former and perhaps future) customers.
Of course I take these comments seriously, what makes you think
otherwise? I can't do much about Object Arts being a 1.5 man band but we
(all of us here in this forum) can try and revitalized the community and
show that the product is still alive and well by creating new versions.
Trying to find a commercially viable way of doing this is what this
thread is all about.
rush
I must say that it is very nice to see OA's renewed push for Dolphin.
Regarding all price points I think they are fair, but unfortunately at
the moment I can not pledge for any amount. I think that if it gets
priced at $200 i would very likely buy it, at $500 it is likely that I
will buy it but it would probably take me some time to buy it, and at
$1000 I might postpone buy for a longer period.
And lastly, I know I might going to nerves since I am repeating this
like a parrot, I would really really like to see fully fledged latest
seaside in Dolphin, with continuations, adequate support for unicode,
web tools (class browser, inspector hallo's).
If Magritte, Pier, OmniBrowser could also fit in, that would be
fabulous, but I guess that would be a bit too much to expect, and
probably can be done by someone else. But I am afraid that support for
rock solid, efficient, performing non leaking continuations in seaside
requires a touch of someone very intimate with Dolphin stack/exception/
ensure handling.
Andy Bower
> And lastly, I know I might going to nerves since I am repeating this
> like a parrot, I would really really like to see fully fledged latest
> seaside in Dolphin, with continuations, adequate support for unicode,
> web tools (class browser, inspector hallo's).
I understand and will see what can be done but, as with the 64 bit VM, I
can't guarantee anything yet. Let's see how the D64 pledge round goes
and we might be able to roll another round in for continuations/unicode.
The latter, however, sounds rather an extensive job to me.
Best regards
Andy Bower
Udo Schneider
> And lastly, I know I might going to nerves since I am repeating this
> like a parrot, I would really really like to see fully fledged latest
> seaside in Dolphin, with continuations, adequate support for unicode,
> web tools (class browser, inspector hallo's).
As far as I understood Sebastian the current port does support Unicode.
The "only" thing missing is continutations based stuff (like #call: and
#answer:). This is due to Dolphins missing /partial/ continuation support.
However we are currently working on that issue. This involves a bit of
stack-rewrite magic. We are currently in the process of trying to
understand Dolphins Stack very thoroughly (which already provided a
Debugger with a graphical stack viewer as a sideeffect ...). Currently
it at least seems possible ... it's just that there is so little time.
We'll keep you updated.
For the curious here is a screenshot:
https://udos.s3.amazonaws.com/StackDrawDbg.png
> If Magritte, Pier, OmniBrowser could also fit in, that would be
> fabulous, but I guess that would be a bit too much to expect, and
I'm not quite sure what you expect from OmniBrowser - I can however say
a few things regarding Magritte and Pier.
Easy one first: IF Seaside is ported and IF Magritte is ported then Pier
is easy to port. There are nearly no other dependencies in the core Pier
Packages.
The hard one: Magritte is a different beast - although quite easy to
port (due to the huge ammount of unit tests) there was (~2y ago) one
thing which stopped me porting it. I was nearly done (<1% Unit tests
were failing) when I discovered, that Magritte overwrites #yourself.
However the Dolphin Compiler "inlines" #yourself - so the Magritte
implementation never got called. Sadly Magritte relies on overwriting
#yourself at several very core levels :-(
As I said this was 2y ago - I can try to find out what's the current
situation.
CU,
Udo
Andreas Wacknitz
> Rush,
>
>> And lastly, I know I might going to nerves since I am repeating this
>> like a parrot, I would really really like to see fully fledged latest
>> seaside in Dolphin, with continuations, adequate support for unicode,
>> web tools (class browser, inspector hallo's).
> As far as I understood Sebastian the current port does support Unicode.
> The "only" thing missing is continutations based stuff (like #call: and
> #answer:). This is due to Dolphins missing /partial/ continuation support.
>
> However we are currently working on that issue. This involves a bit of
> stack-rewrite magic. We are currently in the process of trying to
> understand Dolphins Stack very thoroughly (which already provided a
> Debugger with a graphical stack viewer as a sideeffect ...). Currently
> it at least seems possible ... it's just that there is so little time.
> We'll keep you updated.
>
> For the curious here is a screenshot:
> https://udos.s3.amazonaws.com/StackDrawDbg.png
Looks nice.
>
>> If Magritte, Pier, OmniBrowser could also fit in, that would be
>> fabulous, but I guess that would be a bit too much to expect, and
> I'm not quite sure what you expect from OmniBrowser - I can however say
> a few things regarding Magritte and Pier.
>
> Easy one first: IF Seaside is ported and IF Magritte is ported then Pier
> is easy to port. There are nearly no other dependencies in the core Pier
> Packages.
>
> The hard one: Magritte is a different beast - although quite easy to
> port (due to the huge ammount of unit tests) there was (~2y ago) one
> thing which stopped me porting it. I was nearly done (<1% Unit tests
> were failing) when I discovered, that Magritte overwrites #yourself.
> However the Dolphin Compiler "inlines" #yourself - so the Magritte
> implementation never got called. Sadly Magritte relies on overwriting
> #yourself at several very core levels :-(
>
> As I said this was 2y ago - I can try to find out what's the current
> situation.
>
> CU,
>
> Udo
Will you release this enhanced debugger some time in the future?
Maybe we can resurrect the idea of a central STS repository or at least
a server that will host all freely available stuff for Dolphin...
Best regards,
Andreas
Udo Schneider
> Will you release this enhanced debugger some time in the future?
Find it attached :-)
BTW: WARNING!!! Messing around with Stack Frames (even just displaying
them) could have serious (side-)effects. So don't complain if your image
then is running havoc, skinning your cat ... or if the fridge is empty
afterwards ... you have been warned.
Please note that the current version has (except for the package
comment) no documentation whatsoever ... it's time that I finish that
blog entry about the Dolphin Stack which I wanted to write for a long
time :-)
> Maybe we can resurrect the idea of a central STS repository or at least
> a server that will host all freely available stuff for Dolphin...
I absolutely agree. IMHO everyone of us has a whole bunch of goodies on
his/her HD ... we are even willing to share - it's just that the easy
possibility doing so is missing.
CU,
Udo
John Brant
> The hard one: Magritte is a different beast - although quite easy to
> port (due to the huge ammount of unit tests) there was (~2y ago) one
> thing which stopped me porting it. I was nearly done (<1% Unit tests
> were failing) when I discovered, that Magritte overwrites #yourself.
> However the Dolphin Compiler "inlines" #yourself - so the Magritte
> implementation never got called. Sadly Magritte relies on overwriting
> #yourself at several very core levels :-(
Why not use the code rewriter to change all #yourself messages to
something like #urself or #youself? For example, you could fix all sends
by executing search "``@a yourself" and replacement "``@a youself". Once
you've fixed all of their sends, you would simply need to rename their
implementation of #yourself to #youself, and add a #youself method to
Object.
John Brant
SteveAW
> thing which stopped me porting it. I was nearly done (<1% Unit tests
> were failing) when I discovered, that Magritte overwrites #yourself.
> However the Dolphin Compiler "inlines" #yourself
Did you try compiling, or recompiling, the methods with the "1024
SendYourself. Don't optimize out #yourself" flag set? (see the comment
in Compiler class>>compile:in:flags:)
I remember playing around with this flag for a code coverage tool a
few years back. From memory, the flag did what it said it would do.
I'm not sure that will solve the problem you had with Magritte, but
you never know.
Thanks for all the work you and others are doing on Seaside and these
other tools!
Steve
--
swa...@ozemail.com.au
SteveAW
Thanks for organizing this. A new version of "traditional" Dolphin
would be great to see!
I sent my pledge e-mail to you a few days back.
Steve
--
swa...@ozemail.com.au
Travis Kay
> Hi Udo,
>
> > thing which stopped me porting it. I was nearly done (<1% Unit tests
> > were failing) when I discovered, that Magritte overwrites #yourself.
> > However the Dolphin Compiler "inlines" #yourself
>
> Did you try compiling, or recompiling, the methods with the "1024
> SendYourself. Don't optimize out #yourself" flag set? (see the comment
> in Compiler class>>compile:in:flags:)
wow, 0_o thanks for pointing this out.
>
> I remember playing around with this flag for a code coverage tool a
> few years back. From memory, the flag did what it said it would do.
> I'm not sure that will solve the problem you had with Magritte, but
> you never know.
>
> Thanks for all the work you and others are doing on Seaside and these
> other tools!
>
> Steve
> --
Travis Kay
wrote:
> package := Package name: 'US StackDraw'.
> package paxVersion: 1;
> basicComment: '$id: US StackDraw 0.005$
> $for: Dolphin Smalltalk X6.1 Beta 2$...
>
> (c) $date: 18.11.2009$, $developer: udos@udos-laptop$ <Udo.Schnei...@homeaddress.de>
> Public Domain, Freeware
>
> Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
> * The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
>
> THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
>
> This package contains two classes: StackDrawer and StackDrawDebugger. StackDraw simply takes a process and creates a DIB of the stack. You can use it as follows:
>
> p := Processor activeProcess copy.
> dib := StackDrawer new drawFromFrame: p topFrame.
> sc := ScrollingDecorator show.
> iv := sc addSubView: ImageView new.
> iv value: dib.
> iv usePreferredExtent: true
>
> StackFrameDebugger uses StackDrawer to provide a Debugger with an additional StackDraw view. Please note that it currently only display a "static" picture of the stack - once I find some time I may recode it as a dynamic view.
>
> You can either start the StackDrawDebugger manually on a process or choose it to be the default Debugger class (in Dolphin options):
>
> p := Processor activeProcess copy.
> StackDrawDebugger
> show: p printString
> process: p
> topFrame: p topFrame
> resumable: p isTerminated not'.
>
> package basicPackageVersion: '0.005'.
>
> package classNames
> add: #StackDrawDebugger;
> add: #StackDrawer;
> yourself.
>
> package binaryGlobalNames: (Set new
> yourself).
>
> package globalAliases: (Set new
> yourself).
>
> package setPrerequisites: (IdentitySet new
> add: '..\Documents\Dolphin Smalltalk X6.1\Object Arts\Dolphin\IDE\Base\Development System';
> add: '..\Documents\Dolphin Smalltalk X6.1\Object Arts\Dolphin\Base\Dolphin';
> add: '..\Documents\Dolphin Smalltalk X6.1\Object Arts\Dolphin\MVP\Views\Cards\Dolphin Card Containers';
> add: '..\Documents\Dolphin Smalltalk X6.1\Object Arts\Dolphin\MVP\Views\Common Controls\Dolphin Common Controls';
> add: '..\Documents\Dolphin Smalltalk X6.1\Object Arts\Dolphin\MVP\Views\Control Bars\Dolphin Control Bars';
> add: '..\Documents\Dolphin Smalltalk X6.1\Object Arts\Dolphin\MVP\Presenters\Image\Dolphin Image Presenter';
> add: '..\Documents\Dolphin Smalltalk X6.1\Object Arts\Dolphin\MVP\Models\List\Dolphin List Models';
> add: '..\Documents\Dolphin Smalltalk X6.1\Object Arts\Dolphin\MVP\Presenters\List\Dolphin List Presenter';
> add: '..\Documents\Dolphin Smalltalk X6.1\Object Arts\Dolphin\MVP\Base\Dolphin MVP Base';
> add: '..\Documents\Dolphin Smalltalk X6.1\Object Arts\Dolphin\MVP\Views\Scrollbars\Dolphin Scrollbars';
> add: '..\Documents\Dolphin Smalltalk X6.1\Object Arts\Dolphin\MVP\Type Converters\Dolphin Type Converters';
> add: '..\Documents\Dolphin Smalltalk X6.1\Object Arts\Dolphin\MVP\Models\Value\Dolphin Value Models';
> add: '..\Documents\Dolphin Smalltalk X6.1\Object Arts\Dolphin\MVP\Gdiplus\Gdiplus';
> add: '..\Documents\Dolphin Smalltalk X6.1\Object Arts\Dolphin\ActiveX\Shell\Windows Shell';
> yourself).
>
> package!
>
> "Class Definitions"!
>
> Object subclass: #StackDrawer
> instanceVariableNames: 'process dib canvas evenFrame graphics width dibHeight'
> classVariableNames: ''
> poolDictionaries: 'GdiplusConstants Win32Constants'
> classInstanceVariableNames: ''!
> Debugger subclass: #StackDrawDebugger
> instanceVariableNames: 'graphicalCallStackPresenter'
> classVariableNames: ''
> poolDictionaries: ''
> classInstanceVariableNames: ''!
>
> "Global Aliases"!
>
> "Loose Methods"!
>
> "End of package definition"!
>
> "Source Globals"!
>
> "Classes"!
>
> StackDrawer guid: (GUID fromString: '{FA821B18-222D-4706-BDFF-C2178BBECFC8}')!
> StackDrawer comment: '| p stack sender |
> p := Processor activeProcess copy.
> "p := [] newProcess."
> frames := OrderedCollection new.
> frames add: p topFrame.
> [(frame := frames first sender) isNil] whileFalse: [frames addFirst: frame].
> frames.
> (1 to: p size) collect: [:each | p at: each].
> Profiler profile:
> [dib := StackDrawer new drawFromFrame: p topFrame.
> sc := ScrollingDecorator show.
> iv := sc addSubView: ImageView new.
> iv value: dib.
> iv usePreferredExtent: true].
> FooBar new foo'!
> !StackDrawer categoriesForClass!Kernel-Objects! !
> !StackDrawer methodsFor!
>
> arrowOffset
> ^self entryWidth - (self arrowWidth )!
>
> arrowWidth
> ^40!
>
> descriptionOffset
> ^128!
>
> descriptorOffset
> ^32!
>
> drawArrowFrom: entryOffset to: targetOffset width: width color: anARGB
> | rect |
> rect := (self arrowOffset - (width )) @ (entryOffset + (self entryHeight / 2))
> corner: (self arrowOffset + (width )) @ (targetOffset + (self entryHeight / 2)).
> graphics drawBezier: (Array
> with: rect topCenter
> with: rect topRight
> with: rect bottomRight
> with: rect bottomCenter)
> pen: ((GdiplusPen color: anARGB)
> lineCap: LineCapRoundAnchor
> endCap: LineCapArrowAnchor
> dashCap: LineCapRound;
> width: 3)!
>
> drawBackground: frame
> frame bp - 1 < frame asInteger
> ifTrue: [self drawBackgroundFrom: frame bp - 1 to: frame asInteger - 1].
> self
> drawBackgroundFrom: frame asInteger
> to: frame asInteger + 5 .frame sp > (frame asInteger + 5)
> ifTrue: [self drawBackgroundFrom: frame asInteger + 6 to: frame sp]!
>
> drawBackgroundFrom: firstIndex to: lastIndex
> | firstOffset lastOffset rect |
> firstOffset := self indexOffset: firstIndex - 1.
> lastOffset := self indexOffset: lastIndex.
> rect := 0 @ firstOffset corner: self arrowOffset @ lastOffset.
> evenFrame
> ifTrue:
> [canvas
> fillRectangle: rect
> startColor: Color yellow
> endColor: Color white
> verticalGradient: true]
> ifFalse:
> [canvas
> fillRectangle: rect
> startColor: Color light3d
> endColor: Color white
> verticalGradient: true].
> !
>
> drawBasePointer: frame
> | index entryOffset |
> index := frame asInteger + 5.
> entryOffset := self indexOffset: index.
> self drawIndex: index offset: entryOffset.
> self drawDescriptor: 'BP' offset: entryOffset.
> self drawPointer: index offset: entryOffset.
> self drawBasePointerPointerArrow: index offset: entryOffset!
>
> drawBasePointerPointerArrow: index offset: entryOffset
> | entry targetIndex targetOffset |
> entry := process at: index.
> targetIndex := process indexOfSP: entry.
> targetOffset := self indexOffset: targetIndex.
> self
> drawArrowFrom: entryOffset
> to: targetOffset
> width: self arrowWidth/2
> color: (ARGB
> a: 128
> r: 0
> g: 255
> b: 0)!
>
> drawBPs: frame
> | entryOffset count temps descriptor |
> frame bp = frame asInteger ifTrue: [^self].
> count := 1.
> temps := (frame temps asSortedCollection: [:x :y | x third <= y third]) collect: [:each | each first] .
> frame bp to: frame asInteger - 1
> do:
> [:bpIndex |
> entryOffset := self indexOffset: bpIndex.
> self drawIndex: bpIndex offset: entryOffset.
> descriptor := temps at: count
> ifAbsent:
> [count <= frame argumentCount
> ifTrue: ['<1d><2d>' expandMacrosWith: 'arg' with: count]
> ifFalse: ['<1d><2d>' expandMacrosWith: 'tmp' with: count - frame argumentCount]].
> self
> drawDescriptor: descriptor offset: entryOffset;
> drawDescription: bpIndex offset: entryOffset.
> count := count + 1]!
>
> drawCallingStackFrameAddress: frame
> | index entryOffset |
> index := frame asInteger + 2.
>
> entryOffset := self indexOffset: index.
> self drawIndex: index offset: entryOffset.
> self drawDescriptor: 'CSFA' offset: entryOffset.
> self drawPointer: index offset: entryOffset.
> self drawCallingStackFrameAddressArrow: index offset: entryOffset!
>
> drawCallingStackFrameAddressArrow: index offset: entryOffset
> | entry targetIndex targetOffset rect |
> entry := process at: index.
> entry = 0 ifTrue: [^self].
> targetIndex := process indexOfSP: entry.
> targetOffset := self indexOffset: targetIndex.
> self
> drawArrowFrom: entryOffset
> to: targetOffset
> width: self arrowWidth
> color: (ARGB
> a: 128
> r: 0
> g: 0
> b: 255)!
>
> drawDescription: index offset: entryOffset
> | entry rect |
> entry := process at: index.
> rect := (self descriptionOffset + Icon smallExtent x + 4) @ entryOffset
> corner: self arrowOffset @ (entryOffset + self entryHeight).
> rect := rect insetBy: self entryInset.
> entry icon
> drawOn: canvas
> at: (self descriptionOffset + 2) @ entryOffset + ((self entryHeight - Icon smallExtent) / 2)
> extent: Icon smallExtent.
> canvas
> formatText: entry printString
> in: rect
> flags: DT_LEFT | DT_SINGLELINE | DT_VCENTER | DT_WORD_ELLIPSIS!
>
> drawDescriptor: descriptor offset: entryOffset
> | rect |
> rect := self descriptorOffset @ entryOffset
> corner: self descriptionOffset @ (entryOffset + self entryHeight).
> rect := rect insetBy: self entryInset.
> canvas
> formatText: descriptor
> in: rect
> flags: DT_CENTER | DT_SINGLELINE | DT_VCENTER!
>
> drawEnvironment: frame
> | index entryOffset |
> index := frame asInteger + 1.
> entryOffset := self indexOffset: index.
>
> self drawIndex: index offset: entryOffset.
> self drawDescriptor: 'ENV' offset: entryOffset.
> self drawDescription: index offset: entryOffset!
>
> drawFrame: frame
> canvas font: self font.
> self
> drawBackground: frame;
> drawSelf: frame;
> drawBPs: frame.
> canvas font: self font beItalic beBold.
> self
> drawMethod: frame;
> drawEnvironment: frame;
> drawCallingStackFrameAddress: frame;
>
> read more »
Thank you =)
rush
wrote:
> The "only" thing missing is continutations based stuff (like #call: and
> #answer:). This is due to Dolphins missing /partial/ continuation support.
I'll put reply concerning seaside porting details in seaside thread in
order not to polute this one too much.
> I'm not quite sure what you expect from OmniBrowser - I can however say
> a few things regarding Magritte and Pier.
Well I see that quite a few goodies are using it, and I expect that
quite of a few things in the future will also rely on it. Having OB
working in Dolphin, might ease porting.
Let me put this way, several years ago it was great if we could use
code and goodies from other smalltalks. I think now it is cruicall
that Dolphin has available if not all the best tools from other
smalltalks, than at least the big ones. Once we have that, Dolphin can
easily differentiate as a Cadilac or Benz of Smalltalks. But without
being able to use tools produced by others we might be in trouble. I
see Seaside stack (which takan liberaly may also include Pier and by
consequence also Magritte) as an infrastructure.
Udo Schneider
> Why not use the code rewriter to change all #yourself messages to
> something like #urself or #youself? For example, you could fix all sends
> by executing search "``@a yourself" and replacement "``@a youself". Once
> you've fixed all of their sends, you would simply need to rename their
> implementation of #yourself to #youself, and add a #youself method to
> Object.
Excellent idea ... to be honest I never quite had enough "need" to
familirze myself with the Rerwite rule syntax - I'll take look now.
Promised :-)
My first thought was "well then I have to do it every time I import a
new version (from Squeak)" ... however this shouldn't be a problem. I
also just checked Magritte in a current Pharo image and it seems that
the problem is historic anyway. According to Pharo the only class
implementing yourself is Object.
Thanks for the hint.
CU,
Udo
Udo Schneider
> Did you try compiling, or recompiling, the methods with the "1024
> SendYourself. Don't optimize out #yourself" flag set? (see the comment
> in Compiler class>>compile:in:flags:)
No I didn't - I wasn't even aware of something like this. Again an area
of Dolphin where interesting stuff can be learned ... So many things -
so little time :-)
Thanks.
CU,
Udo
Andy Bower
> Maybe we can resurrect the idea of a central STS repository or at least
> a server that will host all freely available stuff for Dolphin...
If we can get this Dolphin7-32/64 idea off the ground then one thing
I'll make sure goes in there is the networking STS client and, in
addition, OA will host a central repository. We can also include STS in
the free version, DCE, but this will probably remain as 32 bit only.
Best regards
Andy Bower
Bernhard Kohlhaas
I pledge $500 toward a package comprising D7PRO32 & D7PRO64.
Best Regards,
Bernhard
Andy Bower wrote:
[...]
Shaping
>> a server that will host all freely available stuff for Dolphin...
> I absolutely agree. IMHO everyone of us has a whole bunch of goodies on
> his/her HD ... we are even willing to share - it's just that the easy
> possibility doing so is missing.
I agree.
Shaping
> | package |
> package := Package name: 'US StackDraw'.
> package paxVersion: 1;
> basicComment: '$id: US StackDraw 0.005$
> $for: Dolphin Smalltalk X6.1 Beta 2$
>
> (c) $date: 18.11.2009$, $developer: udos@udos-laptop$
> drawInstructionPointer: frame;
> drawStackPointer: frame;
> drawBasePointer: frame.
> canvas font: self font.
> self drawStack: frame!
>
> drawFrames: topFrame
> | frame |
> frame := topFrame.
> evenFrame := false.
> [
> evenFrame := evenFrame not.
> (frame := frame sender) notNil] whileTrue.
> frame := topFrame.
> [self drawFrame: frame.
> evenFrame := evenFrame not.
> (frame := frame sender) notNil] whileTrue!
>
> drawFromFrame: aStackFrame
> ^[self drawFromFrameInsecure: aStackFrame] on: Error
> do:
> [:ex |
> DIBSection
> width: 32
> height: 32
> depth: 32]!
>
> drawFromFrameInsecure: aStackFrame
> process := aStackFrame process.
> dib := DIBSection
> width: self width
> height: aStackFrame sp * self entryHeight
> depth: 32.
> dibHeight := dib extent y.
> canvas := dib canvas.
> canvas
> setBkMode: TRANSPARENT;
> fillRectangle: (0 @ 0 extent: dib extent) color: Color white;
> pen: (Pen color: Color black).
> graphics := GdiplusGraphics fromCanvas: canvas.
> graphics smoothingMode: SmoothingModeAntiAlias.
> self drawFrames: aStackFrame.
> self drawGrid.
> ^dib!
>
> drawGrid
>
> (0 to: dibHeight by: self entryHeight) do: [:y | canvas lineFrom: 0 @ y
> to: self arrowOffset @ y].
> canvas
> lineFrom: 0 @ 0 to: 0 @ dibHeight;
> lineFrom: self descriptorOffset @ 0 to: self descriptorOffset @ dibHeight;
> lineFrom: self descriptionOffset @ 0 to: self descriptionOffset @
> dibHeight;
> lineFrom: self arrowOffset @ 0 to: self arrowOffset @ dibHeight!
>
> drawIndex: index offset: entryOffset
> | rect |
> rect := 0 @ entryOffset extent: self descriptorOffset @ self entryHeight.
> rect := rect insetBy: self entryInset.
> canvas
> formatText: index displayString
> in: rect
> flags: DT_CENTER | DT_SINGLELINE | DT_VCENTER!
>
> drawInstructionPointer: frame
> | index entryOffset entry rect |
> index := frame asInteger + 3.
> entryOffset := self indexOffset: index.
> self drawIndex: index offset: entryOffset.
> self drawDescriptor: 'IP' offset: entryOffset.
> entry := process at: index.
> rect := self descriptionOffset @ entryOffset
> corner: self arrowOffset @ (entryOffset + self entryHeight).
> rect := rect insetBy: self entryInset.
> canvas
> formatText: entry displayString
> in: rect
> flags: DT_LEFT | DT_SINGLELINE | DT_VCENTER!
>
> drawMethod: frame
> | index entryOffset |
> index := frame asInteger + 0.
> entryOffset := self indexOffset: index.
>
> self drawIndex: index offset: entryOffset.
> self drawDescriptor: 'ME' offset: entryOffset.
> self drawDescription: index offset: entryOffset!
>
> drawPointer: index offset: entryOffset
> | entry targetIndex description rect |
> entry := process at: index.
> targetIndex := entry = 0 ifFalse: [process indexOfSP: entry] ifTrue:
> [nil].
> description := '<1p> (<2d>)' expandMacrosWith: targetIndex with: entry.
> rect := self descriptionOffset @ entryOffset
> corner: self arrowOffset @ (entryOffset + self entryHeight).
> rect := rect insetBy: self entryInset.
> canvas
> formatText: description
> in: rect
> flags: DT_LEFT | DT_SINGLELINE | DT_VCENTER!
>
> drawSelf: frame
> | index entryOffset |
> index := frame bp - 1.
> entryOffset := self indexOffset: index.
> self drawIndex: index offset: entryOffset.
> self drawDescriptor: 'self' offset: entryOffset.
> self drawDescription: index offset: entryOffset!
>
> drawStack: frame
> | entryOffset count |
> frame sp = (frame asInteger + 5) ifTrue: [^self].
> count := 0.
> frame asInteger + 6 to: frame sp
> do:
> [:bpIndex |
> entryOffset := self indexOffset: bpIndex.
> self drawIndex: bpIndex offset: entryOffset.
> self drawDescriptor: ('<1d><2d>' expandMacrosWith: '_stack' with: count)
> offset: entryOffset.
> self drawDescription: bpIndex offset: entryOffset.
> count := count + 1]!
>
> drawStackPointer: frame
> | index entryOffset |
> index := frame asInteger + 4.
> entryOffset := self indexOffset: index.
>
> self drawIndex: index offset: entryOffset.
> self drawDescriptor: 'SP' offset: entryOffset.
> self drawPointer: index offset: entryOffset.
> self drawStackPointerArrow: index offset: entryOffset!
>
> drawStackPointerArrow: index offset: entryOffset
> | entry targetIndex targetOffset rect |
> entry := process at: index.
> targetIndex := process indexOfSP: entry.
> targetOffset := self indexOffset: targetIndex.
> self
> drawArrowFrom: entryOffset
> to: targetOffset
> width: self arrowWidth/2
> color: (ARGB
> a: 128
> r: 255
> g: 0
> b: 0)!
>
> entryHeight
> ^20!
>
> entryInset
> ^1!
>
> entryWidth
> ^self width - 16!
>
> font
> ^Font name: 'Arial' pointSize: 9!
>
> indexOffset: index
> ^dibHeight - (index * self entryHeight)!
>
> process
> ^process!
>
> process: anObject
> process := anObject!
>
> width
>
> width isNil ifTrue: [width := 512].
> ^width!
>
> width: anInteger
>
> width := anInteger! !
> !StackDrawer categoriesFor: #arrowOffset!constants!private! !
> !StackDrawer categoriesFor: #arrowWidth!constants!private! !
> !StackDrawer categoriesFor: #descriptionOffset!constants!private! !
> !StackDrawer categoriesFor: #descriptorOffset!constants!private! !
> !StackDrawer categoriesFor:
> #drawArrowFrom:to:width:color:!drawing!operations!private! !
> !StackDrawer categoriesFor: #drawBackground:!drawing!operations!private! !
> !StackDrawer categoriesFor:
> #drawBackgroundFrom:to:!drawing!operations!private! !
> !StackDrawer categoriesFor: #drawBasePointer:!drawing!operations!private!
> !
> !StackDrawer categoriesFor:
> #drawBasePointerPointerArrow:offset:!drawing!operations!private! !
> !StackDrawer categoriesFor: #drawBPs:!drawing!operations!private! !
> !StackDrawer categoriesFor:
> #drawCallingStackFrameAddress:!drawing!operations!private! !
> !StackDrawer categoriesFor:
> #drawCallingStackFrameAddressArrow:offset:!drawing!operations!private! !
> !StackDrawer categoriesFor:
> #drawDescription:offset:!drawing!operations!private! !
> !StackDrawer categoriesFor:
> #drawDescriptor:offset:!drawing!operations!private! !
> !StackDrawer categoriesFor: #drawEnvironment:!drawing!operations!private!
> !
> !StackDrawer categoriesFor: #drawFrame:!drawing!operations!private! !
> !StackDrawer categoriesFor: #drawFrames:!drawing!operations!private! !
> !StackDrawer categoriesFor: #drawFromFrame:!drawing!operations!public! !
> !StackDrawer categoriesFor:
> #drawFromFrameInsecure:!drawing!operations!public! !
> !StackDrawer categoriesFor: #drawGrid!drawing!operations!private! !
> !StackDrawer categoriesFor: #drawIndex:offset:!drawing!operations!private!
> !
> !StackDrawer categoriesFor:
> #drawInstructionPointer:!drawing!operations!private! !
> !StackDrawer categoriesFor: #drawMethod:!drawing!operations!private! !
> !StackDrawer categoriesFor:
> #drawPointer:offset:!drawing!operations!private! !
> !StackDrawer categoriesFor: #drawSelf:!drawing!operations!private! !
> !StackDrawer categoriesFor: #drawStack:!drawing!operations!private! !
> !StackDrawer categoriesFor: #drawStackPointer:!drawing!operations!private!
> !
> !StackDrawer categoriesFor:
> #drawStackPointerArrow:offset:!drawing!operations!private! !
> !StackDrawer categoriesFor: #entryHeight!constants!private! !
> !StackDrawer categoriesFor: #entryInset!constants!private! !
> !StackDrawer categoriesFor: #entryWidth!constants!private! !
> !StackDrawer categoriesFor: #font!constants!private! !
> !StackDrawer categoriesFor: #indexOffset:!helpers!private! !
> !StackDrawer categoriesFor: #process!accessing!private! !
> !StackDrawer categoriesFor: #process:!accessing!private! !
> !StackDrawer categoriesFor: #width!accessing!private! !
> !StackDrawer categoriesFor: #width:!drawing!operations!private! !
>
> !StackDrawer class methodsFor!
>
> new
> ^super new initialize! !
> !StackDrawer class categoriesFor: #new!public! !
>
> StackDrawDebugger guid: (GUID fromString:
> '{4C142DDA-567F-4DF8-96E7-CF87650D0667}')!
> StackDrawDebugger comment: ''!
> !StackDrawDebugger categoriesForClass!Development! !
> !StackDrawDebugger methodsFor!
>
> createComponents
>
> super createComponents.
> graphicalCallStackPresenter := self add: ImagePresenter new name:
> 'graphicalCallStack'!
>
> displayFrame
> super displayFrame. self updateCallStack!
>
> refreshFrame
> super refreshFrame.
> self updateCallStack!
>
> updateCallStack
> graphicalCallStackPresenter value: ((StackDrawer new)
> width: graphicalCallStackPresenter view parentView width - 4;
> drawFromFrame: topFrame)! !
> !StackDrawDebugger categoriesFor: #createComponents!public! !
> !StackDrawDebugger categoriesFor: #displayFrame!private!updating! !
> !StackDrawDebugger categoriesFor: #refreshFrame!private!updating! !
> !StackDrawDebugger categoriesFor: #updateCallStack!private!updating! !
>
> !StackDrawDebugger class methodsFor!
>
> resource_Default_view
> "Answer the literal data from which the 'Default view' resource can be
> reconstituted.
> DO NOT EDIT OR RECATEGORIZE THIS METHOD.
>
> If you wish to modify this resource evaluate:
> ViewComposer openOn: (ResourceIdentifier class: self selector:
> #resource_Default_view)
> "
>
> ^#(#'!!STL' 3 788558 10 ##(Smalltalk.STBViewProxy) 8
> ##(Smalltalk.DebuggerShellView) 98 27 0 0 98 2 27131905 131073 416 0
> 524550 ##(Smalltalk.ColorRef) 8 4294967295 0 551 0 0 0 416 788230
> ##(Smalltalk.BorderLayout) 1 1 410 8 ##(Smalltalk.Toolbar) 98 25 0 416
> 98 2 8 1140851532 65 560 0 482 8 4278190080 0 519 0 263174
> ##(Smalltalk.Font) 0 16 459014 ##(Smalltalk.LOGFONT) 8 #[243 255 255 255
> 0 0 0 0 0 0 0 0 0 0 0 0 144 1 0 0 0 0 0 0 3 2 1 34 65 114 105 97 108 0 0 0
> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0] 328198
> ##(Smalltalk.Point) 193 193 0 560 482 656 8 4294910303 234 256 98 8 410 8
> ##(Smalltalk.ReferenceView) 98 14 0 560 98 2 8 1140850688 131073 848 0 0
> 0 7 0 0 0 848 1180166 ##(Smalltalk.ResourceIdentifier) 576 8
> #resource_Debugger_tools 0 983302 ##(Smalltalk.MessageSequence) 202 208
> 98 1 721670 ##(Smalltalk.MessageSend) 8 #createAt:extent: 98 2 754 201 51
> 754 293 51 848 983302 ##(Smalltalk.WINDOWPLACEMENT) 8 #[44 0 0 0 0 0 0 0
> 1 0 0 0 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255
> 100 0 0 0 25 0 0 0 246 0 0 0 50 0 0 0] 98 0 754 193 193 0 27 8
> 'debuggerTools' 410 864 98 14 0 560 98 2 8 1140850688 131073 1232 0 0 0 7
> 0 0 0 1232 930 576 8 #resource_Workspace_tools 0 978 202 208 98 1 1042
> 1072 98 2 754 1 51 754 201 51 1232 1138 8 #[44 0 0 0 0 0 0 0 1 0 0 0 255
> 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 0 0 0 0 25 0 0
> 0 100 0 0 0 50 0 0 0] 1184 1200 0 27 8 'workspaceTools' 410 864 98 14 0
> 560 98 2 8 1140850688 131073 1488 0 0 0 7 0 0 0 1488 930 576 8
> #resource_Smalltalk_tools 0 978 202 208 98 1 1042 1072 98 2 754 63 1 754
> 991 51 1488 1138 8 #[44 0 0 0 0 0 0 0 1 0 0 0 255 255 255 255 255 255 255
> 255 255 255 255 255 255 255 255 255 31 0 0 0 0 0 0 0 14 2 0 0 25 0 0 0]
> 1184 1200 0 27 8 'smalltalkTools' 410 864 98 14 0 560 98 2 8 1140850688
> 131073 1744 0 0 0 7 0 0 0 1744 930 576 8 #resource_Image_tools 0 978 202
> 208 98 1 1042 1072 98 2 754 1 1 754 63 51 1744 1138 8 #[44 0 0 0 0 0 0 0 1
> 0 0 0 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 0 0
> 0 0 0 0 0 0 31 0 0 0 25 0 0 0] 1184 1200 0 27 8 'imageTools' 234 256 1184
> 202 208 1184 234 240 1184 0 1 0 754 33 33 754 45 45 0 656198 1
> ##(Smalltalk.FlowLayout) 1 1 1 978 202 208 98 2 1042 1072 98 2 754 1 1
> 754 1169 101 560 1042 8 #updateSize 1184 560 1138 8 #[44 0 0 0 0 0 0 0 1 0
> 0 0 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 0 0 0
> 0 0 0 0 0 72 2 0 0 50 0 0 0] 98 4 1744 1488 1232 848 1200 0 27 0 0 0 410 8
> ##(Smalltalk.ContainerView) 98 15 0 416 98 2 8 1140850688 131073 2304 0 0
> 0 7 0 0 0 2304 1180166 ##(Smalltalk.ProportionalLayout) 202 8
> ##(Smalltalk.Dictionary) 98 2 721414 ##(Smalltalk.Association) 410 8
> ##(Smalltalk.Splitter) 98 12 0 2304 98 2 8 1140850688 1 2496 0 482 656 0
> 519 0 0 0 2496 978 202 208 98 1 1042 1072 98 2 754 1 285 754 1169 19 2496
> 1138 8 #[44 0 0 0 0 0 0 0 1 0 0 0 255 255 255 255 255 255 255 255 255 255
> 255 255 255 255 255 255 0 0 0 0 142 0 0 0 72 2 0 0 151 0 0 0] 98 0 1200 0
> 27 1 2466 410 864 98 14 0 2304 98 2 8 1140916224 131073 2768 0 0 0 23 0 0
> 0 2768 930 8 ##(Smalltalk.MethodWorkspace) 8 #resource_Debugger_source 0
> 978 202 208 98 1 1042 1072 98 2 754 1 303 754 1169 287 2768 1138 8 #[44 0
> 0 0 0 0 0 0 1 0 0 0 255 255 255 255 255 255 255 255 255 255 255 255 255
> 255 255 255 0 0 0 0 151 0 0 0 72 2 0 0 38 1 0 0] 1184 1200 0 27 3 16 234
> 256 98 2 2768 8 'source' 0 978 202 208 98 1 1042 1072 98 2 754 1 101 754
> 1169 589 2304 1138 8 #[44 0 0 0 0 0 0 0 1 0 0 0 255 255 255 255 255 255
> 255 255 255 255 255 255 255 255 255 255 0 0 0 0 50 0 0 0 72 2 0 0 88 1 0
> 0] 98 3 410 2320 98 15 0 2304 98 2 8 1140850688 131073 3232 0 0 0 7 0 0 0
> 3232 2386 202 2432 98 3 2466 410 8 ##(Smalltalk.CardContainer) 98 16 0
> 3232 98 2 8 1409286144 131073 3360 0 482 8 4278190080 0 7 0 0 0 3360
> 655878 ##(Smalltalk.CardLayout) 202 208 98 2 2466 8 'List' 410 8
> ##(Smalltalk.ListBox) 98 17 0 3360 98 2 8 1144062209 1 3568 590662 2
> ##(Smalltalk.ListModel) 202 208 1184 0 1310726
> ##(Smalltalk.IdentitySearchPolicy) 482 656 0 5 265030 4
> ##(Smalltalk.Menu) 0 16 98 13 984134 2 ##(Smalltalk.CommandMenuItem) 1
> 1180998 4 ##(Smalltalk.CommandDescription) 8 #stepInto 8 'Step &Into'
> 1269 5 263494 3 ##(Smalltalk.Icon) 0 16 1572870
> ##(Smalltalk.ImageRelativeFileLocator) 8 'StepInto.ico' 2032142
> ##(Smalltalk.STBExternalResourceLibraryProxy) 8 'dolphindr006.dll' 0 0 0
> 3794 1 3826 8 #stepOver 8 'Step O&ver' 1267 5 3890 0 16 3936 8
> 'StepOver.ico' 3984 0 0 3794 1 3826 8 #stepOut 8 'Step O&ut' 5365 1 3890 0
> 16 3936 8 'StepOut.ico' 3984 0 0 3794 1 3826 8 #returnFromMessage 8
> 'Retur&n ...' 1 1 0 0 0 3794 1 3826 8 #restartFrame 8 '&Restart' 1 1 3890
> 0 16 3936 8 'Restart.ico' 3984 0 0 983366 1 ##(Smalltalk.DividerMenuItem)
> 4097 3746 0 16 98 0 8 'Im&plement in' 8 #implementDNUMenu 134217729 0 0 0
> 0 0 3746 0 16 98 16 3794 1 3826 8 #renameMethod 8 'Re&name...' 1 1 0 0 0
> 3794 1 3826 8 #renameMethodReferences 8 'Rename Re&ferences...' 1 1 0 0 0
> 3794 1 3826 8 #safeRemoveMethods 8 'Rem&ove' 1 5 0 0 0 4370 4097 3794 1
> 3826 8 #addParameter 8 'Add &Parameter...' 1 1 0 0 0 3746 0 16 98 0 8
> 'Remo&ve Parameter' 8 #removeParameterMenu 134217729 0 0 0 0 0 3746 0 16
> 98 0 8 'Rena&me Parameter' 8 #renameParameterMenu 134217729 0 0 0 0 0 3746
> 0 16 98 0 8 '&Inline Parameter' 8 #inlineParameterMenu 134217729 0 0 0 0 0
> 4370 4097 3746 0 16 98 0 8 'Rename &Temporary' 8 #renameTempMenu 134217729
> 0 0 0 0 0 3746 0 16 98 0 8 'Convert Temp to Inst. Var.' 8
> #convertTempToInstVarMenu 134217729 0 0 0 0 0 4370 4097 3794 1 3826 8
> #inlineAllSelfSends 8 'Inline &Self Sends' 1 1 0 0 0 3794 1 3826 8 #pushUp
> 8 'Push &Up' 1 1 0 0 0 3794 1 3826 8 #pushDown 8 'Push &Down' 1 1 0 0 0
> 3794 1 3826 8 #moveMethod 8 'Move to &Component...' 1 1 0 0 0 8
> 'Refactorin&gs' 8 #methodRefactoringsMenu 134217729 3890 0 16 3936 8
> 'Refactoring.ico' 3984 0 0 0 0 4370 4097 3794 1 3826 8 #moreFrames 8
> '&More' 1 1 0 0 0 3794 1 3826 8 #allFrames 8 'A&ll' 1 1 0 0 0 4370 4097
> 3746 0 16 98 6 3746 0 16 98 1 3794 1 3826 8 #browseDefinitions 8 'Browse
> Defi&nitions' 247 1 0 0 0 8 '&Definitions Of' 8 #definitionsMenu 134217729
> 0 0 0 0 0 3746 0 16 98 1 3794 1 3826 8 #browseReferences 8 'Browse
> &References' 4343 1 0 0 0 8 '&References To' 8 #referencesMenu 134217729 0
> 0 0 0 0 3794 1 3826 8 #browseMethodInheritanceChain 8 '&Inheritance Chain'
> 1 1 0 0 0 4370 4097 3794 1 3826 8 #browseMethodHistory 8 '&Change History
> in Image' 1 1 0 0 0 3794 1 3826 8 #browseMethodEditions 8 'Browse
> &Editions' 1 1 0 0 0 8 '&Browse' 0 134217729 0 0 0 0 0 8 '&Debug' 0
> 134217729 0 0 0 0 0 0 0 3568 0 8 4294909103 8
> ##(Smalltalk.BasicListAbstract) 1184 0 978 202 208 98 3 1042 1072 98 2
> 754 9 49 754 559 229 3568 1042 8 #contextMenu: 98 1 3760 3568 1042 8
> #horizontalExtent: 98 1 1 3568 1138 8 #[44 0 0 0 0 0 0 0 0 0 0 0 255 255
> 255 255 255 255 255 255 255 255 255 255 255 255 255 255 4 0 0 0 24 0 0 0
> 27 1 0 0 138 0 0 0] 98 0 1200 0 27 2466 8 'Graphical' 410 8
> ##(Smalltalk.ScrollingDecorator) 98 18 0 3360 98 2 8 1143996416 131073
> 6448 0 0 0 7 0 0 0 6448 1573190 1 ##(Smalltalk.ScrollingDecoratorLayout)
> 16 234 256 98 2 410 8 ##(Smalltalk.ImageView) 98 21 0 6448 98 2 8
> 1140850944 1025 6592 721990 2 ##(Smalltalk.ValueHolder) 0 0 1376774
> ##(Smalltalk.PluggableSearchPolicy) 459270 ##(Smalltalk.Message) 8 #= 98
> 0 6738 8 #hash 98 0 0 482 8 4278190080 0 519 0 0 0 6592 0 8 4294903431
> 852486 ##(Smalltalk.NullConverter) 0 0 0 0 8 #scaleToFit 1 0 0 978 202
> 208 98 1 1042 1072 98 2 754 1 1 754 559 229 6592 1138 8 #[44 0 0 0 0 0 0 0
> 1 0 0 0 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 0
> 0 0 0 0 0 0 0 23 1 0 0 114 0 0 0] 98 0 1200 0 27 8 'graphicalCallStack' 0
> 754 1 1 16 754 17 17 978 202 208 98 1 1042 1072 98 2 754 9 49 754 559 229
> 6448 1138 8 #[44 0 0 0 0 0 0 0 1 0 0 0 255 255 255 255 255 255 255 255 255
> 255 255 255 255 255 255 255 4 0 0 0 24 0 0 0 27 1 0 0 138 0 0 0] 98 1 6592
> 1200 0 27 6448 234 256 98 2 3568 8 'stack' 0 410 8 ##(Smalltalk.TabViewXP)
> 98 28 0 3360 98 2 8 1140916736 1 7360 3650 202 208 98 2 3552 6432 0 3712 0
> 0 1 0 0 0 7360 0 8 4294911709 787814 3 ##(Smalltalk.BlockClosure) 0 0
> 918822 ##(Smalltalk.CompiledMethod) 2 3 8 ##(Smalltalk.ListControlView)
> 8 #defaultGetTextBlock 575230339 8 #[30 105 226 0 106] 8 #displayString
> 7520 7 257 0 7506 0 0 7538 2 3 8 ##(Smalltalk.IconicListAbstract) 8
> #defaultGetImageBlock 579598755 8 #[30 105 226 0 106] 8 #iconImageIndex
> 7632 7 257 0 1049670 1 ##(Smalltalk.IconImageManager) 0 0 0 0 0 8
> #noIcons 0 0 0 0 0 978 202 208 98 3 1042 1072 98 2 754 1 1 754 575 285
> 7360 1042 8 #basicSelectionsByIndex: 98 1 98 1 5 7360 1042 8
> #tcmSetExtendedStyle:dwExStyle: 98 2 -1 1 7360 1138 8 #[44 0 0 0 0 0 0 0 1
> 0 0 0 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 0 0
> 0 0 0 0 0 0 31 1 0 0 142 0 0 0] 98 0 1200 0 27 978 202 208 98 1 1042 1072
> 98 2 754 1 1 754 575 285 3360 1138 8 #[44 0 0 0 0 0 0 0 1 0 0 0 255 255
> 255 255 255 255 255 255 255 255 255 255 255 255 255 255 0 0 0 0 0 0 0 0 31
> 1 0 0 142 0 0 0] 98 3 3568 6448 7360 1200 0 27 13 2466 410 2320 98 15 0
> 3232 98 2 8 1140850688 131073 8224 0 0 0 7 0 0 0 8224 2386 234 240 98 4
> 410 8 ##(Smalltalk.ListView) 98 30 0 8224 98 2 8 1140949069 1 8336 3650
> 202 208 1184 0 3712 482 656 0 7 3746 0 16 98 8 3794 1 3826 8 #inspectIt 8
> '&Inspect' 1 1 3890 0 16 3936 8 'BasicInspector.ico' 3984 0 0 3794 1 3826
> 8 #inspectReferences 8 'Inspect &References' 1 1 0 0 0 4370 4097 3794 1
> 3826 8 #nilVariable 8 'Set to &Nil' 1 1 0 0 0 4370 4097 3794 1 3826 8
> #browseVariableClass 8 '&Browse Class' 1 1 0 0 0 4370 4097 3794 1 3826 8
> #refreshVariables 8 'Re&fresh' 1 1 0 0 0 8 '&Inspect' 0 134217729 0 0 0 0
> 0 0 0 8336 0 8 4294908133 6738 8 #first 98 0 0 7744 0 7506 0 0 1180966
> ##(Smalltalk.CompiledExpression) 3 1 8 ##(Smalltalk.UndefinedObject) 8
> 'doIt' 8 '[:each | Debugger debugPrintStringFor: each]' 8 #[31 105 45 17
> 177 106] 2466 8 #Debugger 8 ##(Smalltalk.Debugger) 8
> #debugPrintStringFor: 8976 7 257 0 0 0 0 0 202 208 98 2 920646 5
> ##(Smalltalk.ListViewColumn) 8 'Variable' 301 8 #left 6144 8
> ##(Smalltalk.SortedCollection) 7506 0 0 8994 2 1 9024 8 'doIt' 8 '[:each
> | each first]' 8 #[30 105 17 158 106] 8944 9264 7 257 0 0 8336 0 1 0 0
> 9186 8 'Value' 277 9232 7506 0 0 8994 3 1 9024 8 'doIt' 8 '[:each |
> Debugger debugPrintStringFor: each]' 8 #[31 105 45 17 177 106] 2466 9104
> 9120 9136 9376 7 257 0 7506 0 0 7538 1 83886081 170 8 'Dolphin' 8
> 'SortedCollection' 8 #defaultSortBlock 1540880899 8 #[29 105 233 1 130
> 106] 9472 7 513 0 7506 0 0 8994 2 1 9024 8 'doIt' 8 '[:each | each
> second]' 8 #[30 105 17 158 106] 8 #second 9584 7 257 0 0 8336 0 3 0 0 8
> #report 1184 0 131143 0 0 978 202 208 98 3 1042 1072 98 2 754 1 1 754 577
> 199 8336 1042 6288 98 1 8464 8336 1042 8 #text: 98 1 8 'Variable' 8336
> 1138 8 #[44 0 0 0 0 0 0 0 1 0 0 0 255 255 255 255 255 255 255 255 255 255
> 255 255 255 255 255 255 0 0 0 0 0 0 0 0 32 1 0 0 99 0 0 0] 98 0 1200 0 27
> 7 410 864 98 14 0 8224 98 2 8 1140916224 131073 9952 0 0 0 23 0 0 0 9952
> 930 8 ##(Smalltalk.SmalltalkWorkspace) 8 #resource_Default_view 0 978 202
> 208 98 1 1042 1072 98 2 754 1 217 754 577 69 9952 1138 8 #[44 0 0 0 0 0 0
> 0 1 0 0 0 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255
> 0 0 0 0 108 0 0 0 32 1 0 0 142 0 0 0] 1184 1200 0 27 3 16 234 256 98 4
> 8336 8 'temps' 9952 8 'inspector' 590342 ##(Smalltalk.Rectangle) 754 1 1
> 754 1 1 978 202 208 98 1 1042 1072 98 2 754 593 1 754 577 285 8224 1138 8
> #[44 0 0 0 0 0 0 0 1 0 0 0 255 255 255 255 255 255 255 255 255 255 255 255
> 255 255 255 255 40 1 0 0 0 0 0 0 72 2 0 0 142 0 0 0] 98 3 8336 410 2512 98
> 12 0 8224 98 2 8 1140850688 1 10496 0 482 656 0 519 0 0 0 10496 978 202
> 208 98 1 1042 1072 98 2 754 1 199 754 577 19 10496 1138 8 #[44 0 0 0 0 0 0
> 0 1 0 0 0 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255
> 0 0 0 0 99 0 0 0 32 1 0 0 108 0 0 0] 98 0 1200 0 27 9952 1200 0 27 13 2466
> 410 2512 98 12 0 3232 98 2 8 1140850688 1 10752 0 482 656 0 519 0 0 0
> 10752 978 202 208 98 1 1042 1072 98 2 754 575 1 754 19 285 10752 1138 8
> #[44 0 0 0 0 0 0 0 1 0 0 0 255 255 255 255 255 255 255 255 255 255 255 255
> 255 255 255 255 31 1 0 0 0 0 0 0 40 1 0 0 142 0 0 0] 98 0 1200 0 27 1 32
> 234 256 1184 0 978 202 208 98 1 1042 1072 98 2 754 1 1 754 1169 285 3232
> 1138 8 #[44 0 0 0 0 0 0 0 1 0 0 0 255 255 255 255 255 255 255 255 255 255
> 255 255 255 255 255 255 0 0 0 0 0 0 0 0 72 2 0 0 142 0 0 0] 98 3 3360
> 10752 8224 1200 0 27 2496 2768 1200 0 27 234 256 98 4 2304 8 'main' 560 8
> 'toolbar' 0 461638 4 ##(Smalltalk.MenuBar) 0 16 98 8 3746 0 16 98 8 3794
> 1 3826 8 #fileNew 8 '&New' 9373 1 3890 0 16 3936 8 'FileNew.ico' 3984 0 0
> 3794 1 3826 8 #fileOpen 8 '&Open...' 9375 1 3890 0 16 3936 8
> 'FileOpen.ico' 3984 0 0 3794 1 3826 8 #fileFileIn 8 '&File In...' 1 1 0 0
> 0 4370 4097 3794 1 3826 8 #saveImage 8 'Sa&ve Image' 1 1 3890 0 16 3936 8
> 'Snapshot.ico' 3984 0 0 3794 1 3826 8 #smalltalkExit 8 'E&xit Dolphin' 1 1
> 3890 0 16 3936 8 'PowerSwitch.ico' 3984 0 0 4370 4097 3794 1 3826 8 #exit
> 8 'Close' 17639 1 3890 0 16 3936 8 'CloseWindow.ico' 3984 0 0 8 '&File' 0
> 134217729 0 0 16889 0 0 3746 0 16 98 13 3794 1 3826 8 #undo 8 '&Undo' 9397
> 1 3890 0 16 3936 8 'EditUndo.ico' 3984 0 0 4370 4097 3794 1 3826 8
> #cutSelection 8 'Cu&t' 9393 1 3890 0 16 3936 8 'EditCut.ico' 3984 0 0 3794
> 1 3826 8 #copySelection 8 '&Copy' 9351 1 3890 0 16 3936 8 'EditCopy.ico'
> 3984 0 0 3794 1 3826 8 #pasteClipboard 8 '&Paste' 9389 1 3890 0 16 3936 8
> 'EditPaste.ico' 3984 0 0 3794 1 3826 8 #editDelete 8 '&Delete' 1 1 3890 0
> 16 3936 8 'EditClear.ico' 3984 0 0 3746 0 16 98 2 3794 1 3826 8
> #reformatSource 8 '&Source' 9391 1 0 0 0 3794 1 3826 8 #reformatComment 8
> '&Comment' 9367 1 0 0 0 8 'Ref&ormat' 0 134217729 0 0 16959 0 0 4370 4097
> 3794 1 3826 8 #selectAll 8 'Select &All' 9347 1 0 0 0 4370 4097 3794 1
> 3826 8 #editFind 8 '&Find...' 9357 1 3890 0 16 3936 47 786694
> ##(Smalltalk.ShellLibrary) 0 0 3794 1 3826 8 #findNext 8 'Find &Next'
> 1253 1 3890 0 16 3936 8 'FindNext.ico' 3984 0 0 3794 1 3826 8 #findReplace
> 8 '&Replace...' 9361 1 0 0 0 8 '&Edit' 0 134217729 0 0 17029 0 0 3746 0 16
> 98 17 3794 1 3826 8 #browseIt 8 '&Browse It' 9349 1 3890 0 16 3936 8
> 'ClassBrowserShell.ico' 3984 0 0 3794 1 3826 8 #displayIt 8 '&Display It'
> 9353 1 3890 0 16 3936 8 'DisplayIt.ico' 3984 0 0 3794 1 3826 8 #evaluateIt
> 8 '&Evaluate It' 9355 1 3890 0 16 3936 8 'EvaluateIt.ico' 3984 0 0 3794 1
> 3826 8528 8 '&Inspect It' 9363 1 8560 0 0 3794 1 3826 8 #debugIt 8 'Deb&ug
> It' 1 1 3890 0 16 3936 8 'Debugger.ico' 3984 0 0 3794 1 3826 8 #fileItIn 8
> 'Fi&le It In' 1 1 0 0 0 4370 4097 3794 1 3826 5696 8 'Defi&nitions...'
> 1271 1 0 0 0 3794 1 3826 5824 8 '&References...' 5367 1 0 0 0 4370 4097
> 3794 2097153 3826 8 #accept 8 '&Accept' 9383 1 3890 0 16 3936 8 'True.ico'
> 3984 0 0 3794 1 3826 8 #reformatAccept 8 'Refor&mat/Accept' 13479 1 0 0 0
> 3794 1 3826 8 #acceptNoRestart 8 'Acce&pt No Restart' 1 1 0 0 0 4370 4097
> 3746 0 16 98 13 3794 1 3826 8 #renameVariable 8 'Re&name <1d>...' 1 1 0 0
> 0 4370 4097 3794 1 3826 8 #extractToTemporary 8 'Extract to &Temporary...'
> 9385 1 0 0 0 3794 1 3826 8 #extractMethod 8 'E&xtract Method...' 9371 1 0
> 0 0 3794 1 3826 8 #extractToComponent 8 'Extract to &Component...' 1 1 0 0
> 0 3794 1 3826 8 #inlineMessage 8 'Inline &Message' 13467 1 0 0 0 4370 4097
> 3794 1 3826 8 #inlineTemporary 8 '&Inline Temporary' 13481 1 0 0 0 3794 1
> 3826 8 #moveTempToInnerScope 8 'Move to Inner &Scope' 9655 1 0 0 0 3794 1
> 3826 8 #convertTempToInstVar 8 'Con&vert to Instance Variable' 1 1 0 0 0
> 4370 4097 3794 1 3826 8 #inlineParameter 8 'In&line Parameter' 1 1 0 0 0
> 3794 1 3826 8 #removeParameter 8 'Remove &Parameter' 1 1 0 0 0 8
> 'Re&factorings' 8 #codeRefactoringsMenu 134217729 3890 0 16 3936 8
> 'Refactoring.ico' 3984 0 17159 0 0 4370 4097 3746 0 16 98 7 3794 1 3826 8
> #toggleAutoCompletion 8 '&Auto-complete' 1 1 0 0 0 3794 1 3826 8
> #toggleIndentationGuides 8 'Indentation &Guides' 1 1 0 0 0 3794 1 3826 8
> #toggleLineEndings 8 'Line &Endings' 1 1 0 0 0 3794 1 3826 8
> #toggleLineNumbers 8 'Line N&umbers' 1 1 0 0 0 3794 1 3826 8
> #toggleStyling 8 '&Syntax Coloring' 1 1 0 0 0 3794 1 3826 8
> #toggleWhitespace 8 'W&hitespace' 1 1 0 0 0 3794 1 3826 8 #toggleWordWrap
> 8 '&Word Wrap' 1 1 0 0 0 8 '&Options' 0 134217729 0 0 17215 0 0 8
> '&Workspace' 0 134217729 0 0 17217 0 0 3746 0 16 98 22 3794 1 3826 8
> #resumeProcess 8 'G&o/detach' 1257 1 0 0 0 3794 1 3826 8 #toggleAnimation
> 8 '&Animate' 1 1 0 0 0 3794 1 3826 8 #terminateProcess 8 '&Terminate' 5353
> 1 0 0 0 3794 1 3826 8 #killProcess 8 '&Kill' 1 1 0 0 0 3794 1 3826 8
> #userBreak 8 '&Break' 1 1 0 0 0 4370 4097 3794 1 3826 3856 8 'Step &Into'
> 1269 5 3890 0 16 3936 8 'StepInto.ico' 3984 0 0 3794 1 3826 4048 8 'Step
> O&ver' 1267 5 3890 0 16 3936 8 'StepOver.ico' 3984 0 0 3794 1 3826 4144 8
> 'Step O&ut' 5365 1 3890 0 16 3936 8 'StepOut.ico' 3984 0 0 3794 1 3826 8
> #runToCursor 8 'Run to &Cursor' 9459 1 3890 0 16 3936 8 'RunToCursor.ico'
> 3984 0 0 3794 1 3826 8 #runProcess 8 '&Run' 9449 1 3890 0 16 3936 8
> 'Run.ico' 3984 0 0 3794 1 3826 4304 8 'R&estart' 13545 1 0 0 0 3794 1 3826
> 4240 8 'Retur&n ...' 1 1 0 0 0 4370 4097 3746 0 16 98 0 8 'Im&plement in'
> 4448 134217729 0 0 17355 0 0 3746 0 16 98 14 3746 0 16 98 3 3794 1 3826
> 4528 8 'All...' 1 1 0 0 0 3794 1 3826 8 #renameMethodInHierarchy 8 'In
> &Hierarchy...' 1 1 0 0 0 3794 1 3826 8 #renameMethodInPackage 8 'In
> &Package...' 1 1 0 0 0 8 'Re&name' 0 134217729 0 0 17363 0 0 3794 1 3826
> 4656 8 'Rem&ove' 1 1 0 0 0 4370 4097 3794 1 3826 4736 8 'Add
> &Parameter...' 1 1 0 0 0 3746 0 16 98 0 8 'Remo&ve Parameter' 4816
> 134217729 0 0 17369 0 0 3746 0 16 98 0 8 'Rena&me Parameter' 4880
> 134217729 0 0 17371 0 0 3746 0 16 98 0 8 '&Inline Parameter' 4944
> 134217729 0 0 17373 0 0 4370 4097 3746 0 16 98 0 8 'Rename &Temporary'
> 5024 134217729 0 0 17375 0 0 3746 0 16 98 0 8 'Convert Temp to Inst. Var.'
> 5088 134217729 0 0 17377 0 0 4370 4097 3794 1 3826 5152 8 'Inline &Self
> Sends' 1 1 0 0 0 3794 1 3826 8 #pushUpMethods 8 'Push &Up' 1 1 0 0 0 3794
> 1 3826 8 #pushDownMethods 8 'Push &Down' 1 1 0 0 0 8 'Refactorin&gs' 5392
> 134217729 3890 0 16 3936 8 'Refactoring.ico' 3984 0 17385 0 0 4370 4097
> 3794 1 3826 8 #toggleBreakpoint 8 'Toggle Breakpoint' 1265 1 0 0 0 3794 1
> 3826 8 #toggleDisassembly 8 'Disasse&mbly' 9461 1 0 0 0 3794 1 3826 8
> #showNextStatement 8 'Show Ne&xt Statement' 17621 1 0 0 0 4370 4097 3746 0
> 16 98 2 3794 1 3826 5488 8 '&More' 1 1 0 0 0 3794 1 3826 5552 8 'A&ll' 1 1
> 0 0 0 8 'Call &Stack' 0 134217729 0 0 17397 0 0 8 '&Debug' 0 134217729 0 0
> 17399 0 0 3746 0 16 98 3 3794 1 3826 8 #undoChange 8 '&Undo <1d>' 1 1 3890
> 0 16 3936 8 'EditUndo.ico' 3984 0 0 3794 1 3826 8 #redoChange 8 '&Redo
> <1d>' 1 1 3890 0 16 3936 8 'EditRedo.ico' 3984 0 0 3794 1 3826 8
> #clearChangeHistory 8 'Clear Change &History' 1 1 0 0 0 8 'H&istory' 0
> 134217729 0 0 17407 0 0 3746 0 16 98 0 8 '&Tools' 8 #toolsMenu 134217729 0
> 0 17409 0 0 3746 0 16 98 0 8 'Wi&ndow' 8 #windowMenu 134217729 0 0 17411 0
> 0 3746 0 16 98 19 3794 1 3826 8 #helpContents 8 '&Contents' 1025 1 3890 0
> 16 3936 49 12800 0 0 3794 1 3826 8 #help 8 'On this &Tool' 1249 1 0 0 0
> 3794 1 3826 8 #helpWhatsThis 8 'What''s This?' 5345 1 0 0 0 4370 4097 3794
> 1 3826 8 #helpFirstSplash 8 'First Splash!!' 1 1 0 0 0 4370 4097 3794 1
> 3826 8 #helpWhatsNew 8 'What''s &New' 1 1 0 0 0 3794 1 3826 8
> #helpGuidedTour 8 '&Guided Tour' 1 1 0 0 0 3794 1 3826 8 #helpTutorials 8
> 'Tutorials' 1 1 0 0 0 3746 0 16 98 4 3794 2097153 3826 8 #tipOfTheDay 8
> '&Next Tip of the Day' 9441 1 3890 0 16 3936 8 'TipOfTheDay.ico' 3984 0 0
> 3794 1 3826 8 #previousTipOfTheDay 8 '&Previous Tip of the Day' 13537 1
> 3890 0 16 3936 8 'TipOfTheDay.ico' 3984 0 0 4370 4097 3794 1 3826 8
> #toggleShowTipsAtStartup 8 '&Show Tips at Startup' 1 1 0 0 0 8 'Tip of the
> &Day' 0 134217729 0 0 17433 0 0 4370 4097 3794 1 3826 8
> #objectArtsHomePage 8 'Object Arts Homepage' 1 1 0 0 0 3794 1 3826 8
> #dolphinNewsgroup 8 'Dolphin Newsgroup/Forum' 1 1 0 0 0 3794 1 3826 8
> #dolphinWikiWeb 8 'Dolphin WikiWeb' 1 1 0 0 0 3794 1 3826 8
> #myDolphinAccount 8 'My Dolphin Account' 1 1 0 0 0 4370 4097 3794 1 3826 8
> #dolphinLiveUpdate 8 'Check for Live &Updates...' 1 1 3890 0 16 3936 8
> 'LiveUpdate.ico' 3984 0 0 4370 4097 3794 1 3826 8 #aboutDolphin 8 '&About
> Dolphin Smalltalk' 1 1 3890 0 16 3936 8 '!!APPLICATION' 3984 0 0 8 '&Help'
> 0 134217729 0 0 17447 0 0 8 '' 0 134217729 0 0 0 0 0 0 0 0 1 0 0 0 0 1 0 0
> 978 202 208 98 2 1042 1072 98 2 754 3359 21 754 1201 801 416 1042 8
> #updateMenuBar 1184 416 1138 8 #[44 0 0 0 0 0 0 0 0 0 0 0 255 255 255 255
> 255 255 255 255 255 255 255 255 255 255 255 255 143 6 0 0 10 0 0 0 231 8 0
> 0 154 1 0 0] 98 2 560 2304 1200 0 27 )! !
> !StackDrawDebugger class categoriesFor:
> #resource_Default_view!public!resources-views! !
>
> "Binary Globals"!
>
>
>
Andreas Wacknitz
GLORP port some months ago. There were a lot of problems with inlined
messages like #yourself. The proxies used some messages to materialize
the real objects. Sigh.
Andreas
Wilhelm K. Schwab
>>>> The biggest competitor of Dolphin IMHO will be:
>>>> http://www.refactory.com/Software/SharpSmalltalk/Implementation.html
>>>
>>> It's possible but you do realize that those S# pages are over 4 years
>>> old. I'm not even sure whether The Refactory are working on S# any more.
>>
>> They *had to stop* development after they realized, that the .NET VM
>> didn't fully support *full dynamic languages*.
>
> Hmmm... IIRC S# was created by Don Roberts and John Brant of Refactory
> Inc. As witnessed by the fact that these are the same guys who created
> the Refactoring Browser, they are quite obviously smart cookies. Do you
> *really* think they didn't realize that the .NET VM didn't properly
> support full dynamic languages until they were half way through the
> development? I think you do them a disservice by even suggesting it. I
> can't speak for them of course but it is more likely is that they
> created S# purely as an experiment.
I agree to a point, but my impression at the time was that they actually
believed MS was going to support dynamic languages. They are smart
indeed, perhaps slightly naive and just plain betrayed.
Bill
Wilhelm K. Schwab
> Let's say that Blair judged that the 64 bit VM work should cost in the
> region of $10,000 (as yet, I have no idea of this amount). If we have 30
> pledges of $200, 20 of $500 and 12 of $1000 this would mean we could
> finance the development work at either of the latter two price points.
> We would then choose the lower ($500) and start development.
>
> Pledgers would not be asked for the $500 upgrade fee until the new
> version is complete (although perhaps a small "beta registration" fee to
> join the beta programme might be requested to show good faith).
>
> Once the final release is available it would then be offered to other
> (non-pledging) users for at least the original pledgers upgrade fee
> (i.e. at least $500). The intention is that there would be no
> disadvantage to being an early adopter/pledger.
>
> My aim was to makes thing clearer, however this post has turned out
> rather longer than I'd expected, so I hope it hasn't ending up
> increasing the confusion.
$200 is a given, and I would probably pay $500. At $1000, I might have
to seriously consider sending that money to Steve Jobs; the forces there
are complicated and unclear. Start supporting Linux/mac, and my
interest would rise greatly.
There has been mention of DNG and Linux, but I have no basis on which to
evaluate that given that you are not the one calling the shots.
Bill
Shaping
Andy, thanks for clarifying. I misread/misunderstood twice.
I see now that we have the possible 64-bit D64 (to be called Dolphin 7) from
OA, if we get the needed funding from Dolphin fans, and the entirely
separate DNG (currently running on a 32-bit VM and hopefully soon on a
64-bit VM) from LSW.
My concern: I've read that DNG supports the current Dolphin Pro class
frameworks via SSLs, as if the DNG Dolphin SSLs are a snapshot of Dolphin
Pro at some recent point in its evolution. Will DNG continue to be updated
with the latest and greatest Dolphin class frameworks as the OA Dolphin
products evolve? Or, is there now, with the creation and launch of DNG, a
split and a starting over in this regard, where LSW will continue
independent development of the initial Dolphin frameworks in a separate
direction? Will there be significant divergence of Dolphin and DNG class
frameworks?
DNG will likely be significantly more expensive than D64, and I prefer not
to own both if possible. However, I like the Dolphin frameworks and want to
continue to benefit from them.
Shaping
"Andy Bower" <bo...@SnipThisObject-arts.com> wrote in message
news:7mi62fF...@mid.individual.net...
> Udo, Shaping,
>
>>> Andy, I recently responded to this, and just now realize that I did not
>>> read it carefully. I see that you mean the entire price of the new DNG.
>>> I thought we were talking about only the cost the 64-bit version after
>>> we have paid for the normal price for the 32-bit version (whatever that
>>> is). In any case, I will pay as much as $1000.
>> I still do understand Andys mail as "only" covering the current DST -
>> just with a 64bit VM.
>>
>> @Andy: Could you please clarify? Otherwise this thread might not be
>> usefull at all :-(
>
> Okay, sorry for the confusion, I'll attempt to clarify things here.
>
> First of all, the 64 bit VM version of Dolphin we are talking about here
> is nothing to do with DNG. Let me explain:
>
> DNG
>
> DNG is not an Object Arts product although it is endorsed by us. At some
> point DNG *may* be sold by us as an addition to the current product line.
> As I understand it DNG will be a high performance, cutting edge Smalltalk
> running Dolphin frameworks. Initially, DNG will be offered as 32 bit only
> but the capability is there to produce a 64 bit version in future (and
> possibly even Linux/Mac versions too).
>
> However, there are a number of reasons why existing (and new) Dolphin
> users might wish to stay with the current (OA) products rather than moving
> to DNG. One of these reasons *may* be price. It is difficult to speak in
> exact terms about this due to Frank's and Alejandro's decision to only
> discuss DNG pricing and features under the cloak of an NDA. I understand
> why they have chosen this route but, personally, I think it's a mistake as
> it creates confusion and suspicion in the minds of potential customers.
>
> If you are curious as to whether you should stick with OA Dolphin in
> future or plan for DNG then I urge you to contact Frank Lesser and discuss
> the possibilities that DNG will offer. He will ask that you sign an NDA
> but, after that, you should learn about pricing and projected timescales.
>
> D32 & D64
>
> Let's call the existing product line using the OA interpretive VM, D32.
>
> What we are talking about in this thread is an attempt to revitalize this
> line by adding a 64 bit version, which we can call D64. Then OA would have
> two products, D32 and D64. The new version will likely be similar to the
> 6.1 beta with a few other features (along the lines that Udo suggested
> earlier) and the twin 32/64 bit VMs. I think we'd call it Dolphin 7.
>
> What I am asking in this thread is how many people are interested in such
> a move forward and how much are they willing to "pledge" to make it
> happen. Since I am mostly likely "preaching to the choir" in that most
> people reading this are already DPRO customers, the amounts we are talking
> about are upgrade fees from the existing D6PRO32.
>
> So I have asked existing users to choose the maximum amount you would
> pledge to upgrade from D6PRO32 to a new package comprising D7PRO32 *and*
> D7PRO64. To make it easier, I gave three possible options: $200, $500 and
> $1000. Some people may want to use the 64 bit version straightaway but
> others may just be happy to pay an upgrade fee and use D7PRO32. That way
> they would get some new features and bug fixes in D7 with the additional
> security of knowing that a 64 bit VM is available when needed in the
> future.
>
> HOW THE PLEDGING WILL WORK
>
> Note that, even if you "pledge" a maximum of $1000 for the upgrade, that
> may not be the final amount you end up having to pay. The important thing
> will be for us to find an amount that has sufficient respondents to make
> the development worthwhile (in effect, to pay for the work).
>
> Let's say that Blair judged that the 64 bit VM work should cost in the
> region of $10,000 (as yet, I have no idea of this amount). If we have 30
> pledges of $200, 20 of $500 and 12 of $1000 this would mean we could
> finance the development work at either of the latter two price points. We
> would then choose the lower ($500) and start development.
>
> Pledgers would not be asked for the $500 upgrade fee until the new version
> is complete (although perhaps a small "beta registration" fee to join the
> beta programme might be requested to show good faith).
>
> Once the final release is available it would then be offered to other
> (non-pledging) users for at least the original pledgers upgrade fee (i.e.
> at least $500). The intention is that there would be no disadvantage to
> being an early adopter/pledger.
>
> My aim was to makes thing clearer, however this post has turned out rather
> longer than I'd expected, so I hope it hasn't ending up increasing the
> confusion.
>
Guido Stepken
Franks work, expecially his "Just In Time Compiler", which is written in
- yes, 386 Assembler!!!!! I'm a assembler freak too :)
Fastest VM / Jitter for full dynamic languages on earth, hopefully the
fastest Smalltalk on earth - faster than C!!! And - very compact code,
this Jitter generates!!!! Very small executables.
Going 32/64bit, means 32bit instruction, 64bit data (AMD allows this) or
full 64bit - there has a lot of work to be done. Not that much to get
64bit code generated, but optimizing for performance and - IMHO the most
time consuming part - getting the debugging right.
Frank simply underestimated the work even for the DNG 32bit VM to be
done. He's perfectionist. Debugging Smalltalk even at machine code level
... "wow", i must say! And - Frank introduced a new concept of "garbage
collection", very similar (IMHO) to that, what makes the new performance
boost in JAVA6!
So 64bit ... well, IMHO, 32bit instruction code will do the next few
decades ... 64 bit databases adress space is already there ....
But he (and Ale) seem to come to an end very soon ... stay tuned!
regards, Guido Stepken
Travis Kay
> But he (and Ale) seem to come to an end very soon ... stay tuned!
I'm still tuned in, just not happy about the process. I think your
post had some more sound bites then I've seen elsewhere recently.
Thanks.
> regards, Guido Stepken
Malbs
$500 possibly.
I'd love to see a 64 bit VM and (hopefully) full unicode support.
Andy Bower
> My concern: I've read that DNG supports the current Dolphin Pro class
> frameworks via SSLs, as if the DNG Dolphin SSLs are a snapshot of
> Dolphin Pro at some recent point in its evolution. Will DNG continue to
> be updated with the latest and greatest Dolphin class frameworks as the
> OA Dolphin products evolve? Or, is there now, with the creation and
> launch of DNG, a split and a starting over in this regard, where LSW
> will continue independent development of the initial Dolphin frameworks
> in a separate direction? Will there be significant divergence of
> Dolphin and DNG class frameworks?
I don't think so but Frank should clarify this. At present DNG is based
on a snapshot of the D6.1 codebase. Future versions of the Dolphin
frameworks will also be made available so that the two product lines can
be kept in step.
At some point it will hopefully be possible to perform the development
off a single codebase but this is some way off.
Best regards
Andy Bower
Frank Lesser [LSW]
yes there are differences in the framework of DNG round 0, we try to keep
small as possible.
Depending of what one wants to do these differences are minimal or can be
enormous:
DNG is Unicode based whereas Dolphin is ANSI. This is difference hidden in
the framework classes.
DNG-VM has no Object-Table - thus making become a costly operation. As
mentioned earlier in we have several ways around this problem.
DNG-VM has no way to make single objects immutable - also here are ways
around this problem.
DNG-VM has differs in the way fixed objects are created.
the representation of CompiledCode is diifferent, bytecode is different,
primitives are different.
Associations instance-vars are swapped.
they way DNG starts is different: DNG-VM starts without an image. Only a
base-sll is needed. This base sll further boots DNG. After the boot process
is finished an image can be saved.
DNG-VM is multithreaded - but do not make use of this feature in most of the
framework classes.
I also vote for maintaining a synchronized code-base.
But for now we are busy with the open issues and with Unit testing.
The most important technical reason for creating a 64Bit VM based on D6 VM
is integration with Win64.
Frank
Guido Stepken
> DNG-VM has no Object-Table - thus making become a costly operation. As
> mentioned earlier in we have several ways around this problem.
Nice details.
But - What's the reason for "no object table"? Advantage for customer?
> DNG-VM has no way to make single objects immutable - also here are ways
> around this problem.
Advantage for customer?
> DNG-VM has differs in the way fixed objects are created.
Where's the advantage for customer?
> the representation of CompiledCode is diifferent, bytecode is different,
> primitives are different.
> Associations instance-vars are swapped.
Advantage for customer?
> they way DNG starts is different: DNG-VM starts without an image. Only a
> base-sll is needed. This base sll further boots DNG. After the boot process
> is finished an image can be saved.
Where's the advantage for customer?
> DNG-VM is multithreaded - but do not make use of this feature in most of the
> framework classes.
Advantage for customer? Why not? What's about multi-processor support?
> I also vote for maintaining a synchronized code-base.
Advantage for customer?
> But for now we are busy with the open issues and with Unit testing.
Advantage for customer? Ever heard of "Linus law"?
> The most important technical reason for creating a 64Bit VM based on D6 VM
> is integration with Win64.
Advantage for customer?
regards, Guido Stepken
Andy Bower
Are you serious?
> But - What's the reason for "no object table"? Advantage for customer?
Speed.
>> DNG-VM has no way to make single objects immutable - also here are
>> ways around this problem.
>
> Advantage for customer?
Speed.
>> DNG-VM has differs in the way fixed objects are created.
>
> Where's the advantage for customer?
Speed.
>> the representation of CompiledCode is diifferent, bytecode is
>> different, primitives are different.
>> Associations instance-vars are swapped.
>
> Advantage for customer?
Speed.
<snip>
>> I also vote for maintaining a synchronized code-base.
>
> Advantage for customer?
Price and reliability.
>
>> But for now we are busy with the open issues and with Unit testing.
>
> Advantage for customer?
Fewer bugs.
Ever heard of "Linus law"?
No. But I just Googled it. And your point is?
Andy Bower
Guido Stepken
> Guido,
>
> Are you serious?
Oh, yes!
>> But - What's the reason for "no object table"? Advantage for customer?
>
> Speed.
Speed's always fine :-)
Advantage for customer? Do I get my programming job done quicker? Does
the customer have any advantage? Can he probably type or click quicker?
Are your goals the customers (programmer's) goals or is it just your
fetischism (The brand new XEON i7 is about 3 times faster that last
XEON! - that will compensate all your tuning efforts :-( )
>>> But for now we are busy with the open issues and with Unit testing.
>>
>> Advantage for customer?
>
> Fewer bugs.
>
> Ever heard of "Linus law"?
>
> No. But I just Googled it. And your point is?
You will find out, hopefully soon! All i can say - it's some sort of
"magic process design" which enormously can reduce development cost :-)
> Andy Bower
Have fun, Guido Stepken
Frank Lesser [LSW]
as people know me I am always technical in public.
OK what is important Dolphin development goes on.
Dolphin 6 VM is advanced and that Andy announce possibility of having a new
version is great news.
That is advantage for all customers
- whether they are hobby programmers - willing to buy a professional edition
of Dolphin - in times when you can get a lot of dev-envs just for free.
- or professional Software Developers - seeing that one of the best
dev-environments for Windows development is alive and kicking & worth a
decision.
I am against OpenSource - sorry to say that - I cant see advantage for
customers - cheap or free means low quality in the long term.
ClosedSource to comply with RiskManagement is ok - but it has its price.
Frank
Guido Stepken
their 'usability look, feel' seem to change.
Please have a look at this GUI first, enjoy!
Isn't that pure beauty? Can u imagine to have such a IDE, yes, even
(database) application?
Then look at your old fashioned IDE. Overloaded with little symbols,
functionality. For a professional programmer, ok, functionality is
speed. For a beginner, it's horror.
How can you gain market shares in future? Win back old customers, extend
your business?
Apple shows, how important "beauty" of GUI's (without having to miss
functionality) really is. Have a look at iWorks. Same concept like
ommwriter.
It's the beauty of simplicity that rises acceptance enormously. I am
stressed by these overloaded IDE's GUI's. Not really helpful to find
into the mental model behind a programming language, the concept of IDE.
I promise, that nobody in very soon future is willing to use that old
fashioned GUI stuff any longer.
Therein lies a big chance to gain new market shares. Did you notice,
that "usability companies" are exploding around the globe?
The first company, that will be able to offer such a "innovative" GUI,
will win the race.
And - have a look at 'palm pre' and 'android', 'GoogleOS' those little
GUI's for pocket computers. Their "look and feel" is beauty and many
companies see that, offer that functionality and "look and feel" for
desktop computing. OpenGL Hardware behind. It's cheap. See TI OMAP chip.
Have you already seen FLUX Library for OpenGL GUI? No? See here:
http://www.youtube.com/watch?v=4vo0yK7P8-s
In very soon future i see a 32bit renaissance. Browser OS, OpenGL
built-in. A new standard coming up. No - no more GUI/OS wars!
I see Javascript as "new mainstream programming language". A de facto
standard already. Nobody sees, that Javascript is in reality SMALLTALK!
Yes! Same mental models there behind! Even a ST2JS - Translator is
there! http://www.squeaksource.com/ST2JS/
Means - new way's of interactivity, easy to do, even by non-programmers,
e.g. (sorry german, but functionality, that counts!):
http://www.destatis.de/bevoelkerungspyramide/
Smalltalk - by design, due to its flexibility - will play a huge role in
future gui's, IMHO. The frontier between programmers and users will
simply disappear!
So IDE's and GUI's of the past, overloaded with functionality, ugly,
rectangular 'static', 'unanimated' windows, 'pull down menu's' - that
stuff all will disappear in very near future. In 2-3 years, i think.
And - it's a new chance expecially for the Smalltalk language to start
off! Squeak Etoys was the first GUI, where non-programmers, yes, even
children could 'programm', do funny things in their mother language. No
need to learn any 'programming language'. Strange, isn't it?
Microsoft .NET - the former "Standard" - C#, C++, win32, win64, SQL
databases - lightyears crawling behind.
"This is the end, my friend" :-)
Have fun, Guido Stepken
Travis Kay
software.com> wrote:
> Dear all,
>
Thank you for clarifying this.
>
> Frank
Guido Stepken
> Hi Guido,
>
> as people know me I am always technical in public.
Yes, i do :-)
> OK what is important Dolphin development goes on.
> Dolphin 6 VM is advanced and that Andy announce possibility of having a new
> version is great news.
>
> That is advantage for all customers
> - whether they are hobby programmers - willing to buy a professional edition
> of Dolphin - in times when you can get a lot of dev-envs just for free.
> - or professional Software Developers - seeing that one of the best
> dev-environments for Windows development is alive and kicking & worth a
> decision.
Ok, to make long things short: Those technical details may sound
important (speed ...), but where is the advantage for the customer, the
software developer, what makes him paying update fees, where is his
advantage, where can he save money with?
And some additional note:
I really appreciate Andy's video's, where he shows, how to develop a
nice aviation application. As far as i remember, he mentions, hat the
GUI Templates are only available in the professional version.
Hmm, i asked myself, expecially these templates should be in the free
beginners version ... Dolphin free edition as 'crippleware'?
> I am against OpenSource - sorry to say that - I cant see advantage for
> customers - cheap or free means low quality in the long term.
Hmmm, HMHO you all still haven't really understood the real sense of
opensouce. Please revisit Google and "Linus law" !
> ClosedSource to comply with RiskManagement is ok - but it has its price.
If i were a decision maker, i wouldn't make my enterprise dependant on a
development team of at least 1 core developer and 2 'helpers' and a
product, wich was already announced to be discontinued.
Think strategic! Would you rely on such an enterprise or product?
So, consequently, (IMHO) the O N L Y chance you have (Frank, Ale, Andy,
...)
to make it opensource to enable customers to continue the product in case
of bankruptcy.
These ist the 1st problem you had to solve. But you still don't.
And no Andy - this is nothing against you and your product. It's a fact,
you shouldn't abnegate.
regards, Guido Stepken
GallegO
Smalltalk is open source! Yes of course in the case of Dolphin the VM
is not open source but this really matters?
You can count with one hand fingers the hackers currently available to
touch a modern and production level VM.
As you can see, Andy says that only Blair can work on the Dolphin VM,
you really think that others, outside Object-Arts can work on the VM?
Can you see any progress on strongtalk or with the strongtalk VM,
recently (recently in Smalltalk time :) being open source?
I don't see any advantages on Dolphin being open source.
Best Regards
Sebastian Calvo
Guido Stepken
> Hi Guido:
>
> Smalltalk is open source! Yes of course in the case of Dolphin the VM
> is not open source but this really matters?
> You can count with one hand fingers the hackers currently available to
> touch a modern and production level VM.
> As you can see, Andy says that only Blair can work on the Dolphin VM,
> you really think that others, outside Object-Arts can work on the VM?
> Can you see any progress on strongtalk or with the strongtalk VM,
> recently (recently in Smalltalk time :) being open source?
> I don't see any advantages on Dolphin being open source.
>
> Best Regards
> Sebastian Calvo
No problem. E.g. i've learned how to build my own compiler at
university, programmed 6510, Z80, 8080, 80386, Sparc, ALPHA and ARM
assembler. Depends on how well that stuff is documented.
I would like to remember here again to "linus law". There are many many
assembler freaks out there in the wild. Not just Frank and Blair!
Have fun, Guido Stepken
Shaping
> the framework classes.
I need to be sure that our definitions are the same.
I want to be able to have one thread in one OS process start a second and a
third single-threaded OS process. I call this "multiprocessing". The
threads have their own respective application memory spaces, and must
exchange data/signals asynchronously with, say, TCP/IP sockets.
I also want to be able to have one thread in one OS process create a second
and a third thread in the same OS process. I call this "multithreading".
The threads run in one application memory space, potentially sharing data,
and must be careful to take turns locking resources they change. There is
some contention for the data, but there is a also a saving of bandwidth in
not having to move large amounts of data between separate OS processes.
Are both scenarios possible with DNG?
Shaping
Frank Lesser [LSW]
In DNG we have the both, the old green thread ( Process ) & the OS-Process
( SmalltalkThread )
green threads share the Windows Message Queue, while each SmalltalkThread
instance has its own.
SmalltalkThread instances can benefit from a multicore system whereas
Process instances cannot.
Objects which need to be passed along between Smalltalk threads must
implement their thread-savety.
The VM has support for that.
Frank
"Shaping" <sha...@bigfoot.com> schrieb im Newsbeitrag
news:Jq5Pm.87$Lq5...@newsfe20.iad...
Guido Stepken
> Yes our definitions are the same.
> In DNG we have the both, the old green thread ( Process ) & the OS-Process
> ( SmalltalkThread )
> green threads share the Windows Message Queue, while each SmalltalkThread
> instance has its own.
> SmalltalkThread instances can benefit from a multicore system whereas
> Process instances cannot.
> Objects which need to be passed along between Smalltalk threads must
> implement their thread-savety.
> The VM has support for that.
>
> Frank
Hi Frank!
Did you already do a full redesign of Dolphin GUI to support
multithreading or even multi processors? Just to have multithreading in
the VM is pretty useless, IMHO. The complete class / dependency system
has to be adapted.
Btw. Does Dolphin support /partial continuations/? Seaside seems to have
changed from full to partial continuations!
regards, Guido
Guido Stepken
> Regarding the rest of what you're saying, the best I can figure is you
> are focused solely on the GUI.
Yes. As you know, customers always decide for a product with the most
elegant (and functional) design.
Look at the customers point of view. He wants a formular with database
access to scroll through the data sets.
Dolphin e.g. suggests: Create a controller, choose a view ... connector
... Ok, customer sais, too complicated, let's go MS Access!
Again a lost potential customer for Smtalltalk solutions and future
business. The entry hurdle is much too high. Professionals don't see
that. The suffer from tunnel vision.
> I don't think at all that Dolphin's GUI
> has been a critical issue in its acceptance.
As far as i can tell you, from my experience with children and teaching
them programming, Dolphin is absolutely unacceptable. So over long time
Dolphin looses market shares, if there is no "simplified version" for
educational purposes.
In germany schools go Java and BlueJ Framework. No Smalltalk.
> All other programmer
> development tools provide a similar interface, some better and some
> worse.
Yes, a huge problem for beginners and expecially teachers.
...
> -- Louis
regards, Guido Stepken
Andy Bower
>> I don't think at all that Dolphin's GUI has been a critical issue in
>> its acceptance.
>
> As far as i can tell you, from my experience with children and teaching
> them programming, Dolphin is absolutely unacceptable. So over long time
> Dolphin looses market shares, if there is no "simplified version" for
> educational purposes.
I totally agree with you that the current Dolphin UI is inappropriate
for children. But it was never meant to be - it was intended for
professionals and hobbyist students/adults.
However, don't assume that no one is interested in filling this gap. For
example, at the beginning of the summer I started a project in Dolphin
aimed at 8yo children (and upwards) with the idea to get them learning
programming using Smalltalk. It's no coincidence that my two eldest
children match this age range (being aged 8 and 13) since I cruelly
intended using them as programming guinea pigs.
So far the project, written in Dolphin and entitled "Aragon 3D", is
still a work in progress. The idea was to capture the attention of the
kids by giving them a dynamic 3D environment that is
programmable/scriptable in Smalltalk to do the sort of stuff they might
be interested in. Here's a recent screen shot:
The aim is for the kids to be able to do some simple exploratory
programming, like the Squeak eToys demos, but in an environment that
piques their interest. I was particularly concerned with programming
with real "words" rather than by using drag and drop style "blocks" that
you see in eToys or in the Lego NXT programming environment for example.
I wanted to do this to reflect that a programming language is just that,
a *language* to enable a dialogue between a human and a computer.
The current system is far from complete and still way too complex for my
8yo son although he is certainly excited by it. My 13yo just about gets
it and, with help, can make some progress getting 3D models to fight
(sigh) each other. Neither have really programmed anything before.
Unfortunately, I've had to put Aragon on the back burner for now while I
attend to some "real work". Hopefully, I'll get back to it at some point
to wrap it up into a releasable state so others can perhaps take it
forwards.
Best regards
Andy Bower
Bruno Buzzi Brasesco
Friedrich Dominicus
> Guido,
>
>>> I don't think at all that Dolphin's GUI has been a critical issue
>>> in its acceptance.
>>
>> As far as i can tell you, from my experience with children and
>> teaching them programming, Dolphin is absolutely unacceptable. So
>> over long time Dolphin looses market shares, if there is no
>> "simplified version" for educational purposes.
>
> I totally agree with you that the current Dolphin UI is inappropriate
> for children. But it was never meant to be - it was intended for
> professionals and hobbyist students/adults.
>
> However, don't assume that no one is interested in filling this
> gap. For example, at the beginning of the summer I started a project
> in Dolphin aimed at 8yo children (and upwards) with the idea to get
> them learning programming using Smalltalk. It's no coincidence that my
> two eldest children match this age range (being aged 8 and 13) since I
> cruelly intended using them as programming guinea pigs.
>
> So far the project, written in Dolphin and entitled "Aragon 3D", is
> still a work in progress. The idea was to capture the attention of the
> kids by giving them a dynamic 3D environment that is
> programmable/scriptable in Smalltalk to do the sort of stuff they
> might be interested in. Here's a recent screen shot:
Isnt that the Squeak development model? I just can say Squeak is the
worst stuff I've ever seen for GUI programming. Nothing is traditional,
you can not get along with what you have learned everywhere else. I just
can say that Seaside is a pleasure to use. So how about a Seaside with a
decent View part not that generation of HTML with Smalltalk. And a very
easy interface to all kind of relational databases a ORM Wrapper like
Rails for Ruby would be "great".
It feels
ugly, but if you'd provide a sort of GUI Builder for Seaside, this would
be quite a nice thing to have.
Howerver if this Smalltalk will live on on the Windows platform it might
be best to have it simply emit CRL code. Given access to all the
available libraries and what else. I just can compare it to JRuby which
runs on the Java VM, because of this I'm going to use it in some
programming undertaking. I have though about Seaside also but I've done
too less work with it to really make it usefule for me. I've done my
share with Rails and am quite comfortable there. For me a Rails for
Smalltalk (maybe Snails) would be a bummer ;-)
Howerver I can fully understand the frustration of the original
developer. It's unfortunate that development tools are "supposed to be
just there" and free. So even if Smalltalk is way better than Java, you
simply can not compete with a 0 price tag. Sun has paid dearly for Java,
and well it might be it's tombstone also. Who knows what will happen if
Sun is overtaken....
Another bit trouble spot is that you write for a certain Smalltalk and
this probably hinders the acceptance of Smalltalk more than anything
else. But I may be wrong about that....
I was also wrong about the "naive" idea that good language would feed
at least their inventors. This may hold for a few languages but surely
not for the majority, and in a minority smalltalk is another
minority,....
Regards
Friedrich
--
Please remove just-for-news- to reply via e-mail.
jarober
We provide a scaffolding (UI) layer on top of Seaside, with
ActiveRecord database mapping. There are a bunch of video demos on
the site, as well as links to the evaluation download
On Nov 27, 10:04 am, Friedrich Dominicus <just-for-news-fr...@q-
Snorik
solutions.de> wrote:
> It feels
> ugly, but if you'd provide a sort of GUI Builder for Seaside, this would
> be quite a nice thing to have.
Did you have a look at SeaBreeze? Heeg Contribution, a Seaside GUI
Builder written in Seaside.