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

Re: [Pharo-dev] The Pharo Morphic book

by stepharo

Le 19/1/15 22:21, kilon alios a Ã©crit : > Ok then I think the best way to do this is to start this in my own > github account then give you guys the link , review the documentation > and if you find satisfying add it to SquareBracketAssociates via > forking it, if not I can still continue it with my github account. Of > course I will use pillar and follow the same workflow as PBE. I don't > want to do this via blog posts , I prefer pillar and github. We can create a repo on > > PBE wise looks like from what I see from a first look that 12 out 16 > chapters are ported. So PBE is near completion at least at a draft > level. I can give a hand with a couple more chapters thats not a big > deal. Thanks. We will have to read it again. I have to check (I got stuck in the model chapter and the first one). > There is no Pharo book for Morphic and for me this is a big omission. > Frankly I would take even a small docs about Morphic and Pharo 3/4 > over no documentation at all, any day. Sure Just read what I said. Go incremental. > I am not saying that you should contribute to a Morphic book I mean > this is your choice but its something I want to work on. If people > want to contribute all they have to do is fork my repo and send me > pull requests or even add them as contributors. If they dont want, no > problemo I continue alone. > > In any case when I have something substantial (something more than 30 > pages) I will alert the list. > > On Mon, Jan 19, 2015 at 10:31 PM, stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>> wrote: > > > Hello people, I am really interested since PBE seems to go > very well to now concentrate on a project I had in mind for > some time and it is to start a book on Pharo Morphic. > > > I would start small and for example as a series of blog posts. > Then we you reach a certain amount I would then turn them into a book. > > For Spec we plan to collect all the material and have a small booklet. > > > My plan is to add it to github group SquareBracketAssociates > which I am member of for contributing to the new PBE. > > Is that ok with you ? > > > it is ok but now the strategy I adopted is the following one: > - avoid to have many unfinished books (or many not making > progress or slow progress) > - this is why I have work in progress to work on the chapters, > ready for reviews then the chapters will populate the books > - this way I do not give the impression that Pharo is starting > stuff and not finishing > - I would suggest the same: host some chapter in the work in > progress and when you enough push that to a book. > > I finished an editorial pass on deep into pharo and will continue > to work on Pharo by example, then resume my work on > the other books (slow is n't it :)). > > > I will try to port all documentation available already for > Morphic from self and squeak to Pharo 4 and of course add my > own pages as well. > > There is not much available, or exciting but you can start there. > > > I also have forgot my travis password, I have asked here > before but none replied, so if anyone can help me recover my > password or create a new one or create a job for the project , > I will appreciate it. > > > travis I do not know. > > > Obviously I want to make this project according to the > guidelines of the community. So if you have suggestions fire > away :) > > I would like this to be the official book on Morphic , I want > it to be both a tutorial but also a reference book with more > emphasis on the reference side. Probably will divide in into a > Part 1 and a Part 2 where Part 1 is the tutorial and Part 2 is > the reference. > > I dont expect to of course to do a ton of work and finish this > book any time soon, but then something is better than nothing. > > > >

Jan. 24, 2015

Issue 12970 - 16 steps to get through #halt - PROPOSED FIX

by Ben Coman

I've found a fix for something that has annoyed me for a long time - but I can't determine what it might break. 1. In Workspace I evaluate the following Halt enableHaltOnce. a := 1. self halt. b := 2. self haltOnce. c := 3. Transcript show: a + b + c. 2. In the debugger after it stops at the #halt, it takes a SINGLE <Step Over> to move to d:=2 - no problem. 3. Now <Restart> and then <Step Over> down to c:=3 and observe: * the #halt now takes EIGHT (used to be SIXTEEN) steps to traverse (ouch!) * the #haltOnce takes THREE steps to traverse (good) Tracing through for both #halt and #haltOnce it seems that the specific conditional reference to #halt in Halt>>signalerContext is the difference! Removing that condition results in the #halt behaving like #haltOnce, taking only THREE <Step Over>s to traverse a restarted #halt. Halt>>signalerContext ^ signalContext findContextSuchThat: [ :context | (context receiver == self or: [ (context receiver == self class) or: [ context method selector = #halt ]]) not ] Now #haltOnce seems to have been operating without a problem for a long timer, so presumably its okay to make #halt behave the same way. But this is deep stuff I don't fully understand. Anyone see a problem with removing that last condition? cheers -ben

Jan. 24, 2015

Re: [Pharo-dev] Package cleaning

by Ben Coman

