Release candidate Squeak4.4-12320 ready

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
76 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Re: Release candidate Squeak4.4-12320 ready

Frank Shearar-3
On 23 December 2012 19:33, tim Rowledge <[hidden email]> wrote:

>
> On 23-12-2012, at 11:15 AM, Frank Shearar <[hidden email]> wrote:
>
>> On 22 December 2012 23:36, Bert Freudenberg <[hidden email]> wrote:
>>>
>>> We're talking about _where_ the window opens.
>>
>> OK. I suspect the reason I've not noticed anything like that is
>> because I'm running 1024x768 on a Lucid box. The window opens rather
>> close to the top left, pretty much where I'd expect it to. I just
>> opened a TrunkImage.image on a Mac and it looks like it opens it right
>> in the centre of the screen. Is that what you see?
>
>
> Last I recall there was no info in the image header to specify where the main squeak window would open and it was a platform decision at start time. Now, with the Ffenestri stuff in proper use one could revise that by allowing the image code to specify where the first window opens, with appropriate policy objects to discover the screen size and look at OS preferences etc.
>
> Are non-RISC OS vm *still* opening a main window by default? I hope not. It's a stupid thing to do; no window should even created until (and unless!) some displaying to Display (or suitable other object) is done.

As far as I understand it, only the Windows VM has issues running
headless (because of Windows' bonkers split between console
applications and windowed applications). Certainly when testing the
build scripts (thus headless, on a Linux machine), the builds behave
just as you'd expect a command line application to.

Which has its own problems, since there's a great deal of code in the
image that assumes that popping up a Debugger is a sensible thing to
do. I know Camillo Bruni and the Pharo guys have done a great deal of
work on command line issues: there might well be some tasty
easy-to-pluck fruit hanging off our neighbour's tree...

frank

> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Throughout history, every mystery solved has turned out to be...
> *not magic*
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Release candidate Squeak4.4-12320 ready

David T. Lewis
In reply to this post by timrowledge
On Sun, Dec 23, 2012 at 11:33:11AM -0800, tim Rowledge wrote:

>
> On 23-12-2012, at 11:15 AM, Frank Shearar <[hidden email]> wrote:
>
> > On 22 December 2012 23:36, Bert Freudenberg <[hidden email]> wrote:
> >>
> >> We're talking about _where_ the window opens.
> >
> > OK. I suspect the reason I've not noticed anything like that is
> > because I'm running 1024x768 on a Lucid box. The window opens rather
> > close to the top left, pretty much where I'd expect it to. I just
> > opened a TrunkImage.image on a Mac and it looks like it opens it right
> > in the centre of the screen. Is that what you see?
>
>
> Last I recall there was no info in the image header to specify where the main squeak window would open and it was a platform decision at start time. Now, with the Ffenestri stuff in proper use one could revise that by allowing the image code to specify where the first window opens, with appropriate policy objects to discover the screen size and look at OS preferences etc.
>

Right, window size is stored in the header, but not window location.

For verification, load package 'ImageFormat' from SqueakMap, then do this:

  | fs |
  fs := (FileStream readOnlyFileNamed: Smalltalk imageName) binary.
  ([ImageFileHeader readFrom: fs] ensure: [fs close]) explore

This will show the contents of an image file header. It's handy as a memory jogger.

There is also CogImageFileHeader, which displays header fields relevant to Cog but
ignored by the interpreter VM:

  | fs |
  fs := (FileStream readOnlyFileNamed: Smalltalk imageName) binary.
  ([CogImageFileHeader readFrom: fs] ensure: [fs close]) explore

> Are non-RISC OS vm *still* opening a main window by default?

Yes.

> I hope not. It's a stupid thing to do; no window should even created until (and unless!) some displaying to Display (or suitable other object) is done.
>

You're right. Somebody should do something about that ;-)

Dave


Reply | Threaded
Open this post in threaded view
|

Re: Release candidate Squeak4.4-12320 ready

timrowledge

On 23-12-2012, at 12:23 PM, "David T. Lewis" <[hidden email]> wrote:
>
>
>> Are non-RISC OS vm *still* opening a main window by default?
>
> Yes.

Sigh.

>
>> I hope not. It's a stupid thing to do; no window should even created until (and unless!) some displaying to Display (or suitable other object) is done.
>>
>
> You're right. Somebody should do something about that ;-)

