December 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] doing stupid things (image will become unusable)

by Robert Withers

i AM MORE INTERESTED IN WHAT STATE HER CONSCIOUSNESS IS INAFTER TRICKING HER? If there is true loss of perceptory connection with the mirage, real pratyahara, there may still be a seed of meditation, so called Sabija Samadhi. It is not clear to me whether there actually is - messages sent without an Object??? Or is it blocked from finishing that operation and so there is no Nirbija Samadhi, not to speak loudly of Dharma Megha Samadhi! Wir Sind Tot! Alice ist jetzt Bardo! Nameste . On 12/08/2015 11:19 AM, Nicolai Hess wrote: > > Object := nil > > you can evaluate that piece of code, but afterwards .... > > Opal checks for assignments to read only variables (method arguments > for example) > and signals an error if you try to modify those vars. > But it does not check globals. > > Should all Globals (OCLiteralVariable with isGlobalVar == true) be > read only ? > or can we distinguish global vars and class bindings? >

Dec. 8, 2015

Re: [Pharo-dev] displayingProgress on demand

by John Brant

On 12/7/2015 5:27 PM, HernÃ¡n Morales Durand wrote: > > but now I am failing to see how to replace #collect: with > #collect:thenDo: using the rewriter: > > http://ws.stfx.eu/MOWS947F000O You don't need to first search using the RBParseTreeSearcher. The RBParseTreeRewriter works with search patterns. What your code is really doing is searching for the literal pattern that it found from the RBParseTreeSearcher in the FooClass>>foo: method: aString asFileReference entries collect: [ : fileEntry | self openOnFileNamed: fileEntry fullName ] It then tries to replace it with the pattern: `@collection collect: `@arg1 thenDo: [ : fileEntry | index := index + 1. JobProgress progress: (0.1 * index); title: 'Procesing...', index asString ] However, since neither `@collection nor `@arg1 appear in your search pattern, you get an error. Here's a version that works: | cm rewriteRule replacement | cm := FooClass >> #foo:. replacement := '`@collection collect: `@arg1 thenDo: [ : fileEntry | index := index + 1. JobProgress progress: (0.1 * index); title: ''Procesing...'', index asString ]'. rewriteRule := RBParseTreeRewriter new replace: '`@collection collect: `@arg1' with: replacement. rewriteRule executeTree: cm parseTree. rewriteRule tree newSource Essentially, I used the same search pattern you used, but I used it for the RBParseTreeRewriter and removed all of the RBParseTreeSearcher code. If you want to change all #collect: sends in a method, then you should probably change `@aCollection and `@arg1 to ``@aCollection and ``@arg1. John Brant

Dec. 8, 2015

Re: [Pharo-dev] doing stupid things (image will become unusable)

by Marcus Denker

Yes, I wondered why it was not done in semantic analysisâ¦ would be much easier. The binding approach only takes care of reflective change (Smalltalk globals at: Object put: nil), a case that is not as important to fix. (reflection is dangerous, disallowing just this one operation does not help). We should do some experiments. Marcus > On 08 Dec 2015, at 17:33, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > I remember. But what I do not remember is if the compiler was aware of it. > > I remember you had these ReadOnlyVariable, subclass of association that redefined #value:. You were however still capable of doing: > > MyReadOnlyVar := 1. > >> On 8 dic 2015, at 5:29 p.m., Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: >> >> Hi, >> >> There used to be a mechanism for that (readonly variable bindings). >> >> It was there but not used: half the globals where readonly, all globals added >> after the experiment was done where ânormalâ. >> >> With the new âfirst classâ variables we could easily add that back in a clean way. >> >> Marcus >> >>> On 08 Dec 2015, at 17:19, Nicolai Hess <nicolaihess(a)gmail.com <mailto:nicolaihess@gmail.com>> wrote: >>> >>> Object := nil >>> >>> you can evaluate that piece of code, but afterwards .... >>> >>> Opal checks for assignments to read only variables (method arguments for example) >>> and signals an error if you try to modify those vars. >>> But it does not check globals. >>> >>> Should all Globals (OCLiteralVariable with isGlobalVar == true) be read only ? >>> or can we distinguish global vars and class bindings? >>> >> >

Dec. 8, 2015

Re: [Pharo-dev] doing stupid things (image will become unusable)

by Guillermo Polito

