f



Strange look&feel of DNG.

I see these screenshots: http://www.dng.st/dng_round_0.htm

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...
0
alex_wh (1)
11/11/2009 8:32:24 AM
comp.lang.smalltalk.dolphin 3769 articles. 0 followers. Post Follow

103 Replies
1384 Views

Similar Articles

[PageSpeed] 7

your conclusion is wrong.
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" <alex_wh@mail.ru> schrieb im Newsbeitrag 
news:592279a0-b609-41e7-a778-9be9a7bf8b7e@l13g2000yqb.googlegroups.com...
>I see these screenshots: http://www.dng.st/dng_round_0.htm
>
> 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... 


0
Frank
11/11/2009 9:01:50 AM
Frank Lesser [LSW] schrieb:
> DNG as Dolphin uses Windows & do not bitblt as some other Smalltalks.
> There is still a glitch in adjusting the thing.
The website states

[...]
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
0
Udo
11/11/2009 9:30:07 AM
On 11 =D0=BD=D0=BE=D1=8F, 12:30, Udo Schneider <Udo.Schnei...@homeaddress.d=
e> wrote:
> Frank Lesser [LSW] schrieb:> DNG as Dolphin uses Windows & do not bitblt =
as some other Smalltalks.
> > There is still a glitch in adjusting the thing.
>
> The website states
>
> [...]
> 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

I'm interesting in DNG too, but not ready to buy a pig in a poke yet.
0
Dmitry
11/11/2009 11:03:55 AM
On Nov 11, 1:30=A0am, Udo Schneider <Udo.Schnei...@homeaddress.de>
wrote:
> Frank Lesser [LSW] schrieb:> DNG as Dolphin uses Windows & do not bitblt =
as some other Smalltalks.
> > There is still a glitch in adjusting the thing.
>
> The website states
>
> [...]
> 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? :-)

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

0
Travis
11/12/2009 4:38:06 PM
On Nov 11, 3:03=C2=A0am, Dmitry Zamotkin <zamot...@gmail.com> wrote:
> On 11 =D0=BD=D0=BE=D1=8F, 12:30, Udo Schneider <Udo.Schnei...@homeaddress=
..de> wrote:
>
>
>
> > Frank Lesser [LSW] schrieb:> DNG as Dolphin uses Windows & do not bitbl=
t as some other Smalltalks.
> > > There is still a glitch in adjusting the thing.
>
> > The website states
>
> > [...]
> > 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
>
> I'm interesting in DNG too, but not ready to buy a pig in a poke yet.

Agreed.
0
Travis
11/12/2009 4:38:59 PM
Travis Kay wrote:
> On Nov 11, 1:30 am, Udo Schneider <Udo.Schnei...@homeaddress.de>
> wrote:
>> The website states
>>
>> [...]
>> 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? :-)
> 
> 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.
> 

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
0
Christopher
11/12/2009 11:40:53 PM
Hi Frank.

When can we expect a 64-bit VM for DNG?


Shaping 
0
Shaping
11/13/2009 6:09:34 AM
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.

"Shaping" <shaping@bigfoot.com> schrieb im Newsbeitrag 
news:SK6Lm.114$kY2.7@newsfe01.iad...
> Hi Frank.
>
> When can we expect a 64-bit VM for DNG?
>
>
> Shaping 


0
Frank
11/13/2009 11:25:31 AM
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.
How to purchase?

Best Regards,

Udo
0
Udo
11/13/2009 12:11:56 PM
On 13 Nov., 13:11, Udo Schneider <Udo.Schnei...@homeaddress.de> wrote:
> 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.
>
> How to purchase?
>

How about pricing?

How about getting access to bugfixes and updates?

0
Snorik
11/13/2009 12:36:56 PM
On Nov 13, 3:25=A0am, "Frank Lesser [LSW]" <frank-les...@lesser-
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 th=
e
> 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$kY2.=
7@newsfe01.iad...
>
>
>
> > Hi Frank.
>
> > When can we expect a 64-bit VM for DNG?
>
> > Shaping- Hide quoted text -
>
> - Show quoted text -

0
Travis
11/13/2009 6:01:48 PM
Travis and others,

> 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
0
Andy
11/13/2009 7:03:04 PM
IMHO I dont need DNG right now, Dolphin6 is an excellent platform and
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.

0
dcoronel32
11/13/2009 7:10:59 PM
> 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

0
Travis
11/13/2009 9:02:06 PM
On Nov 13, 11:10=A0am, "dcorone...@gmail.com" <dcorone...@gmail.com>
wrote:
> IMHO I dont need DNG right now, Dolphin6 is an excellent platform and
> 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.

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.
0
Travis
11/13/2009 9:07:06 PM
Diego,

> 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
0
Andy
11/14/2009 2:07:19 PM
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, 
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
0
Louis
11/14/2009 11:13:29 PM
>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
0
IanB
11/15/2009 8:13:33 AM
Louis Sumberg schrieb:
> 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,
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.
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
0
Andreas
11/15/2009 8:51:54 AM
IanB schrieb:
>> 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

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
0
Guido
11/15/2009 9:42:45 AM
If I could chime in, I would also say that I do not see a lot of
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).

rush
http://www.cloud208.com/
0
rush
11/15/2009 11:01:19 AM
> 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.

If the VM has to garbage collect on a 64-bit address space, I doubt one 
would see a speed increase.

--g


0
geoff
11/15/2009 3:39:39 PM
On 14 =D0=BD=D0=BE=D1=8F, 20:07, Andy Bower <bo...@SnipThisObject-arts.com>=
 wrote:
> 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.
It is too hard to write assembler code in all times, moreover for 64-
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.
0
HandleX
11/15/2009 4:14:18 PM
Andreas, Louis,

>> 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
0
Andy
11/15/2009 5:38:22 PM
Alex,

> 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
0
Andy
11/15/2009 5:40:27 PM
[...]
> 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 

0
Shaping
11/15/2009 11:55:16 PM
I understand why "now" nobody needs 64 bits and the possible drawbacks
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


On 15 nov, 17:55, "Shaping" <shap...@bigfoot.com> wrote:
> [...]
>
> > 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. =A0Other benefits include much larger
> > SmallIntegers...".
>
> Yes, and Double floating-point, as well.
>
>
>
> >http://www.cincomsmalltalk.com/userblogs/cincom/blogView?content=3Droadm=
ap
>
> > 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 liab=
le
> > 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 b=
it
> > will become another check box left empty on some management comparison =
of
> > potential development tools.
>
> Exactly. =A0Those "check boxes" really matter to those in management, mak=
ing
> 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 machi=
ne.
> I will be getting another machine with 32 GB, in the next six months. =A0=
 I
> intend to use all of this memory, too. =A0A database would be too slow, e=
xcept
> for cold persistence of the app's model following shutdown of the app. =
=A0All
> objects must be live for the application run at acceptable speeds.
>
> Shaping

0
dcoronel32
11/16/2009 2:08:26 PM
Diego, thanks for your predictions, summaries of the pertinent issues, 
and compelling arguments for action and patience.

-- Louis
0
Louis
11/16/2009 2:48:26 PM
Shaping schrieb:

> 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
0
Guido
11/16/2009 11:48:15 PM
Andy Bower <bower@snipthisobject-arts.com> wrote:
> 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.
0
gavin
11/17/2009 1:20:18 AM
"Guido Stepken" <gstepken@googlemail.com> wrote in message 
news:hdsoa0$tl0$01$1@news.t-online.com...
> Shaping schrieb:
>
>> 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?

....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

 

0
Shaping
11/17/2009 7:52:06 AM
Folks,

> 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
0
Andy
11/17/2009 5:44:00 PM
Andy,
> 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
0
Udo
11/17/2009 6:45:49 PM
Andy,

>    - 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
0
Udo
11/17/2009 6:47:19 PM
Udo Schneider schrieb:
> Andy,
>> 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
Good ideas,

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

0
Andreas
11/17/2009 7:09:56 PM
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.

Shaping

"Andreas Wacknitz" <a.wacknitz@gmx.de> wrote in message 
news:7mgao4F3i3lfoU1@mid.individual.net...
> Udo Schneider schrieb:
>> Andy,
>>> 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
> Good ideas,
>
> 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
> 
0
Shaping
11/18/2009 6:26:30 AM
On Nov 17, 8:45=A0pm, Udo Schneider <Udo.Schnei...@homeaddress.de>
wrote:
> =A0 =A0 - 32bit only for =80500

Why increase the price of classic 32-bit version, especially after a -
somewhat- competitor product comes out?
0
ZuLuuuuuu
11/18/2009 7:30:57 AM
>>     - 32bit only for �500
> 
> Why increase the price of classic 32-bit version, especially after a -
> somewhat- competitor product comes out?
My line of thought was to create a reason for OA to keep DST alive - 
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

