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

Re: [Pharo-dev] UpdatedPharoByExample for 3.0, 4.0, 5.0

by stepharo

there is no technical problem. there is a huge time / energy investment problems. We will reintroduce in pillar the possibility to run tests. and we will add support (should check what stephan did to get automatic scrneeshots). Stef Le 4/4/15 15:04, Sean P. DeNigris a Ã©crit : > Would it make sense to freeze the documentation for each image version? Maybe > a branch per image? This way, people who choose/need to work with previous > image versions have an accurate reference. From my limited Git experience it > shouldn't be much extra work. > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/UpdatedPharoByExample-for-3-0-4-0-5-0-tp4817514.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > >

April 4, 2015

Re: [Pharo-dev] UpdatedPharoByExample for 3.0, 4.0, 5.0

by kilon alios

I agree it makes sense, we can use git tags , or branches. Having separate docs for every version is how it works for all other languages I have used. Its zero extra work. I dont know about the generation of pdfs though, I am not familair with CI / Jenkins and how easy it is to assign specific builds to git tags / branches. On Sat, Apr 4, 2015 at 4:04 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Would it make sense to freeze the documentation for each image version? > Maybe > a branch per image? This way, people who choose/need to work with previous > image versions have an accurate reference. From my limited Git experience > it > shouldn't be much extra work. > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/UpdatedPharoByExample-for-3-0-4-0-5-0-tp4817514.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

April 4, 2015

UpdatedPharoByExample for 3.0, 4.0, 5.0

by Sean P. DeNigris

Would it make sense to freeze the documentation for each image version? Maybe a branch per image? This way, people who choose/need to work with previous image versions have an accurate reference. From my limited Git experience it shouldn't be much extra work. ----- Cheers, Sean -- View this message in context: http://forum.world.st/UpdatedPharoByExample-for-3-0-4-0-5-0-tp4817514.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 4, 2015

Re: [Pharo-dev] Binding semantics of SystemDictionary

by Max Leske

> On 31 Mar 2015, at 23:12, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > Thanks Nicolas. I was hoping to see a bit more activity on this thread so I didnât reply immediately. > not only the globals but the methods in MethodDictionary too :) Ok, that might even be worse. AFAIK MethodDictionary is treated as a special class by the VM. So storing other objects in there may be a real problem, not just a philosphical one. CCâing vm-dev on this. > It might be a feature, it's just that it's unused because of limited IDE and compiler. If you look far enough, almost anything can be considered a featureâ¦ :) > > 2015-03-31 20:49 GMT+02:00 Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>>: > Hi > > Tommaso and I, while hacking on Fuel, today discovered that globals in Pharo can have very weird bindings (I guess some of you already know that). For example: > > class := Class new > setName: 4; > yourself. > Smalltalk > at: class name > put: class. > > So we now have a class with name 4 (which is a SmallInteger): > > self assert: (Smalltalk at: 4) == class. > > > There are basically two different issues: > 1. SystemDictionary will store any kind of association, not only symbols / strings > 2. SystemDictionary is an IdentityDictionary and as such two equivalent but not identical keys will not resolve to the same object: > > class := Class new > setName: (String streamContents: [ :s | s nextPutAll: 'someName']); > yourself. > Smalltalk > at: class name > put: class. > > Smalltalk > at: (String streamContents: [ :s | s nextPutAll: 'someNameâ]) > ifAbsent: [ false ]. âââ> falseâ > > > In Fuel we simply assume that any key to a global is either a ByteString or ByteSymbol. If thatâs not the case bad things happen. > It would help us a lot if we could clear up the semantics of bindings in SystemDictionary: > 1. Are bindings with keys that are not ByteString or ByteSymbol valid? > 2. Should we keep allowing ByteString as keys to globals (ByteSymbol guarantees identity)? > 3. If we allow ByteString, do we also allow WideString? > 4. Would âtype checksâ on SystemDictionary incur a big performance penalty? > > > Any suggestions are welcome. > > Cheers, > Max >

April 4, 2015

Re: [Pharo-dev] Binding semantics of SystemDictionary

by Max Leske

Bumpâ¦ I really think this is something we should talk aboutâ¦ Otherwise Iâll open an issue on phogbugz. > On 01 Apr 2015, at 22:58, stepharo <stepharo(a)free.fr> wrote: > > Please do not use Smalltalk at: > We will ban it for real! Good to know. I wasnât aware of that. > > Stef > > Le 31/3/15 20:49, Max Leske a Ã©crit : >> Hi >> >> Tommaso and I, while hacking on Fuel, today discovered that globals in Pharo can have very weird bindings (I guess some of you already know that). For example: >> >> class := Class new >> setName: 4; >> yourself. >> Smalltalk >> at: class name >> put: class. >> >> So we now have a class with name 4 (which is a SmallInteger): >> >> self assert: (Smalltalk at: 4) == class. >> >> >> There are basically two different issues: >> 1. SystemDictionary will store any kind of association, not only symbols / strings > > arghhhh Exactly the sound I made when we discovered that :) > >> 2. SystemDictionary is an IdentityDictionary and as such two equivalent but not identical keys will not resolve to the same object: >> >> class := Class new >> setName: (String streamContents: [ :s | s nextPutAll: 'someName']); >> yourself. >> Smalltalk >> at: class name >> put: class. >> >> Smalltalk >> at: (String streamContents: [ :s | s nextPutAll: 'someNameâ]) >> ifAbsent: [ false ]. âââ> falseâ >> >> >> In Fuel we simply assume that any key to a global is either a ByteString or ByteSymbol. If thatâs not the case bad things happen. >> It would help us a lot if we could clear up the semantics of bindings in SystemDictionary: >> 1. Are bindings with keys that are not ByteString or ByteSymbol valid? >> 2. Should we keep allowing ByteString as keys to globals (ByteSymbol guarantees identity)? >> 3. If we allow ByteString, do we also allow WideString? >> 4. Would âtype checksâ on SystemDictionary incur a big performance penalty? >> >> >> Any suggestions are welcome. >> >> Cheers, >> Max >> > >

April 4, 2015

Re: [Pharo-dev] VM and .sources in separate dirs question

by Max Leske

> On 03 Apr 2015, at 19:02, Dmitri Zagidulin <dmitri(a)zagidulin.net> wrote: > > Do you happen to know how it does it? (I wouldn't know where to look, in the source code). Does it still work if you move the sources to another directory, from your current one? Does Pharo do a whole-disk search every time? (Or just when it doesn't find them?) > > On Fri, Apr 3, 2015 at 12:00 PM, Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>> wrote: > >> On 03 Apr 2015, at 17:55, Dmitri Zagidulin <dmitri(a)zagidulin.net <mailto:dmitri@zagidulin.net>> wrote: >> >> On Fri, Apr 3, 2015 at 11:49 AM, Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>> wrote: >> > that you can keep the VM and .sources in different directories? How do you tell the VM where to locate the sources? >> >> You donât. Itâs detected automagically! >> >> Wait, how does it know which .sources file to pick? :) What if there are .sources from multiple versions of Pharo, etc, lying around on the hard drive? No, Pharo wonât search your disk, that would take way too long. Basically, the image tries to find the sources in two places: 1. the image directory 2. the vm directory In reality Pharo tries to do a bit more. The places Pharo looks in are listed in OSPlatform>>potentialLocationsOfSourcesFile (and subclasses). See also PharoFilesOpener>>openSources. Note that the Pharo implementation has probably diverged a bit from the one that Squeak uses / used to use. Cheers, Max >> > > The image decides which sources file it needs. I have all of mine in a single directory with all the different VMs. Works like a charm. >

April 4, 2015

Re: [Pharo-dev] Freeze while running a loop

by Gaurav Singh

Thanks Alain :) On Sat, Apr 4, 2015 at 5:02 PM, Alain Rastoul <alf.mmm.cat(a)gmail.com> wrote: > Hi Gaurav, > > As said by Aliaksei, the problem is string concatenation with , > your example takes 33 secs on a core i7 3.3Ghz (quite some ms ;) ) > In Smalltalk, you handle that with streams (see Aliaksei example). > You can also add objects to all types of collections, not only strings > (Arrays etc). > You will find examples by searching references of WriteStream class (in > Nautilus, on WriteStream, right click / Analyse Class refs) or senders of > streamContents: . > Have a look at Pharo by examples chapter on streams > http://pharo.gforge.inria.fr/PBE1/PBE1ch11.html > (pdf here: http://pharobyexample.org/) > > And if you want to see what is going on with some code, you can select > your code in the workspace and use the 'Profile it' option in the menu. > Alternatively, you can open the profiler tools with World Menu/Tools/Time > Profiler, paste your code in the code pane of the profiler and run it. > A very handy tool, worth to know about it. > > HTH > > Regards, > > Alain > > >