I remember. But what I do not remember is if the compiler was aware of it. I remember you had these ReadOnlyVariable, subclass of association that redefined #value:. You were however still capable of doing: MyReadOnlyVar := 1. > On 8 dic 2015, at 5:29 p.m., Marcus Denker <marcus.denker(a)inria.fr> wrote: > > Hi, > > There used to be a mechanism for that (readonly variable bindings). > > It was there but not used: half the globals where readonly, all globals added > after the experiment was done where ânormalâ. > > With the new âfirst classâ variables we could easily add that back in a clean way. > > Marcus > >> On 08 Dec 2015, at 17:19, Nicolai Hess <nicolaihess(a)gmail.com <mailto:nicolaihess@gmail.com>> wrote: >> >> Object := nil >> >> you can evaluate that piece of code, but afterwards .... >> >> Opal checks for assignments to read only variables (method arguments for example) >> and signals an error if you try to modify those vars. >> But it does not check globals. >> >> Should all Globals (OCLiteralVariable with isGlobalVar == true) be read only ? >> or can we distinguish global vars and class bindings? >> >

Dec. 8, 2015

Re: [Pharo-dev] doing stupid things (image will become unusable)

by Marcus Denker

Hi, There used to be a mechanism for that (readonly variable bindings). It was there but not used: half the globals where readonly, all globals added after the experiment was done where ânormalâ. With the new âfirst classâ variables we could easily add that back in a clean way. Marcus > On 08 Dec 2015, at 17:19, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > Object := nil > > you can evaluate that piece of code, but afterwards .... > > Opal checks for assignments to read only variables (method arguments for example) > and signals an error if you try to modify those vars. > But it does not check globals. > > Should all Globals (OCLiteralVariable with isGlobalVar == true) be read only ? > or can we distinguish global vars and class bindings? >

Dec. 8, 2015

Re: [Pharo-dev] doing stupid things (image will become unusable)

by Guillermo Polito

I had this semester a lot of students having the same problemâ¦ Iâm +1 to fix it. > On 8 dic 2015, at 5:19 p.m., Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > Object := nil > > you can evaluate that piece of code, but afterwards .... > > Opal checks for assignments to read only variables (method arguments for example) > and signals an error if you try to modify those vars. > But it does not check globals. > > Should all Globals (OCLiteralVariable with isGlobalVar == true) be read only ? > or can we distinguish global vars and class bindings? >

Dec. 8, 2015

doing stupid things (image will become unusable)

by Nicolai Hess

Object := nil you can evaluate that piece of code, but afterwards .... Opal checks for assignments to read only variables (method arguments for example) and signals an error if you try to modify those vars. But it does not check globals. Should all Globals (OCLiteralVariable with isGlobalVar == true) be read only ? or can we distinguish global vars and class bindings?

Dec. 8, 2015

Re: [Pharo-dev] Documentation epiphany

by phil＠highoctane.be

FWIW, the Blue Book is very good and is a free PDF now. Phil On Tue, Dec 8, 2015 at 4:36 PM, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > "Actually this joke I think is "stolen" by a previous joke about 3d > artists" > > nope I think I am wrong once again, looks older. > > By the way Pharo documentation is so good, I decided to start recommending > it even to people new to coding. Much much better than it used to be 2 > years ago, in another 2 we will be much better :) > > We still missing a good tutorial on OOP for absolute beginners but at some > point I think I will get around to writing a chapter for UPBE. > > On Tue, Dec 8, 2015 at 5:24 PM Dimitris Chloupis <kilon.alios(a)gmail.com> > wrote: > >> Actually this joke I think is "stolen" by a previous joke about 3d >> artists , because our rendering times can be way longer than compiling the >> most complex C++ code. Easily can reach months of rendering time. >> >> Its a good joke, but it should be taken as it is , a joke and nothing >> more. >> >> Because I happen to build blender from time to time which is 1 million >> lines of destruction code, aka C/C++ code. Compiling is not that bad. Sure >> C++ still is hog slow and outperformed 10 times by Pascal compilers which I >> think that even the Pharo compiler would have a hard time competing with. >> But makefiles are smart enough to compile and re link whatever it changes >> and not the whole project. >> >> So each new commit I fetch for Blender produces a couple of seconds of >> compiling time. But the very first compile which compiles everything from >> scratch can reach even an hour and is not even a complete compile since I >> use many prebuilt libraries and some prebuilt dependencies. >> >> To the subject of documentation it comes attached with a big depends. >> Documentation is the usual problem pretty much with any programming >> languages and is based on the fact that coders dont like to document as >> much they dont like to design good code and make very good GUIs. >> >> Frankly you should always feel glad if you find documentation in any >> language your are coding. If its good documentation too, then its your >> lucky day indeed. >> >> But even in popular languages like Python, sure plenty of documentation >> for the standard stuff but the moment you start depend on third party >> libraries you are all alone VS the Alien :D >> >> On Tue, Dec 8, 2015 at 4:42 PM Ben Coman <btc(a)openinworld.com> wrote: >> >>> I just understood! Other languages might get better documentation >>> because of all the extra slack time they get between compile cycles, >>> that we don't get with Pharo's tight code-run-debug loop. >>> >>> I know... not a valid excuse for us**, but then I get to show this... >>> https://xkcd.com/303/ >>> >>> ** of course documentation is getting better every day - but I can't >>> let the truth get in the way of a good story :) >>> >>> cheers -ben >>> >>>

