January 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Enthousiasm is the main currency among developers

by Guido Stepken

I see quite a difference between "doing things right" and "doing the right things" ! :-) Am 27.01.2012 22:50 schrieb "Eliot Miranda" <eliot.miranda(a)gmail.com>: > > > On Fri, Jan 27, 2012 at 11:51 AM, Guido Stepken <gstepken(a)googlemail.com>wrote: > >> Hi Elliot! >> >> When I rethink, why new programming languages came up from zero to a >> significant market share, like PERL, PHP, Python, Ruby, JAVA, C# (.net) >> Visual Basic, Visual C++ and others died out, like Delphi, >> TurboBasic/Pascal/C I could name different reasons: >> >> - Free license vs. expensive >> - Wrong payment model (per developer, per runtime, both) >> - Good, free support on websites vs. "Bronze/silver/gold" >> paystupid-support >> - Attractiveness of one "killer app" that made programmers change to >> another language >> - Portability of code onto other platforms >> - Mightyness of libraries >> - Missing standards, protocols, support of hardware >> - Good vs. bad marketing, deciders not convinced that product will >> survive/missing timeline, visions, lack of money in background >> - Subcritical mass of programmers using product, lack of professionals >> >> That was in former times. >> >> Today, new criterias play a far more relevant role, hat haven't really >> existed just 3 years ago: >> >> - Has it (the OS,the programming language and GUI framework) an >> appstore/plugin concept to let free, creative brains being able to >> participate, earn money with? >> - Barrier - free payment model included (mobile payment, card, bank >> account)? >> - Free use with sponsoring by ads possible (programmers payed from >> multiple resources, not user alone) >> - Cryptographic prevention of missuse included? >> - Free and matured SDK available? >> - Connections to social software like facebook/twitter/Google+/Groupon >> included (API access, programming language and all protocols supported) >> - GUI designed for desktop as well usable for touch and self adapting to >> different screen/touch sizes? >> - Touch gestures possible and lib avail? >> - Microsofts Kinect hardware/video recognition of faces, hand/face mimic >> gestures possible and supported in libs? >> - Voice recognition supported? >> - Mobile ready? (touch, GPS, compass, barometer, gyro, hardware OpenGL) >> - Rockstable? >> - Fast, running in low power devices? Joule per clock cycle ratio??? >> - Critical mass of users already reached, increasing? >> - Critical number of apps there to raise interest? >> ... >> >> So, the Pharo developers might now decide, what to invest their >> brainpower into! :-) >> >> Just my 2ct. >> > > OK, that looks like a great list. But don't you agree that criticism (in > the sense of something that leads to quality software engineering) > underlies several of these, such as Rockstable, Fast, running on low-power > devices, etc? To me, being critical doesn't mean being uncreative or > conservative; it means thinking about what you're doing, and doing a good > job. > >> Guido Stepken >> Am 27.01.2012 19:46 schrieb "Eliot Miranda" <eliot.miranda(a)gmail.com>: >> >> >>> >>> On Fri, Jan 27, 2012 at 5:33 AM, Marcus Denker <marcus.denker(a)inria.fr>wrote: >>> >>>> >>>> On Jan 27, 2012, at 6:13 AM, dimitris chloupis wrote: >>>> >>>> > This article is really encapsulates the attitude and what is wrong >>>> with programming in general. The attitude of superiority and intelligence >>>> that seems to plague coders and being the biggest obstacle to progress. >>>> >>>> Yes! The "Everyone is dumb but me" phenomenon... >>>> >>>> What those "intelligent" people don't get is that complexity is >>>> inherently exponential. So even if you are >>>> 10 times more intelligent than me (very well possible), it is >>>> *completely* irrelevant considering that complexity >>>> grows non-linearly. >>>> >>>> If you combine this with the notion of Evolution: that it is impossible >>>> to creat "the perfect" out of nothing, yet >>>> entropy grows when you incrementally improve things... than this has >>>> some very serious consequences. >>>> >>>> > For me the main problem with is the whole aura of "elitism" , what >>>> better example than Lisp, where beginners are attacked and be excluded. >>>> >>>> We had the same effect in Squeak at the end. No progress, every >>>> improvement was actively fighted against, if needed with the nice argument >>>> that >>>> one can do it even better, and only "the best" is worth for Squeak. >>>> >>>> Another thing that "intelligent" people don't get is that critizising >>>> is trivial: You can *always* do better, there is no perfection. It's an >>>> endless process. >>>> This implies that one has to accept and embrace imperfection if one >>>> wants to have a future. Else you end up never finishing anything, the death >>>> of any >>>> incremental progress. >>>> >>> >>> But criticism is essential. How does one identify a mistake if not by >>> criticising? There's a huge difference between constructive criticism >>> (analysis, testing, comparison, evaluation, measurement) and negativity >>> (denial, fear, slander). How can one engineer without measurement, without >>> thought? Being agile doesn't imply being random. Evolution measures, and >>> most harshly; the weaker don't survive. >>> >>> >>>> Pharo was started with the explicit goal to do as many mistakes as >>>> possible, as fast as possible. >>>> >>>> Marcus >>>> >>>> -- >>>> Marcus Denker -- http://marcusdenker.de >>>> >>>> >>>> >>> >>> >>> -- >>> best, >>> Eliot >>> >>> > > > -- > best, > Eliot > >

