My own Squeak direction

Juan Vuletich wrote:
> Well, the part I didn't get was: "This image would support multiple
> simultaneous viewpoints such that if you have a pointer to an object and
> I have a pointer to the same object we might get different results when
> sending the exact same message." How does this help sharing persistent
> objects?

If my version of class ByteString is slightly different than the version
of that class that you use, then some object that depends on it and
which I send to you might break when you try it in your environment. If,
on the other hand, it carries the changes it needs to ByteString and
loads them into your environment then it will work just fine but might
break other stuff. The solution I see is to allow different objects in
your environment to "see" the same class as slightly different. Then the
code you wrote yourself will work side by side with objects I shared
with you.

> By changing the language semantics I meant what you say about sending
> the same message to the same object and getting different results...
> Doesn't that change language semantics?

It can, like how Self was changed into Us by adding viewpoint operations
as a fundamental language concept. But for Squeak I am thinking about
having this mechanism stay more in the background. So it would allow you
to do in a single image what you can now do using two separate images,
but otherwise the language is the same.

-- Jecel

On Sun, 15 Nov 2009, Randal L. Schwartz wrote:

According to the seaside website, squeak is not supported anymore:
http://www.seaside.st/download/squeak

Seaside 3.0 works in trunk, but not for long:
http://code.google.com/p/pharo/issues/detail?id=331

I'm sure that squeak won't have all the changes that pharo has, and pharo
won't have all the changes that squeak has, even at the lowest level.

> "Squeak Compat" vs "Pharo Compat".  Squeak *is* Pharo.  Pharo *is* Squeak.
> They just have redundant dev teams. :)

They are similar but have different directions, different goals and the
gap between them is getting wider every day.


Levente

>
> --
> Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
> <[hidden email]> <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
>
>

2009/11/17 Eliot Miranda <[hidden email]>:
Nan trick or SmallDouble like trick or ?

Nicolas

Levente Uzonyi wrote:
> According to the seaside website, squeak is not supported anymore:
> http://www.seaside.st/download/squeak

Then let's fix it. What it takes is someone to write up a page of how to
install Seaside in Squeak, test the instructions, put them up on
Squeak.org and ask the folks at Seaside.st to link to it. You can
probably copy most of the Pharo instructions verbatim. Any takers?

> Seaside 3.0 works in trunk, but not for long:
> http://code.google.com/p/pharo/issues/detail?id=331
>
> I'm sure that squeak won't have all the changes that pharo has, and
> pharo won't have all the changes that squeak has, even at the lowest level.

Given that Seaside runs across a wide variety of Smalltalks I think that
supporting Squeak is somewhere between straightforward and trivial.
Unless you mean to imply that the above bug report is a fundamental
invariant of Seaside which happens to be violated in Squeak in which
case I'd argue that we should probably fix it if all the other
Smalltalks do it that way.

> They are similar but have different directions, different goals and the
> gap between them is getting wider every day.

I don't see this as a problem. Seaside (as a project) can have no
interest in splintering their basis so that only a few implementations
can and will support it. To the contrary - I would expect that
cross-dialect projects like Seaside do more for standardization than any
committees will ever do since they provide practical context in which to
make decisions in corner cases.

 From a practical perspective, I feel quite comfortable with saying that
Seaside support is a priority to the point that it might be driving
issues like String/Symbol comparisons, underscores in selectors etc. If
Cincom, Dolphin, GST, Gemstone and VA support a particular feature in
Seaside in a particular way, I think we should consider it as well.

Cheers,
   - Andreas

On Sun, Nov 15, 2009 at 10:48:49AM -0500, David T. Lewis wrote:
I opened a SqueakSource project for the Speech Klatt package:

MCHttpRepository
    location: 'http://www.squeaksource.com/Speech'
    user: ''
    password: ''

This is the speech package that is present in Squeak images up to and
including Squeak 3.9. It is packaged here to make it available as a MC
package, and allow the VMMaker package to access the Speech shared pool
for use in KlattSynthesizerPlugin. The initial version in the repository
is the Squeak 3.9a version that I copied from http://source.squeak.org/39a.
I have updated it to recategorize the shared pool and other references
needed for VMMaker.

I picked a couple of reputable soundings names out of a hat, thereby
nominating Marcus Denker and Andreas Raab as "developers". If anyone has
any sense of ownership over the Speech package, please speak up and I'll
turn the package over to you.

The purpose of this change is to enable "VMMaker updateFromServer" to
first load the Klatt shared pools, then load VMMaker and various related
plugins. A similar update will be needed for FFI shared pools.

Dave

Nicolas Cellier wrote:
> 2009/11/17 Eliot Miranda <[hidden email]>:
>>> Travis, Martin, what's the current demand like?