Example code in the RISC OS branch. sqRPCWindows.c|ioShowDisplayOnWindow()
When a display operation is intended to affect the on-screen display, if no window already exists, make one first, then do the normal display work.  If no displaying is ever done - oh, I don't know, maybe because the image is set up to be a headless server - then no window needs to be created.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
If you think C++ is not overly complicated, just what is a protected abstract virtual base pure virtual private destructor and when was the last time you needed one?
Reply | Threaded
Open this post in threaded view
|

Re: Release candidate Squeak4.4-12320 ready

Nicolas Cellier
In reply to this post by David T. Lewis
2012/12/23 David T. Lewis <[hidden email]>:

> On Sun, Dec 23, 2012 at 11:33:11AM -0800, tim Rowledge wrote:
>>
>> On 23-12-2012, at 11:15 AM, Frank Shearar <[hidden email]> wrote:
>>
>> > On 22 December 2012 23:36, Bert Freudenberg <[hidden email]> wrote:
>> >>
>> >> We're talking about _where_ the window opens.
>> >
>> > OK. I suspect the reason I've not noticed anything like that is
>> > because I'm running 1024x768 on a Lucid box. The window opens rather
>> > close to the top left, pretty much where I'd expect it to. I just
>> > opened a TrunkImage.image on a Mac and it looks like it opens it right
>> > in the centre of the screen. Is that what you see?
>>
>>
>> Last I recall there was no info in the image header to specify where the main squeak window would open and it was a platform decision at start time. Now, with the Ffenestri stuff in proper use one could revise that by allowing the image code to specify where the first window opens, with appropriate policy objects to discover the screen size and look at OS preferences etc.
>>
>
> Right, window size is stored in the header, but not window location.
>
> For verification, load package 'ImageFormat' from SqueakMap, then do this:
>
>   | fs |
>   fs := (FileStream readOnlyFileNamed: Smalltalk imageName) binary.
>   ([ImageFileHeader readFrom: fs] ensure: [fs close]) explore
>
> This will show the contents of an image file header. It's handy as a memory jogger.
>
> There is also CogImageFileHeader, which displays header fields relevant to Cog but
> ignored by the interpreter VM:
>
>   | fs |
>   fs := (FileStream readOnlyFileNamed: Smalltalk imageName) binary.
>   ([CogImageFileHeader readFrom: fs] ensure: [fs close]) explore
>
>> Are non-RISC OS vm *still* opening a main window by default?
>
> Yes.
>
>> I hope not. It's a stupid thing to do; no window should even created until (and unless!) some displaying to Display (or suitable other object) is done.
>>
>
> You're right. Somebody should do something about that ;-)
>

Smalltalk meant to be graphical, so I bet that the stupid thing used
to be to not open a window...
It may be that the shift of code was a few years late behind the shift
of idea...

Nicolas

> Dave
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Release candidate Squeak4.4-12320 ready

timrowledge

On 23-12-2012, at 12:41 PM, Nicolas Cellier <[hidden email]> wrote:
>
>
> Smalltalk meant to be graphical, so I bet that the stupid thing used
> to be to not open a window...
> It may be that the shift of code was a few years late behind the shift
> of idea…


Well, originally Smalltalk simply took over the entire machine and so whatever else might have been running got terminated with prejudice and cleared off the screen. I'm thinking of maybe building a RaspberryPi SD card image that just does enough to allow Squeak to run. Sort a slot-in Smalltalk engine.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: TOAC: Turn Off Air Conditioner



Reply | Threaded
Open this post in threaded view
|

Re: Release candidate Squeak4.4-12320 ready

Chris Muller-3
In reply to this post by Bert Freudenberg
>>> So, we should please deploy the image at 800x600.
>
> Chris, when I wrote "position" in the paragraph above I meant precisely that. I did not propose to change the size.

Yes, I knew that.  *I* was talking about the extent of the window, not
its position.

Reply | Threaded
Open this post in threaded view
|

Re: Release candidate Squeak4.4-12320 ready

David T. Lewis
In reply to this post by timrowledge
On Sun, Dec 23, 2012 at 12:38:10PM -0800, tim Rowledge wrote:

