- Pharo-users - lists.pharo.org

Re: [Pharo-users] Slots in Pharo 5

by Jan Cada

Hi, I have opened the issue #19153 <https://pharo.fogbugz.com/f/cases/19153/Change-of-class-structure-with-Rela…>. Thanks, Jan > On 28 Sep 2016, at 16:10, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > Hi. > > It looks like bug. Could you open issue? > > 2016-09-28 15:36 GMT+02:00 Jan Cada <jan(a)cada.cz <mailto:jan@cada.cz>>: > Hi, > > I started to play with slots and I am observing odd behaviour after the class structure gets changed. > > I am having classes: > > Object subclass: #CTA > slots: { #x. #b => ToManyRelationSlot inverse: #a inClass: #CTB } > classVariables: { } > category: âClassTest' > > and > > Object subclass: #CTB > slots: { #x. #a => ToOneRelationSlot inverse: #b inClass: #CTA } > classVariables: { } > category: âClassTest' > > then I create instance of CTA and CTB pointing to CTA: > > a1 := CTA new x: 1; yourself. > b1 := CTB new x: 1; a: a1; yourself. > > the a1 is updated as expected with b having RelationSet with my CTB instance. > > The problem is when I decided to update the class CTA - changing position of slot #b => ToManyRelationSlot inverse: #a inClass: #CTB. > In the case I drop all the instances of CTA and CTB and recreate new by code above, the inverse update always addresses slot on same position as before and not the one with right name. > > For example when I change it like : > > Object subclass: #CTA > slots: { #x. #children => ToManyRelationSlot inverse: #parent inClass: #CTA. > #b => ToManyRelationSlot inverse: #a inClass: #CTB. > #parent => ToOneRelationSlot inverse: #children inClass: #CTA } > classVariables: { } > category: âClassTest' > > the result of the code > > a1 := CTA new x: 1; yourself. > b1 := CTB new x: 1; a: a1; yourself. > > is that slot children gets updated having RelationSet with my CTB instance instead of slot b which has empty RelationSet. > > The question is: Am I doing something wrong ? Is there any way how to tell class to reinit slots as its order has changed ? > > Thanks, > > Jan > > >

Sept. 28, 2016

Re: [Pharo-users] Tech Meeting notes

by FranÃ§ois Stephany

Thanks! On Wed, Sep 28, 2016 at 4:29 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > Thanks for the recording, I wasn't able to attend so it's good to at least > hear about the current state of things. > > Peter > > On Tue, Sep 27, 2016 at 7:37 PM, Dimitris Chloupis <kilon.alios(a)gmail.com> > wrote: > >> And for those that were not able to attend the voice meeting here you can >> find the recording so you can listen to it at your convenience >> >> https://dl.dropboxusercontent.com/u/1404140/Pharo%20Voice%20 >> Meetings/PharoVR1.ogg >> >> Have fun :) >> >> On Tue, Sep 27, 2016 at 8:23 PM stepharo <stepharo(a)free.fr> wrote: >> >>> Hi guys >>> >>> I tried to take some notes of the discussion and report of effort made >>> by esteban >>> >>> >>> >>> >>> VM works >>> ======== >>> - migrating our source to opensmalltalk vm 80% of our source >>> - keybindings enhancement >>> - shift key pressed >>> - library symbols >>> - change our cmake maker -> plain makefiles >>> - port our process (running all the tests) >>> - new VMs will get out >>> - ARM VM is under dev and started to run. >>> - migration planned for end of week of next weeks >>> >>> - right now able to build >>> 32 and 64 on mac and linux. >>> plan with mid october. >>> >>> - for windows >>> - We will produce assert vm to help people to find problems. >>> >>> - Sierra support is coming. >>> - openssl >>> It will come after the end of the merge finished. >>> >>> - FFI bug about the Athens canvas. >>> >>> - FT bug is getting on the radar and esteban suspects that the bug >>> is in the C plugin. We plan to throw away the FT plugin. >>> If people want to help please have a look at thibaultRaffaillac >>> bindings. >>> >>> - Pharo is using different VM functionalities so sometimes we are >>> going >>> on unfrequented paths. >>> >>> - Threaded FFI will come after 64, ARM, two bugs >>> Probably beginning of the year. >>> >>> >>> Iceberg >>> ======== >>> here is the log that nicolas sent to our internal mailing-list >>> >>> ### Last week: >>> - Improved travis support, working on having all green tests in travis, >>> still 4 to go. >>> - Extending libgit support. >>> - Support for synchronizing an Iceberg repository with code that was >>> loaded with gitfiletree (was not working, as reported by Norbert). >>> - Fixed some bugs (see >>> https://github.com/npasserini/iceberg/milestone/7?closed=1) >>> >>> >>> ### This week (starting 2016-09-26): >>> >>> - Finish having all tests running on travis. >>> - Better management of ssh keys (which in turn is required for travis >>> working correctly). >>> - Also I would like to add some little GUI details that bother me in >>> daily work (such as remembering common options, highlighting outdated >>> repositories, or opening repositories from spotter). >>> >>> I think that this might take the whole week. After that I plan to add >>> basic support synchronizing against code that was loaded from any >>> repository. With that finished, we could release v0.3 >>> >>> After that, the plan for v0.4 is to make libgit our default backend, and >>> make gitfiletree dependencies optional. >>> - I am pretty close to have all tests running for libgit again, then we >>> should try to use libgit as backend for the UI. But in that process also >>> improve test coverage so that we minimize dependence on manual >>> verification of the UI. >>> - Remodularice in order to separate gitfiletree dependencies, so we will >>> be able to use Iceberg without loading ossubprocess (or gitfiletree). >>> - That will require also to write an independent cypress reader/writer, >>> because the current one inherits from gitfiletree. >>> >>> If we have all this, I think that we could have a version that could be >>> included in the base image, probably in the second half of october. >>> >>> >>> >

