My own Squeak direction

2009/11/16 Göran Krampe <[hidden email]>:
Yeah! :)
I really happy that we get to the point where such changes is possible.
I came with the idea of having sets with nils more than a year ago,
and finally there is enough critical mass of people
who not only like it, but what's more important - don't afraid to make
such changes in core system class(es).
Even more than that, i am also not satisfied seeing a Dictionary be a
subclass of Set, and also ranted about it more than 2 years ago.
And i hope, we will come with elegant & nice solution to that as well
as we did with nils in sets.

I see that with new development model, we have more and more
contributions. So, at the end, i think Board did right decision.
Yet, we have to deal with release management & image building etc
etc.. but that's another story.

> If we could also get say... some really slick concurrency mechanisms
> (Promises? Asynch messages?) either into a really good library and/or into
> the language - I really think we should stop being so afraid of modifying
> the language and its core. That is my incoherent point really.
>
> Regarding Pharo etc, IMHO it's "just a fork". And forks are good. Really. :)
> As long as we don't build fences between them (mentally or technically).
>

+1 i have the same view on it. More forks is more good.
Ironically, but it shows that Squeak, despite flaws & crap, has very
high development potential,
because forks possible, only when original design allows that without
much sacrifice.
So people, instead of complete rewrite of everything, could change
system incrementally to satisfy their own needs.

> regards, Göran
>
> PS. I really love all the exciting stuff on vm-dev (threaded VM, Cog, event
> based VM etc).
>
>
>



--
Best regards,
Igor Stasenko AKA sig.

Hi!

K. K. Subramaniam wrote:
I am slightly unsure about what you wrote above - but I *presume* you
mean that we do not have any mechanism for tracking *image* changes. We
*do* have tools for *source code* management, but not for the image
(objects).

> 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

Well, Magma is pretty close :)

regards, Göran

On 17.11.2009, at 04:18, K. K. Subramaniam wrote:

I'd love to have even a simple version of this. E.g., split the image into just two parts. Sort-of like VW's perm space (which is not garbage-collected ever) which would be the "base-image", plus all the rest in a second image file. This would allow to share a base image and a differential image in a similar fashion as we have a sources and a changes file. A regular save would just save the non-permanent part of the object memory.

- Bert -

Not just laziness, but also convenience.
The people who trying it first time, obviously having lack of knowledge,
where all those plugins resided, in what repositories, and most
important - do he needs them to build a test VM.

So, i think there are missing some kind of registry in VMMaker, which
could tell a user , what plugins existing and
where he can download them, what plugins is critical for running an
image, and what is optional and can be ignored.

It would be cool to have a 1-click VM builder. So, anyone could
download, install & build VM, without requiring user attention.



2009/11/17 Andreas Raab <[hidden email]>:


--
Best regards,
Igor Stasenko AKA sig.

On Tue, Nov 17, 2009 at 02:23:13PM +0200, Igor Stasenko wrote:
Look at the "update" category in VMMaker on SqueakSource, and
VMMaker class>>updateFromServer.

A one-click install or update would be:
  MCMcmUpdater updateFromRepositories: #('http://squeaksource.com/VMMaker' )

I'm not sure if I have the MC configuration right yet (don't have time
to check right now) but it's close.

Dave
 

Bert Freudenberg wrote:
> On 17.11.2009, at 04:18, K. K. Subramaniam wrote:
> > 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?

I suggested that a couple of messages back in this thread.

> I'd love to have even a simple version of this. E.g., split the image into just two
> parts. Sort-of like VW's perm space (which is not garbage-collected ever) which
> would be the "base-image", plus all the rest in a second image file. This would
> allow to share a base image and a differential image in a similar fashion as we
> have a sources and a changes file. A regular save would just save the non-permanent
> part of the object memory.

Sure: http://wiki.squeak.org/squeak/584

-- Jecel

On Tue, 17 Nov 2009 12:52:28 +0100, Bert Freudenberg
<[hidden email]> wrote:

>I'd love to have even a simple version of this. E.g., split the image into just two parts. Sort-of like VW's perm space (which is not garbage-collected ever) which would be the "base-image", plus all the rest in a second image file. This would allow to share a base image and a differential image in a similar fashion as we have a sources and a changes file. A regular save would just save the non-permanent part of the object memory.

The other thing this would buy us is the ability to do FLASH-memory
based devices. Those objects (and of course that includes code) that
are "permanent" can be in PermSpace, which physically sits in FLASH.

Later,
Jon

On 17.11.2009, at 17:07, Jon Hylands wrote:

That would require a segmented object memory, right?

I thought of it as being loaded into a contiguous region of memory - same as now. A simple oop comparison would suffice to determine if we're in perm space, just like the oldspace check works now. Basically, GC would simply start at the top of perm space. Not sure how to deal with stores into old space though, and I guess "outpointers" are needed too. But then, there are people more familiar with Object Memory design around here ;)