Jan. 27, 2012

Re: [Pharo-project] Enthousiasm is the main currency among developers

by Eliot Miranda

On Fri, Jan 27, 2012 at 11:51 AM, Guido Stepken <gstepken(a)googlemail.com>wrote: > Hi Elliot! > > When I rethink, why new programming languages came up from zero to a > significant market share, like PERL, PHP, Python, Ruby, JAVA, C# (.net) > Visual Basic, Visual C++ and others died out, like Delphi, > TurboBasic/Pascal/C I could name different reasons: > > - Free license vs. expensive > - Wrong payment model (per developer, per runtime, both) > - Good, free support on websites vs. "Bronze/silver/gold" paystupid-support > - Attractiveness of one "killer app" that made programmers change to > another language > - Portability of code onto other platforms > - Mightyness of libraries > - Missing standards, protocols, support of hardware > - Good vs. bad marketing, deciders not convinced that product will > survive/missing timeline, visions, lack of money in background > - Subcritical mass of programmers using product, lack of professionals > > That was in former times. > > Today, new criterias play a far more relevant role, hat haven't really > existed just 3 years ago: > > - Has it (the OS,the programming language and GUI framework) an > appstore/plugin concept to let free, creative brains being able to > participate, earn money with? > - Barrier - free payment model included (mobile payment, card, bank > account)? > - Free use with sponsoring by ads possible (programmers payed from > multiple resources, not user alone) > - Cryptographic prevention of missuse included? > - Free and matured SDK available? > - Connections to social software like facebook/twitter/Google+/Groupon > included (API access, programming language and all protocols supported) > - GUI designed for desktop as well usable for touch and self adapting to > different screen/touch sizes? > - Touch gestures possible and lib avail? > - Microsofts Kinect hardware/video recognition of faces, hand/face mimic > gestures possible and supported in libs? > - Voice recognition supported? > - Mobile ready? (touch, GPS, compass, barometer, gyro, hardware OpenGL) > - Rockstable? > - Fast, running in low power devices? Joule per clock cycle ratio??? > - Critical mass of users already reached, increasing? > - Critical number of apps there to raise interest? > ... > > So, the Pharo developers might now decide, what to invest their brainpower > into! :-) > > Just my 2ct. > OK, that looks like a great list. But don't you agree that criticism (in the sense of something that leads to quality software engineering) underlies several of these, such as Rockstable, Fast, running on low-power devices, etc? To me, being critical doesn't mean being uncreative or conservative; it means thinking about what you're doing, and doing a good job. > Guido Stepken > Am 27.01.2012 19:46 schrieb "Eliot Miranda" <eliot.miranda(a)gmail.com>: > > >> >> On Fri, Jan 27, 2012 at 5:33 AM, Marcus Denker <marcus.denker(a)inria.fr>wrote: >> >>> >>> On Jan 27, 2012, at 6:13 AM, dimitris chloupis wrote: >>> >>> > This article is really encapsulates the attitude and what is wrong >>> with programming in general. The attitude of superiority and intelligence >>> that seems to plague coders and being the biggest obstacle to progress. >>> >>> Yes! The "Everyone is dumb but me" phenomenon... >>> >>> What those "intelligent" people don't get is that complexity is >>> inherently exponential. So even if you are >>> 10 times more intelligent than me (very well possible), it is >>> *completely* irrelevant considering that complexity >>> grows non-linearly. >>> >>> If you combine this with the notion of Evolution: that it is impossible >>> to creat "the perfect" out of nothing, yet >>> entropy grows when you incrementally improve things... than this has >>> some very serious consequences. >>> >>> > For me the main problem with is the whole aura of "elitism" , what >>> better example than Lisp, where beginners are attacked and be excluded. >>> >>> We had the same effect in Squeak at the end. No progress, every >>> improvement was actively fighted against, if needed with the nice argument >>> that >>> one can do it even better, and only "the best" is worth for Squeak. >>> >>> Another thing that "intelligent" people don't get is that critizising is >>> trivial: You can *always* do better, there is no perfection. It's an >>> endless process. >>> This implies that one has to accept and embrace imperfection if one >>> wants to have a future. Else you end up never finishing anything, the death >>> of any >>> incremental progress. >>> >> >> But criticism is essential. How does one identify a mistake if not by >> criticising? There's a huge difference between constructive criticism >> (analysis, testing, comparison, evaluation, measurement) and negativity >> (denial, fear, slander). How can one engineer without measurement, without >> thought? Being agile doesn't imply being random. Evolution measures, and >> most harshly; the weaker don't survive. >> >> >>> Pharo was started with the explicit goal to do as many mistakes as >>> possible, as fast as possible. >>> >>> Marcus >>> >>> -- >>> Marcus Denker -- http://marcusdenker.de >>> >>> >>> >> >> >> -- >> best, >> Eliot >> >> -- best, Eliot