Sept. 28, 2016

Re: [Pharo-users] Tech Meeting notes

by Peter UhnÃ¡k

Thanks for the recording, I wasn't able to attend so it's good to at least hear about the current state of things. Peter On Tue, Sep 27, 2016 at 7:37 PM, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > And for those that were not able to attend the voice meeting here you can > find the recording so you can listen to it at your convenience > > https://dl.dropboxusercontent.com/u/1404140/Pharo%20Voice% > 20Meetings/PharoVR1.ogg > > Have fun :) > > On Tue, Sep 27, 2016 at 8:23 PM stepharo <stepharo(a)free.fr> wrote: > >> Hi guys >> >> I tried to take some notes of the discussion and report of effort made >> by esteban >> >> >> >> >> VM works >> ======== >> - migrating our source to opensmalltalk vm 80% of our source >> - keybindings enhancement >> - shift key pressed >> - library symbols >> - change our cmake maker -> plain makefiles >> - port our process (running all the tests) >> - new VMs will get out >> - ARM VM is under dev and started to run. >> - migration planned for end of week of next weeks >> >> - right now able to build >> 32 and 64 on mac and linux. >> plan with mid october. >> >> - for windows >> - We will produce assert vm to help people to find problems. >> >> - Sierra support is coming. >> - openssl >> It will come after the end of the merge finished. >> >> - FFI bug about the Athens canvas. >> >> - FT bug is getting on the radar and esteban suspects that the bug >> is in the C plugin. We plan to throw away the FT plugin. >> If people want to help please have a look at thibaultRaffaillac >> bindings. >> >> - Pharo is using different VM functionalities so sometimes we are >> going >> on unfrequented paths. >> >> - Threaded FFI will come after 64, ARM, two bugs >> Probably beginning of the year. >> >> >> Iceberg >> ======== >> here is the log that nicolas sent to our internal mailing-list >> >> ### Last week: >> - Improved travis support, working on having all green tests in travis, >> still 4 to go. >> - Extending libgit support. >> - Support for synchronizing an Iceberg repository with code that was >> loaded with gitfiletree (was not working, as reported by Norbert). >> - Fixed some bugs (see >> https://github.com/npasserini/iceberg/milestone/7?closed=1) >> >> >> ### This week (starting 2016-09-26): >> >> - Finish having all tests running on travis. >> - Better management of ssh keys (which in turn is required for travis >> working correctly). >> - Also I would like to add some little GUI details that bother me in >> daily work (such as remembering common options, highlighting outdated >> repositories, or opening repositories from spotter). >> >> I think that this might take the whole week. After that I plan to add >> basic support synchronizing against code that was loaded from any >> repository. With that finished, we could release v0.3 >> >> After that, the plan for v0.4 is to make libgit our default backend, and >> make gitfiletree dependencies optional. >> - I am pretty close to have all tests running for libgit again, then we >> should try to use libgit as backend for the UI. But in that process also >> improve test coverage so that we minimize dependence on manual >> verification of the UI. >> - Remodularice in order to separate gitfiletree dependencies, so we will >> be able to use Iceberg without loading ossubprocess (or gitfiletree). >> - That will require also to write an independent cypress reader/writer, >> because the current one inherits from gitfiletree. >> >> If we have all this, I think that we could have a version that could be >> included in the base image, probably in the second half of october. >> >> >>

Sept. 28, 2016

Re: [Pharo-users] Slots in Pharo 5

by Denis Kudriashov