- Bert -

On 17.11.2009, at 16:59, Jecel Assumpcao Jr wrote:

Sounds a bit less simple than what I had in mind. Your idea is more flexible, of course, but I wonder if it's not too complex to get adopted?

- Bert -

Bert Freudenberg wrote:
> > Sure: http://wiki.squeak.org/squeak/584
>
> Sounds a bit less simple than what I had in mind. Your idea is more
> flexible, of course, but I wonder if it's not too complex to get adopted?

That seems to be the case, which is ironic given that the Chunky Squeak
proposal was a simplification of http://wiki.squeak.org/squeak/5637
(viewpoints and islands were eliminated) in order to be something that
might get adopted. If I have to go in my own direction, then it might as
well be the full system instead.

Even simpler systems than Chunky Squeak would still be useful. You can
limit it to two levels, for example, or eliminate the "patch old
objects" stuff. The key idea is to not divide a bunch of bits into two
pieces and then put them together again using a changed version of one
of the pieces (which is what we have with ImageSegments). If you join
the same exact bits and it worked before, it will work again.

-- Jecel

After today's update, the following code:

    [ fHandle atEnd ] whileFalse: [
        stringFromFile := fHandle nextLine.
        draw := Draw newFromString: stringFromFile.
        draw isNil
            ifTrue: [
                Transcript show: 'Failed to load draw.'; cr.
                fHandle close.
                ^nil ].
        model draws addLast: draw ].

Results in the following error:

nextLine
    "Answer next line (may be empty), or nil if at end.
    Handle a zoo of line delimiters CR, LF, or CR-LF pair"

    | newStream element crlf |
    self atEnd ifTrue: [^nil].
    crlf := CharacterSet crlf.
    newStream := WriteStream on: (collection species new: 100).
    [self atEnd ifTrue: [^newStream contents].
    crlf includes: (element := self next)]
        whileFalse: [newStream nextPut: element].
    element = Character cr ifTrue: [self peekFor: Character lf]. "handle
an eventual CR LF pair"
    ^newStream contents

=============================================================

new: sizeRequested
    "Answer an initialized instance of this class with the number of
indexable
    variables specified by the argument, sizeRequested."

    ^ (self basicNew: sizeRequested) initialize

=============================================================

basicNew: sizeRequested
    "Primitive. Answer an instance of this class with the number
    of indexable variables specified by the argument, sizeRequested.
    Fail if this class is not indexable or if the argument is not a
    positive Integer, or if there is not enough memory available.
    Essential. See Object documentation whatIsAPrimitive."

    <primitive: 71>
    self isVariable ifFalse:
        [self error: self printString, ' cannot have variable sized
instances'].
    (sizeRequested isInteger and: [sizeRequested >= 0]) ifTrue:
        ["arg okay; space must be low."
        self environment signalLowSpace.
        ^ self basicNew: sizeRequested  "retry if user proceeds"].
    self primitiveFailed

=============================================================

error: aString
    "Throw a generic Error exception."

    ^Error new signal: aString

Error: UndefinedObject cannot have variable sized instances

CONTENTS DELETED

On 11/14/2009 11:29 PM, Andreas Raab wrote: Thanks for starting this thread.

What I would like to see with Squeak and I really don't know how
possible it is or what it would take or even if it would be acceptable
and supported by the community. But here goes.

Presently I am writing an app that I would love to do in Squeak but cannot.
Why Squeak?
Simply because I love working within a live environment.
I love the tools available for writing the code.
I love being able to fix a problem live and continue on. Not starting
all over.

But I am constrained. I am provided two options for my application.
1. Interface with a Windows COM library.
2. Interface with Java libraries.

I would love to see Squeak running on the JVM able to import and
interoperate with native Java libraries.
I would love to see Squeak give Jython or Clojure a run for their money.
I would love to see Squeak enable more people to use less of Java.
I would love to see Squeak enable more people to make a living within
the constraints imposed upon them by the business world by using Squeak.

I really believe that the more people who can make a living using
Squeak, the better the opportunities for Squeak to be those things the
rest of the community would like. A thriving ecosystem with a healthy
number of users enables a lot of things.

And like Andreas said in the Sophie thread,
> This entirely line of arguments is one of the better reasons why
> "being popular" isn't such a bad thing :-)

I would love to see myself, Andreas and whomever not have to choose
Python, etc. for some of the things that it gets chosen for. I would
love to do those things in Squeak and better than I can do them in Python.

So presently I am using Python with win32 extensions to access the COM
dll, writing data to a MongoDB, reading the MongoDB from Jython and
passing the data to some Java libraries and then doing other stuff in
Jython and passing data back to MongoDB and Python win32. :(    But it
works.

I don't know how much technically I can contribute to my vision above.
But at a later time I would possibly be interested in finding out if it
is reasonable to pay (fund) to have Squeak on the JVM.

And yes I know about the start that Dan made on that direction. But I
don't know how complete it is. And if it meets all of the requirements.

I think this could get Squeak into the business world in a way that it
currently cannot.
I think this could also provide a potential migratory path for people
who choose so to move away from Java but are constrained not due to
technical reasons but political and bureaucratic.
Why should we have a great Lisp dialect (Clojure) on the JVM and not
have an equally good Squeak (Smalltalk)?

And then maybe we can win Sophie back to Squeak. :)

Just some of my thoughts.

Thanks.

Jimmie

IMHO, Squeak should reduce itself to a kernel that people can make forks of.

Gulik.


--
http://gulik.pbwiki.com/

Hi Casimiro,
it would help if you would provide receiver class information.
Otherwise, I see I probably messed up the horrific Stream hierarchy !
I will revert this change until a better fix - mean more tests .

Cheers

2009/11/17 Casimiro de Almeida Barreto <[hidden email]>:

I get it.
I wanted to use #upToAnyOf: crlf.
Unfortunately, this one would not tell me whether a cr or a lf was hit
(or the end of stream).
So I inlined the sole implementor in the hierarchy naively thinking it
would just work...
MY ERROR!
not only is it sub optimal (slow), #upToAnyOf: is broken in
StandardFileStream...

Recipe:
- create an inst var in abstract superclass,
- use it in many methods,
- define a subclass that do not use this inst var,
- define only a subset of superclass messages in the subclass,
congratulations you created at least as many bugs as the number of
methods you failed to override.

When I read all this code, I get the feeling that the whole stream
hierarchy is broken...
If you trust library consistency, you're in trouble.
That is the next big core library deserving clean-up in trunk.
I guess Pharo will have an easier task integrating Nile complete rewrite ;)

