Re: VW on Kubuntu

Hi Federico:

I use Libranet on my old Vaio.  It works fine, but I believe they are  
shutting down and are not selling their distro any longer.  It is a  
Debian-based Distro.  I run Kubuntu on a *really* finky shoebox  
computer with an nForce chipset.  It works well.

I use VW 7.1-7.3.1 on both without trouble.

On Nov 30, 2005, at 8:13 AM, <balaguer <at> uiuc.edu> <balaguer <at> uiuc.edu>  
wrote:

> Did anyone tried VW7.x on Kubuntu? Any ideas what would be the
> best linux to run VW on a notebook?
>
> Thanks, Federico
>

Thanks!!
Joseph Bacanskas [|]
--- I use Smalltalk.  My amp goes to eleven.

[DLLCC] Wrong return value for defines?

For some reason if #define method references another #define instead of 
a value, it returns a 0 instead of a proper value of a #define it 
references.

Say, we have

TBPARAM_PRINT_FILE
    <C: #define TBPARAM_PRINT_FILE CFG_IJPRINTER_PRINTBMP>

CFG_IJPRINTER_PRINTBMP
    <C: #define CFG_IJPRINTER_PRINTBMP 33>

One would expect that both of them return 33, but thats not quite the 
case, because only CFG_IJPRINTER_PRINTBMP returns 33, TBPARAM_PRINT_FILE 
returns 0.

Any ideas?

-Boris

--

-- 
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5

boris <at> deepcovelabs.com

CONFIDENTIALITY NOTICE

RE: Interesting problem with actionButton ...

Dennis

Our system is a client/server system. At times it is
possible for a client request to take a while. However,
we also want the various active applications to update
their displays with current data coming from the server
while the user is waiting for his response. This meant
we could not block the UI process while it waited for a
response.

My solution was to modify the window manager and a couple
of event classes so it would ignore any user input events
until the server completed the user's request.

It works quite well.

Terry

===========================================================
Terry Raymond       Smalltalk Professional Debug Package
Crafted Smalltalk
80 Lazywood Ln.
Tiverton, RI  02878
(401) 624-4517      traymond <at> craftedsmalltalk.com
<http://www.craftedsmalltalk.com>
===========================================================
> -----Original Message-----
> From: Dennis Smith [mailto:dennis <at> CherniakSoftware.com]
> Sent: Wednesday, November 30, 2005 1:29 PM
> To: VWNC,

Bug in MethodDictionary

Here is an example which demonstrates a problem in the 7.3.1 image.  The circumstances in which
the problem occur are dependent on the initial size of the method dictionary, and the identityHash
of particular Symbols.  The problem can be reproduced in any image, but it would require other
Symbols to be used.