Hi. It looks like bug. Could you open issue? 2016-09-28 15:36 GMT+02:00 Jan Cada <jan(a)cada.cz>: > Hi, > > I started to play with slots and I am observing odd behaviour after the > class structure gets changed. > > I am having classes: > > Object subclass: #*CTA* > slots: { #x. #*b* => ToManyRelationSlot inverse: #*a* inClass: #*CTB* } > classVariables: { } > category: âClassTest' > > and > > Object subclass: #*CTB* > slots: { #x. #*a* => ToOneRelationSlot inverse: #*b* inClass: #*CTA* } > classVariables: { } > category: âClassTest' > > then I create instance of *CTA* and *CTB* pointing to *CTA*: > > a1 := *CTA* new x: 1; yourself. > b1 := *CTB* new x: 1; *a*: a1; yourself. > > the a1 is updated as expected with *b* having RelationSet with my *CTB* > instance. > > The problem is when I decided to update the class *CTA* - changing > position of slot #*b* => ToManyRelationSlot inverse: #*a* inClass: > #CTB. > In the case I drop all the instances of *CTA* and *CTB* and recreate new > by code above, the inverse update always addresses slot on same position as > before and not the one with right name. > > For example when I change it like : > > Object subclass: #*CTA* > slots: { #x. #*children* => ToManyRelationSlot inverse: #parent inClass: # > *CTA*. > #*b* => ToManyRelationSlot inverse: #*a* inClass: #*CTB*. > #parent => ToOneRelationSlot inverse: #children inClass: #*CTA* } > classVariables: { } > category: âClassTest' > > the result of the code > > a1 := *CTA* new x: 1; yourself. > b1 := *CTB* new x: 1; *a*: a1; yourself. > > is that slot *children* gets updated having RelationSet with my *CTB* > instance instead of slot *b* which has empty RelationSet. > > The question is: Am I doing something wrong ? Is there any way how to tell > class to reinit slots as its order has changed ? > > Thanks, > > Jan > > >

Sept. 28, 2016

Re: [Pharo-users] Slots in Pharo 5

by Jan Cada

Hi, I investigated a little bit more and I see that CTA slots are as expected - slot b has index 3: while CTB slots have inverse slot for a with old index 2 - so the inverse part was not updated when I changed CTA structure Thanks for any advice, Jan > On 28 Sep 2016, at 15:36, Jan Cada <jan(a)cada.cz> wrote: > > Hi, > > I started to play with slots and I am observing odd behaviour after the class structure gets changed. > > I am having classes: > > Object subclass: #CTA > slots: { #x. #b => ToManyRelationSlot inverse: #a inClass: #CTB } > classVariables: { } > category: âClassTest' > > and > > Object subclass: #CTB > slots: { #x. #a => ToOneRelationSlot inverse: #b inClass: #CTA } > classVariables: { } > category: âClassTest' > > then I create instance of CTA and CTB pointing to CTA: > > a1 := CTA new x: 1; yourself. > b1 := CTB new x: 1; a: a1; yourself. > > the a1 is updated as expected with b having RelationSet with my CTB instance. > > The problem is when I decided to update the class CTA - changing position of slot #b => ToManyRelationSlot inverse: #a inClass: #CTB. > In the case I drop all the instances of CTA and CTB and recreate new by code above, the inverse update always addresses slot on same position as before and not the one with right name. > > For example when I change it like : > > Object subclass: #CTA > slots: { #x. #children => ToManyRelationSlot inverse: #parent inClass: #CTA. > #b => ToManyRelationSlot inverse: #a inClass: #CTB. > #parent => ToOneRelationSlot inverse: #children inClass: #CTA } > classVariables: { } > category: âClassTest' > > the result of the code > > a1 := CTA new x: 1; yourself. > b1 := CTB new x: 1; a: a1; yourself. > > is that slot children gets updated having RelationSet with my CTB instance instead of slot b which has empty RelationSet. > > The question is: Am I doing something wrong ? Is there any way how to tell class to reinit slots as its order has changed ? > > Thanks, > > Jan > >

Sept. 28, 2016

Slots in Pharo 5

by Jan Cada

Hi, I started to play with slots and I am observing odd behaviour after the class structure gets changed. I am having classes: Object subclass: #CTA slots: { #x. #b => ToManyRelationSlot inverse: #a inClass: #CTB } classVariables: { } category: âClassTest' and Object subclass: #CTB slots: { #x. #a => ToOneRelationSlot inverse: #b inClass: #CTA } classVariables: { } category: âClassTest' then I create instance of CTA and CTB pointing to CTA: a1 := CTA new x: 1; yourself. b1 := CTB new x: 1; a: a1; yourself. the a1 is updated as expected with b having RelationSet with my CTB instance. The problem is when I decided to update the class CTA - changing position of slot #b => ToManyRelationSlot inverse: #a inClass: #CTB. In the case I drop all the instances of CTA and CTB and recreate new by code above, the inverse update always addresses slot on same position as before and not the one with right name. For example when I change it like : Object subclass: #CTA slots: { #x. #children => ToManyRelationSlot inverse: #parent inClass: #CTA. #b => ToManyRelationSlot inverse: #a inClass: #CTB. #parent => ToOneRelationSlot inverse: #children inClass: #CTA } classVariables: { } category: âClassTest' the result of the code a1 := CTA new x: 1; yourself. b1 := CTB new x: 1; a: a1; yourself. is that slot children gets updated having RelationSet with my CTB instance instead of slot b which has empty RelationSet. The question is: Am I doing something wrong ? Is there any way how to tell class to reinit slots as its order has changed ? Thanks, Jan