On Sat, Jan 24, 2015 at 9:47 PM, Ben Coman <btc(a)openinworld.com> wrote: > How about doing it as a post load script like this (tested on my local > package-cache)... > > oldPackageName := 'ShoutTests'. > newPackageName := 'Shout-Tests'. > repository := MCRepository allSubInstances detect: [ :repo | repo location > = > '/Users/ben/Library/Application Support/Pharo/package-cache' ]. > " 'http://smalltalkhub.com/mc/Pharo/Pharo40/main' ]." > oldPackage := RPackageOrganizer default packageNamed: oldPackageName. > newPackage := oldPackage renameTo: newPackageName. > mcWorkingCopy := newPackage mcPackage workingCopy. > uniqueNewVersion := (mcWorkingCopy uniqueVersionNameIn: repository) > trimBoth. > newVersion := mcWorkingCopy > newVersionWithName: uniqueNewVersion > message: 'Issue 14439 - ShoutTests should be Shout-Tests' > in: repository. > newVersion ifNotNil: [ > Cursor wait showWhile: [ > [ repository storeVersion: newVersion. > ] ensure: [ (MCVersionInspector new version: newVersion) show ] > ] > ]. > > For reference, I munged that together from tracing > NautliusMonticello>>commit:in: > I've set it up ready to integrate here... https://pharo.fogbugz.com/default.asp?14439 hopefully works.

Jan. 24, 2015

Re: [Pharo-dev] Package cleaning

by Ben Coman

How about doing it as a post load script like this (tested on my local package-cache)... oldPackageName := 'ShoutTests'. newPackageName := 'Shout-Tests'. repository := MCRepository allSubInstances detect: [ :repo | repo location = '/Users/ben/Library/Application Support/Pharo/package-cache' ]. " 'http://smalltalkhub.com/mc/Pharo/Pharo40/main' ]." oldPackage := RPackageOrganizer default packageNamed: oldPackageName. newPackage := oldPackage renameTo: newPackageName. mcWorkingCopy := newPackage mcPackage workingCopy. uniqueNewVersion := (mcWorkingCopy uniqueVersionNameIn: repository) trimBoth. newVersion := mcWorkingCopy newVersionWithName: uniqueNewVersion message: 'Issue 14439 - ShoutTests should be Shout-Tests' in: repository. newVersion ifNotNil: [ Cursor wait showWhile: [ [ repository storeVersion: newVersion. ] ensure: [ (MCVersionInspector new version: newVersion) show ] ] ]. For reference, I munged that together from tracing NautliusMonticello>>commit:in: cheers -ben On Sat, Jan 24, 2015 at 1:33 AM, Ben Coman <btc(a)openinworld.com> wrote: > > > On Fri, Jan 23, 2015 at 8:00 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > >> Hi Marcus, Ben and others, >> >> how can we proceed on META issue https://pharo.fogbugz.com/f/cases/14447? >> >> Anyone with deeper knowdlege of Monticello and the integration process >> able to help here? It's a merging issue although nothing to merge. >> >> Thx >> T. >> >> > Actually, I discovered that the problem only occurs when you wrap the > package in a slice. Given that these will be isolated single package > updates, without needing to synchronise with other packages, would it be > possible & pragmatic to load the packages directly without a slice, to get > the issues out of the way. Or maybe a script that does the rename and then > pushes the dirty packages to the repository? > > Now do we need to be concerned with the oldnamed package being an ancestor > of the renamed ? > > cheers -ben > > >

Jan. 24, 2015

Re: [Pharo-dev] [Slots] Invisible Slots

by Marcus Denker

> On 24 Jan 2015, at 11:24, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > Hi, > > One of the power of slots is the concept of Virtual Slots that do not have an ivar to store their state. > But of course, some uses fo this concept want to store state in the object. > (e.g. imagine a property slot, all proper slots of the object would store into a property dictionary). > > The idea is that one can add iVars reflectively that are hidden from both introspection *and* the class > definition. (the inspector should get a view to see reality, of course, similar to how we tread Dictionaries and OrderedCollection: > The âbasicâ view is not relavant in most cases, it is just available in addition, the default is the high level view that is closer > to the âmental modelâ of the programmer). > > https://pharo.fogbugz.com/f/cases/14786/Slots-add-HiddenInstanceVariableSlo… <https://pharo.fogbugz.com/f/cases/14786/Slots-add-HiddenInstanceVariableSlo…> > Ups, loading the Slice crashes the VM :-) This kind of shows why doing these things in tiny, tiny steps is they way to goâ¦ Marcus

Jan. 24, 2015

[Slots] Invisible Slots

by Marcus Denker