Jan. 27, 2012

Re: [Pharo-project] Enthousiasm is the main currency among developers

by Guido Stepken

Hi Elliot! When I rethink, why new programming languages came up from zero to a significant market share, like PERL, PHP, Python, Ruby, JAVA, C# (.net) Visual Basic, Visual C++ and others died out, like Delphi, TurboBasic/Pascal/C I could name different reasons: - Free license vs. expensive - Wrong payment model (per developer, per runtime, both) - Good, free support on websites vs. "Bronze/silver/gold" paystupid-support - Attractiveness of one "killer app" that made programmers change to another language - Portability of code onto other platforms - Mightyness of libraries - Missing standards, protocols, support of hardware - Good vs. bad marketing, deciders not convinced that product will survive/missing timeline, visions, lack of money in background - Subcritical mass of programmers using product, lack of professionals That was in former times. Today, new criterias play a far more relevant role, hat haven't really existed just 3 years ago: - Has it (the OS,the programming language and GUI framework) an appstore/plugin concept to let free, creative brains being able to participate, earn money with? - Barrier - free payment model included (mobile payment, card, bank account)? - Free use with sponsoring by ads possible (programmers payed from multiple resources, not user alone) - Cryptographic prevention of missuse included? - Free and matured SDK available? - Connections to social software like facebook/twitter/Google+/Groupon included (API access, programming language and all protocols supported) - GUI designed for desktop as well usable for touch and self adapting to different screen/touch sizes? - Touch gestures possible and lib avail? - Microsofts Kinect hardware/video recognition of faces, hand/face mimic gestures possible and supported in libs? - Voice recognition supported? - Mobile ready? (touch, GPS, compass, barometer, gyro, hardware OpenGL) - Rockstable? - Fast, running in low power devices? Joule per clock cycle ratio??? - Critical mass of users already reached, increasing? - Critical number of apps there to raise interest? ... So, the Pharo developers might now decide, what to invest their brainpower into! :-) Just my 2ct. Guido Stepken Am 27.01.2012 19:46 schrieb "Eliot Miranda" <eliot.miranda(a)gmail.com>: > > > On Fri, Jan 27, 2012 at 5:33 AM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > >> >> On Jan 27, 2012, at 6:13 AM, dimitris chloupis wrote: >> >> > This article is really encapsulates the attitude and what is wrong with >> programming in general. The attitude of superiority and intelligence that >> seems to plague coders and being the biggest obstacle to progress. >> >> Yes! The "Everyone is dumb but me" phenomenon... >> >> What those "intelligent" people don't get is that complexity is >> inherently exponential. So even if you are >> 10 times more intelligent than me (very well possible), it is >> *completely* irrelevant considering that complexity >> grows non-linearly. >> >> If you combine this with the notion of Evolution: that it is impossible >> to creat "the perfect" out of nothing, yet >> entropy grows when you incrementally improve things... than this has some >> very serious consequences. >> >> > For me the main problem with is the whole aura of "elitism" , what >> better example than Lisp, where beginners are attacked and be excluded. >> >> We had the same effect in Squeak at the end. No progress, every >> improvement was actively fighted against, if needed with the nice argument >> that >> one can do it even better, and only "the best" is worth for Squeak. >> >> Another thing that "intelligent" people don't get is that critizising is >> trivial: You can *always* do better, there is no perfection. It's an >> endless process. >> This implies that one has to accept and embrace imperfection if one wants >> to have a future. Else you end up never finishing anything, the death of any >> incremental progress. >> > > But criticism is essential. How does one identify a mistake if not by > criticising? There's a huge difference between constructive criticism > (analysis, testing, comparison, evaluation, measurement) and negativity > (denial, fear, slander). How can one engineer without measurement, without > thought? Being agile doesn't imply being random. Evolution measures, and > most harshly; the weaker don't survive. > > >> Pharo was started with the explicit goal to do as many mistakes as >> possible, as fast as possible. >> >> Marcus >> >> -- >> Marcus Denker -- http://marcusdenker.de >> >> >> > > > -- > best, > Eliot > >

