February 2012 - Pharo-users

funny idea Symbol vs. Selector
by stephane ducasse May 14, 2015

May 14, 2015

Hi guys I'm thinking aloud... I was wondering if we could not take advantage of a new class: Selector. MethodDict would only contain selectors and not symbols. I remember that I talked about that with hernan. Stef

8 27

Postmark email library
by Francois Stephany Aug. 31, 2013

Aug. 31, 2013

Hi guys, I've made a simple wrapper around the Postmark API. It lets you send emails without dealing with a SMTP server. You can read about it here: http://developer.postmarkapp.com/developer-libs.html http://developer.postmarkapp.com/developer-build.html and there: http://articles.tulipemoutarde.be/send-email-from-pharo-with-postmark It's pretty simple and naive implementation but it gets the job done. I'll add email attachements when I will need it. Francois

4 20

Package browser?
by Rob Vens June 28, 2013

June 28, 2013

I am attempting to do the Pharo by Example book, but a package browser (which is used in the examples) is not in the 1.1.1 or 1.2 image. Should I still use categories? If I create a package in Monticello browser I am not able to add classes or anything (not as far as I could see). Just starting out using Pharo, so apologies if these questions are already answered elsewhere.

12 22

Zinc crashes an image.
by Paul DeBruicker Sept. 25, 2012

Sept. 25, 2012

Hi - I'm pretty sure I'm having the same problem Phillipe had/described in this message: http://forum.world.st/Zinc-crashing-image-at-start-up-td3785797.html At least the PharoDebug.log is the same. It happens on both the most recent Cog and interpreter VM. Is there a way to recover from this? I could follow Sean's instructions from this thread if necessary: http://forum.world.st/Fwd-Oops-I-put-a-halt-in-a-startup-method-td3800729.h… Or is there a way to extract changes from a changes file for one image into another image? I'd rather fix the broken image but if its not possible I'd then just try to load those changes I don't have. Thanks for any guidance you can provide. Paul

4 3

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

Re: [Pharo-users] [Pharo-project] fun with NBOpenGL
by StÃ©phane Ducasse Feb. 29, 2012

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

ProfStef - syntax highlighting
by Markus Schlager Feb. 28, 2012

Feb. 28, 2012

Hi all, Is there any chance to get syntax highlighting back for ProfStef tutorials? Even ProfStef is black&white only in Pharo1.3. ProfStefBrowser has vanished already in 1.2. Could the helpbrowser or at least the SystemWindow used by ProfStef get an option for syntax highlighting? All this would be highly appreciated since ProfStef-tutorials are a nice way for writing course-material in order to teach Smalltalk at school. LedMorph and LedTimerMorph are great example-classes to start with teaching. I'm missing WatchMorph, though. Markus

5 9

Feb. 28, 2012

Hello,,,I search info about this subject., ,I'm interesting by picaxe also,,,, A beginner in object programmation,,, I wait the 25th may,,, Thanks in advance.

2 2