Dec. 8, 2015

Re: [Pharo-dev] Documentation epiphany

by Dimitris Chloupis

"Actually this joke I think is "stolen" by a previous joke about 3d artists" nope I think I am wrong once again, looks older. By the way Pharo documentation is so good, I decided to start recommending it even to people new to coding. Much much better than it used to be 2 years ago, in another 2 we will be much better :) We still missing a good tutorial on OOP for absolute beginners but at some point I think I will get around to writing a chapter for UPBE. On Tue, Dec 8, 2015 at 5:24 PM Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > Actually this joke I think is "stolen" by a previous joke about 3d artists > , because our rendering times can be way longer than compiling the most > complex C++ code. Easily can reach months of rendering time. > > Its a good joke, but it should be taken as it is , a joke and nothing > more. > > Because I happen to build blender from time to time which is 1 million > lines of destruction code, aka C/C++ code. Compiling is not that bad. Sure > C++ still is hog slow and outperformed 10 times by Pascal compilers which I > think that even the Pharo compiler would have a hard time competing with. > But makefiles are smart enough to compile and re link whatever it changes > and not the whole project. > > So each new commit I fetch for Blender produces a couple of seconds of > compiling time. But the very first compile which compiles everything from > scratch can reach even an hour and is not even a complete compile since I > use many prebuilt libraries and some prebuilt dependencies. > > To the subject of documentation it comes attached with a big depends. > Documentation is the usual problem pretty much with any programming > languages and is based on the fact that coders dont like to document as > much they dont like to design good code and make very good GUIs. > > Frankly you should always feel glad if you find documentation in any > language your are coding. If its good documentation too, then its your > lucky day indeed. > > But even in popular languages like Python, sure plenty of documentation > for the standard stuff but the moment you start depend on third party > libraries you are all alone VS the Alien :D > > On Tue, Dec 8, 2015 at 4:42 PM Ben Coman <btc(a)openinworld.com> wrote: > >> I just understood! Other languages might get better documentation >> because of all the extra slack time they get between compile cycles, >> that we don't get with Pharo's tight code-run-debug loop. >> >> I know... not a valid excuse for us**, but then I get to show this... >> https://xkcd.com/303/ >> >> ** of course documentation is getting better every day - but I can't >> let the truth get in the way of a good story :) >> >> cheers -ben >> >>

Dec. 8, 2015

Re: [Pharo-dev] Documentation epiphany

by Dimitris Chloupis

Actually this joke I think is "stolen" by a previous joke about 3d artists , because our rendering times can be way longer than compiling the most complex C++ code. Easily can reach months of rendering time. Its a good joke, but it should be taken as it is , a joke and nothing more. Because I happen to build blender from time to time which is 1 million lines of destruction code, aka C/C++ code. Compiling is not that bad. Sure C++ still is hog slow and outperformed 10 times by Pascal compilers which I think that even the Pharo compiler would have a hard time competing with. But makefiles are smart enough to compile and re link whatever it changes and not the whole project. So each new commit I fetch for Blender produces a couple of seconds of compiling time. But the very first compile which compiles everything from scratch can reach even an hour and is not even a complete compile since I use many prebuilt libraries and some prebuilt dependencies. To the subject of documentation it comes attached with a big depends. Documentation is the usual problem pretty much with any programming languages and is based on the fact that coders dont like to document as much they dont like to design good code and make very good GUIs. Frankly you should always feel glad if you find documentation in any language your are coding. If its good documentation too, then its your lucky day indeed. But even in popular languages like Python, sure plenty of documentation for the standard stuff but the moment you start depend on third party libraries you are all alone VS the Alien :D On Tue, Dec 8, 2015 at 4:42 PM Ben Coman <btc(a)openinworld.com> wrote: > I just understood! Other languages might get better documentation > because of all the extra slack time they get between compile cycles, > that we don't get with Pharo's tight code-run-debug loop. > > I know... not a valid excuse for us**, but then I get to show this... > https://xkcd.com/303/ > > ** of course documentation is getting better every day - but I can't > let the truth get in the way of a good story :) > > cheers -ben > >

Dec. 8, 2015