- Pharo-users - lists.pharo.org

Re: [Pharo-users] [Seaside] seaside on pharo 1.4 w/ zinc (ConfigurationOfSeaside30 mcz attached)

by Lukas Renggli

> There has been continuous problems with OmniBrowser across multiple platforms (another example of a project where the maintainer doesn't use metacello) and that has caused problems in Seaside, because the seaside maintainers insist that OB be included in the core ... so I disagree with their decision, but it is their decision ... Uhh? No! Nothing in Seaside depends on OB. We like OB and we use it in our development images. This is all. Lukas -- Lukas Renggli www.lukas-renggli.ch

March 5, 2012

Re: [Pharo-users] [Seaside] seaside on pharo 1.4 w/ zinc (ConfigurationOfSeaside30 mcz attached)

by Dale Henrichs

Pat, I'm not sure what you're trying to do with the changes ... but it looks like you've excluded the load of Kom? the changes with tthe OmniBrowser and Swazoo groups probably don't affect what is loaded with your load expression, but removing 'Seaside-Adaptors-Comanche' and the tests definitely does so presumably that was the important piece to get working for Pharo 1.4 ... I have been trying to follow the wishes of Lukas, Philippe and Julian when it comes to defining the default behavior of the metacello configuration for seaside, but since it appears that none of the maintainers of seaside actually uses metacello there is tension between what they have told be to do and what is practical ... The point of metacello goes something like this: developer gets project working on Pharo1.4 and records what works in metacello configuration that way when a user of the project wants to load the project in Pharo1.4, they don't have to do anything but load the configuration ... When a developer answers a question about why something doesn't work on Pharo1.4 with something along the lines of: - do xyz - I don't use w anymore, try q The there is a clear indication that the relevant information has not been recorded in the configuration ... I periodically visit the seaside project (usually around the time that I'm preparing to do Seaside work in GemStone) and pull in information that I can glean from the mcz files lying around in the various repositories and reconstruct what I think the seaside developers have in mind ... I then load the configuration of a variety of platforms (pharo1.0, squeak, etc.) and if the tests pass, I say my work is done ... There has been continuous problems with OmniBrowser across multiple platforms (another example of a project where the maintainer doesn't use metacello) and that has caused problems in Seaside, because the seaside maintainers insist that OB be included in the core ... so I disagree with their decision, but it is their decision ... There's only so much I can do... Dale ----- Original Message ----- | From: "Pat Maddox" <patmaddox(a)me.com> | To: "Seaside - general discussion general discussion" <seaside(a)lists.squeakfoundation.org>, "Pharo mailing list list" | <pharo-users(a)lists.gforge.inria.fr> | Sent: Thursday, March 1, 2012 6:22:29 PM | Subject: [Seaside] seaside on pharo 1.4 w/ zinc (ConfigurationOfSeaside30 mcz attached) | | Hi, I don't know how many people have successfully run seaside on | pharo 1.4 or even tried to, and I've not seen it documented | anywhere. I have it running and while many of the unit tests don't | pass :( I can start up a zinc server and click through the example | apps and some of my own apps fine. I've attached the .mcz file which | excludes Comanche, Swazoo, and OmniBrowser from the default install | group (OB is only used for the server manager I think, which is not | very important, and I'm using nautilus on 1.4). | | I understand that this patch might break earlier stuff so with any | luck Dale will be able to give me some tips on how to make it more | compatible. | | Anyway, load up the mcz and then | ConfigurationOfSeaside30 project latestVersion load: #('default' | 'Zinc-Seaside') | | and to run a server | ZnZincServerAdaptor startOn: 8282 | | and you should be set. | | note: I *just* got this "working" and it seems to work fine with my | apps so far, but no promises that everything will go smoothly. | | Pat | | | | _______________________________________________ | seaside mailing list | seaside(a)lists.squeakfoundation.org | http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |

March 5, 2012

Re: [Pharo-users] seaside on pharo 1.4 w/ zinc (ConfigurationOfSeaside30 mcz attached)

by Sven Van Caekenberghe

Pat, On 02 Mar 2012, at 03:22, Pat Maddox wrote: > Hi, I don't know how many people have successfully run seaside on pharo 1.4 or even tried to, and I've not seen it documented anywhere. I have it running and while many of the unit tests don't pass :( I can start up a zinc server and click through the example apps and some of my own apps fine. I've attached the .mcz file which excludes Comanche, Swazoo, and OmniBrowser from the default install group (OB is only used for the server manager I think, which is not very important, and I'm using nautilus on 1.4). > > I understand that this patch might break earlier stuff so with any luck Dale will be able to give me some tips on how to make it more compatible. > > Anyway, load up the mcz and then > ConfigurationOfSeaside30 project latestVersion load: #('default' 'Zinc-Seaside') > > and to run a server > ZnZincServerAdaptor startOn: 8282 > > and you should be set. > > note: I *just* got this "working" and it seems to work fine with my apps so far, but no promises that everything will go smoothly. > > Pat > > > <ConfigurationOfSeaside30-PatMaddox.354.mcz> I am assuming you did something with the ConfigurationOfSeaside30, maybe others can comment on that part. But the combination Seaside on Pharo 1.3 and 1.4 using Zinc has been working for some time (for 1.4) and for more than a year (for 1.3). Including passing tests. See for example http://jenkins.lukas-renggli.ch/job/Seaside%203.0/ http://jenkins.lukas-renggli.ch/job/Seaside%203.0%20(Metacello)/ http://jenkins.lukas-renggli.ch/job/Seaside%203.1/ and of course https://ci.lille.inria.fr/pharo/job/Seaside%20Pharo%201.3/ https://ci.lille.inria.fr/pharo/job/Seaside%20Pharo%201.4/ All these build on Pharo and include variants with ZnZincServerAdaptor. Building these yourself can sometimes be a bit of an adventure, but the above will certainly help. Regards, Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

March 2, 2012

seaside on pharo 1.4 w/ zinc (ConfigurationOfSeaside30 mcz attached)

by Pat Maddox

Hi, I don't know how many people have successfully run seaside on pharo 1.4 or even tried to, and I've not seen it documented anywhere. I have it running and while many of the unit tests don't pass :( I can start up a zinc server and click through the example apps and some of my own apps fine. I've attached the .mcz file which excludes Comanche, Swazoo, and OmniBrowser from the default install group (OB is only used for the server manager I think, which is not very important, and I'm using nautilus on 1.4). I understand that this patch might break earlier stuff so with any luck Dale will be able to give me some tips on how to make it more compatible. Anyway, load up the mcz and then ConfigurationOfSeaside30 project latestVersion load: #('default' 'Zinc-Seaside') and to run a server ZnZincServerAdaptor startOn: 8282 and you should be set. note: I *just* got this "working" and it seems to work fine with my apps so far, but no promises that everything will go smoothly. Pat

March 2, 2012

[ANN] Ideas for this year GSoC wanted

by Janko MivÅ¡ek

Dear Smalltalkers, Let we apply this year again for the Google Summer of Code, which as you know is a Google's stipendium program for students to encourage them working on open-source projects [1]. Ok, our first step as community is to collect ideas for possible projects and to apply to the GSoC as an organization. Deadline is next Friday, so please hurry on with ideas. Just put them as reply to this email or to admins directly and we will put them on our website [2]. Your project idea should be written as answers to these questions: Name Level (Beginner, Intermediate, Advanced) Possible mentor Possible second mentor Description Technical Details Benefits to the Student Benefits to the Community See how such ideas look like in past: http://gsoc2010.esug.org/ideas. Waiting for your ideas Carla and Janko, your GSoC Admin team [1] http://www.google-melange.com/gsoc/homepage/google/gsoc2012 [2] http://gsoc2012.esug.org -- Carla F. Griggio, Janko MivÅ¡ek Smalltalk GSoC Admin Team http://gsoc2012.esug.org

March 1, 2012

Nearly limitless Image: revisited

by James Foster

Hi Ted, You have done a good job of describing what GemStone/S 64 Bit provides. Your 'image' size is essentially limited to disk that can be connected to one machine. Collection classes have been enhanced with B-Tree indexes that are automatically updated when objects are modified. Multiple VMs can connect to the same image and each is provided with a consistent (isolated) view. Views are updated at transaction boundaries. Updates are done in a transaction with each transaction recorded to a separate log for disaster recovery. There is no need for an external database, since you have a persistent, transactional image that can be shared across multiple machines. Existing users have images of hundreds of GB in size with hundreds of VMs. Check it out at http://seaside.gemstone.com/. James > I've brought this up before, but it seems nobody is interested in this > topic.. why? > > it's about image size. > > ... > > Anyway, IMHO this very limited storage violates the Smalltalk-all-in-one > image ideal, > because with this limited storage one cannot avoid the use of external > data stores > like databases (of course, exception: there always will be import an > export of objects/data) > > External data storage is complex, unreliable and should be something of > the past. > I'd suggest: don't waste time with this. rather improve the Smalltalk > internal data handling. > > I wish to have a very large image so e.q. I can have an entire > company's administration > (client and accounting data etc.) alive in it. > I want to use Collections and descendants, not external databases. > So, everything within the image. > > The beautiful (although opinions may vary) principle > of a Smalltalk environment is Image Persistence, isn't it? > > IMHO this requires: > - virtually unlimited image memory size. > -no external databases like e.g. Mongo or DB2 whatever. > -no persistent external storage at all. > > -You should see the (currently still) faster database performance as a > challenge > to improve the Collection and other related data handling classes > > -You would have to completely restructure the architecture. > or just extend the address width: 64 bits? > > what about an image of virtually unlimited size > gigabytes so > > (for now, if it goes beyond the physical memory size (say 32 GB?) > one could use a VM that works with virtual storage based VM > Virtual storage was first in use successfully with IBM mainframes > in the 1970s (and still is) ) > > on the other hand, I estimate holographic? physical memory > going in Terabytes is about to be available in 5-10 years from now. > blindingly fast, compared with today's standards. > > So, one has about 5 years to come up with such a system :o) > if one does, Smalltalk is ahead of everything then.. > > Don't laugh. One didn't even dream of 4 gigabytes of memory > during the Commodore 64 era. 1982-1994. > > In short: what would have to be changed to enable this? > > Some thoughts and speculations? > Anyone for tennis? > > Thanks > Ted

Feb. 29, 2012

Re: [Pharo-users] [Pharo-project] fun with NBOpenGL

by StÃ©phane Ducasse

:) you seems to have fun after the lantronix XP. Stef On Feb 29, 2012, at 7:33 PM, Jean Baptiste Arnaud wrote: > <Screen shot 2012-02-29 at 7.31.10 PM.png>

Feb. 29, 2012

Re: [Pharo-users] Nearly limitless Image: revisited.

by Janko MivÅ¡ek

Good compromise is a step by step approach, something like: 1.step: image based persistence up to 1GB with hourly snapshot 2.step: parts migrated to Fuel and file based persistence 3.step: Gemstone, with "images" running in parallel (well, any DB with images in parallel, Gemstone is certainly the easiest to scale from image based persistence) 1GB limit is here just for simplicity, you can probably go further with 64bit images. Advantages: - very very simple start - freedom of pure OO modeling, - good enough for probably 90% of all projects - fastest way from your dreams to reality - speed of development - no impedance mismatch, no ORM nightmare - you won't believe how much data you can put in 1GB image - speed because of always in-memory data processing - you can always scale further if you make your design from the start with above steps in mind - reliability good enough, on reliable hardware probably even better than more complex solutions. Main reason: simplicity. Disadvantages: - you easy forgot to include later scalability requirements in upfront design - such scaling is easy only to OO database while migrating to NoSQL (not to mention SQL) database later is very hard if not possible - up to about 1GB only, because of GC problems as Igor described - active users limit (number of requests/s) - single point of failure - corrupted image will loose all data (but good backup approach helps) - undetected image corruption fear (after many otherwise successful snapshots, causing non-startable image) - lengthy snapshots of bigger images (can be improved with two step snapshots, first in memory, then on disk) - loss of data between snapshots in case of power or machine failure (but this is very rare those days) Bet regards Janko S, Igor Stasenko piÅ¡e: > Incidentally, we had a little chat with Marcus yesterday about that. > > No, i don't think it is feasible to use single image to store everything. > It is convenient, cheap and of course it is way better than dealing > with communicating with external DB/servers whatever. > > But there's one thing you should know already: the days of vertical > growth is over. > > Running a service (under VM or not) on a single machine is asking for troubles: > - limits on load > - susceptible to power outage and other reliability problems > etc > > Also, think that the amount of data you need to process correlates > with CPU horsepower available. > Which means that yes, you can run a huge image with 64Gb data in it.. > but that means that responsiveness > of your service will quite often fall beyond any usability limits. > > If we look in terms of VM and pick only one thing - garbage collection, > you will see that there is certain limits beyond which a performance > will drop too much, so you naturally > will start thinking about ways to split data to separate chunks and > run them on different machines/VMs. > > It is because GC's mark algorithm is O(n) bound, when n is total > number of references between objects, > and GC's scavenge algorithm is at best O(n) bound where n is total > number of objects in object memory, > and at worst is where n is total memory used by objects. > No matter how you turn it, i just wanted to indicate that time to run > GC is in linear dependency from the amount of data. > > Yes, we might invest a lot of effort in making GC more clever, more > complex and more robust.. but no matter what you do, > you cannot change the above facts. It means, that any improvements > will be about diminishing returns, but won't change the picture > radically. > > That means that sooner or later you will have to deal with it: a > problem of splitting data on multiple independent chunks, > and making your service to run on multiple machines , in order to use > more CPU power, more memory and be more reliable etc. > At this point, your main dilemma is to invent a fast and robust > interfaces to communicate between images or between image(s)/ database > etc. > > We should concentrate on things which dealing with inter-image > communication and image-database communication, > because it is the only way to ensure that we will answer upcoming > future problems. Relying on using a single huge image is way to > nowhere. > -- Janko MivÅ¡ek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si

Feb. 29, 2012

Re: [Pharo-users] [Pharo-project] Nearly limitless Image: revisited.

by Igor Stasenko

Incidentally, we had a little chat with Marcus yesterday about that. No, i don't think it is feasible to use single image to store everything. It is convenient, cheap and of course it is way better than dealing with communicating with external DB/servers whatever. But there's one thing you should know already: the days of vertical growth is over. Running a service (under VM or not) on a single machine is asking for troubles: - limits on load - susceptible to power outage and other reliability problems etc Also, think that the amount of data you need to process correlates with CPU horsepower available. Which means that yes, you can run a huge image with 64Gb data in it.. but that means that responsiveness of your service will quite often fall beyond any usability limits. If we look in terms of VM and pick only one thing - garbage collection, you will see that there is certain limits beyond which a performance will drop too much, so you naturally will start thinking about ways to split data to separate chunks and run them on different machines/VMs. It is because GC's mark algorithm is O(n) bound, when n is total number of references between objects, and GC's scavenge algorithm is at best O(n) bound where n is total number of objects in object memory, and at worst is where n is total memory used by objects. No matter how you turn it, i just wanted to indicate that time to run GC is in linear dependency from the amount of data. Yes, we might invest a lot of effort in making GC more clever, more complex and more robust.. but no matter what you do, you cannot change the above facts. It means, that any improvements will be about diminishing returns, but won't change the picture radically. That means that sooner or later you will have to deal with it: a problem of splitting data on multiple independent chunks, and making your service to run on multiple machines , in order to use more CPU power, more memory and be more reliable etc. At this point, your main dilemma is to invent a fast and robust interfaces to communicate between images or between image(s)/ database etc. We should concentrate on things which dealing with inter-image communication and image-database communication, because it is the only way to ensure that we will answer upcoming future problems. Relying on using a single huge image is way to nowhere. -- Best regards, Igor Stasenko.

Feb. 29, 2012

Re: [Pharo-users] [Pharo-project] Nearly limitless Image: revisited.

by Davorin Rusevljan

On Wed, Feb 29, 2012 at 1:06 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > Someone needs to start fixing and improving. Why not, for example, you? Funny, I was also inclined in last few days to post how Pharo would need to stabilize VM at least a bit, and the reason I did not was that I have expected answer along these lines. Now I understand and I am grateful for all effort that goes on to improve Pharo, and also that helping hand is much more needed than people instructing what should be done by someone. But I do not think it is also good that many observations about pharo get quickly dismissed that way. For instance what would someone that tries Pharo, gets VM crash, complains, gets the "go-hack-yourself-vm answer" think about this whole smalltalk business? "Smalltalk - I am going to use that, yeah right." So yes, complaints can be complete noise, but sometimes they can also be a small contribution. Orders of magnitude smaller than committing code for sure, but still valuable. Davorin Rusevljan http://www.cloud208.com/

Feb. 29, 2012