Jan. 27, 2012

Re: [Pharo-project] Artifacts Mirroring

by Sven Van Caekenberghe

On 27 Jan 2012, at 17:31, Camillo Bruni wrote: > ./googlecode_upload.py --help > Usage: googlecode-upload.py -s SUMMARY -p PROJECT [options] FILE > > Options: > -h, --help show this help message and exit > -s SUMMARY, --summary=SUMMARY > Short description of the file > -p PROJECT, --project=PROJECT > Google Code project name > -u USER, --user=USER Your Google Code username > -w PASSWORD, --password=PASSWORD > Your Google Code password > -l LABELS, --labels=LABELS > An optional lis I had a quick look at http://code.google.com/p/support/source/browse/trunk/scripts/googlecode_upl… should be doable with zn+zdc as wellâ¦ ;-)

Jan. 27, 2012

Re: [Pharo-project] Meaning of the name "Pharo"

by StÃ©phane Ducasse

look at the beam nicolas :) Yes it turns. > And even a rock solid Pharo requires maintenance. > An abandoned Pharo would not be of much help, just a seamark, but not > an active guide, and it will sooner or later be tumbling down. > That's a good software metaphor, and we shall rejoice of current level > of activity. > > Nicolas Stef (sick in bed just woke up by telephoneâ¦.)

Jan. 27, 2012

Re: [Pharo-project] Beginner question about "self" in block

by Marcus Denker

On Jan 27, 2012, at 3:26 PM, Ben Coman wrote: > StÃ©phane Ducasse wrote: >> I guess that in naked objects book they discussed some patterns for relationships. >> What I would love to have is first class slots so that we can easily express relationships like the ones you describe. >> But I have too busy. >> I'm rereading the paper of toon, camillo et all to see what we could reasonably do. >> For those who want to read it: http://rmod.lille.inria.fr/web/pier/publications/bib?&query=Verw11a&display… Toon Verwaest, Camillo Bruni, Mircea Lungu, and Oscar Nierstrasz. Flexible object layouts: enabling lightweight language extensions by intercepting slot access. In Proceedings of OOPSLA '11 Abstract --------- Programming idioms, design patterns and application libraries often introduce cumbersome and repetitive boilerplate code to a software system. Language extensions and external DSLs (domain specific languages) are sometimes introduced to reduce the need for boilerplate code, but they also complicate the system by introducing the need for language dialects and inter-language mediation. To address this, we propose to extend the structural reflective model of the language with object layouts, layout scopes and slots. Based on the new reflective language model we can 1) provide behavioral hooks to object layouts that are triggered when the fields of an object are accessed and 2) simplify the implementation of state-related language extensions such as stateful traits. By doing this we show how many idiomatic use cases that normally require boilerplate code can be more effectively supported. We present an implementation in Smalltalk, and illustrate its usage through a series of extended examples. -- Marcus Denker -- http://marcusdenker.de

Jan. 27, 2012

Re: [Pharo-project] Enthousiasm is the main currency among developers

by Eliot Miranda