>
> On 23-12-2012, at 12:23 PM, "David T. Lewis" <[hidden email]> wrote:
> >
> >
> >> Are non-RISC OS vm *still* opening a main window by default?
> >
> > Yes.
>
> Sigh.
>
> >
> >> I hope not. It's a stupid thing to do; no window should even created until (and unless!) some displaying to Display (or suitable other object) is done.
> >>
> >
> > You're right. Somebody should do something about that ;-)
>
> Example code in the RISC OS branch. sqRPCWindows.c|ioShowDisplayOnWindow()
> When a display operation is intended to affect the on-screen display, if no window already exists, make one first, then do the normal display work.  If no displaying is ever done - oh, I don't know, maybe because the image is set up to be a headless server - then no window needs to be created.
>

Yes I see. And an arbitrary number of display windows is supported via:

  windowDescriptorBlock *windowBlockFromIndex(int windowIndex)

>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> If you think C++ is not overly complicated, just what is a protected abstract virtual base pure virtual private destructor and when was the last time you needed one?

Reply | Threaded
Open this post in threaded view
|

Re: Release candidate Squeak4.4-12320 ready

Frank Shearar-3
In reply to this post by Chris Muller-3
On 23 December 2012 22:28, Chris Muller <[hidden email]> wrote:
>>>> So, we should please deploy the image at 800x600.
>>
>> Chris, when I wrote "position" in the paragraph above I meant precisely that. I did not propose to change the size.
>
> Yes, I knew that.  *I* was talking about the extent of the window, not
> its position.

Which means, to be clear, that there is nothing to be done here:
(a) The window _is_ 800x600.
(b) Precisely where on the screen the window opens is platform
dependent at best and simply uncontrolled at worst.

Right?

frank

Reply | Threaded
Open this post in threaded view
|

Re: Release candidate Squeak4.4-12320 ready

Chris Muller-3
> Right?

Oops!  Yes.  Ok, NOW I understand what Bert said.  (Lol!)


On Sun, Dec 23, 2012 at 4:53 PM, Frank Shearar <[hidden email]> wrote:

> On 23 December 2012 22:28, Chris Muller <[hidden email]> wrote:
>>>>> So, we should please deploy the image at 800x600.
>>>
>>> Chris, when I wrote "position" in the paragraph above I meant precisely that. I did not propose to change the size.
>>
>> Yes, I knew that.  *I* was talking about the extent of the window, not
>> its position.
>
> Which means, to be clear, that there is nothing to be done here:
> (a) The window _is_ 800x600.
> (b) Precisely where on the screen the window opens is platform
> dependent at best and simply uncontrolled at worst.
>
> Right?
>
> frank
>

Reply | Threaded
Open this post in threaded view
|

Re: Release candidate Squeak4.4-12320 ready

timrowledge
In reply to this post by David T. Lewis

On 23-12-2012, at 2:32 PM, "David T. Lewis" <[hidden email]> wrote:
>
> Yes I see. And an arbitrary number of display windows is supported via:
>
>  windowDescriptorBlock *windowBlockFromIndex(int windowIndex)


Yup. A linked list. I hate arbitrary limits due to lazy planning. I intend to avoid that 255 times.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: SCEU: Simulate Correct Execution, Usually



Reply | Threaded
Open this post in threaded view
|

Re: Release candidate Squeak4.4-12320 ready

Bert Freudenberg
In reply to this post by Frank Shearar-3

On 2012-12-23, at 20:15, Frank Shearar <[hidden email]> wrote:

> On 22 December 2012 23:36, Bert Freudenberg <[hidden email]> wrote:
>>
>> On 22.12.2012, at 23:51, Frank Shearar <[hidden email]> wrote:
>>
>>> On 22 December 2012 21:02, Chris Muller <[hidden email]> wrote:
>>>>> Another point: The window opens at 560@286 so its bottom-right corner is at 1360@886 which might by off of some screens. I'd position it further up to the left, maybe at ((1024@768) - (800@600)) / 2 ==> 112@84
>>>>
>>>> Past Squeak releases were saved in standard size 800x600, which is a
>>>> good balance between what's needed to operate Squeak, what's available
>>>> on screens, and what's a desired-size operating environment that users
>>>> not wishing to run full-screen would want.  800x600 is a *balanced*
>>>> size.
>>>>
>>>> 560x286 is non-standard and probably something that will force users
>>>> into a resize gesture before they will do anything.
>>>>
>>>> So, we should please deploy the image at 800x600.
>>
>> Chris, when I wrote "position" in the paragraph above I meant precisely that. I did not propose to change the size.
>>
>>> So I presume that we are actually talking about the window in which
>>> Squeak lives, right?
>>
>> Yes.
>>
>>> The extent of the host window?
>>
>> No.
>>
>>> The window's the same size as the 4.3 release. I've not altered it.
>>> Note as well that the ReleaseBuilder says 'self setDisplayExtent: 800
>>> @ 600'.
>>>
>>> frank
>>
>> We're talking about _where_ the window opens.
>
> OK. I suspect the reason I've not noticed anything like that is
> because I'm running 1024x768 on a Lucid box. The window opens rather
> close to the top left, pretty much where I'd expect it to. I just
> opened a TrunkImage.image on a Mac and it looks like it opens it right
> in the centre of the screen. Is that what you see?


Indeed it is. I hadn't noticed yet that Eliot's Mac VM opens the window centered, while John's Mac VM opens it in the top-left.

So I retract my remark, there's nothing to do about that for this release :)

- Bert -


Reply | Threaded
Open this post in threaded view
|

R-Pi as a Squeak computer (was: Release candidate Squeak4.4-12320 ready)

Jecel Assumpcao Jr
In reply to this post by timrowledge
Tim Rowledge wrote:

> Well, originally Smalltalk simply took over the entire machine and so whatever
> else might have been running got terminated with prejudice and cleared off
> the screen. I'm thinking of maybe building a RaspberryPi SD card image that
> just does enough to allow Squeak to run. Sort a slot-in Smalltalk engine.

The main complication is that the ARM is just the I/O processor on this
machine and it is the secret "GPU" that boots first and does all the
initialization. This has already been figured out for Linux in the form
of a binary blob, though I think there are enough details available to
adapt it for other uses. There is the option of having a stripped down
Linux under Squeak, like Dan Ingalls used in his Squeak Box
(unfortunately, http://www.fflinux.org where all the code was is long
gone):

http://wiki.squeak.org/squeak/3558
http://wiki.squeak.org/squeak/3502

-- Jecel


Reply | Threaded
Open this post in threaded view
|

(no subject)

Hans-Martin Mosner
In reply to this post by Frank Shearar-3
        <CAD+=c1j5i9YQr2kSNmKn7reUMRObXYFjbm9G7Wn=[hidden email]>

        <[hidden email]>

        <[hidden email]>

        <[hidden email]>

        <[hidden email]>

        <[hidden email]>

        <CAJbhyRFjCdSd7VpYqHB9iEe44j4WJgw6pN1XcqZjtm=[hidden email]>

        <[hidden email]>

        <[hidden email]>

        <CAKnRiT4hj4=[hidden email]>

        <[hidden email]>
Subject: Re: [squeak-dev] R-Pi as a Squeak computer (was: Release candidate
 Squeak4.4-12320 ready)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

I will have some time during the next days so hopefully I'll be able to explorr the possibilities. One that should certainly work is to create a very minimal Linux system that immediately starts up Squeak. Another would be to look at the non-Linux alternatives such as RISC OS and see how they are doing it.

Cheers,
Hans-Martin

 

-----Original Message-----
From: "Jecel Assumpcao Jr." <[hidden email]>
To: The general-purpose Squeak developers list <[hidden email]>
Sent: Mo., 24 Dez 2012 14:56
Subject: [squeak-dev] R-Pi as a Squeak computer (was: Release candidate Squeak4.4-12320 ready)

Tim Rowledge wrote:

> Well, originally Smalltalk simply took over the entire machine and so whatever
> else might have been running got terminated with prejudice and cleared off
> the screen. I'm thinking of maybe building a RaspberryPi SD card image that
> just does enough to allow Squeak to run. Sort a slot-in Smalltalk engine.

The main complication is that the ARM is just the I/O processor on this
machine and it is the secret "GPU" that boots first and does all the
initialization. This has already been figured out for Linux in the form
of a binary blob, though I think there are enough details available to
adapt it for other uses. There is the option of having a stripped down
Linux under Squeak, like Dan Ingalls used in his Squeak Box
(unfortunately, http://www.fflinux.org where all the code was is long
gone):