0
Udo
11/18/2009 7:45:53 AM
Shaping schrieb:
> 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 :-(

CU,

Udo
0
Udo
11/18/2009 7:48:18 AM
The biggest competitor of Dolphin IMHO will be:

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
0
Guido
11/18/2009 11:56:34 AM
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.

Best regards

Andy Bower
Object Arts Ltd

0
Andy
11/18/2009 12:02:23 PM
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.

> 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

Best regards

Andy Bower
Object Arts Ltd
0
Andy
11/18/2009 12:36:48 PM
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

>> 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
0
Guido
11/18/2009 2:04:57 PM
Andy,

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 

0
Don
11/18/2009 2:50:19 PM
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*. 

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
0
Andy
11/18/2009 3:05:20 PM
Don,

> 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
0
Udo
11/18/2009 3:11:49 PM
Udo,
"Udo Schneider" <Udo.Schneider@homeaddress.de> wrote in message 
news:G6-dnRZJ25kjk5nWnZ2dnUVZ_rGdnZ2d@totallyobjects.com...
> Don,
>
>> 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.
That's exactly what I think, too.  It might be more dream than plan at this 
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 

0
Don
11/18/2009 3:47:53 PM
Guido Stepken wrote:
> 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
0
John
11/18/2009 4:21:30 PM
Hi Andy!

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
0
Guido
11/18/2009 4:42:09 PM
John,

> 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
0
Andy
11/18/2009 5:04:18 PM
Guido,

> 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.

Best regards

Andy Bower
Object Arts Ltd
0
Andy
11/18/2009 6:18:24 PM
Andy,

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.

rush
http://www.cloud208.com/
0
rush
11/18/2009 6:33:29 PM
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).

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
0
Andy
11/18/2009 6:46:12 PM
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

> 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
0
Udo
11/18/2009 7:28:59 PM
Udo Schneider schrieb:
> 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
0
Andreas
11/18/2009 7:55:30 PM
This is a multi-part message in MIME format.
--------------030402080008090709030405
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Andreas,

> 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


--------------030402080008090709030405
Content-Type: text/plain;
 name="US StackDraw.pac"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline;
 filename="US StackDraw.pac"

| package |
package :=3D 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.Schneider@home=
address.de>
Public Domain, Freeware

Permission is hereby granted, free of charge, to any person obtaining a c=
opy of this software and associated documentation files (the "Software"),=
 to deal in the Software without restriction, including without limitatio=
n the rights to use, copy, modify, merge, publish, distribute, sublicense=
, and/or sell copies of the Software, and to permit persons to whom the S=
oftware is furnished to do so, subject to the following conditions:
 * The above copyright notice and this permission notice shall be include=
d in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS O=
R 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 OTH=
ER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISIN=
G FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEA=
LINGS IN THE SOFTWARE.

This package contains two classes: StackDrawer and StackDrawDebugger. Sta=
ckDraw simply takes a process and creates a DIB of the stack. You can use=
 it as follows:

p :=3D Processor activeProcess copy.
dib :=3D StackDrawer new drawFromFrame: p topFrame.
sc :=3D ScrollingDecorator show.
iv :=3D sc addSubView: ImageView new.
iv value: dib.
iv usePreferredExtent: true

StackFrameDebugger uses StackDrawer to provide a Debugger with an additio=
nal 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 dynami=
c view.

You can either start the StackDrawDebugger manually on a process or choos=
e it to be the default Debugger class (in Dolphin options):

p :=3D Processor activeProcess copy.
StackDrawDebugger=20
	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\D=
evelopment System';
	add: '..\Documents\Dolphin Smalltalk X6.1\Object Arts\Dolphin\Base\Dolph=
in';
	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\Presen=
ters\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\Presen=
ters\List\Dolphin List Presenter';
	add: '..\Documents\Dolphin Smalltalk X6.1\Object Arts\Dolphin\MVP\Base\D=
olphin 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 C=
onverters\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\Gdiplu=
s\Gdiplus';
	add: '..\Documents\Dolphin Smalltalk X6.1\Object Arts\Dolphin\ActiveX\Sh=
ell\Windows Shell';
	yourself).

package!

"Class Definitions"!

Object subclass: #StackDrawer
	instanceVariableNames: 'process dib canvas evenFrame graphics width dibH=
eight'
	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-C2178BBECFC=