OK, end of rant :)

Nicolas

2009/11/17 Nicolas Cellier <[hidden email]>:

2009/11/17 Michael van der Gulik <[hidden email]>:
reduction is a bit too strong word. Splitting on modules is more correct.
Potentially, community can maintain a much larger code base, not just kernel.
But it is critical to keep things in such state, that any optional
component (all but kernel) could be easily
and cleanly removed from system at user's will.


> Gulik.
>
>
> --
> http://gulik.pbwiki.com/
>
>
>
>



--
Best regards,
Igor Stasenko AKA sig.

I would like to see the following directions included for Squeak:

Modularity and minimal core - so that you can load what you want onto a minimal core and be sure that you can unload the same thing cleanly. If a newly loaded package provides a new version of a method when the existing version is absolutely required by another existing package, allow the previous version to remain usable alongside the new. This should all be done in such a manner as to hopefully minimize the need for forking, or think of all custom images as forks like Guilik just mentioned.

Along with the modularity, a convenient system of automatically loading your custom modifications, such as:

Automatic test and build server eg. Installer, 'Sake/Packages' and 'Bob the Builder'.

Simple method of logging your ongoing work and migrating all your current image state to a fresh image.

Remove the barriers to using the latest dev tools like MC and ensure various updates get merged into the externally managed and loadable/unloadable package.

Remove the barriers to loading/unloading things like Tweak, Sophie, EToys.

Good code execution visualization tool to help understand the way things work.

A bug/enhancement tracking system that people like to use.

   Ken G. Brown

>>>>> "Julian" == Julian Fitzell <[hidden email]> writes:

Julian> It's just a matter of continually testing, fixing things that don't
Julian> work using Squeak-specific packages, and letting the rest of the
Julian> Seaside team know if there are things that need to be moved into
Julian> platform-specific packages in order to make porting possible. Probably
Julian> tracking changes to the Pharo-specific packages and adapting as
Julian> necessary would cover most of it.

As a datapoint, the alpha5 release works just fine in Squeak-trunk.

I'd like to reduce the "scare factor" that people are generating
about "Oh my gawd... Seaside will *only* run on Pharo!".  I will
personally commit to fixing *any* test failure for Squeak-trunk
on every released Squeak-trunk image.

I may ask for help.  But I want to make sure it's clear that
Squeak-trunk and Seaside 3.0 *are* compatible... we say so.

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

Randal L. Schwartz wrote:
> As a datapoint, the alpha5 release works just fine in Squeak-trunk.
>
> I'd like to reduce the "scare factor" that people are generating
> about "Oh my gawd... Seaside will *only* run on Pharo!".  I will
> personally commit to fixing *any* test failure for Squeak-trunk
> on every released Squeak-trunk image.
>
> I may ask for help.  But I want to make sure it's clear that
> Squeak-trunk and Seaside 3.0 *are* compatible... we say so.

Absolutely. I also tried to make this very, very clear during the
podcast. We're committed to supporting Seaside. We'll need help in the
form of people pointing out when things get broken, we may need help
from people writing tests to document what got broken and how to fix
this but you *will* find help here if you report a problem with Seaside
in Squeak.

Cheers,
   - Andreas