Sept. 28, 2016

bug in debugger?

by Usman Bhatti

Hello, I have a strange error in my image that results in image start taking up system memory and crashes when it attains the max. the VM can provide on my machine (2Gb). I am working on Pharo 4.0 + Spec debugger. After some digging in the image, I know that the error comes from an assignment operation (below in bold). And the bug only occurs when the method initialize is executed as inherited method. The strange part is that that it does not crash when the value assigned is slightly different e.g. "nosignature1" instead of "nosignature". FAMIXInvocation>>initialize super initialize. sender := nil. receiver := nil. receiverSourceCode := nil. *signature := 'nosignature'.* candidates := FMMultiMultivalueLink on: self opposite: #incomingInvocations. The crash doesn't happen when I override initialize in the subclass without sending initialize message to the superclass. So this report is about a very very specific case, but it is there. I tried to analyze further in the debugger but with announcements, etc. I wasn't able to achieve anything. So, if someone's interested to have a look, I can provide the image. regards. Usman

Sept. 28, 2016

Re: [Pharo-users] Subscript Out Of Bounds: 1 when commiting from Versionner

by HernÃ¡n Morales Durand

May be this issue : https://pharo.fogbugz.com/f/cases/18684/Versionner-Error-while-commiting-a-… And here for the fix : https://pharo.fogbugz.com/f/cases/18927/Komitter-throws-up-if-it-has-commit… HernÃ¡n 2016-09-28 1:29 GMT-03:00 stepharo <stepharo(a)free.fr>: > Yes it was fix in pharo 60 and we should port it back but I forgot the > issue number > > > > Le 27/9/16 Ã 21:00, HernÃ¡n Morales Durand a Ã©crit : > > When commiting with Versionner in Pharo 5.0 I always have to manually >> override this method >> >> KomitStagingArea>>remotes >> | result | >> >> result := self packages first remotes. >> self packages allButFirst do: [ :each | >> result := result intersection: each remotes ]. >> >> ^ result collect: [ :each | each koRemote ] >> >> to >> >> KomitStagingArea>>remotes >> >> self packages isEmpty >> ifFalse: [ >> | result | >> result := self packages first remotes. >> self packages allButFirst do: [ :each | >> result := result intersection: each remotes ]. >> ^ result collect: [ :each | each koRemote ] ]. >> ^ Array empty. >> >> Screenshot attached. >> Is this known issue or was this reported before? >> >> Hernan >> >> > >

Sept. 28, 2016

Re: [Pharo-users] Subscript Out Of Bounds: 1 when commiting from Versionner

by stepharo

Yes it was fix in pharo 60 and we should port it back but I forgot the issue number Le 27/9/16 Ã 21:00, HernÃ¡n Morales Durand a Ã©crit : > When commiting with Versionner in Pharo 5.0 I always have to manually > override this method > > KomitStagingArea>>remotes > | result | > > result := self packages first remotes. > self packages allButFirst do: [ :each | > result := result intersection: each remotes ]. > > ^ result collect: [ :each | each koRemote ] > > to > > KomitStagingArea>>remotes > > self packages isEmpty > ifFalse: [ > | result | > result := self packages first remotes. > self packages allButFirst do: [ :each | > result := result intersection: each remotes ]. > ^ result collect: [ :each | each koRemote ] ]. > ^ Array empty. > > Screenshot attached. > Is this known issue or was this reported before? > > Hernan >

Sept. 28, 2016

Subscript Out Of Bounds: 1 when commiting from Versionner

by HernÃ¡n Morales Durand

When commiting with Versionner in Pharo 5.0 I always have to manually override this method KomitStagingArea>>remotes | result | result := self packages first remotes. self packages allButFirst do: [ :each | result := result intersection: each remotes ]. ^ result collect: [ :each | each koRemote ] to KomitStagingArea>>remotes self packages isEmpty ifFalse: [ | result | result := self packages first remotes. self packages allButFirst do: [ :each | result := result intersection: each remotes ]. ^ result collect: [ :each | each koRemote ] ]. ^ Array empty. Screenshot attached. Is this known issue or was this reported before? Hernan

Sept. 27, 2016