http://wiki.squeak.org/squeak/3558
http://wiki.squeak.org/squeak/3502

-- Jecel


Reply | Threaded
Open this post in threaded view
|

Re: (no subject)

timrowledge

On 24-12-2012, at 8:54 AM, Hans-Martin Mosner <[hidden email]> wrote:
>
> I will have some time during the next days so hopefully I'll be able to explorr the possibilities. One that should certainly work is to create a very minimal Linux system that immediately starts up Squeak. Another would be to look at the non-Linux alternatives such as RISC OS and see how they are doing it.

I was looking at Tiny Core Linux a while back. They have apparently done some work on the Pi and it looks like a really minimal linux setup that leaves out all that nasty X stuff.
http://www.raspberrypi.org/phpBB3/viewtopic.php?f=56&t=20487

Jecel is right about the binary blob-booting stuff and it has been fairly easy (apparently) to adapt for other systems. AIUI there is enough code onboard to be able to start up and find the SD card, open up a FAT32 filing system, find a config file and do what it says.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
To succeed in politics, it is often necessary to rise above your principles.



Reply | Threaded
Open this post in threaded view
|

RE: Squeaksource, Squeak and Pharo..

J. Vuletich (mail lists)
In reply to this post by Ron Teitelbaum

Hi Folks,

Thanks for suggesting all this, Ron.
(inline)

Quoting Ron Teitelbaum <[hidden email]>:

I?m happy with the fragmentation.  I wasn?t at the start of this conversation but I think I?m starting to appreciate it.  I agree that the goals for each are a bit different and having separated achieving those goals is easier.  We are building some new stuff and it seems that selecting the right fork for the right job ?may? not have been possible without the split.  There are a number of new developments coming, (in the VM, Spoon, Seaside, Cuis, EToys, ?) and it?s possible that one big monolithic Squeak may have made it more difficult for all.  It seems that we are closer to having split up the components then we had thought. 

I agree.

I know we cannot make everyone happy.  It seems that the starting point which seems to me to be COG, is the common link that binds everything else.  Let me know if you think that is wrong.  If that is true then building Squeak, or Pharo, or Cuis from a single point seems like something that might help bring the communities back together.  Will Github or SmalltalkHub help to accomplish this?  If this were a goal would either do more than the other? 


I believe that the option that allows for a minimal image that can grow is something close to the package support in Cuis, that is extremely compact, doesn't require Monticello and relies on Github (or similar) for version control. I like the idea of building each distribution from a single point. That single point could be not far from current Cuis. I believe that Cuis, removing Morphic, programming tools, and any other non-kernel image or Cuis specific stuff, could become that single point.

If the people behind other Squeak distributions and Squeak derived projects want to go ahead with this, I volunteer for building that starting point by removing from Cuis any stuff that anybody doesn't want in there. Then, the Cuis distribution would be built by loading a set of packages on top of it. The same could be done for the projects that adhere to this idea. Some of those packages could be shared. For instance, for Cuis, I'd be more than happy to use the Compiler package that Eliot works on. But, most likely, I'd not use the same Morphic package as Squeak. This could reduce the effort due to code duplication.


I agree with the goal, we want to be able to load a package and have it work and it would be nice if the dependencies were limited/managed such so that it will load in any fork.  Not all packages will load in every fork so knowing which will work beforehand is preferable.  VW is different since nobody expects that with some work it will run on Oinq, I mean Cog (my name for the vm didn?t stick). 

It seems to me that it doesn?t really matter.  There seems to be some movement behind Metacello and SmalltalkHub.  Sometimes movement is preferable to good ideas.  If Metacello works for Squeak and will work with SmalltalkHub should we not include it in Squeak to give it a boost?  If Squeak goes with GitHub will Pharo follow?


Cuis doesn't include Monticello. I believe that a more compact and simpler implementation of package support, together with Github for version control, repositories, etc. is better. We are already using this with Cuis, and the results are good. It would be quite improbable that I could be persuaded of pre-loading Monticello into Cuis.


Nobody likes change but if we would all benefit from adopting some similar tools should we not consider doing that for the benefit of the entire Smalltalk community.


Agreed. Especially if it helps making the system (Cuis in my case) simpler, easy to understand, and manage.

Cheers,
Juan Vuletich