On Fri, Jan 27, 2012 at 5:33 AM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > > On Jan 27, 2012, at 6:13 AM, dimitris chloupis wrote: > > > This article is really encapsulates the attitude and what is wrong with > programming in general. The attitude of superiority and intelligence that > seems to plague coders and being the biggest obstacle to progress. > > Yes! The "Everyone is dumb but me" phenomenon... > > What those "intelligent" people don't get is that complexity is inherently > exponential. So even if you are > 10 times more intelligent than me (very well possible), it is *completely* > irrelevant considering that complexity > grows non-linearly. > > If you combine this with the notion of Evolution: that it is impossible to > creat "the perfect" out of nothing, yet > entropy grows when you incrementally improve things... than this has some > very serious consequences. > > > For me the main problem with is the whole aura of "elitism" , what > better example than Lisp, where beginners are attacked and be excluded. > > We had the same effect in Squeak at the end. No progress, every > improvement was actively fighted against, if needed with the nice argument > that > one can do it even better, and only "the best" is worth for Squeak. > > Another thing that "intelligent" people don't get is that critizising is > trivial: You can *always* do better, there is no perfection. It's an > endless process. > This implies that one has to accept and embrace imperfection if one wants > to have a future. Else you end up never finishing anything, the death of any > incremental progress. > But criticism is essential. How does one identify a mistake if not by criticising? There's a huge difference between constructive criticism (analysis, testing, comparison, evaluation, measurement) and negativity (denial, fear, slander). How can one engineer without measurement, without thought? Being agile doesn't imply being random. Evolution measures, and most harshly; the weaker don't survive. > Pharo was started with the explicit goal to do as many mistakes as > possible, as fast as possible. > > Marcus > > -- > Marcus Denker -- http://marcusdenker.de > > > -- best, Eliot

Jan. 27, 2012

Re: [Pharo-project] Beginner question about "self" in block

by Ben Coman

StÃ©phane Ducasse wrote: > I guess that in naked objects book they discussed some patterns for relationships. > What I would love to have is first class slots so that we can easily express relationships like the ones you describe. > But I have too busy. > I'm rereading the paper of toon, camillo et all to see what we could reasonably do. > I found the description of Bidrectional Associations interesting [1], as well as the naming convention for Derived Fields and Actions. [1] http://www.nakedobjects.org/book/section19.html > Stef > > On Jan 27, 2012, at 6:11 AM, Ben Coman wrote: > > >> StÃ©phane Ducasse wrote: >> >>> Welcome >>> >>> >>> >>> >>>> Hi, I have one begginer question. It is may be simple, but it very baffles me. >>>> >>>> I am reading Pharo by Example (great book btw, thanks!). I'm in chapter two where I'm creating Lights Out game. There is this simple code http://pastebin.com/eQregZ35. What baffles me is line 10. I assign "Block of code" to mouseAction variable of LOCell. In this Block, there is "self", that obviously refers to LOGame object in that time. But when is this Block actualy EVALUATED (when I click on Cell), "self" should be reffering to LOCell object, isn't it? If I inspect one LOCell, inspector shows that it has instance variable >>>> >>>> >>> Here is a draft of a next chapter on block :) >>> But I should finish it :) >>> ------------------------------------------------------------------------ >>> >>> >>> But I want to add how block are implemented at the bye code level so it take times because not that many people are helping, so I have to learn first. >>> >>> Stef >>> >>> >> Thanks Stef. A very enlightening read. Its has helped in an example I'll relate for other neophytes, and in case there are any traps or patterns I am missing. >> >> I have been struggling with how to implement a bidirectional relationship between two classes such that consistency is enforced. Take for instance the following classes... >> Object subclass: #Book instanceVariableNames: 'bookTitle library' >> Object subclass: #Library instanceVariableNames: 'libraryName books' >> >> I want both the 'books' and 'library' instvars to remain private - meaning that I don't want the default accessors providing direct access to either. Then a method like 'Library>>addBook: aBook' which can update its internal state modifying the 'books' collection cannot update the internal 'library' state of 'aBook' - without Book having a setter method to directly change the 'library' instvar - which I want to avoid having. Trying to resolve this led me into recursion hell with too much cross checking and guarding code. >> >> What I was wanting was a way to expose the private state of one object to another object in a controlled manner. So now I think this might be achieved like this... >> >> Library>>addBook: aBook >> aBook addToLibrary: self. >> >> Book>>addToLibrary: aLibrary >> aLibrary addBook: self withBackLink: [ :backlinkValue | library := backlinkValue ]. >> >> Library>>addBook: aBook withBackLink: setBacklinkBlock >> books ifNil: [ books := OrderedCollection new ]. >> books add: aBook. >> setBacklinkBlock value: self. >> >> Now having done that, I think I missed an alternative implementation... >> >> Library >> addBook: aBook >> aBook addToLibrary: self withInternalCollection: books >> >> Book>>addToLibrary: aLibrary withInternalCollection: libraryInternalBooksCollection >> libraryInternalBooksCollection add: self. >> library := aLibrary. >> >> >> Book>>addToLibrary: aLibrary >> aLibrary addBook: self. >> >> and I'm not really sure of the pros & cons of each approach. Thoughts anyone? >> >> > > > >

