headers
Michael Lucas-Smith | 1 Oct 2005 01:36

Re[2]: Pollock - displaying is INCREDIBLY SLOW


> I think it should be just a matter of scale. If you are using fractional
> frames only, then you have to increase the depth of the pane tree by 
> adding nested forms with widgets and other such forms. If you are using
> relational frames, then you can increase the number of widgets with 
> relational frames and make relations to widgets which themselves use 
> relational frames. After doing this, you should see the 'desired' effect...

I can reproduce the speed issue with the relational frame's, but not
with the fractional frame's.

Actually, the relational ones are definitely an issue. They slow down
very quickly. We tried to use them in WithStyle V4 originally but
dumped them for a completely different layout style due to their
inter-dependant slowness.

What I'd suggest is that there isn't a "major" hole here in Pollock.
It's just those two kinds of Frame objects that don't do their job
very well. The rest of Pollock's design is still good and will scale
just fine. These two classes's slowness are definitely isolated.

Cheers,
Michael
Permalink | Reply | 0 comments |
headers
Michael Lucas-Smith | 1 Oct 2005 01:40

Re[2]: Auto-completion


Read my blog about the various utilities that I use in VW.
http://www.cincomsmalltalk.com/userblogs/mls/blogView?showComments=true&entry=3262461779

> I don't load any of these from the CD, but from the open repository:

> AutoComplete -- started this thread

> SUnitToo -- An experimental fork of the venerable SUnit, makes it 
> easier to "plug" tools into it and solves some memory problems

> ExtraRBForSUnitToo -- Adds test buttons, stats, a variety of test-task
> shortcut keys, icon feedback for test status, etc (if you're using 
> SUnit, you really should look at using RBSUnitExtensions, which 
> inspired this package)

> ExtraEmphases -- Makes the text emphases engine more "pluggable". As an
> example, it uses it to insert "stop signs" in for the breakpoints.

> NumericCollections -- Allows you to do APL-ish things with collections.
> I use it in every app I've ever built it, but I use it lots in just 
> workspace scripts too. As a Mechanical Engineer in college, I could 
> floor any prof with what I could do with a VW workspace and this thing.

> SymbolValue -- Take simple one arg blocks of form [:each | each 
> unaryMessage] and just replace them with #unaryMessage. For example: 
> 'Hello and how are you' runsFailing: #isSeparator.

> StoreExtensions -- adds tools for computing
(Continue reading)

Permalink | Reply | 0 comments |
headers
Reinout Heeck | 1 Oct 2005 08:30
Favicon

Re: Auto-completion

Travis Griggs wrote:
>
> StoreForGlorpVWUI - Just reintroduced myself to this today.
>

I ran into version skew problems doing that, I switched to loading bundle 
StoreGlorp to get these tools into the image.

R
-
Permalink | Reply | 0 comments |
headers
Terry Raymond | 1 Oct 2005 16:13

Why does VW have error checking based on declarations?

Hi

One of the reasons many of us like smalltalk is the lack
of secondary code declarations, like type declarations,
that make the code more difficult to change and maintain,
even though they tend to catch errors earlier in the
development process. This makes me wonder why a similar
declaration is necessary for trigger events. Yes, I realize
that a class may, in some manner, turn off this check but
why is it there anyway? Furthermore, the list of events is
constructed via #constructEventsTriggered but how do you
extend this when you extend a class in some package, use
overrides, ugh!! IMHO it would be much preferable to have
a smalllint rule to advise the user of a potential event
mismatch, by looking at senders, than generate a runtime
error due to the absence of a declaration.

There is a similar situation with pragmas, but at least you
only get a warning at compile time and not a runtime error.
It would seem to me that the pragma warning really should
be a test of implementors of the pragma message and not its
presence in a declaration. Warnings are nice if you don't
need a separate declaration.

- runtime error checking based on declarations are bad
- compiler warnings and smalllint rules based on senders and
  implementors are good.
- anything that looks like a declaration should use a pragma,
  otherwise extensibility is messy.
(Continue reading)

Permalink | Reply | 5 comments |
headers
Tim Hutchison | 1 Oct 2005 17:12

[VW7.3.1][Display Icon in Dataset]

How do you display an icon in a Dataset?
Permalink | Reply | 1 comment |
headers
Vassili Bykov | 1 Oct 2005 18:40
Favicon

Re: Why does VW have error checking based on declarations?