All the best,

Ron Teitelbaum

Head Of Engineering

3d Immersive Collaboration Consulting

[hidden email]

Follow Me On Twitter: @RonTeitelbaum

www.3dicc.com

3d ICC on G+

From: [hidden email] [mailto:[hidden email]] On Behalf Of Juan Vuletich (mail lists)
Sent: Friday, December 21, 2012 3:47 PM
To: dimitris chloupis; The general-purpose Squeak developers list
Subject: Re: [squeak-dev] Squeaksource, Squeak and Pharo..

Cuis is reasonably compatible with Squeak. It has a distinct set of objectives, so some decisions are taken differently. Please see http://www.jvuletich.org/Cuis/Index.html .

Maybe after some time with the various Smalltalk variants you get used to that fragmentation, and believe there are reasons for it. Or maybe you can help find the means to reduce that fragmentation.

Cheers,

Juan Vuletich

Quoting dimitris chloupis <[hidden email]>:

Thank you.  I am definetly going to take a look at Cuis. How compatible is Cuis to Squeak ? 

By the way I am already using Github for my first smalltalk (pharo) project which I call "Ephestos", together with ss3 as a backup plan.

I dont do much with git , just the usual stuff, git push commit pull rm add .

I have to say, the smalltalk field is abit confusing to me as a beginner, there is squeak , then there is pharo , then there is Cuis, etc etc

Its a pity there is so much fragmentation. I am sure for some people this kind of freedome is cool and fun , but I personally try find ways to make things work together.  

But I have loads of fun with pharo , and definitely my eye is on Squeak too. I love smalltalk I wish I had discovered it earlier. But better late than never I guess :D


From: Juan Vuletich (mail lists) <[hidden email]>
To: dimitris chloupis <[hidden email]>; The general-purpose Squeak developers list <[hidden email]>
Sent: Friday, 21 December 2012, 21:33
Subject: Re: [squeak-dev] Squeaksource, Squeak and Pharo..

Hi Dimitris,

With Cuis, we use Github as the main place for storing packages. We use git as it is intended to be used. This means that we let git handle file versioning. Besides, Cuis uses lf as the line terminator. This means that git can diff and merge Cuis packages. For example see

Cheers,

Juan Vuletich

Quoting dimitris chloupis <[hidden email]>:

SqueakMap is dead, SqueakSource dead, later SmalltalkHub will be dead.

I am coming from pharo by the way, I am new with smalltalk, I was a python developer. 

And I love squeak too.

I dont understand why every smalltalk problem should be solved by smalltalk. 

Github is a great community , already has gathered tons of ruby and python projects, js and many more.

I think its a great candidate for smalltalk, no offense intended but definitely better that what SmalltalkHub can offer.

I want to embrace at times all these smalltalk technologies, but is hard to abandon Gihub that I have used for my projects and support the smalltalk solutions instead.

I dont want to downgrade the hard work of good people, but its hard to compete with products that are designed full time by big teams and matured through thousands of use cases.

My vote goes to Github.


From: Göran Krampe <[hidden email]>
To: The general-purpose Squeak developers list <[hidden email]>
Sent: Thursday, 20 December 2012, 23:14
Subject: Re: [squeak-dev] Squeaksource, Squeak and Pharo..


Hi folks!

As the author of SqueakMap, long time Squeaker (and nowadays both Squeaker and Pharooner) and also involved in some other related projects (SmalltalkHub and more) my view might be of some interest.

First of all, Angel compares with the rest of the world - but we have both historic and technical differences at play. Some things worth noting:

- SqueakMap was indeed started out as a generic package *catalog*. It is not a SCM tool. It was format agnostic from the very beginning.

- Monticello and SqueakSource came from Avi. Superb tools but when Squeaksource came I quickly warned the community that it would deminish SqueakMap because it overlapped and "took over" several "catalog" aspects. I was right unfortunately, but at the same time SS was great and has served us very well in its own right.

- Noone has really taken SM and moved it forward. I also don't have that amount of free time anymore.

- SqueakMap is dead. Face it. :) It is not the future IMHO.

- Monticello and Metacello are the de facto standard these days for SCM and package loading. Metacello took the whole dependencies/tagging/releases issue and simply rode on MC to solve it. I have felt it looks overly complex but it's mostly some line noise - it is not that complicated.