8}')!
StackDrawer comment: '| p stack sender |
p :=3D Processor activeProcess copy.
"p :=3D [] newProcess."
frames :=3D OrderedCollection new.
frames add: p topFrame.
[(frame :=3D frames first sender) isNil] whileFalse: [frames addFirst: fr=
ame].
frames.
(1 to: p size) collect: [:each | p at: each].
Profiler profile:=20
		[dib :=3D StackDrawer new drawFromFrame: p topFrame.
		sc :=3D ScrollingDecorator show.
		iv :=3D 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=20
	| rect |
	rect :=3D (self arrowOffset - (width )) @ (entryOffset + (self entryHeig=
ht / 2))=20
				corner: (self arrowOffset + (width )) @ (targetOffset + (self entryHe=
ight / 2)).
	graphics drawBezier: (Array=20
				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=20
	frame bp - 1 < frame asInteger=20
		ifTrue: [self drawBackgroundFrom: frame bp - 1 to: frame asInteger - 1]=
=2E
	self=20
		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=20
	| firstOffset lastOffset rect |
	firstOffset :=3D self indexOffset: firstIndex - 1.
	lastOffset :=3D self indexOffset: lastIndex.
	rect :=3D 0 @ firstOffset corner: self arrowOffset @ lastOffset.
	evenFrame=20
		ifTrue:=20
			[canvas=20
				fillRectangle: rect
				startColor: Color yellow
				endColor: Color white
				verticalGradient: true]
		ifFalse:=20
			[canvas=20
				fillRectangle: rect
				startColor: Color light3d
				endColor: Color white
				verticalGradient: true].
	!

drawBasePointer: frame=20
	| index entryOffset |
	index :=3D frame asInteger + 5.
	entryOffset :=3D 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=20
	| entry targetIndex targetOffset |
	entry :=3D process at: index.
	targetIndex :=3D process indexOfSP: entry.
	targetOffset :=3D self indexOffset: targetIndex.
	self=20
		drawArrowFrom: entryOffset
		to: targetOffset
		width: self arrowWidth/2
		color: (ARGB=20
				a: 128
				r: 0
				g: 255
				b: 0)!

drawBPs: frame=20
	| entryOffset count temps descriptor |
	frame bp =3D frame asInteger ifTrue: [^self].
	count :=3D 1.
	temps :=3D (frame temps asSortedCollection: [:x :y | x third <=3D y thir=
d]) collect: [:each | each first] .
	frame bp to: frame asInteger - 1
		do:=20
			[:bpIndex |=20
			entryOffset :=3D self indexOffset: bpIndex.
			self drawIndex: bpIndex offset: entryOffset.
			descriptor :=3D temps at: count
						ifAbsent:=20
							[count <=3D frame argumentCount=20
								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 :=3D count + 1]!

drawCallingStackFrameAddress: frame=20
	| index entryOffset |
	index :=3D frame asInteger + 2.


	entryOffset :=3D 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=20
	| entry targetIndex targetOffset rect |
	entry :=3D process at: index.
	entry =3D 0 ifTrue: [^self].
	targetIndex :=3D process indexOfSP: entry.
	targetOffset :=3D self indexOffset: targetIndex.
	self=20
		drawArrowFrom: entryOffset
		to: targetOffset
		width: self arrowWidth
		color: (ARGB=20
				a: 128
				r: 0
				g: 0
				b: 255)!

drawDescription: index offset: entryOffset=20
	| entry rect |
	entry :=3D process at: index.
	rect :=3D (self descriptionOffset + Icon smallExtent x + 4) @ entryOffse=
t=20
				corner: self arrowOffset @ (entryOffset + self entryHeight).
	rect :=3D rect insetBy: self entryInset.
	entry icon=20
		drawOn: canvas
		at: (self descriptionOffset + 2) @ entryOffset + ((self entryHeight - I=
con smallExtent) / 2)
		extent: Icon smallExtent.
	canvas=20
		formatText: entry printString
		in: rect
		flags: DT_LEFT | DT_SINGLELINE | DT_VCENTER | DT_WORD_ELLIPSIS!

drawDescriptor: descriptor offset: entryOffset=20
	| rect |
	rect :=3D self descriptorOffset @ entryOffset=20
				corner: self descriptionOffset @ (entryOffset + self entryHeight).
	rect :=3D rect insetBy: self entryInset.
	canvas=20
		formatText: descriptor
		in: rect
		flags: DT_CENTER | DT_SINGLELINE | DT_VCENTER!

drawEnvironment: frame=20
	| index entryOffset |
	index :=3D frame asInteger + 1.
	entryOffset :=3D self indexOffset: index.
=09
	self drawIndex: index offset: entryOffset.
	self drawDescriptor: 'ENV' offset: entryOffset.
	self drawDescription: index offset: entryOffset!

drawFrame: frame=20
	canvas font: self font.
	self
		drawBackground: frame;
		drawSelf: frame;
		drawBPs: frame.
	canvas font: self font beItalic beBold.
	self
		drawMethod: frame;
		drawEnvironment: frame;
		drawCallingStackFrameAddress: frame;
		drawInstructionPointer: frame;
		drawStackPointer: frame;
		drawBasePointer: frame.
	canvas font: self font.
	self drawStack: frame!

drawFrames: topFrame=20
	| frame |
	frame :=3D topFrame.
	evenFrame :=3D false.
	[
	evenFrame :=3D evenFrame not.
	(frame :=3D frame sender) notNil] whileTrue.
	frame :=3D topFrame.
	[self drawFrame: frame.
	evenFrame :=3D evenFrame not.
	(frame :=3D frame sender) notNil] whileTrue!

drawFromFrame: aStackFrame=20
	^[self drawFromFrameInsecure:  aStackFrame] on: Error
		do:=20
			[:ex |=20
			DIBSection=20
				width: 32
				height: 32
				depth: 32]!

drawFromFrameInsecure: aStackFrame=20
	process :=3D aStackFrame process.
	dib :=3D DIBSection=20
				width: self width
				height: aStackFrame sp * self entryHeight
				depth: 32.
	dibHeight :=3D dib extent y.
	canvas :=3D dib canvas.
	canvas
		setBkMode: TRANSPARENT;
		fillRectangle: (0 @ 0 extent: dib extent) color: Color white;
		pen: (Pen color: Color black).
	graphics :=3D GdiplusGraphics fromCanvas: canvas.
	graphics smoothingMode: SmoothingModeAntiAlias.
	self drawFrames: aStackFrame.
	self drawGrid.
	^dib!

drawGrid
=09
	(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 @ dibHeig=
ht;
		lineFrom: self descriptionOffset @ 0 to: self descriptionOffset @ dibHe=
ight;
		lineFrom: self arrowOffset @ 0 to: self arrowOffset @ dibHeight!

drawIndex: index offset: entryOffset=20
	| rect |
	rect :=3D 0 @ entryOffset extent: self descriptorOffset @ self entryHeig=
ht.
	rect :=3D rect insetBy: self entryInset.
	canvas=20
		formatText: index displayString
		in: rect
		flags: DT_CENTER | DT_SINGLELINE | DT_VCENTER!

drawInstructionPointer: frame=20
	| index entryOffset entry rect |
	index :=3D frame asInteger + 3.
	entryOffset :=3D self indexOffset: index.
	self drawIndex: index offset: entryOffset.
	self drawDescriptor: 'IP' offset: entryOffset.
	entry :=3D process at: index.
	rect :=3D self descriptionOffset @ entryOffset=20
				corner: self arrowOffset @ (entryOffset + self entryHeight).
	rect :=3D rect insetBy: self entryInset.
	canvas=20
		formatText: entry displayString
		in: rect
		flags: DT_LEFT | DT_SINGLELINE | DT_VCENTER!

drawMethod: frame=20
	| index entryOffset |
	index :=3D frame asInteger + 0.
	entryOffset :=3D self indexOffset: index.
=09
	self drawIndex: index offset: entryOffset.
	self drawDescriptor: 'ME' offset: entryOffset.
	self drawDescription: index offset: entryOffset!

drawPointer: index offset: entryOffset=20
	| entry targetIndex description rect |
	entry :=3D process at: index.
	targetIndex :=3D entry =3D 0 ifFalse: [process indexOfSP: entry] ifTrue:=
 [nil].
	description :=3D '<1p> (<2d>)' expandMacrosWith: targetIndex with: entry=
=2E
	rect :=3D self descriptionOffset @ entryOffset=20
				corner: self arrowOffset @ (entryOffset + self entryHeight).
	rect :=3D rect insetBy: self entryInset.
	canvas=20
		formatText: description
		in: rect
		flags: DT_LEFT | DT_SINGLELINE | DT_VCENTER!

drawSelf: frame=20
	| index entryOffset |
	index :=3D frame bp - 1.
	entryOffset :=3D self indexOffset: index.
	self drawIndex: index offset: entryOffset.
	self drawDescriptor: 'self' offset: entryOffset.
	self drawDescription: index offset: entryOffset!

drawStack: frame=20
	| entryOffset count |
	frame sp =3D (frame asInteger + 5) ifTrue: [^self].
	count :=3D 0.
	frame asInteger + 6 to: frame sp
		do:=20
			[:bpIndex |=20
			entryOffset :=3D self indexOffset: bpIndex.
			self drawIndex: bpIndex offset: entryOffset.
			self drawDescriptor: ('<1d><2d>' expandMacrosWith: '_stack' with: coun=
t) offset: entryOffset.
			self drawDescription: bpIndex offset: entryOffset.
			count :=3D count + 1]!

drawStackPointer: frame=20
	| index entryOffset |
	index :=3D frame asInteger + 4.
	entryOffset :=3D self indexOffset: index.
=09
	self drawIndex: index offset: entryOffset.
	self drawDescriptor: 'SP' offset: entryOffset.
	self drawPointer: index offset: entryOffset.
	self drawStackPointerArrow: index offset: entryOffset!

drawStackPointerArrow: index offset: entryOffset=20
	| entry targetIndex targetOffset rect |
	entry :=3D process at: index.
	targetIndex :=3D process indexOfSP: entry.
	targetOffset :=3D self indexOffset: targetIndex.
	self=20
		drawArrowFrom: entryOffset
		to: targetOffset
		width: self arrowWidth/2
		color: (ARGB=20
				a: 128
				r: 255
				g: 0
				b: 0)!

entryHeight
	^20!

entryInset
^1!

entryWidth
	^self width - 16!

font
	^Font name: 'Arial' pointSize: 9!

indexOffset: index=20
	^dibHeight - (index * self entryHeight)!

process
	^process!

process: anObject
	process :=3D anObject!

width
=09
	width isNil ifTrue: [width :=3D 512].
	^width!

width: anInteger=20

	width :=3D 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!operat=
ions!private! !
!StackDrawer categoriesFor: #drawBackground:!drawing!operations!private! =
!
!StackDrawer categoriesFor: #drawBackgroundFrom:to:!drawing!operations!pr=
ivate! !
!StackDrawer categoriesFor: #drawBasePointer:!drawing!operations!private!=
 !
!StackDrawer categoriesFor: #drawBasePointerPointerArrow:offset:!drawing!=
operations!private! !
!StackDrawer categoriesFor: #drawBPs:!drawing!operations!private! !
!StackDrawer categoriesFor: #drawCallingStackFrameAddress:!drawing!operat=
ions!private! !
!StackDrawer categoriesFor: #drawCallingStackFrameAddressArrow:offset:!dr=
awing!operations!private! !
!StackDrawer categoriesFor: #drawDescription:offset:!drawing!operations!p=
rivate! !
!StackDrawer categoriesFor: #drawDescriptor:offset:!drawing!operations!pr=
ivate! !
!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!pu=
blic! !
!StackDrawer categoriesFor: #drawGrid!drawing!operations!private! !
!StackDrawer categoriesFor: #drawIndex:offset:!drawing!operations!private=
! !
!StackDrawer categoriesFor: #drawInstructionPointer:!drawing!operations!p=
rivate! !
!StackDrawer categoriesFor: #drawMethod:!drawing!operations!private! !
!StackDrawer categoriesFor: #drawPointer:offset:!drawing!operations!priva=
te! !
!StackDrawer categoriesFor: #drawSelf:!drawing!operations!private! !
!StackDrawer categoriesFor: #drawStack:!drawing!operations!private! !
!StackDrawer categoriesFor: #drawStackPointer:!drawing!operations!private=
! !
!StackDrawer categoriesFor: #drawStackPointerArrow:offset:!drawing!operat=
ions!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-CF876=
50D0667}')!
StackDrawDebugger comment: ''!
!StackDrawDebugger categoriesForClass!Development! !
!StackDrawDebugger methodsFor!

createComponents

	super createComponents.
graphicalCallStackPresenter :=3D self add: ImagePresenter new name: 'grap=
hicalCallStack'!

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 r=
econstituted.
	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.Debug=
gerShellView)  98 27 0 0 98 2 27131905 131073 416 0 524550 ##(Smalltalk.C=
olorRef)  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 ##(Smallt=
alk.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 429491030=
3 234 256 98 8 410 8 ##(Smalltalk.ReferenceView)  98 14 0 560 98 2 8 1140=
850688 131073 848 0 0 0 7 0 0 0 848 1180166 ##(Smalltalk.ResourceIdentifi=
er)  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 104=
2 1072 98 2 754 1 51 754 201 51 1232 1138 8 #[44 0 0 0 0 0 0 0 1 0 0 0 25=
5 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 #resour=
ce_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 25=
5 255 255 255 255 255 255 255 31 0 0 0 0 0 0 0 14 2 0 0 25 0 0 0] 1184 12=
00 0 27 8 'smalltalkTools' 410 864 98 14 0 560 98 2 8 1140850688 131073 1=
744 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.F=
lowLayout)  1 1 1 978 202 208 98 2 1042 1072 98 2 754 1 1 754 1169 101 56=
0 1042 8 #updateSize 1184 560 1138 8 #[44 0 0 0 0 0 0 0 1 0 0 0 255 255 2=
55 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 ##(Smallta=
lk.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.Dicti=
onary)  98 2 721414 ##(Smalltalk.Association)  410 8 ##(Smalltalk.Splitte=
r)  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 2=
55 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 86=
4 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 232=
0 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 140=
9286144 131073 3360 0 482 8 4278190080 0 7 0 0 0 3360 655878 ##(Smalltalk=
=2ECardLayout)  202 208 98 2 2466 8 'List' 410 8 ##(Smalltalk.ListBox)  9=
8 17 0 3360 98 2 8 1144062209 1 3568 590662 2 ##(Smalltalk.ListModel)  20=
2 208 1184 0 1310726 ##(Smalltalk.IdentitySearchPolicy)  482 656 0 5 2650=
30 4 ##(Smalltalk.Menu)  0 16 98 13 984134 2 ##(Smalltalk.CommandMenuItem=
)  1 1180998 4 ##(Smalltalk.CommandDescription)  8 #stepInto 8 'Step &Int=
o' 1269 5 263494 3 ##(Smalltalk.Icon)  0 16 1572870 ##(Smalltalk.ImageRel=
ativeFileLocator)  8 'StepInto.ico' 2032142 ##(Smalltalk.STBExternalResou=
rceLibraryProxy)  8 'dolphindr006.dll' 0 0 0 3794 1 3826 8 #stepOver 8 'S=
tep 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 379=
4 1 3826 8 #returnFromMessage 8 'Retur&n ...' 1 1 0 0 0 3794 1 3826 8 #re=
startFrame 8 '&Restart' 1 1 3890 0 16 3936 8 'Restart.ico' 3984 0 0 98336=
6 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 #re=
nameMethod 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 &Paramete=
r...' 1 1 0 0 0 3746 0 16 98 0 8 'Remo&ve Parameter' 8 #removeParameterMe=
nu 134217729 0 0 0 0 0 3746 0 16 98 0 8 'Rena&me Parameter' 8 #renamePara=
meterMenu 134217729 0 0 0 0 0 3746 0 16 98 0 8 '&Inline Parameter' 8 #inl=
ineParameterMenu 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 'Conver=
t Temp to Inst. Var.' 8 #convertTempToInstVarMenu 134217729 0 0 0 0 0 437=
0 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 1=
6 3936 8 'Refactoring.ico' 3984 0 0 0 0 4370 4097 3794 1 3826 8 #moreFram=
es 8 '&More' 1 1 0 0 0 3794 1 3826 8 #allFrames 8 'A&ll' 1 1 0 0 0 4370 4=
097 3746 0 16 98 6 3746 0 16 98 1 3794 1 3826 8 #browseDefinitions 8 'Bro=
wse Defi&nitions' 247 1 0 0 0 8 '&Definitions Of' 8 #definitionsMenu 1342=
17729 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 Cha=
in' 1 1 0 0 0 4370 4097 3794 1 3826 8 #browseMethodHistory 8 '&Change His=
tory in Image' 1 1 0 0 0 3794 1 3826 8 #browseMethodEditions 8 'Browse &E=
ditions' 1 1 0 0 0 8 '&Browse' 0 134217729 0 0 0 0 0 8 '&Debug' 0 1342177=
29 0 0 0 0 0 0 0 3568 0 8 4294909103 8 ##(Smalltalk.BasicListAbstract)  1=
184 0 978 202 208 98 3 1042 1072 98 2 754 9 49 754 559 229 3568 1042 8 #c=
ontextMenu: 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.Scroll=
ingDecoratorLayout)  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.Messa=
ge)  8 #=3D 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 'graphi=
calCallStack' 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 2=
55 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 20=
8 98 2 3552 6432 0 3712 0 0 1 0 0 0 7360 0 8 4294911709 787814 3 ##(Small=
talk.BlockClosure)  0 0 918822 ##(Smalltalk.CompiledMethod)  2 3 8 ##(Sma=
lltalk.ListControlView)  8 #defaultGetTextBlock 575230339 8 #[30 105 226 =
0 106] 8 #displayString 7520 7 257 0 7506 0 0 7538 2 3 8 ##(Smalltalk.Ico=
nicListAbstract)  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 7=
54 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 10=
72 98 2 754 1 1 754 575 285 3360 1138 8 #[44 0 0 0 0 0 0 0 1 0 0 0 255 25=
5 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 365=
0 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 3=
826 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 1=
77 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 1=
05 45 17 177 106] 2466 9104 9120 9136 9376 7 257 0 7506 0 0 7538 1 838860=
81 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 833=
6 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 'Vari=
able' 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 2=
3 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 1=
6 234 256 98 4 8336 8 'temps' 9952 8 'inspector' 590342 ##(Smalltalk.Rect=
angle)  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 2=
55 255 255 255 255 255 255 255 255 40 1 0 0 0 0 0 0 72 2 0 0 142 0 0 0] 9=
8 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 11=
38 8 #[44 0 0 0 0 0 0 0 1 0 0 0 255 255 255 255 255 255 255 255 255 255 2=
55 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 2=
7 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 2=
55 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=
=2E..' 1 1 0 0 0 4370 4097 3794 1 3826 8 #saveImage 8 'Sa&ve Image' 1 1 3=
890 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 3=
794 1 3826 8 #exit 8 'Close' 17639 1 3890 0 16 3936 8 'CloseWindow.ico' 3=
984 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 409=
7 3794 1 3826 8 #cutSelection 8 'Cu&t' 9393 1 3890 0 16 3936 8 'EditCut.i=
co' 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 379=
4 1 3826 8 #reformatSource 8 '&Source' 9391 1 0 0 0 3794 1 3826 8 #reform=
atComment 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 4=
097 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' 12=
53 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 1=
6 98 17 3794 1 3826 8 #browseIt 8 '&Browse It' 9349 1 3890 0 16 3936 8 'C=
lassBrowserShell.ico' 3984 0 0 3794 1 3826 8 #displayIt 8 '&Display It' 9=
353 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 #fileI=
tIn 8 'Fi&le It In' 1 1 0 0 0 4370 4097 3794 1 3826 5696 8 'Defi&nitions.=
=2E.' 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 'Tru=
e.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 4=
370 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 &Te=
mporary...' 9385 1 0 0 0 3794 1 3826 8 #extractMethod 8 'E&xtract Method.=
=2E.' 9371 1 0 0 0 3794 1 3826 8 #extractToComponent 8 'Extract to &Compo=
nent...' 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' 1=
3481 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 #toggleLineN=
umbers 8 'Line N&umbers' 1 1 0 0 0 3794 1 3826 8 #toggleStyling 8 '&Synta=
x 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 #terminat=
eProcess 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' 3=
984 0 0 3794 1 3826 4144 8 'Step O&ut' 5365 1 3890 0 16 3936 8 'StepOut.i=
co' 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' 9=
449 1 3890 0 16 3936 8 'Run.ico' 3984 0 0 3794 1 3826 4304 8 'R&estart' 1=
3545 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 37=
46 0 16 98 3 3794 1 3826 4528 8 'All...' 1 1 0 0 0 3794 1 3826 8 #renameM=
ethodInHierarchy 8 'In &Hierarchy...' 1 1 0 0 0 3794 1 3826 8 #renameMeth=
odInPackage 8 'In &Package...' 1 1 0 0 0 8 'Re&name' 0 134217729 0 0 1736=
3 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 1342177=
29 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 #push=
DownMethods 8 'Push &Down' 1 1 0 0 0 8 'Refactorin&gs' 5392 134217729 389=
0 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 #toggl=
eDisassembly 8 'Disasse&mbly' 9461 1 0 0 0 3794 1 3826 8 #showNextStateme=
nt 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 'Cal=
l &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 393=
6 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 #clearChangeHistor=
y 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 1=
9 3794 1 3826 8 #helpContents 8 '&Contents' 1025 1 3890 0 16 3936 49 1280=
0 0 0 3794 1 3826 8 #help 8 'On this &Tool' 1249 1 0 0 0 3794 1 3826 8 #h=
elpWhatsThis 8 'What''s This?' 5345 1 0 0 0 4370 4097 3794 1 3826 8 #help=
FirstSplash 8 'First Splash!!' 1 1 0 0 0 4370 4097 3794 1 3826 8 #helpWha=
tsNew 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 374=
6 0 16 98 4 3794 2097153 3826 8 #tipOfTheDay 8 '&Next Tip of the Day' 944=
1 1 3890 0 16 3936 8 'TipOfTheDay.ico' 3984 0 0 3794 1 3826 8 #previousTi=
pOfTheDay 8 '&Previous Tip of the Day' 13537 1 3890 0 16 3936 8 'TipOfThe=
Day.ico' 3984 0 0 4370 4097 3794 1 3826 8 #toggleShowTipsAtStartup 8 '&Sh=
ow 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!res=
ources-views! !