Terry Raymond wrote:
> Hi
> 
> One of the reasons many of us like smalltalk is the lack
> of secondary code declarations, like type declarations,
> that make the code more difficult to change and maintain,
> even though they tend to catch errors earlier in the
> development process. This makes me wonder why a similar
> declaration is necessary for trigger events. Yes, I realize
> that a class may, in some manner, turn off this check but
> why is it there anyway?

Because this is better than triggering #butonPressed: in a class that 
should signal #buttonPressed: and not getting any indication that you 
goofed other than something silently not working. Such silent failures 
are often very hard to track down to the source. Just as hard as 
tracking down failures because of MessageNotUnderstood silenced inside

   [...] on: Error do: [:ex | ex return: nil]

> Furthermore, the list of events is
> constructed via #constructEventsTriggered but how do you
> extend this when you extend a class in some package, use
> overrides, ugh!!

Yes, this is why in Pollock I replaced this with pragma-based event 
declarations. (Last year I used a few extra events in some widgets, 
which since then made it into the Pollock proper). Pollock panes now 
declare events triggered by implementing a method with <eventsTriggered> 
pragma. An extending package adds a separate extension method to declare
(Continue reading)

Permalink | Reply | 4 comments |
headers
Terry Raymond | 1 Oct 2005 19:37

RE: Why does VW have error checking based on declarations?

Vassili

> -----Original Message-----
> From: Vassili Bykov [mailto:vbykov <at> cincom.com]
> Sent: Saturday, October 01, 2005 12:41 PM
> To: Terry Raymond
> Cc: VWNC
> Subject: Re: Why does VW have error checking based on declarations?
> 
> Terry Raymond wrote:
> > Hi
> >
> > One of the reasons many of us like smalltalk is the lack
> > of secondary code declarations, like type declarations,
> > that make the code more difficult to change and maintain,
> > even though they tend to catch errors earlier in the
> > development process. This makes me wonder why a similar
> > declaration is necessary for trigger events. Yes, I realize
> > that a class may, in some manner, turn off this check but
> > why is it there anyway?
> 
> Because this is better than triggering #butonPressed: in a class that
> should signal #buttonPressed: and not getting any indication that you
> goofed other than something silently not working. Such silent failures
> are often very hard to track down to the source. Just as hard as
> tracking down failures because of MessageNotUnderstood silenced inside

As you said below, " This is why we write unit tests ", it seems to me
that if you have unit tests, then you will catch the error during test.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Vassili Bykov | 2 Oct 2005 00:37
Favicon

Re: Why does VW have error checking based on declarations?

Terry Raymond wrote:
>>Because this is better than triggering #butonPressed: in a class that
>>should signal #buttonPressed: and not getting any indication that you
>>goofed other than something silently not working. Such silent failures
>>are often very hard to track down to the source. Just as hard as
>>tracking down failures because of MessageNotUnderstood silenced inside
> 
> 
> As you said below, " This is why we write unit tests ", it seems to me
> that if you have unit tests, then you will catch the error during test.

I said that about the exactly opposite thing. Unit tests can catch 
errors that *happen*. Letting undeclared events slide means they don't. 
You have the code that works fine, except that something else it should 
cause to happen doesn't. Or you mark a method with a pragma but it 
doesn't get noticed because of a typo. Things like these might be 
obvious and caught by a test, or they might not be.

> As long as you don't try to figure out what pragmas exist
> every time you need the eventlist.  If you do, you will kill
> things that are dynamic, such as DependentList, with excessive
> processing. We use DependenList to hold collections of orders
> and this list can be updated very frequently.
> 
> Now, the obvious solution is to cache the event list, but
> then you have to make sure that you properly update the cache
> whenever the code changes. So, now you introduce more overhead
> into things like parcel and package loading as well as more
> complexity.
(Continue reading)

Permalink | Reply | 0 comments |
headers
ralfkieselbach | 2 Oct 2005 12:40
Picon

Smalltalk beginners question - Event Dispatching

Hallo,

On 2005/09/28 I wrote a mail asking something about event dispatching in a MVC context.

Maybe the questions were not clear enought or confusing you...

Are there any examples about a GUI using more than one controller?

Ralf
Permalink | Reply | 4 comments |
headers
Cesar Rabak | 2 Oct 2005 20:04
Picon

KGraph or Graphs package for VW

I'm searching for packages for graph (from graph theory) work and until 
now the only one I found is version for Squeak (Graphs, Kgraphs link 
seems to be dead, although is squeak as well).

Is there an implementation already done for VW?

I would like not re-invent the wheel ;-)

--

-- 
Cesar Rabak
GNU/Linux User 52247.
Get counted: http://counter.li.org/
Permalink | Reply | 3 comments |

Gmane