- This also means that for a very, very long time package management and source code management will be forever "intertwined" in the Smalltalk world. Personally I say - fine! Again, let's just embrace it and go.

- The advantage is that Metacello "configurations" is "just code" and can offer functionality totally independent of the hosting platform for MC. So it doesn't matter if you load a Metacello configuration from a website, from SS or SS3 or Smalltalkhub - it all works the same!

- Monticello AND Metacello are meant to work in Squeak too. I haven't tried, but I presume Metacello works or is very close to working?

- Pharo is betting hard on Smalltalkhub. It is a really nice system AND there is also an image side client tool brewing for it! This means the equivalence of the SqueakMap Package Loader will be easy to build in Squeak for Smalltalkhub.


So my advice would be:

1. Keep SqueakMap on oxygen for a little while longer while we get ready to ditch it. Really.

2. Bet hard on Monticello (we already do, right?) and Metacello for Squeak. Make sure they work. Embrace Metacello even if it does look a bit complex to begin with. There are lots of articles, tutorials and tons of examples to just copy from. I have written two configurations these last two days and "the shit works". Good work Dale! :)

3. Get involved in Smalltalkhub and help out making it work fine for Squeak, note the name - *Smalltalk* hub. It's not Pharohub! Don't set up your own unless for some odd reason Pharo makes it uninhabitable for Squeak and turns it into "Pharohub".

Note that Smalltalkhub is "just" a new SS, but much more solid architecture, really snazzy modern web UI, offering githubish features and bloody hell, I mean, it can show diffs right there in the browser!

Smalltalkhub also has a really cool architecture so the coding fun is rated A++, Nicolas is busy as a bee making it better, better. I think it should be seen as a unifying playground and Metacello as the "glue" that makes it possible to have projects tailored for both Squeak and Pharo. It has many functions for EXACTLY that.

Either way, I am putting my efforts right there. IMHO the Squeak community should do so too. If the Squeak community can ride a bit on the momentum in Pharo - there is really no reason not to.

regards, Göran




Reply | Threaded
Open this post in threaded view
|

Re: Squeaksource, Squeak and Pharo..

Hannes Hirzel
In reply to this post by kilon
On 12/20/12, dimitris chloupis <[hidden email]> wrote:
> I hear the new filesystem might do just that. I dont know I am new to all
> this.
>
> But I dont believe integrating github with squeak or pharo is that hard
> anyway.
>
> I am already working with file outs , tedious but not that hard.

FileTree now nicely loads into Squeak 4.4, I just tested it yesterday.

http://lists.squeakfoundation.org/pipermail/squeak-dev/2012-December/167275.html

Besides Monticello a means for moving packages around between
different distributions.

--Hannes

 And if I