"Binary Globals"!



--------------030402080008090709030405--
0
Udo
11/18/2009 9:01:52 PM
Udo Schneider wrote:

> 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
0
John
11/18/2009 9:50:25 PM
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:)

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
 --
swaring@ozemail.com.au
0
SteveAW
11/18/2009 10:09:12 PM
Hi Andy,

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
 --
swaring@ozemail.com.au
0
SteveAW
11/18/2009 10:26:33 PM
On Nov 18, 2:09=A0pm, SteveAW <swar...@ozemail.com.au> wrote:
> 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
> =A0--
> swar...@ozemail.com.au

0
Travis
11/18/2009 10:34:04 PM
On Nov 18, 1:01=A0pm, Udo Schneider <Udo.Schnei...@homeaddress.de>
wrote:
> Andreas,
>
> > 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
>
> [US StackDraw.pac39K ]| package |
> package :=3D Package name: 'US StackDraw'.
> package paxVersion: 1;
> =A0 =A0 =A0 =A0 basicComment: '$id: US StackDraw 0.005$
> $for: Dolphin Smalltalk X6.1 Beta 2$...
>
> (c) $date: 18.11.2009$, $developer: udos@udos-laptop$ <Udo.Schnei...@home=
address.de>
> Public Domain, Freeware
>
> Permission is hereby granted, free of charge, to any person obtaining a c=
opy of this software and associated documentation files (the "Software"), t=
o deal in the Software without restriction, including without limitation th=
e 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:
> =A0* The above copyright notice and this permission notice shall be inclu=
ded in all copies or substantial portions of the Software.
>
> THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS O=
R 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 LIA=
BILITY, 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 T=
HE SOFTWARE.
>
> This package contains two classes: StackDrawer and StackDrawDebugger. Sta=
ckDraw simply takes a process and creates a DIB of the stack. You can use i=
t as follows:
>
> p :=3D Processor activeProcess copy.
> dib :=3D StackDrawer new drawFromFrame: p topFrame.
> sc :=3D ScrollingDecorator show.
> iv :=3D sc addSubView: ImageView new.
> iv value: dib.
> iv usePreferredExtent: true
>
> StackFrameDebugger uses StackDrawer to provide a Debugger with an additio=
nal StackDraw view. Please note that it currently only display a "static" p=
icture of the stack - once I find some time I may recode it as a dynamic vi=
ew.
>
> You can either start the StackDrawDebugger manually on a process or choos=
e it to be the default Debugger class (in Dolphin options):
>
> p :=3D Processor activeProcess copy.
> StackDrawDebugger
> =A0 =A0 =A0 =A0 show: p printString
> =A0 =A0 =A0 =A0 process: p
> =A0 =A0 =A0 =A0 topFrame: p topFrame
> =A0 =A0 =A0 =A0 resumable: p isTerminated not'.
>
> package basicPackageVersion: '0.005'.
>
> package classNames
> =A0 =A0 =A0 =A0 add: #StackDrawDebugger;
> =A0 =A0 =A0 =A0 add: #StackDrawer;
> =A0 =A0 =A0 =A0 yourself.
>
> package binaryGlobalNames: (Set new
> =A0 =A0 =A0 =A0 yourself).
>
> package globalAliases: (Set new
> =A0 =A0 =A0 =A0 yourself).
>
> package setPrerequisites: (IdentitySet new
> =A0 =A0 =A0 =A0 add: '..\Documents\Dolphin Smalltalk X6.1\Object Arts\Dol=
phin\IDE\Base\Development System';
> =A0 =A0 =A0 =A0 add: '..\Documents\Dolphin Smalltalk X6.1\Object Arts\Dol=
phin\Base\Dolphin';
> =A0 =A0 =A0 =A0 add: '..\Documents\Dolphin Smalltalk X6.1\Object Arts\Dol=
phin\MVP\Views\Cards\Dolphin Card Containers';
> =A0 =A0 =A0 =A0 add: '..\Documents\Dolphin Smalltalk X6.1\Object Arts\Dol=
phin\MVP\Views\Common Controls\Dolphin Common Controls';
> =A0 =A0 =A0 =A0 add: '..\Documents\Dolphin Smalltalk X6.1\Object Arts\Dol=
phin\MVP\Views\Control Bars\Dolphin Control Bars';
> =A0 =A0 =A0 =A0 add: '..\Documents\Dolphin Smalltalk X6.1\Object Arts\Dol=
phin\MVP\Presenters\Image\Dolphin Image Presenter';
> =A0 =A0 =A0 =A0 add: '..\Documents\Dolphin Smalltalk X6.1\Object Arts\Dol=
phin\MVP\Models\List\Dolphin List Models';
> =A0 =A0 =A0 =A0 add: '..\Documents\Dolphin Smalltalk X6.1\Object Arts\Dol=
phin\MVP\Presenters\List\Dolphin List Presenter';
> =A0 =A0 =A0 =A0 add: '..\Documents\Dolphin Smalltalk X6.1\Object Arts\Dol=
phin\MVP\Base\Dolphin MVP Base';
> =A0 =A0 =A0 =A0 add: '..\Documents\Dolphin Smalltalk X6.1\Object Arts\Dol=
phin\MVP\Views\Scrollbars\Dolphin Scrollbars';
> =A0 =A0 =A0 =A0 add: '..\Documents\Dolphin Smalltalk X6.1\Object Arts\Dol=
phin\MVP\Type Converters\Dolphin Type Converters';
> =A0 =A0 =A0 =A0 add: '..\Documents\Dolphin Smalltalk X6.1\Object Arts\Dol=
phin\MVP\Models\Value\Dolphin Value Models';
> =A0 =A0 =A0 =A0 add: '..\Documents\Dolphin Smalltalk X6.1\Object Arts\Dol=
phin\MVP\Gdiplus\Gdiplus';
> =A0 =A0 =A0 =A0 add: '..\Documents\Dolphin Smalltalk X6.1\Object Arts\Dol=
phin\ActiveX\Shell\Windows Shell';
> =A0 =A0 =A0 =A0 yourself).
>
> package!
>
> "Class Definitions"!
>
> Object subclass: #StackDrawer
> =A0 =A0 =A0 =A0 instanceVariableNames: 'process dib canvas evenFrame grap=
hics width dibHeight'
> =A0 =A0 =A0 =A0 classVariableNames: ''
> =A0 =A0 =A0 =A0 poolDictionaries: 'GdiplusConstants Win32Constants'
> =A0 =A0 =A0 =A0 classInstanceVariableNames: ''!
> Debugger subclass: #StackDrawDebugger
> =A0 =A0 =A0 =A0 instanceVariableNames: 'graphicalCallStackPresenter'
> =A0 =A0 =A0 =A0 classVariableNames: ''
> =A0 =A0 =A0 =A0 poolDictionaries: ''
> =A0 =A0 =A0 =A0 classInstanceVariableNames: ''!
>
> "Global Aliases"!
>
> "Loose Methods"!
>
> "End of package definition"!
>
> "Source Globals"!
>
> "Classes"!
>
> StackDrawer guid: (GUID fromString: '{FA821B18-222D-4706-BDFF-C2178BBECFC=
8}')!
> StackDrawer comment: '| p stack sender |
> p :=3D Processor activeProcess copy.
> "p :=3D [] newProcess."
> frames :=3D OrderedCollection new.
> frames add: p topFrame.
> [(frame :=3D frames first sender) isNil] whileFalse: [frames addFirst: fr=
ame].
> frames.
> (1 to: p size) collect: [:each | p at: each].
> Profiler profile:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 [dib :=3D StackDrawer new drawFromFrame: =
p topFrame.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 sc :=3D ScrollingDecorator show.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 iv :=3D sc addSubView: ImageView new.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 iv value: dib.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 iv usePreferredExtent: true].
> FooBar new foo'!
> !StackDrawer categoriesForClass!Kernel-Objects! !
> !StackDrawer methodsFor!
>
> arrowOffset
> =A0 =A0 =A0 =A0 ^self entryWidth - (self arrowWidth )!
>
> arrowWidth
> =A0 =A0 =A0 =A0 ^40!
>
> descriptionOffset
> =A0 =A0 =A0 =A0 ^128!
>
> descriptorOffset
> =A0 =A0 =A0 =A0 ^32!
>
> drawArrowFrom: entryOffset to: targetOffset width: width color: anARGB
> =A0 =A0 =A0 =A0 | rect |
> =A0 =A0 =A0 =A0 rect :=3D (self arrowOffset - (width )) @ (entryOffset + =
(self entryHeight / 2))
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 corner: (=
self arrowOffset + (width )) @ (targetOffset + (self entryHeight / 2)).
> =A0 =A0 =A0 =A0 graphics drawBezier: (Array
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 with: rec=
t topCenter
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 with: rec=
t topRight
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 with: rec=
t bottomRight
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 with: rec=
t bottomCenter)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 pen: ((GdiplusPen color: anARGB)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 lineCap: =
LineCapRoundAnchor
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 endCap: LineCapArrowAnchor
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 dashCap: LineCapRound;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 width: 3)=
!
>
> drawBackground: frame
> =A0 =A0 =A0 =A0 frame bp - 1 < frame asInteger
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ifTrue: [self drawBackgroundFrom: frame b=
p - 1 to: frame asInteger - 1].
> =A0 =A0 =A0 =A0 self
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 drawBackgroundFrom: frame asInteger
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 to: frame asInteger + 5 .frame sp > (fram=
e asInteger + 5)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ifTrue: [self drawBackgroundFrom: frame a=
sInteger + 6 to: frame sp]!
>
> drawBackgroundFrom: firstIndex to: lastIndex
> =A0 =A0 =A0 =A0 | firstOffset lastOffset rect |
> =A0 =A0 =A0 =A0 firstOffset :=3D self indexOffset: firstIndex - 1.
> =A0 =A0 =A0 =A0 lastOffset :=3D self indexOffset: lastIndex.
> =A0 =A0 =A0 =A0 rect :=3D 0 @ firstOffset corner: self arrowOffset @ last=
Offset.
> =A0 =A0 =A0 =A0 evenFrame
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ifTrue:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 [canvas
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 fillRecta=
ngle: rect
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 startColo=
r: Color yellow
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 endColor:=
 Color white
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 verticalG=
radient: true]
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ifFalse:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 [canvas
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 fillRecta=
ngle: rect
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 startColo=
r: Color light3d
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 endColor:=
 Color white
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 verticalG=
radient: true].
> =A0 =A0 =A0 =A0 !
>
> drawBasePointer: frame
> =A0 =A0 =A0 =A0 | index entryOffset |
> =A0 =A0 =A0 =A0 index :=3D frame asInteger + 5.
> =A0 =A0 =A0 =A0 entryOffset :=3D self indexOffset: index.
> =A0 =A0 =A0 =A0 self drawIndex: index offset: entryOffset.
> =A0 =A0 =A0 =A0 self drawDescriptor: 'BP' offset: entryOffset.
> =A0 =A0 =A0 =A0 self drawPointer: index offset: entryOffset.
> =A0 =A0 =A0 =A0 self drawBasePointerPointerArrow: index offset: entryOffs=
et!
>
> drawBasePointerPointerArrow: index offset: entryOffset
> =A0 =A0 =A0 =A0 | entry targetIndex targetOffset |
> =A0 =A0 =A0 =A0 entry :=3D process at: index.
> =A0 =A0 =A0 =A0 targetIndex :=3D process indexOfSP: entry.
> =A0 =A0 =A0 =A0 targetOffset :=3D self indexOffset: targetIndex.
> =A0 =A0 =A0 =A0 self
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 drawArrowFrom: entryOffset
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 to: targetOffset
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 width: self arrowWidth/2
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 color: (ARGB
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 a: 128
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 r: 0
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 g: 255
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 b: 0)!
>
> drawBPs: frame
> =A0 =A0 =A0 =A0 | entryOffset count temps descriptor |
> =A0 =A0 =A0 =A0 frame bp =3D frame asInteger ifTrue: [^self].
> =A0 =A0 =A0 =A0 count :=3D 1.
> =A0 =A0 =A0 =A0 temps :=3D (frame temps asSortedCollection: [:x :y | x th=
ird <=3D y third]) collect: [:each | each first] .
> =A0 =A0 =A0 =A0 frame bp to: frame asInteger - 1
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 do:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 [:bpIndex |
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 entryOffset :=3D self ind=
exOffset: bpIndex.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 self drawIndex: bpIndex o=
ffset: entryOffset.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 descriptor :=3D temps at:=
 count
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 ifAbsent:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 [count <=3D frame argumentCount
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ifTrue: ['<1d><2d>'=
 expandMacrosWith: 'arg' with: count]
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ifFalse: ['<1d><2d>=
' expandMacrosWith: 'tmp' with: count - frame argumentCount]].
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 self
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 drawDescr=
iptor: descriptor offset: entryOffset;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 drawDescr=
iption: bpIndex offset: entryOffset.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 count :=3D count + 1]!
>
> drawCallingStackFrameAddress: frame
> =A0 =A0 =A0 =A0 | index entryOffset |
> =A0 =A0 =A0 =A0 index :=3D frame asInteger + 2.
>
> =A0 =A0 =A0 =A0 entryOffset :=3D self indexOffset: index.
> =A0 =A0 =A0 =A0 self drawIndex: index offset: entryOffset.
> =A0 =A0 =A0 =A0 self drawDescriptor: 'CSFA' offset: entryOffset.
> =A0 =A0 =A0 =A0 self drawPointer: index offset: entryOffset.
> =A0 =A0 =A0 =A0 self drawCallingStackFrameAddressArrow: index offset: ent=
ryOffset!
>
> drawCallingStackFrameAddressArrow: index offset: entryOffset
> =A0 =A0 =A0 =A0 | entry targetIndex targetOffset rect |
> =A0 =A0 =A0 =A0 entry :=3D process at: index.
> =A0 =A0 =A0 =A0 entry =3D 0 ifTrue: [^self].
> =A0 =A0 =A0 =A0 targetIndex :=3D process indexOfSP: entry.
> =A0 =A0 =A0 =A0 targetOffset :=3D self indexOffset: targetIndex.
> =A0 =A0 =A0 =A0 self
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 drawArrowFrom: entryOffset
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 to: targetOffset
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 width: self arrowWidth
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 color: (ARGB
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 a: 128
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 r: 0
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 g: 0
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 b: 255)!
>
> drawDescription: index offset: entryOffset
> =A0 =A0 =A0 =A0 | entry rect |
> =A0 =A0 =A0 =A0 entry :=3D process at: index.
> =A0 =A0 =A0 =A0 rect :=3D (self descriptionOffset + Icon smallExtent x + =
4) @ entryOffset
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 corner: s=
elf arrowOffset @ (entryOffset + self entryHeight).
> =A0 =A0 =A0 =A0 rect :=3D rect insetBy: self entryInset.
> =A0 =A0 =A0 =A0 entry icon
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 drawOn: canvas
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 at: (self descriptionOffset + 2) @ entryO=
ffset + ((self entryHeight - Icon smallExtent) / 2)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 extent: Icon smallExtent.
> =A0 =A0 =A0 =A0 canvas
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 formatText: entry printString
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 in: rect
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 flags: DT_LEFT | DT_SINGLELINE | DT_VCENT=
ER | DT_WORD_ELLIPSIS!
>
> drawDescriptor: descriptor offset: entryOffset
> =A0 =A0 =A0 =A0 | rect |
> =A0 =A0 =A0 =A0 rect :=3D self descriptorOffset @ entryOffset
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 corner: s=
elf descriptionOffset @ (entryOffset + self entryHeight).
> =A0 =A0 =A0 =A0 rect :=3D rect insetBy: self entryInset.
> =A0 =A0 =A0 =A0 canvas
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 formatText: descriptor
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 in: rect
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 flags: DT_CENTER | DT_SINGLELINE | DT_VCE=
NTER!
>
> drawEnvironment: frame
> =A0 =A0 =A0 =A0 | index entryOffset |
> =A0 =A0 =A0 =A0 index :=3D frame asInteger + 1.
> =A0 =A0 =A0 =A0 entryOffset :=3D self indexOffset: index.
>
> =A0 =A0 =A0 =A0 self drawIndex: index offset: entryOffset.
> =A0 =A0 =A0 =A0 self drawDescriptor: 'ENV' offset: entryOffset.
> =A0 =A0 =A0 =A0 self drawDescription: index offset: entryOffset!
>
> drawFrame: frame
> =A0 =A0 =A0 =A0 canvas font: self font.
> =A0 =A0 =A0 =A0 self
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 drawBackground: frame;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 drawSelf: frame;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 drawBPs: frame.
> =A0 =A0 =A0 =A0 canvas font: self font beItalic beBold.
> =A0 =A0 =A0 =A0 self
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 drawMethod: frame;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 drawEnvironment: frame;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 drawCallingStackFrameAddress: frame;
>
> read more =BB

Thank you =3D)
0
Travis
11/18/2009 10:34:24 PM
On Nov 18, 8:28=A0pm, Udo Schneider <Udo.Schnei...@homeaddress.de>
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.

rush
http://www.cloud208.com/
0
rush
11/18/2009 11:00:44 PM
John,

> 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
0
Udo
11/18/2009 11:20:23 PM
Steve,

> 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
0
Udo
11/18/2009 11:21:50 PM
Andreas,

> 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

0
Andy
11/19/2009 12:27:26 AM
Hi Andy,

I pledge $500 toward a package comprising D7PRO32 & D7PRO64.

Best Regards,
Bernhard

Andy Bower wrote:
[...]
> 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.
0
Bernhard
11/19/2009 12:31:04 AM
>> 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.

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$ 
> <Udo.Schneider@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;
> 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"!
>
>
> 
0
Shaping
11/19/2009 6:31:05 AM
SteveAW schrieb:
> 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:)
> 
> 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
>  --
> swaring@ozemail.com.au
I wasn't aware of that trick, too. It would have helped me when I did my 
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
0
Andreas
11/19/2009 4:07:41 PM
Andy,