Hi, One of the power of slots is the concept of Virtual Slots that do not have an ivar to store their state. But of course, some uses fo this concept want to store state in the object. (e.g. imagine a property slot, all proper slots of the object would store into a property dictionary). The idea is that one can add iVars reflectively that are hidden from both introspection *and* the class definition. (the inspector should get a view to see reality, of course, similar to how we tread Dictionaries and OrderedCollection: The âbasicâ view is not relavant in most cases, it is just available in addition, the default is the high level view that is closer to the âmental modelâ of the programmer). https://pharo.fogbugz.com/f/cases/14786/Slots-add-HiddenInstanceVariableSlo… <https://pharo.fogbugz.com/f/cases/14786/Slots-add-HiddenInstanceVariableSlo…> -> Add a sublass of normal invar slots that is hidden -> change #slots of Behavior to return #allVisibleSlots Next: When building classes with Slots, the class builder need to call back on the slot and hand the class to each. Then the slot can reflectively change the class, e.g. the PropertySlot will check if there is already a hidden property base slot and if not, add it reflectively). Marcus

Jan. 24, 2015

Re: [Pharo-dev] Commit custom Slot

by Marcus Denker

>> >> This is now in 40457 >> >> #isSpecial is fixed, too. >> >> This means that you can subclass AbstractInstanceVariableSlot and just override #read and #write:to: and it should work. >> > Hmmâ¦ maybe IndexedSlot would be a better nameâ¦? I do not like AbstractSomethings. And it actually is not abstract, > it should work (just slower than InstanceVariableSlot) > I rename it but keep the AbstractInstanceVariableSlot subclass so it does not brake any code loading. Any users should change AbstractInstanceVariableSlot to IndexedSlot, I will remove the class next week. https://pharo.fogbugz.com/f/cases/14786/Slots-add-HiddenInstanceVariableSlo… <https://pharo.fogbugz.com/f/cases/14786/Slots-add-HiddenInstanceVariableSlo…> Marcus

Jan. 24, 2015

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/40459 Home: https://github.com/pharo-project/pharo-core

Jan. 24, 2015

[pharo-project/pharo-core] 31f0fd: 40459

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 31f0fda864bb103a8d7fd8937b8ae24f927fb035 https://github.com/pharo-project/pharo-core/commit/31f0fda864bb103a8d7fd893… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-01-24 (Sat, 24 Jan 2015) Changed paths: M Kernel.package/CompiledMethod.class/instance/literals/headerDescription.st M Nautilus.package/PackageTreeNautilusUI.class/instance/accessing/showHierarchy_.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script459.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40459.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Slot.package/ClassVariable.class/instance/printing/definitionString.st M Slot.package/ClassVariable.class/instance/testing/isSpecial.st M Slot.package/GlobalVariable.class/instance/code generation/emitStore_.st R Slot.package/GlobalVariable.class/instance/printing/definitionString.st R Slot.package/GlobalVariable.class/instance/testing/isSpecial.st M Slot.package/InstanceVariableSlot.class/instance/printing/definitionString.st Log Message: ----------- 40459 14784 toggle show hierarchy gives: list receiver of "package" is nil https://pharo.fogbugz.com/f/cases/14784 14779 fix #definitionString for subclasses of ClassVariable and IntanceVariableSlot https://pharo.fogbugz.com/f/cases/14779 14780 Bug in compiled method printing since signflag is printed. https://pharo.fogbugz.com/f/cases/14780 http://files.pharo.org/image/40/40459.zip

Jan. 24, 2015

Re: [Pharo-dev] Commit custom Slot

by Aliaksei Syrel

Perfect, thanks! Until now all faced bugs are gone and it works flawlessly :) Cheers, Alex On Fri, Jan 23, 2015 at 2:42 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 22 Jan 2015, at 18:15, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > On 22 Jan 2015, at 18:06, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > > And I also think that InstanceVariableSlot >>definitionString in > subclasses should return self printString and not only its name > > > The thing is that we have two cases: > > 1) Full definition {#slot => PropertySlot} > 2) shortened definition { #ivar } > > the later one is for ânormalâ instance variables (and globals), for all > the cases where slots just model what we have now. > > the #isSpecial check returns false for those and true for all other slots. > > I think we should implement definitionString in InstanceVariableSlot to > check isSpecial and call the super > class method for the case when it is. This way it will work even for > subclasses as expected. > > > This is fixed with > > > https://pharo.fogbugz.com/f/cases/14779/fix-definitionString-for-subclasses… > > > Marcus > >

Jan. 23, 2015