> cannot find an existing solution
> that makes me happy , I am more than willing to implement my own library for
> integrating github inside pharo.
>
> Hopefully it will work for squeak too.
>
>
> I was working with emacs for python and magit was great.
>
> Where there is a will there is a way,
>
>
>
> ________________________________
>  From: Frank Shearar <[hidden email]>
> To: dimitris chloupis <[hidden email]>; The general-purpose Squeak
> developers list <[hidden email]>
> Sent: Friday, 21 December 2012, 0:16
> Subject: Re: [squeak-dev] Squeaksource, Squeak and Pharo..
>
> Just a note: github does not replace SM. It does not replace rubygems.
> It's a fantastic tool for versioning source control.
>
> I have a toolbox. It has a hammer AND a screwdriver.
>
> frank
>
> On 20 December 2012 22:15, dimitris chloupis <[hidden email]> wrote:
>> SqueakMap is dead, SqueakSource dead, later SmalltalkHub will be dead.
>>
>> I am coming from pharo by the way, I am new with smalltalk, I was a python
>> developer.
>> And I love squeak too.
>>
>> I dont understand why every smalltalk problem should be solved by
>> smalltalk.
>>
>> Github is a great community , already has gathered tons of ruby and python
>> projects, js and many more.
>>
>> I think its a great candidate for smalltalk, no offense intended but
>> definitely better that what SmalltalkHub can offer.
>>
>> I want to embrace at times all these smalltalk technologies, but is hard
>> to
>> abandon Gihub that I have used for my projects and support the smalltalk
>> solutions instead.
>>
>> I dont want to downgrade the hard work of good people, but its hard to
>> compete with products that are designed full time by big teams and matured
>> through thousands of use cases.
>>
>> My vote goes to Github.
>>
>> ________________________________
>> From: Göran Krampe <[hidden email]>
>> To: The general-purpose Squeak developers list
>> <[hidden email]>
>> Sent: Thursday, 20 December 2012, 23:14
>> Subject: Re: [squeak-dev] Squeaksource, Squeak and Pharo..
>>
>> Hi folks!
>>
>> As the author of SqueakMap, long time Squeaker (and nowadays both Squeaker
>> and Pharooner) and also involved in some other related projects
>> (SmalltalkHub and more) my view might be of some interest.
>>
>> First of all, Angel compares with the rest of the world - but we have both
>> historic and technical differences at play. Some things worth noting:
>>
>> - SqueakMap was indeed started out as a generic package *catalog*. It is
>> not
>> a SCM tool. It was format agnostic from the very beginning.
>>
>> - Monticello and SqueakSource came from Avi. Superb tools but when
>> Squeaksource came I quickly warned the community that it would deminish
>> SqueakMap because it overlapped and "took over" several "catalog" aspects.
>> I
>> was right unfortunately, but at the same time SS was great and has served
>> us
>> very well in its own right.
>>
>> - Noone has really taken SM and moved it forward. I also don't have that
>> amount of free time anymore.
>>
>> - SqueakMap is dead. Face it. :) It is not the future IMHO.
>>
>> - Monticello and Metacello are the de facto standard these days for SCM
>> and
>> package loading. Metacello took the whole dependencies/tagging/releases
>> issue and simply rode on MC to solve it. I have felt it looks overly
>> complex
>> but it's mostly some line noise - it is not that complicated.
>>
>> - This also means that for a very, very long time package management and
>> source code management will be forever "intertwined" in the Smalltalk
>> world.
>> Personally I say - fine! Again, let's just embrace it and go.
>>
>> - The advantage is that Metacello "configurations" is "just code" and can
>> offer functionality totally independent of the hosting platform for MC. So
>> it doesn't matter if you load a Metacello configuration from a website,
>> from
>> SS or SS3 or Smalltalkhub - it all works the same!
>>
>> - Monticello AND Metacello are meant to work in Squeak too. I haven't
>> tried,
>> but I presume Metacello works or is very close to working?
>>
>> - Pharo is betting hard on Smalltalkhub. It is a really nice system AND
>> there is also an image side client tool brewing for it! This means the
>> equivalence of the SqueakMap Package Loader will be easy to build in
>> Squeak
>> for Smalltalkhub.
>>
>>
>> So my advice would be:
>>
>> 1. Keep SqueakMap on oxygen for a little while longer while we get ready
>> to
>> ditch it. Really.
>>
>> 2. Bet hard on Monticello (we already do, right?) and Metacello for
>> Squeak.
>> Make sure they work. Embrace Metacello even if it does look a bit complex
>> to
>> begin with. There are lots of articles, tutorials and tons of examples to
>> just copy from. I have written two configurations these last two days and
>> "the shit works". Good work Dale! :)
>>
>> 3. Get involved in Smalltalkhub and help out making it work fine for
>> Squeak,
>> note the name - *Smalltalk* hub. It's not Pharohub! Don't set up your own
>> unless for some odd reason Pharo makes it uninhabitable for Squeak and
>> turns
>> it into "Pharohub".
>>
>> Note that Smalltalkhub is "just" a new SS, but much more solid
>> architecture,
>> really snazzy modern web UI, offering githubish features and bloody hell,
>> I
>> mean, it can show diffs right there in the browser!
>>
>> Smalltalkhub also has a really cool architecture so the coding fun is
>> rated
>> A++, Nicolas is busy as a bee making it better, better. I think it should
>> be
>> seen as a unifying playground and Metacello as the "glue" that makes it
>> possible to have projects tailored for both Squeak and Pharo. It has many
>> functions for EXACTLY that.
>>
>> Either way, I am putting my efforts right there. IMHO the Squeak community
>> should do so too. If the Squeak community can ride a bit on the momentum
>> in
>> Pharo - there is really no reason not to.
>>
>> regards, Göran
>>
>>
>>
>>
>>
>>

1234