>>>> 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
0
Wilhelm
11/21/2009 5:17:34 PM
Andy,

> 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

0
Wilhelm
11/21/2009 5:47:49 PM
Hi Andy/Frank.

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" <bower@SnipThisObject-arts.com> wrote in message 
news:7mi62fF3hqd3qU1@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.
>
> Best regards
>
> Andy Bower
> Object Arts Ltd
> 
0
Shaping
11/21/2009 9:50:18 PM
I don't see a 64bit version in the next few years. I really appreciate 
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



0
Guido
11/22/2009 12:52:59 PM
> 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

0
Travis
11/22/2009 4:51:12 PM
$200 definitely
$500 possibly.

I'd love to see a 64 bit VM and (hopefully) full unicode support.
0
Malbs
11/23/2009 12:19:50 AM
Shaping,

> 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
0
Andy
11/24/2009 12:21:54 AM
Dear all,

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





0
Frank
11/24/2009 8:04:23 AM
Frank Lesser [LSW] schrieb:

> 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
0
Guido
11/24/2009 4:20:52 PM
Guido,

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
0
Andy
11/24/2009 4:55:22 PM
Andy Bower schrieb:
> 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
0
Guido
11/24/2009 5:20:35 PM
Hi Guido,

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







 


0
Frank
11/24/2009 5:31:32 PM
There are funny things going on in the computing scene. The GUI's and 
their 'usability look, feel' seem to change.