Jan. 27, 2012

Re: [Pharo-project] cogwin/Croquet (Win7) + Moose + very large models = crash (out of Memory)

by Eliot Miranda

Well, the define in sqWin32Alloc.h reads #ifndef MAX_VIRTUAL_MEMORY #define MAX_VIRTUAL_MEMORY 512*1024*1024 #endif (albeit guarded by #ifndef NO_VIRTUAL_MEMORY) so I tried to redefine it in the makefile: VM_DEF=-D'MAX_VIRTUAL_MEMORY=(2*1024*1024*1024)' ... DEFS:= $(COGDEFS) $(WINVER) $(VM_DEF) -DWIN32 -DWIN32_FILE_SUPPORT -DNO_ISNAN \ -DNO_SERVICE -DNO_STD_FILE_SUPPORT \ $(NDEBUG) -DLSB_FIRST -D'VM_NAME="$(VM_NAME)"' -DX86 $(XDEFS) $(CROQUET) But the resulting VM still wouldn't allocate more than 512M, so it is more complex than I hoped :) Andreas, if it is a simple job, do you know what's required to experiment with raising the limit on WIndows? On Thu, Jan 26, 2012 at 2:43 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 25 January 2012 23:18, Mariano Martinez Peck <marianopeck(a)gmail.com> > wrote: > > I think Igor fixed that for the Windows VM, but such changes were not > > integerated in Eliot VMs, but rather in the branch of Git. > > But since the Jenkins is not building Windows VM, I have no idea where > you > > can get such a VM. > > > No, changes are there. But they are not "fixing" the hard limit which > is still 512M. > They only fixing a strange issue with growing image close to that > limit (so 400M (and even less size) images was crashing before even > reaching a limit). > This is because of miscalculation between requested space and > available space, after memory growth. > > > Cheers > > > > > > On Wed, Jan 25, 2012 at 11:12 PM, Hani Abdeen <hani.abdeen(a)gmail.com> > wrote: > >> > >> > >> > >> On 25 January 2012 23:05, Paul DeBruicker <pdebruic(a)gmail.com> wrote: > >>> > >>> > >>> Hani Abdeen wrote > >>> > > >>> > Hello, > >>> > > >>> > I'm using cogwin/Croquet VM (last version > >>> > http://www.mirandabanda.org/files/Cog/VM/VM.r2522/) on windows7, > >>> > and today I had this probelm: when the size of the pharo image become > >>> > so > >>> > large the VM crashes with reason 'out of memory'. > >>> > The same problem with previous versions of cogwin. > >>> > Note that I use a PC with 8G of RAM, so it's really damage to have > such > >>> > a > >>> > problem. > >>> > > >>> > Any idea about another VM working well on Windows and does not have > >>> > such > >>> > an > >>> > issues? > >>> > Any urgent solution? > >>> > > >>> > Thanks, > >>> > Hani > >>> > > >>> > >>> From this thread: > >>> http://forum.world.st/experience-with-large-images-td4101765.html > >>> > >>> It seems that on windows the size of the image by default is limited to > >>> 500MB in RAM. I don't know if you can change it or not. Linux/Mac is > >>> limited to 2GB. Can you try your experiments on a Mac? > >> > >> > >> Unfortunately no, I've not Mac, and the company for which I'll use Moose > >> on their software, Tomorrow morning :(, do not use Mac. > >> > >> > >>> > >>> > >>> > >>> -- > >>> View this message in context: > >>> > http://forum.world.st/cogwin-Croquet-Win7-Moose-very-large-models-crash-out… > >>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >>> > >> > > > > > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > > > > -- > Best regards, > Igor Stasenko. > > -- best, Eliot

Jan. 27, 2012

[Pharo-project] Customizing Explore

by Ben Coman

I want to customize the Explorer that comes up when you press <shift><alt><i> such that as well as browsing my model, I can have a custom menu on each displayed class to instantiate one of the relationships defined on that class. For example, if the Explorer shows a Library object, then right-clicking on that object will bring up a menu with item "Add book". What are the classes I should be looking at for examples? cheers, Ben

Jan. 27, 2012