#( #emitTrace #Macintosh  #foo #disabledDownIconMask )
	do: [:selector |
		Set compile: selector , '
^1'].
<do-It>

| failure |
[Set new emitTrace.
failure := false ]
	on: Error do: [:ex | failure := true ].

(failure & (Set methodDictionary keys includes: #emitTrace))
		ifTrue: [ 'method not found']
		ifFalse: [ 'method found' ]
<print-It>

The problem is in the implementation of binary chop used for key lookup.  It goes wrong if the
first three keys in the dictionary have the same identityHash, and if the chop leads to a test on
the second key before the third.  In the 7.3.1 image build , #emitTrace #Macintosh  and
#disabledDownIconMask have the identityHash 6, which is lower than that of any of the other
selectors in class Set.  The fourth key #foo just puts a 31st method in the class so that the chop
gets to the wrong key first.

It is a bit surprising that the problem can be demonstrated via code execution, since method
lookup is ordinarily done in the VM, not the image.  I did not check the VM source, so it is just

Re: Most Recently Published >= Development

Steven Kelly wrote:
> One thing I've found out recently is that searching for the "most
> recently published version of a package with blessing >= Development" is
> actually a really bad idea. As soon as you start to get forks in your
> version tree, the most recently published version may not be in the fork
> you want. For instance, we have a released version 4.0 of MetaEdit+ and
> versions after that (4.1, 4.2...) are development for the next version,
> 4.5. Sometimes though I'll go back to the 4.0 version and add a patch
> there to solve a customer problem, creating 4.0.1. If I try and build
> 4.5 by "most recent >= Development" I'll inadvertently pick up the 4.0.1
> version. Conversely, if I'm trying to build a server release of 4.0.1
> I'll probably get lots of stuff that's only intended for 4.5.

I was running into this problem trying to keep up with our weekly 
builds. Now I'm using the attached hacks to get around this. The hack is 
rather simple, it assumes that each branch is trivially distinguishable 
based on version stamps.

These hacks refers to two globals that I would set as follows for the 
7.4 release cycle: Release := '7.4%'. OldRelease := '7.3%'. I can then 
be sure that when I do "Package loadLatestVersionWithName: 'X'", that I 
will get either latest '7.4....' or if there is no such version then 
latest '7.3....' otherwise latest overall. I used the globals to keep my 
scripts concise (I load a lot of stuff into my development images), they 
can be easily turned into additional message arguments. Note that the 
version stamp patterns have to use the SQL wildcarding $%, not $* .

Anyway, nothing terribly clever, but since you've asked .

HTH,

Re: Most Recently Published >= Development

Steven Kelly wrote:
> One thing I've found out recently is that searching for the "most
> recently published version of a package with blessing >= Development" is
> actually a really bad idea. As soon as you start to get forks in your
> version tree, the most recently published version may not be in the fork
> you want

Store implements branching but does not support it.

If you use Store as linearly versioned storage you are fine (unless you want 
to do builds of older versions). 
If you use Store as Version Control System you get into trouble like you 
describe above, but hacks and naming conventions will keep your nose above 
the water for a while.
Using Store as a Configuration Management System is simply not supported.

At Soops we branch (=copy) the repository to support major branches -- mostly 
VW upgrades, sometimes a major branch of our projects (but we try to synch 
those two kinds of events).

We also work with lineups[1,2] but we found these somewhat cumbersome to 
maintain unless the automated build creates and publishes these lineups 
automatically. What we use intensively is the underlying model of unversioned 
lineups (which we call Configs here) for poor-man's configuration mgmt.

Note that the lineups package also adds the menu items 'Packages on Branch' 
and 'Merge Branch' based on version string prefixes like Martin suggests.

[1]http://www.cincomsmalltalk.com/userblogs/travis/blogView?showComments=true&title=Line+Ups%2C+Reported+by+Reinout+Heeck&entry=3265388740#3265388740
[2]http://swiki.cdegroot.com/lineups

VisualWorks and Gemstone method execution

Re: VW 7.4 Delivery

Steven Kelly wrote:
>  
> I think all we really need is for Store publishing to work well enough 
> that it can handle VW itself. Even with 7.3.1 we still get problems with 
> overrides not being handled properly, and of course the base VW stuff 
> has plenty of those (PDP etc.).

Yes!  It really irritates me that the base VW image has *overrides*, many of 
them from the PDP debugger.  Grrr.  There is no sane reason why PDP shouldn't 
be fully integrated by this time.

Chris
--

-- 
Chris Winemiller                mailTo:c-winemiller <at> AdventaCT.com
Adventa Control Technologies    Voice: 972-543-1683
3001 East Plano Parkway #100
Plano TX 75074-7422
http://www.AdventaCT.com

Re: VW 7.4 Delivery

Chris Winemiller wrote:
> Steven Kelly wrote:
>>  
>> I think all we really need is for Store publishing to work well 
>> enough that it can handle VW itself. Even with 7.3.1 we still get 
>> problems with overrides not being handled properly, and of course the 
>> base VW stuff has plenty of those (PDP etc.).
>
> Yes!  It really irritates me that the base VW image has *overrides*, 
> many of them from the PDP debugger.  Grrr.  There is no sane reason 
> why PDP shouldn't be fully integrated by this time.
I can think of a couple of reasons why one might want overrides
    a) its simpler for two groups to work on things, one on the base and 
one on the debugger
    b) perhaps more important, if you don't load the debugger 
(production deployment) you don't perhaps want those
          overrides.
I am not saying that this is the case, but it does provide reasons for 
having overrides in the base.
>
> Chris

--

-- 
Dennis Smith                        dennis <at> CherniakSoftware.com
Cherniak Software Development Corporation       +1 905.771.7011
400-10 Commerce Valley Dr E                Fax: +1 905.771.6288
Thornhill, ON Canada L3T 7N7    http://www.CherniakSoftware.com

Re: VW 7.4 Delivery

Dennis Smith wrote:
> 
> Chris Winemiller wrote:
> 
>> Steven Kelly wrote:
>>
>>>  
>>> I think all we really need is for Store publishing to work well 
>>> enough that it can handle VW itself. Even with 7.3.1 we still get 
>>> problems with overrides not being handled properly, and of course the 
>>> base VW stuff has plenty of those (PDP etc.).
>>
>>
>> Yes!  It really irritates me that the base VW image has *overrides*, 
>> many of them from the PDP debugger.  Grrr.  There is no sane reason 
>> why PDP shouldn't be fully integrated by this time.
> 
> I can think of a couple of reasons why one might want overrides
>    a) its simpler for two groups to work on things, one on the base and 
> one on the debugger

The code should be organized for ease of use by customers (me), not the VW 
developers.  That's the same principle we try to apply in our product.  And by 
the way, my customers are fully exposed to the VisualWorks development 
environment, by design.  The fewer overrides to explain and manage, the better.

>    b) perhaps more important, if you don't load the debugger (production 
> deployment) you don't perhaps want those
>          overrides.

It would be better to integrate the PDP debugger and provide a loadable parcel 
(with overrides) for the *old* debugger.

Chris
--

-- 
Chris Winemiller                mailTo:c-winemiller <at> AdventaCT.com
Adventa Control Technologies    Voice: 972-543-1683
3001 East Plano Parkway #100
Plano TX 75074-7422
http://www.AdventaCT.com