Please have a look at this GUI first, enjoy!

http://www.ommwriter.com/

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
0
Guido
11/24/2009 6:21:57 PM
Guido,

> 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.

This is probably the first thing you've posted recently that I've 
understood. It's certainly the first thing I agree with.

Best regards

Andy Bower
0
Andy
11/24/2009 8:05:28 PM
On Nov 24, 12:21=A0pm, Guido Stepken <gstep...@googlemail.com> wrote:
> Please have a look at this GUI first, enjoy!
>
> http://www.ommwriter.com/

Someone typing at 5 words a minute is hardly something people would
want to endure reading.

> Isn't that pure beauty? Can u imagine to have such a IDE, yes, even
> (database) application?

Advanced developers prefer using keyboard shortcuts whenever possible,
not searching through menus and buttons.
Personally I think an artistic IDE is irrelevant.

> 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.

Not sure what IDE's you're comparing this to.

> How can you gain market shares in future? Win back old customers, extend
> your business?

Not by changing my IDE, that's for sure.

> Apple shows, how important "beauty" of GUI's (without having to miss
> functionality) really is. Have a look at iWorks. Same concept like
> ommwriter.

Of course, Microsoft products are far from beautiful, and often times
barely functional, yet they have
dominant market share with many products, so that begs the question on
the value of beauty as a primary attribute.

