- Pharo-users - lists.pharo.org

Refactoring-Spelling + SpellingServices
by Paul DeBruicker March 6, 2012

March 6, 2012

Hi - I integrated SpellingServices (http://www.hpi.uni-potsdam.de/hirschfeld/squeaksource/SpellingServices) and Refactoring-Spelling (the spell checker for the refactoring browser). The changes are in the attached monticello file. if SpellingServices is installed in your image then the spell checker in the refactoring browser will be: (in order of preference) 1. The RBMacSpellChecker 2. The RBSpellingService 3. The RBInternalSpellChecker I only tested it on 64bit Linux. It runs much slower than the RBInternalSpellChecker. But it catches more errors. Or just has a dumber vocabulary. I can't tell yet. All tests pass. Paul

1 0

Announcement: Spelling services
by Tim Felgentreff March 6, 2012

March 6, 2012

Hi Once upon a time, John M. McIntosh built a spellchecker plugin for the MacVM and there was a fileout that added a spelling service class to use it from Squeak. We have added code to provide the same API (for now) to windows and linux users that have ispell (or a compatible program, like aspell) installed on their systems using system callouts. A metacello configuration is available from the MetacelloRepository on Squeaksource, ConfigurationOfSpellingServices. The development repository is at http://www.hpi.uni-potsdam.de/hirschfeld/squeaksource/SpellingServices.html, the repo has global read+write, so if anybody finds this useful and has changes, feel free to commit to that repository. -Tim

2 1

Re: [Pharo-users] [Seaside] seaside on pharo 1.4 w/ zinc (ConfigurationOfSeaside30 mcz attached)
by Dale Henrichs March 6, 2012

March 6, 2012

Philippe, Wouldn't it be more correct to say "we don't use Metacello"? Dale ----- Original Message ----- | From: "Philippe Marschall" <philippe.marschall(a)gmail.com> | To: "Seaside - general discussion" <seaside(a)lists.squeakfoundation.org> | Cc: "Pharo mailing list list" <pharo-users(a)lists.gforge.inria.fr> | Sent: Monday, March 5, 2012 11:43:32 PM | Subject: Re: [Seaside] seaside on pharo 1.4 w/ zinc (ConfigurationOfSeaside30 mcz attached) | | 2012/3/5 Lukas Renggli <renggli(a)gmail.com>: | >> 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. | | Yes, but we don't use Metacello to build them. | | I'm cool with switching the default adaptor to Zinc if that makes | life easier. | | Cheers | Philippe | _______________________________________________ | seaside mailing list | seaside(a)lists.squeakfoundation.org | http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |

2 1

Re: [Pharo-users] [Seaside] seaside on pharo 1.4 w/ zinc (ConfigurationOfSeaside30 mcz attached)
by Sven Van Caekenberghe March 6, 2012

March 6, 2012

On 06 Mar 2012, at 08:43, Philippe Marschall wrote: > 2012/3/5 Lukas Renggli <renggli(a)gmail.com>: >>> 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. > > Yes, but we don't use Metacello to build them. > > I'm cool with switching the default adaptor to Zinc if that makes life easier. This is a configuration issue. >From my point of view, as author of Zn, I can only say that I am very happy with the collaboration and openness of the Seaside developers to adopt Zn. They tried and used Zn as soon as it became available, it was included in builds and distributions, and there are enough abstraction in place to let people use whatever server they want. What should be the default is not for me to say, although it would make some sense on certain Pharo builds. Sven

1 0

seaside on pharo 1.4 w/ zinc (ConfigurationOfSeaside30 mcz attached)
by Pat Maddox March 5, 2012

March 5, 2012

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

4 5

[ANN] Ideas for this year GSoC wanted
by Janko MivÅ¡ek March 1, 2012

March 1, 2012

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

1 0

Nearly limitless Image: revisited
by James Foster Feb. 29, 2012

Feb. 29, 2012

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

1 0

Feb. 29, 2012

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

1 0

Re: [Pharo-users] [Pharo-project] Nearly limitless Image: revisited.
by Marcus Denker Feb. 29, 2012

Feb. 29, 2012

On Feb 29, 2012, at 12:59 PM, Janko MivÅ¡ek wrote: > Hi Ted, > > I also support the image as a sole persistence idea and I'm actually > using it for years on VisualWorks. > > For Pharo there seems everyone is avoiding this idea, mostly because of > image corruption fear. Well, we need to improve the robustness of Pharo > image and VM then this fear will vanish. It is obviously doable, if VW > is reliable enough, why not once Pharo? > Someone needs to start fixing and improving. Why not, for example, you? Here is a link: http://code.google.com/p/pharo/issues/list It's much better than talking. Marcus -- Marcus Denker -- http://marcusdenker.de

4 3

Nearly limitless Image: revisited.
by ted f.a. van gaalen Feb. 29, 2012

Feb. 29, 2012

"I first used image persistence but the image grow too large.." thanks for reminding, Norbert. Hi all, perhaps you'll find me an idiot, I don't care. (i know that I am: (class SelfReflection :o) ) Nevertheless, some brainstorming here. I've brought this up before, but it seems nobody is interested in this topic.. why? it's about image size. Currently, Pharo 1.3-13315 at my 4 Gigabyte Debian amd64 Linux machine reports memory 75,392,160 bytes old 61,370,144 bytes (81.4%) young 2,169,692 bytes (2.9000000000000004%) used 63,539,836 bytes (84.30000000000001%) free 11,852,324 bytes (15.700000000000001%) (nothing peculiar added, just the Seaside package and a few classes of my own. ) So, if i understand this well I have only 11,8 megabytes to play with? To begin with: why is only 75 megabyte available in Pharo (or Squeak as well) when there is 4 gigabyte physical memory available on my machine?? 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 -- Ted F.A. van Gaalen Danketsweiler 608 D-88263 Horgenzell Germany T: +49 750 491 48 38 M: +49 151 587 862 47

5 4