Having more than 4G of object memory is only one reason someone might
want a 64-bit VM. Maybe you use integers > 2**29 but < 2**60 and would
like them to be SmallIntegers for speed and/or space. Maybe you use
floats and would like them to be immediate for speed and/or space. Maybe
you want to call a function in a 64-bit shared library. Maybe you just
want to run a pure 64-bit Linux system without all of those 32-bit
libraries, which is becoming more practical as most common open-source
packages are now 64-bit clean. (These days I have very few 32-bit
executables on my systems.)

But yes, various size considerations were the driver for GemStone to go
64-bit. In GemStone, you don't have to have all of your objects in
memory at the same time, so you could have more than 4GB of objects even
on 32-bit. We had customers with more than 100GB of objects. But when
you have that many object there were two problems:

1. In a 32-bit address space you can only cache <4GB of objects in
memory. When you have 100GB of objects, the working set of
frequently-accessed objects is probably >4GB, so things slow down with
frequent disk accesses to swap objects in (and out, if modified).

2. The total number of persistent objects was limited to 2G objects due
to use of a 32-bit object identifier, and some customers were
approaching that limit.

Going to 64-bit fixes both of these; you can now have 2**40 objects, and
use as much RAM as you've got for caching objects.

So GemStone VMs are now 64-bit. You can use a 32-bit VW VM as a client
to 64-bit GemStone, by connecting client to server via a socket. But
some of our customers put the client and server on the same machine and
have the client VM load the server VM as a shared library, thereby
getting rid of network stack overhead. You can't do that unless client
and server are both the same architecture. So if you have a 64-bit
server VM you have to also have a 64-bit client VM. This is an advantage
to using 64-bit VW even if the client image is quite small, and this is
indeed the major driver we've had in supporting 64-bit VW.



> Nan trick or SmallDouble like trick or ?

For immediate floats: SmallDouble, definitely! At least that's what I'd
like to see. :-)

SmallDoubles are currently bit-compatible between GemStone and VW, and
I'm encouraging all dialects that go 64-bit and want immediate floats to
adopt the same format. The only reason to do otherwise is if someone
comes up with an immediate float format that is significantly better,
and in the past few years of working with the current format it looks
like the design choices were good ones.

Regards,

-Martin

David T. Lewis wrote:
> The purpose of this change is to enable "VMMaker updateFromServer" to
> first load the Klatt shared pools, then load VMMaker and various related
> plugins. A similar update will be needed for FFI shared pools.

For the FFI I'm *strongly* in favor of breaking the package out and
have, e.g.,

* FFI-SharedPools
* FFI-Kernel
* FFI-Tests
* FFI-Examples

The structure makes a lot of sense and I could even imaging moving the
plugin here (i.e., into FFI-Plugin).

Cheers,
   - Andreas

On 16-Nov-09, at 2:40 PM, Eliot Miranda wrote:

> One was Quallaby.  They did a network monitoring app that had huge  
> numbers of large integers in a graph representing the state of the  
> network.

I worked on that app for bit. We had one installation we had to be  
careful with because the images were 3.5 GB, and if we got beyond  
that, there wasn't enough room for the VM to work. Other customers  
were smaller but headed upwards and we could see that we would hit the  
limit eventually. At that point we were already processing much more  
than 4GB of data at once, but the partitioning into separate images  
was based on external factors and wasn't very flexible. Before I left,  
I was part of a project to move to a more cloudy architecture where  
partitioning was much more flexible.

I guess the take-away from that was that many cooperating smaller  
images works as well or better than one huge image. There might be  
applications where that's not true, and everything *has* to be in the  
same address space, but I can't think of any.

That is not to say, however, that 64-bit images aren't needed, just  
that images larger than 4 GB are the least interesting implication of  
having 64-bit pointers. I'd rather use the pointer bandwidth for more/
better immediate values, and run in 64-bit mode for better use of the  
hardware and integration with the host OS.

Colin

Ok, one of the objectives of building 64 bit Squeak VM hosting app was to let people explore solutions to address what a 64 bit image can do,
without the hosting harness it's hard to explore what's feasible.

A simple example is what happens if you have a 4GB 32bit image, although I've asked people if such a beast exists, no takers.

I'l note based on visual feedback at ESUG, and supporting hearsay you'll find *lots* of alpha developers using Squeak run on  OS-X, so let's push the envelope?


On 2009-11-16, at 4:32 PM, Eliot Miranda wrote:

> I concur :)  But that's partially my next target, both to have a more efficient object representation (class decode is very slow with the current one, we could do with immediate characters and in 64-bit immediate Floats) and to provide pinning for the threaded FFI.  Its probably hubris to imagine the product will scale to > 4Gb but I hope it won't be any worse :)
>
> - Bert -
--
===========================================================================
John M. McIntosh <[hidden email]>   Twitter:  squeaker68882
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
===========================================================================

On Mon, Nov 16, 2009 at 06:18:23PM -0800, Andreas Raab wrote:
Good, if you can make this change and make it available on a repository, then
I'll update the MCConfiguration for VMMaker to pull in the FFI-SharedPools.
Bert suggested the same naming convention for Speech-SharedPools, so I
can update the Speech packaging if that is the preference.