> 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.

So...you rely on an IDE to use a language? I think you have two
problems then.

> I promise, that nobody in very soon future is willing to use that old
> fashioned GUI stuff any longer.

People still use notepad to develop many languages regardless of the
existence of a variety of IDEs

> Therein lies a big chance to gain new market shares. Did you notice,
> that "usability companies" are exploding around the globe?

No.

> The first company, that will be able to offer such a "innovative" GUI,
> will win the race.

Doubt it. There is such a  thing as a migration cost, and a mental
model of what an IDE should be like.
Also there is company policy to contend with.

> 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.

What does that have to do with an IDE?

> Have you already seen FLUX Library for OpenGL GUI? No? See here:
>
> http://www.youtube.com/watch?v=3D4vo0yK7P8-s
>
> In very soon future i see a 32bit renaissance.

Why 32bit?

> Browser OS, OpenGL
> built-in. A new standard coming up. No - no more GUI/OS wars!

Doubt it.

> I see Javascript as "new mainstream programming language". A de facto
> standard already.

Its had that status for a few years already. You need to catch up.

> 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/

Actually, JavaScript was influenced by: Self, C, Scheme, Perl, Python,
Java.
Not Smalltalk.

> Means - new way's of interactivity, easy to do, even by non-programmers,
> e.g. (sorry german, but functionality, that counts!):

I don't know about you, but I wouldn't want someone who isn't a
programmer to write code.

> 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!

I think that ship has sailed already, and Smalltalk isn't currently on
board like it was when it first came about.

> 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.

Doubt it.

> 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?

And irrelevant. I don't see Smalltalk upsetting anything in common use
over the next 5 years even.

> Microsoft .NET - the former "Standard" - C#, C++, win32, win64, SQL
> databases - lightyears crawling behind.

I don't see how you came to this conclusion.

0
Michael
11/24/2009 8:58:37 PM
On Nov 24, 12:04=A0am, "Frank Lesser [LSW]" <frank-les...@lesser-
software.com> wrote:
> Dear all,
>

Thank you for clarifying this.

>
> Frank

0
Travis
11/24/2009 9:37:35 PM
>>>>> "Guido" == Guido Stepken <gstepken@googlemail.com> writes:

Guido> Please have a look at this GUI first, enjoy!

Guido> http://www.ommwriter.com/

Guido> Isn't that pure beauty? Can u imagine to have such a IDE, yes, even
Guido> (database) application?

Horrible.  The icons don't have names.  I'd spend forever trying to remember
where the thing is that I need to find.  I also don't like my interface
"disappearing" until I mouseover the right area.

Guido> I see Javascript as "new mainstream programming language". A de facto
Guido> standard already. Nobody sees, that Javascript is in reality SMALLTALK!

No, it's not.

Prototype inheritance is in some ways more powerful than class-based
inheritance, so in that case, Javascript is actually better.

But the overloaded "+"... wrong.

And the complex syntax that requires even more complex meta-tools.
Smalltalk's simply syntax permits incredibly powerful reflection.

Guido> Smalltalk - by design, due to its flexibility - will play a huge role
Guido> in future gui's, IMHO. The frontier between programmers and users will
Guido> simply disappear!

Yeah, they said that every five years for the past 50.  It's not going to
happen.  There are mental models that we programmers have that are *not*
shared (even as "common sense") by the masses.  When's the last time you got
*good* directions from your friend about how to get to that restaurant?

Guido> So IDE's and GUI's of the past, overloaded with functionality, ugly,
Guido> rectangular 'static', 'unanimated' windows, 'pull down menu's' - that
Guido> stuff all will disappear in very near future. In 2-3 years, i think.

Oh, geez.  I hope not.  Anything that is picture-based will mean that my
productivity will go *down*, not up.  I need words on the screen to tell
options.  Or words on the command line.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
0
merlyn
11/24/2009 10:26:12 PM
Frank Lesser [LSW] schrieb:
> 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
0
Guido
11/24/2009 10:55:42 PM
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


On 24 nov, 19:55, Guido Stepken <gstep...@googlemail.com> wrote:
> Frank Lesser [LSW] schrieb:
>
> > 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

0
GallegO
11/24/2009 11:35:34 PM
Michael Haufe ("TNO") schrieb:

> Advanced developers prefer using keyboard shortcuts whenever possible,
> not searching through menus and buttons.
> Personally I think an artistic IDE is irrelevant.

Not really. I tech how to program at school for kids. Squeak (Scratch) 
of course. Very intuitive, very well suited for beginners, no 
overstimulation by needless icons.

To make a programming language a success, you always should consider, 
that working with young talents is important.

Many pupils (expecially girls) are afraid of doing something wrong, when 
learning a language ... With Squeak/Etoys they can even program 
everything in their mother language (french, turkish, german, spanisch, 
portuguese ...) the smalltalk code is generated invisible behind.

So please review again this GUI. Within that 'look and feel' a teacher 
can step by step activate functionality.

This is also very important in public administation, enterprises, call 
centers and so on ... it increases acceptance dramatically, guides a 
mind smoothly into a topic.

>> 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.
> 
> Not sure what IDE's you're comparing this to.

E.g. Squeak/Etoys.


>> 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.
> 
> What does that have to do with an IDE?

Hmmm. Look at Squeak/Etoys or even Pharo. You can't really differ 
between GUI and IDE ... Same like in Javascript. In the very soon 
future, that "barrier" will be gone.

>> 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.
> 
> Why 32bit?

Price. ARM and MIPS (Godson and Loongson processors) are spreading all 
over asia. INTEL processors are too much energy consuming, even the new 
ATOM's.

Linux on ARM and MIPS are making the run. And Android. Whole China 
changes away from Microsoft towards Google OS/Android.

A netbook on Mips there is available for 67$!!!!! I've got one. And 
netbooks become the desktops of the future, see cloud computing.

We are within a change of technology, away from fat clients.

>> Browser OS, OpenGL
>> built-in. A new standard coming up. No - no more GUI/OS wars!
> 
> Doubt it.

That's already fact. You simply didn't notice the change.

>> I see Javascript as "new mainstream programming language". A de facto
>> standard already.
> 
> Its had that status for a few years already. You need to catch up.

AJAX is becoming increasingly popular. It's based on Javascript. Look 
out for Job offers everywhere: Javascript knowledge asked for.

>> 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/
> 
> Actually, JavaScript was influenced by: Self, C, Scheme, Perl, Python,
> Java.
> Not Smalltalk.

Of course. Javascript engine is pure OO. It's VM (See VM engine (V8) in 
Google browser and upcoming firefox).

>> Means - new way's of interactivity, easy to do, even by non-programmers,
>> e.g. (sorry german, but functionality, that counts!):
> 
> I don't know about you, but I wouldn't want someone who isn't a
> programmer to write code.