April 4, 2015

Re: [Pharo-dev] Freeze while running a loop

by Alain Rastoul

Hi Gaurav, As said by Aliaksei, the problem is string concatenation with , your example takes 33 secs on a core i7 3.3Ghz (quite some ms ;) ) In Smalltalk, you handle that with streams (see Aliaksei example). You can also add objects to all types of collections, not only strings (Arrays etc). You will find examples by searching references of WriteStream class (in Nautilus, on WriteStream, right click / Analyse Class refs) or senders of streamContents: . Have a look at Pharo by examples chapter on streams http://pharo.gforge.inria.fr/PBE1/PBE1ch11.html (pdf here: http://pharobyexample.org/) And if you want to see what is going on with some code, you can select your code in the workspace and use the 'Profile it' option in the menu. Alternatively, you can open the profiler tools with World Menu/Tools/Time Profiler, paste your code in the code pane of the profiler and run it. A very handy tool, worth to know about it. HTH Regards, Alain

April 4, 2015

Re: [Pharo-dev] Forcing GTInspector to refresh

by stepharo

Ok I found the icon. Now redoing for the third time my video Stef > Hi > > I was doing a video on teaching how to build a simple counter and > I would like to know how I can refresh the value of an instance > variable in GT. > > I really hope that we will fix such kind of problem because it kills > my fun showing Pharo. > > Stef > >

April 4, 2015

Re: [Pharo-dev] Magritte = Auto-GT Presentation

by Norbert Hartl

Cool! Can you add a spec based editor for the object? ;) That woule be Ã¼bernice, haha. Norbert > Am 04.04.2015 um 06:01 schrieb Sean P. DeNigris <sean(a)clipperadams.com>: > > gtInspectorMagritteIn: composite > <gtInspectorPresentationOrder: 30> > | table | > table := composite table > title: 'Magritte'; > display: [ self magritteDescription children collect: [ :desc | > desc label -> (desc toString: (desc accessor read: self)) ] ]; > column: 'Field' evaluated: #key; > column: 'Value' evaluated: #value; > send: #value > > descriptionName > <magritteDescription> > > ^ MAStringDescription new > accessor: #name; > label: 'Name'; > priority: 100; > yourself > descriptionPages > etc... > > <http://forum.world.st/file/n4817448/Screenshot_2015-04-04_00.png> > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Magritte-Auto-GT-Presentation-tp4817448.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

April 4, 2015