> The structure makes a lot of sense and I could even imaging moving the
> plugin here (i.e., into FFI-Plugin).

I have a slight bias, motivated primarily by personal laziness, toward
the original Squeak categories that would lead to e.g.

  VMConstruction-Interpreter/ObjectMemory
  VMConstruction-Plugins/FFIPlugin
  VMConstruction-Plugins-OSProcessPlugin/OSProcessPlugin

But either convention would be fine. Long term I think that VMMaker should
be repackaged into smaller pieces, and I have a hard time improving on the
category names that were used back in Squeak 2.4.

Dave

On Monday 16 November 2009 07:58:16 pm Göran Krampe wrote:
> Jecel Assumpcao Jr wrote:
> > I want it to be easy and elegant to create and share persistent objects
> > using Squeak.
> >
> > Solutions like Monticello+package universes/squeakmap are a bit too
> > complicated for me and yet don't do some things that I want.
>
> I don't associate those tools much with "persistent objects", mostly
> (well, SM can do Projects so sure...) with source code.
ASCII/UTF-8 encoding seems to be only way to track deltas to an image.
Currently, Squeak does not save deltas to an image. This gap imposes a burden
on developers who make small additions to a base image (which may also undergo
upgrades over time). Not that source code deltas don't break base images, but
toolsets do offer help in coping with such breakages and repairing the source
code.

The object memory has old/new areas, but the image is still a binary monolith.
As solid-state storages take hold, the cost of redundant writes will keep
rising. Is anyone looking at options where an image is a folder of files
instead of a single file?

Subbu

On 16-Nov-09, at 5:46 PM, Andreas Raab wrote:

> From a practical perspective, I feel quite comfortable with saying  
> that Seaside support is a priority to the point that it might be  
> driving issues like String/Symbol comparisons, underscores in  
> selectors etc. If Cincom, Dolphin, GST, Gemstone and VA support a  
> particular feature in Seaside in a particular way, I think we should  
> consider it as well.


Another practical compatibility issue is literal syntax for  
ByteArrays. Just about all the other Smalltalks have it, including  
Pharo. I ran into this while trying to update OmniBrowser to the  
latest Refactoring code. Any objections to implementing it?

Colin

Colin Putney wrote:
If that's a real issue, knock yourself out. Assuming you mean #[1 2 3]
syntax (i.e., no conflict with any existing constructs).

Cheers,
   - Andreas

On 16-Nov-09, at 9:03 PM, Andreas Raab wrote:

Yup, shouldn't affect existing code. I'll take a stab at it.

Colin

>>>>> "Colin" == Colin Putney <[hidden email]> writes:

Colin> Yup, shouldn't affect existing code. I'll take a stab at it.

And this is what I like about the fact that we've rebooted the
contribution process.  Yeay.

In fact, I'm wondering if I shouldn't just step up to ensure that
Squeak and Seaside keep playing together.  I'm sure it's just a
matter of getting commit access to the Squeak adaptor package on
the Seaside repo.

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[hidden email]> <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

David T. Lewis wrote:
>> * FFI-SharedPools
>> * FFI-Kernel
>> * FFI-Tests
>> * FFI-Examples
>
> Good, if you can make this change and make it available on a repository, then
> I'll update the MCConfiguration for VMMaker to pull in the FFI-SharedPools.
> Bert suggested the same naming convention for Speech-SharedPools, so I
> can update the Speech packaging if that is the preference.

Done. I've actually named the package FFI-Pools (shorter and to the
point); I don't think that naming matters as long as you can figure out
what it likely contains.

I have no particular preference either way. The laziness is traded in my
view by making sure you actually know how to find the prerequisites,
i.e., you won't be able to load VMMaker if you don't know where to find
the FFI pools but that should be fair game if you don't care about the
FFI. Or more to the point Speech. I'm sure there are people out there
who don't care about the Klatt plugin and forcing them to go onto a hunt
for this or that prerequisite seems pointless unless they care. But
then, given that I just went through the process of installing all the
bits  I can see your point about laziness :)

Cheers,
   - Andreas

On Mon, Nov 16, 2009 at 9:50 PM, Randal L. Schwartz
<[hidden email]> wrote:
It's just a matter of continually testing, fixing things that don't
work using Squeak-specific packages, and letting the rest of the
Seaside team know if there are things that need to be moved into
platform-specific packages in order to make porting possible. Probably
tracking changes to the Pharo-specific packages and adapting as
necessary would cover most of it.

We're happy to support someone maintaining a Squeak port of Seaside
just like any other platform - we just came to the realization that
the development platform had effectively become Pharo and so could not
actually say with a straight face that we knew it worked with Squeak.

Julian

My brother is a mathematician that researches on issues related to the flow of gases in the atmosphere.

2009/11/17 Ramiro Diaz Trepat <[hidden email]>:
Oh, maybe a use case for Smallapack.
A pity it does not work in Squeak yet...

Nicolas