Have a look at Etoys or Scratch. Even children can program things in 
minutes, where even you would need several weeks.

>> 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!
> 
> I think that ship has sailed already, and Smalltalk isn't currently on
> board like it was when it first came about.

Hmmm. Times seem to change. I think, Smalltalk has a great future.

>> Microsoft .NET - the former "Standard" - C#, C++, win32, win64, SQL
>> databases - lightyears crawling behind.
> 
> I don't see how you came to this conclusion.

Hmmm. Perhaps you may overthink my arguments ....

reagards, Guido Stepken

0
Guido
11/25/2009 12:05:58 AM
GallegO schrieb:
> 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
0
Guido
11/25/2009 12:24:57 AM
Randal L. Schwartz schrieb:

> Guido> http://www.ommwriter.com/
> 
> Guido> Isn't that pure beauty? Can u imagine to have such a IDE, yes, even
> Guido> (database) application?
> 
> Horrible.  The icons don't have names.

That's a minor problem. Can be faded in.

> I'd spend forever trying to remember
> where the thing is that I need to find.  I also don't like my interface
> "disappearing" until I mouseover the right area.

Has advantages for beginners. No overstimulation -> higher acceptance.

> Guido> I see Javascript as "new mainstream programming language". A de facto
> Guido> standard already. Nobody sees, that Javascript is in reality SMALLTALK!
> 
> No, it's not.

No? Ok, different in Syntax, but same concepts behind.

> Prototype inheritance is in some ways more powerful than class-based
> inheritance, so in that case, Javascript is actually better.
> 
> But the overloaded "+"... wrong.

Hmm, yes, overloading is still not allowed in JS :-(

> And the complex syntax that requires even more complex meta-tools.
> Smalltalk's simply syntax permits incredibly powerful reflection.

Yes, agreed.

....
> Guido> So IDE's and GUI's of the past, overloaded with functionality, ugly,
> Guido> rectangular 'static', 'unanimated' windows, 'pull down menu's' - that
> Guido> stuff all will disappear in very near future. In 2-3 years, i think.
> 
> Oh, geez.  I hope not.  Anything that is picture-based will mean that my
> productivity will go *down*, not up.  I need words on the screen to tell
> options.  Or words on the command line.

Yes, but don't think in dimensions of productivity of just one programmer.

Given a easy to learn programming language and such an IDE, open source, 
programmers will come from everywhere to participate, a huge community 
of supporters, followers, coworkers, developers will emerge.
And that team or community will be by far more productive than e.g. 
Andy, Frank, Ale, Blair together. See also 'linus law'.

Take that as fact.

regards, Guido Stepken
0
Guido
11/25/2009 12:32:27 AM
>>>>> "Guido" == Guido Stepken <gstepken@googlemail.com> writes:

Guido> I see Javascript as "new mainstream programming language". A de facto
Guido> standard already. Nobody sees, that Javascript is in reality SMALLTALK!
>> No, it's not.

Guido> No? Ok, different in Syntax, but same concepts behind.

No.  See what I said in the next paragraph.

Javascript uses Prototype Inheritance, and slot-based attributes, like Self.
Smalltalk uses Class-based Inheritance, and instance variables, like most OO
languages.

It's not just a matter of syntax.  It's also a fundamental difference.

You can *avoid* using anything that makes Javascript different from an OO
language, but that doesn't change the fact that someone else might not be so
restricted, so you'd better pay attention to the difference.

Guido> Yes, but don't think in dimensions of productivity of just one programmer.

Guido> Given a easy to learn programming language and such an IDE, open source,
Guido> programmers will come from everywhere to participate, a huge community of
Guido> supporters, followers, coworkers, developers will emerge.

Yes, but remember that some of them will be like me, for which your
proposed interface is a liability, not an asset.

The interface is personal.  Do not presume your favored items are
everyone's favored items.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
0
merlyn
11/25/2009 1:06:00 AM
> Please have a look at this GUI first, enjoy!
> http://www.ommwriter.com/
> Isn't that pure beauty? Can u imagine to have such a IDE....

I can imagine.  I believe it was called Word 3, maybe Word 5.  I was not 
impressed by this demo of a word processor (ommwriter).  For example, 
simplicity for word processing does not require background music.

Regarding the rest of what you're saying, the best I can figure is you 
are focused solely on the GUI.  I don't think at all that Dolphin's GUI 
has been a critical issue in its acceptance.  All other programmer 
development tools provide a similar interface, some better and some 
worse.  Some have to provide more to make up for the limitations of the 
language and environment they are dealing with.

The beauty of Smalltalk is, of course, its inherent simplicity, an 
aesthetic tour de force of birth which, combined with live objects and 
browsers, makes programming easier and faster, and makes their programs 
more robust and more scalable.  These are buzzwords that customers like 
to hear.

Am I looking for a programming development tool that children can use?  No.

> 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'm not sure what you meant by that last part.  Do ommwriter and that 
torus thing provide insight into the concept of their IDEs vis a vis 
their programming language's mental model?

I'm sure I'm preaching to the choir saying these things.  I just don't 
see, in this day and age, a Windows-based development tool's GUI as the 
overwhelmingly driving force behind its success.  I agree that the 
success of many new products (e.g., cellphones) is directly tied to 
their UI, but I don't think Dolphin has ever positioned itself for that 
kind of market.  Besides, I would guess that the GUIs for the 
development tools that created those products are pretty much standard. 
  Then again, I'm not an entrepeneur who thinks outside the box.

-- Louis
0
Louis
11/25/2009 4:43:37 AM
> DNG-VM is multithreaded - but do not make use of this feature in most of 
> 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 

0
Shaping
11/25/2009 7:56:31 AM
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


"Shaping" <shaping@bigfoot.com> schrieb im Newsbeitrag 
news:Jq5Pm.87$Lq5.86@newsfe20.iad...
>> DNG-VM is multithreaded - but do not make use of this feature in most of 
>> 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 


0
Frank
11/25/2009 8:08:42 AM
Randal L. Schwartz schrieb:
>>>>>> "Guido" == Guido Stepken <gstepken@googlemail.com> writes:
> 
> Guido> I see Javascript as "new mainstream programming language". A de facto
> Guido> standard already. Nobody sees, that Javascript is in reality SMALLTALK!
>>> No, it's not.
> 
> Guido> No? Ok, different in Syntax, but same concepts behind.
> 
> No.  See what I said in the next paragraph.
> 
> Javascript uses Prototype Inheritance, and slot-based attributes, like Self.
> Smalltalk uses Class-based Inheritance, and instance variables, like most OO
> languages.
> 
> It's not just a matter of syntax.  It's also a fundamental difference.

Hmmm, yes, I understand. In Smalltalk "plans" inherit from "plans" 
(class definitions) and in Javascript objects inherit from other 
"example" objects (prototypes). In Smalltalk objects are informed to do 
something, in Javascript (and Self) objects listen generally and react 
to a signal, they can interpret.

Well, many modern frameworks support both "paradigms". Information push 
and pull at the same time possible as well as "inversion of control", 
known as "hollywood principle": "Don't call me, i will call you!"

For a programmer is seems to be a quite fundamental difference, yes.

But from the viewpoint of the VM - it's quite the same. Why? For the 
signal/slot paradigm you need a list of (possible) senders which can 
inform, for Smalltalks send/receive messages paradigm you need a list of 
(receivers) to be informed. Both are just simple lists or internally - 
arrays of pointers on functions. Difference - marginal.

Javascript VM and Smalltalk VM are - seen from the internal viewpoint at 
assembler level - quite similar. Both are fully dynamic machines, in 
opposite to .NET including 3.0 and Java including version 6. Neither 
..NET nor Java VM are fully dynamic.

regards, Guido Stepken
0
Guido
11/25/2009 12:14:09 PM
Frank Lesser [LSW] schrieb:
> 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
0
Guido
11/25/2009 12:36:34 PM
Louis Sumberg schrieb:

> 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
0
Guido
11/25/2009 12:56:57 PM
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:

http://i.imgur.com/3T1k8.png

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
0
Andy
11/25/2009 5:30:25 PM
Andy,

>
> http://i.imgur.com/3T1k8.png

Very cool !!!
I will put it in D7.

Regards,
Bruno
0
Bruno
11/25/2009 9:58:48 PM
Andy Bower <bower@SnipThisObject-arts.com> writes:

> 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.
0
Friedrich
11/27/2009 3:04:07 PM
Have you looked at Web Velocity - http://www.web-velocity.com ?

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=A0am, Friedrich Dominicus <just-for-news-fr...@q-
software-solutions.de> wrote:
> Andy Bower <bo...@SnipThisObject-arts.com> writes:
> > 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 =A0good 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.

0
jarober
11/27/2009 4:43:04 PM
I like the concepts behind Omniwriter.
I think they will be lost of most people.
0
jamesl
11/29/2009 12:48:48 AM
On 27 Nov., 16:04, Friedrich Dominicus <just-for-news-fr...@q-software-
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.

0
Snorik
12/2/2009 9:24:53 AM
Reply: