August 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Bag enhancements

by StÃ©phane Ducasse

Ok I will add instead of elementsAndOccurrencesDo: On Aug 12, 2013, at 9:40 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > #withOccurrencesDo: matches better the rest of the pharo system (#withIndexDo:, etc) :) > > On Aug 12, 2013, at 9:16 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> >> On Aug 12, 2013, at 1:49 AM, Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: >> >>> Why not #doWithOccurrences: ?? >> >> ok it was a proposal for a new selector :) >> >>> >>> Eg: >>> bag doWithOccurrences: [:element :count | "do something"] >>> >>> I dont'like the keysAndValuesDo: idea, is just an implementation detail. >>> >>> >>> On Sun, Aug 11, 2013 at 4:52 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> Hi guys >>> >>> I was surprised to see the API of bag for iteration. >>> >>> I propose to add >>> >>> keysAndValuesDo: aBlock >>> "Iterate over the receiver and apply a two argument block on the element and its occurrences." >>> >>> contents associationsDo: [:assoc | aBlock value: assoc key value: assoc value ] >>> >>> and >>> >>> elementsAndOccurrencesDo: aTwoArgBlock >>> "Iterate over the receiver and apply a two argument block on the element and its occurrences." >>> >>> contents associationsDo: [:assoc | aTwoArgBlock value: assoc key value: assoc value ] >>> >>> Once we agree I will add a bug entry. >>> >>> Stef >>> >> >

Aug. 12, 2013

Re: [Pharo-dev] Bag enhancements

by Gabriel Cotelli

+1 Keep it consistent with the rest of the system. On Mon, Aug 12, 2013 at 4:40 AM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: > #withOccurrencesDo: matches better the rest of the pharo system > (#withIndexDo:, etc) :) > > On Aug 12, 2013, at 9:16 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > wrote: > > > On Aug 12, 2013, at 1:49 AM, Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: > > Why not #doWithOccurrences: ?? > > > ok it was a proposal for a new selector :) > > > Eg: > bag doWithOccurrences: [:element :count | "do something"] > > I dont'like the keysAndValuesDo: idea, is just an implementation detail. > > > On Sun, Aug 11, 2013 at 4:52 PM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > >> Hi guys >> >> I was surprised to see the API of bag for iteration. >> >> I propose to add >> >> keysAndValuesDo: aBlock >> "Iterate over the receiver and apply a two argument block on the >> element and its occurrences." >> >> contents associationsDo: [:assoc | aBlock value: assoc key value: >> assoc value ] >> >> and >> >> elementsAndOccurrencesDo: aTwoArgBlock >> "Iterate over the receiver and apply a two argument block on the >> element and its occurrences." >> >> contents associationsDo: [:assoc | aTwoArgBlock value: assoc key >> value: assoc value ] >> >> Once we agree I will add a bug entry. >> >> Stef >> > > > >

Aug. 12, 2013

Re: [Pharo-dev] bug with new inspector?

by Erwan Douaille

[image: Images intÃ©grÃ©es 1] Not very beautifull but usefull. The thing is, the toolbar isn't in the debugger, so we have to use shortcuts 2013/8/12 ClÃ©ment Bera <clement.bera(a)inria.fr> > 2013/8/12 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > >> >> On Aug 12, 2013, at 10:15 AM, ClÃ©ment Bera <bera.clement(a)gmail.com> >> wrote: >> >> 2013/8/12 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >> >>> >>> yeah it tries to do 'bag at: 1' which fails. How would look like a nice >>> bag inspector ? >>> >>> >>> same as set or dictionary >>> a bag is conceptually a collection of pair >>> >> >> Ok I will make a slice >> >>> >>> Now what would be nice is that we can have a default inspector that does >>> not interpret the structure. >>> >>> It exists, it is 'object basicInspect', or in the inspector, right click >> on self, then click on basicInspect. >> >>> >>> It would be also nice that when we dive into an object when we close the >>> window the system popup to the previous object >>> >> >> This happens when you don't dive but open a new window with Cmd+i, it is >> the old inspector workflow that still works on purpose. If it pops up the >> last object on close there is no advantage of dive instead of the old >> inspector that pops new windows. >> >> >>> because this is annoying to close the complete stack >>> we could have a shift or option variant that close everything. >>> >> >> I don't know. 10 days ago, Erwan did a tool bar for the inspector that >> may help (the slice is waiting in fix review needed). >> >> >> did you look at it? >> does it work? >> I will add it to the list of things I should look at. >> > > I've just had a quick look, it does not look very beautiful but it works > fine. > > I think we should integrate then people can improve it incrementally. It > is a nice first step. > > >> Stef >> >> >>> >>> >>> 2013/8/11 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >>> >>>> (Bag new add: 3 ; add: 3 ; add: 3 ; add: 2 ;yourself) inspect >>>> >>>> we got an error when trying to see the second element. >>>> >>>> >>>> Stef >>>> >>>> >>> >>> >> >> > > > -- > ClÃ©ment BÃ©ra > Mate Virtual Machine Engineer > BÃ¢timent B 40, avenue Halley 59650 *Villeneuve d'Ascq* > -- Best regards, Douaille Erwan <douaille.erwan(a)gmail.com>

Aug. 12, 2013

Re: [Pharo-dev] bug with new inspector?

by ClÃ©ment Bera

2013/8/12 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > > On Aug 12, 2013, at 10:15 AM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > 2013/8/12 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > >> >> yeah it tries to do 'bag at: 1' which fails. How would look like a nice >> bag inspector ? >> >> >> same as set or dictionary >> a bag is conceptually a collection of pair >> > > Ok I will make a slice > >> >> Now what would be nice is that we can have a default inspector that does >> not interpret the structure. >> >> It exists, it is 'object basicInspect', or in the inspector, right click > on self, then click on basicInspect. > >> >> It would be also nice that when we dive into an object when we close the >> window the system popup to the previous object >> > > This happens when you don't dive but open a new window with Cmd+i, it is > the old inspector workflow that still works on purpose. If it pops up the > last object on close there is no advantage of dive instead of the old > inspector that pops new windows. > > >> because this is annoying to close the complete stack >> we could have a shift or option variant that close everything. >> > > I don't know. 10 days ago, Erwan did a tool bar for the inspector that may > help (the slice is waiting in fix review needed). > > > did you look at it? > does it work? > I will add it to the list of things I should look at. > I've just had a quick look, it does not look very beautiful but it works fine. I think we should integrate then people can improve it incrementally. It is a nice first step. > Stef > > >> >> >> 2013/8/11 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >> >>> (Bag new add: 3 ; add: 3 ; add: 3 ; add: 2 ;yourself) inspect >>> >>> we got an error when trying to see the second element. >>> >>> >>> Stef >>> >>> >> >> > > -- ClÃ©ment BÃ©ra Mate Virtual Machine Engineer BÃ¢timent B 40, avenue Halley 59650 *Villeneuve d'Ascq*

Aug. 12, 2013

Re: [Pharo-dev] [update 3.0] #30330

by Martin Dias

Aug. 12, 2013

[update 3.0] #30330

by StÃ©phane Ducasse

Aug. 12, 2013

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/label=win/… 1 regressions found. Zinc.Zodiac.ZnHTTPSTests.testGetPharoVersion

Aug. 12, 2013

Re: [Pharo-dev] bug with new inspector?

by StÃ©phane Ducasse

On Aug 12, 2013, at 10:15 AM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > 2013/8/12 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > >> yeah it tries to do 'bag at: 1' which fails. How would look like a nice bag inspector ? > > same as set or dictionary > a bag is conceptually a collection of pair > > Ok I will make a slice > > Now what would be nice is that we can have a default inspector that does not interpret the structure. > > It exists, it is 'object basicInspect', or in the inspector, right click on self, then click on basicInspect. > > It would be also nice that when we dive into an object when we close the window the system popup to the previous object > > This happens when you don't dive but open a new window with Cmd+i, it is the old inspector workflow that still works on purpose. If it pops up the last object on close there is no advantage of dive instead of the old inspector that pops new windows. > > because this is annoying to close the complete stack > we could have a shift or option variant that close everything. > > I don't know. 10 days ago, Erwan did a tool bar for the inspector that may help (the slice is waiting in fix review needed). did you look at it? does it work? I will add it to the list of things I should look at. Stef > > > >> 2013/8/11 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >> (Bag new add: 3 ; add: 3 ; add: 3 ; add: 2 ;yourself) inspect >> >> we got an error when trying to see the second element. >> >> >> Stef >> >> > >

Aug. 12, 2013

Re: [Pharo-dev] bug with new inspector?

by ClÃ©ment Bera

2013/8/12 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > > yeah it tries to do 'bag at: 1' which fails. How would look like a nice > bag inspector ? > > > same as set or dictionary > a bag is conceptually a collection of pair > Ok I will make a slice > > Now what would be nice is that we can have a default inspector that does > not interpret the structure. > > It exists, it is 'object basicInspect', or in the inspector, right click on self, then click on basicInspect. > > It would be also nice that when we dive into an object when we close the > window the system popup to the previous object > This happens when you don't dive but open a new window with Cmd+i, it is the old inspector workflow that still works on purpose. If it pops up the last object on close there is no advantage of dive instead of the old inspector that pops new windows. > because this is annoying to close the complete stack > we could have a shift or option variant that close everything. > I don't know. 10 days ago, Erwan did a tool bar for the inspector that may help (the slice is waiting in fix review needed). > > > > 2013/8/11 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > >> (Bag new add: 3 ; add: 3 ; add: 3 ; add: 2 ;yourself) inspect >> >> we got an error when trying to see the second element. >> >> >> Stef >> >> > >

Aug. 12, 2013

Re: [Pharo-dev] Bag enhancements

by Esteban Lorenzano

#withOccurrencesDo: matches better the rest of the pharo system (#withIndexDo:, etc) :) On Aug 12, 2013, at 9:16 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Aug 12, 2013, at 1:49 AM, Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: > >> Why not #doWithOccurrences: ?? > > ok it was a proposal for a new selector :) > >> >> Eg: >> bag doWithOccurrences: [:element :count | "do something"] >> >> I dont'like the keysAndValuesDo: idea, is just an implementation detail. >> >> >> On Sun, Aug 11, 2013 at 4:52 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> Hi guys >> >> I was surprised to see the API of bag for iteration. >> >> I propose to add >> >> keysAndValuesDo: aBlock >> "Iterate over the receiver and apply a two argument block on the element and its occurrences." >> >> contents associationsDo: [:assoc | aBlock value: assoc key value: assoc value ] >> >> and >> >> elementsAndOccurrencesDo: aTwoArgBlock >> "Iterate over the receiver and apply a two argument block on the element and its occurrences." >> >> contents associationsDo: [:assoc | aTwoArgBlock value: assoc key value: assoc value ] >> >> Once we agree I will add a bug entry. >> >> Stef >> >

Aug. 12, 2013

Re: [Pharo-dev] Understanding Versionner repository selection

by StÃ©phane Ducasse

>> >> > > Thanks Stef. I get it now, it is just a matter of right click the in the right pane in Versionner, the #developement item, and then select the item "release dev" from the popup menu. Pretty easy. > > Now I will take a loot to SnapshotCello because I don't get what's the difference eith Versionner. easy they have nothing to do. Versionner could invoke snapshotcello. Snapshotcello does not produce configurations it produces A flat list of all the packages used by a current configuration and publish as a version. It freezes the current set of packages at the level of your dependency tree and recursively. Stef

Aug. 12, 2013

Re: [Pharo-dev] bug with new inspector?

by StÃ©phane Ducasse

> yeah it tries to do 'bag at: 1' which fails. How would look like a nice bag inspector ? same as set or dictionary a bag is conceptually a collection of pair Now what would be nice is that we can have a default inspector that does not interpret the structure. It would be also nice that when we dive into an object when we close the window the system popup to the previous object because this is annoying to close the complete stack we could have a shift or option variant that close everything. > 2013/8/11 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > (Bag new add: 3 ; add: 3 ; add: 3 ; add: 2 ;yourself) inspect > > we got an error when trying to see the second element. > > > Stef > >

Aug. 12, 2013

Re: [Pharo-dev] Bag enhancements

by StÃ©phane Ducasse

On Aug 12, 2013, at 1:49 AM, Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: > Why not #doWithOccurrences: ?? ok it was a proposal for a new selector :) > > Eg: > bag doWithOccurrences: [:element :count | "do something"] > > I dont'like the keysAndValuesDo: idea, is just an implementation detail. > > > On Sun, Aug 11, 2013 at 4:52 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi guys > > I was surprised to see the API of bag for iteration. > > I propose to add > > keysAndValuesDo: aBlock > "Iterate over the receiver and apply a two argument block on the element and its occurrences." > > contents associationsDo: [:assoc | aBlock value: assoc key value: assoc value ] > > and > > elementsAndOccurrencesDo: aTwoArgBlock > "Iterate over the receiver and apply a two argument block on the element and its occurrences." > > contents associationsDo: [:assoc | aTwoArgBlock value: assoc key value: assoc value ] > > Once we agree I will add a bug entry. > > Stef >

Aug. 12, 2013

Re: [Pharo-dev] Bag enhancements

by StÃ©phane Ducasse

On Aug 12, 2013, at 1:49 AM, Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: > Why not #doWithOccurrences: ?? > > Eg: > bag doWithOccurrences: [:element :count | "do something"] I did not see it in fact. it was probably not in the right place. > I dont'like the keysAndValuesDo: idea, is just an implementation detail. I agree (kind of) but this is polymorphic with hashtable so this is also nice. In fact I was not thinking about implementation when I wrote it. > > > On Sun, Aug 11, 2013 at 4:52 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi guys > > I was surprised to see the API of bag for iteration. > > I propose to add > > keysAndValuesDo: aBlock > "Iterate over the receiver and apply a two argument block on the element and its occurrences." > > contents associationsDo: [:assoc | aBlock value: assoc key value: assoc value ] > > and > > elementsAndOccurrencesDo: aTwoArgBlock > "Iterate over the receiver and apply a two argument block on the element and its occurrences." > > contents associationsDo: [:assoc | aTwoArgBlock value: assoc key value: assoc value ] > > Once we agree I will add a bug entry. > > Stef >

Aug. 12, 2013

Re: [Pharo-dev] bug with new inspector?

by ClÃ©ment Bera

yeah it tries to do 'bag at: 1' which fails. How would look like a nice bag inspector ? 2013/8/11 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > (Bag new add: 3 ; add: 3 ; add: 3 ; add: 2 ;yourself) inspect > > we got an error when trying to see the second element. > > > Stef > >

Aug. 12, 2013

Re: [Pharo-dev] Understanding Versionner repository selection

by HernÃ¡n Morales Durand

El 11/08/2013 4:00, StÃ©phane Ducasse escribiÃ³: > > On Aug 11, 2013, at 6:04 AM, HernÃ¡n Morales Durand > <hernan.morales(a)gmail.com <mailto:hernan.morales@gmail.com>> wrote: > >> El 10/08/2013 14:55, HernÃ¡n Morales Durand escribiÃ³: >>> Hi folks, >>> I have a *very* simple package with no dependencies whatsoever. Now I'm >>> trying to understand Versionner, these are the steps: >>> >>> 1. I set the ConfigurationOf name >>> 2. I choose I don't want to use squeaksource.com >>> <http://squeaksource.com> >>> <http://squeaksource.com>, ok >>> 3. Select a repository... >>> >>> Now that is not clear for me. Which repository are you talking about? >>> the repository where I store MY code, or the repository where I would >>> like to publish the configuration so is displayed in the Configuration >>> Browser (like the MetaRepoForPharo)? >>> >> >> Ok, I choose the MetaRepoForPharo. The ConfigurationOf class is >> generated with its methods. I consider myself this package as stable, >> but there is no generated method for #'stable'. Do I need to create it >> by hand and then Commit to repository? > > normally not but I do not know the status of Versioner and christophe is > on vacation. > Thanks Stef. I get it now, it is just a matter of right click the in the right pane in Versionner, the #developement item, and then select the item "release dev" from the popup menu. Pretty easy. Now I will take a loot to SnapshotCello because I don't get what's the difference eith Versionner. >> >> This is another doubt. Where I should add meta information about my >> package? I just want to put a little description of what it does. > > > Hi all, > > I wish I could release a first beta of Versionner before my holidays but > I'am a bit short. > Nevertheless, you will find an archive on this page > http://chercheurs.lille.inria.fr/~demarey/Tech/Versionner containing the > current status of Versionner. > If you want, you can play a bit with it and give me feedback. > There are a lot of missing features but tit will come time after time. > > From now you can create a new config, release a dev version, update > dependencies. > > See you in 3 weeks, > Christophe.

Aug. 12, 2013

Re: [Pharo-dev] Bag enhancements

by Gabriel Cotelli

Why not #doWithOccurrences: ?? Eg: bag doWithOccurrences: [:element :count | "do something"] I dont'like the keysAndValuesDo: idea, is just an implementation detail. On Sun, Aug 11, 2013 at 4:52 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > Hi guys > > I was surprised to see the API of bag for iteration. > > I propose to add > > keysAndValuesDo: aBlock > "Iterate over the receiver and apply a two argument block on the > element and its occurrences." > > contents associationsDo: [:assoc | aBlock value: assoc key value: > assoc value ] > > and > > elementsAndOccurrencesDo: aTwoArgBlock > "Iterate over the receiver and apply a two argument block on the > element and its occurrences." > > contents associationsDo: [:assoc | aTwoArgBlock value: assoc key > value: assoc value ] > > Once we agree I will add a bug entry. > > Stef >

Aug. 11, 2013

Re: [Pharo-dev] Fix in Athens-Cairo

by Alexandre Bergel

Yes, you're right. The Morphic version of drawing arc does not complain, however it did with Athens. Thanks for fixing this Alexandre On Aug 7, 2013, at 9:00 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > Just to make it clear: > > when you get zero-divide error, where you think the bug is , in #/ method, > or maybe in code which passed zero as divisor? > > by analogy, when you want to draw an arc with zero length, which makes > it non-arc, > where you think the bug is, in code which implements drawing an arc or > in code which provides wrong input? > > because this change actually hiding the mistakes, so instead of > getting error and fixing it, > user now will have hard times figuring out, why it not draws things as > intended and where his mistake is. > > -- > Best regards, > Igor Stasenko. -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Aug. 11, 2013

Bag enhancements

by StÃ©phane Ducasse

Hi guys I was surprised to see the API of bag for iteration. I propose to add keysAndValuesDo: aBlock "Iterate over the receiver and apply a two argument block on the element and its occurrences." contents associationsDo: [:assoc | aBlock value: assoc key value: assoc value ] and elementsAndOccurrencesDo: aTwoArgBlock "Iterate over the receiver and apply a two argument block on the element and its occurrences." contents associationsDo: [:assoc | aTwoArgBlock value: assoc key value: assoc value ] Once we agree I will add a bug entry. Stef

Aug. 11, 2013

bug with new inspector?

by StÃ©phane Ducasse

(Bag new add: 3 ; add: 3 ; add: 3 ; add: 2 ;yourself) inspect we got an error when trying to see the second element. Stef

Aug. 11, 2013

Re: [Pharo-dev] adding temporary adds them outside the temp declaration?

by StÃ©phane Ducasse

Thanks clement. Stef On Aug 11, 2013, at 8:26 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > This is in Pharo 3, isn't it ? > > There are currently bugs with Opal's exception handing in Pharo 3.0. It was fixed then some other changes broke it again. So yeah it is known. You might have bug with: > OCShadowVariableWarning. > OCUndeclaredVariableWarning. > OCUninitializedVariableWarning. > OCUnusedVariableWarning. > OCUnknownSelectorWarning. > > > 2013/8/11 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Hi guys > > Is it a know bug? > > | selector superClasses | > selector := aMethodDefinition selector. > superClasses := aMethodDefinition realClass allSuperclasses. > result := OrderedCollection new. > (superClasses select: [ :eachClass | eachClass hasProtocolFor: selector]) > do: [ :eachClass | (eachClass includesSelector: selector) > ifTrue: [ result add: (self whichCategoryIncludesSelector: selector)]]. > ^ result asBag > > adds result > > result | selector superClasses | > selector := aMethodDefinition selector. > superClasses := aMethodDefinition realClass allSuperclasses. > result := OrderedCollection new. > (superClasses select: [ :eachClass | eachClass hasProtocolFor: selector]) > do: [ :eachClass | (eachClass includesSelector: selector) > ifTrue: [ result add: (self whichCategoryIncludesSelector: selector)]]. > ^ result asBag > > stef >

Aug. 11, 2013

Re: [Pharo-dev] adding temporary adds them outside the temp declaration?

by ClÃ©ment Bera

This is in Pharo 3, isn't it ? There are currently bugs with Opal's exception handing in Pharo 3.0. It was fixed then some other changes broke it again. So yeah it is known. You might have bug with: OCShadowVariableWarning. OCUndeclaredVariableWarning. OCUninitializedVariableWarning. OCUnusedVariableWarning. OCUnknownSelectorWarning. 2013/8/11 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Hi guys > > Is it a know bug? > > | selector superClasses | > selector := aMethodDefinition selector. > superClasses := aMethodDefinition realClass allSuperclasses. > result := OrderedCollection new. > (superClasses select: [ :eachClass | eachClass hasProtocolFor: > selector]) > do: [ :eachClass | (eachClass includesSelector: selector) > ifTrue: [ > result add: (self whichCategoryIncludesSelector: selector)]]. > ^ result asBag > > adds result > > result | selector superClasses | > selector := aMethodDefinition selector. > superClasses := aMethodDefinition realClass allSuperclasses. > result := OrderedCollection new. > (superClasses select: [ :eachClass | eachClass hasProtocolFor: > selector]) > do: [ :eachClass | (eachClass includesSelector: selector) > ifTrue: [ > result add: (self whichCategoryIncludesSelector: selector)]]. > ^ result asBag > > stef >

Aug. 11, 2013

adding temporary adds them outside the temp declaration?

by StÃ©phane Ducasse

Hi guys Is it a know bug? | selector superClasses | selector := aMethodDefinition selector. superClasses := aMethodDefinition realClass allSuperclasses. result := OrderedCollection new. (superClasses select: [ :eachClass | eachClass hasProtocolFor: selector]) do: [ :eachClass | (eachClass includesSelector: selector) ifTrue: [ result add: (self whichCategoryIncludesSelector: selector)]]. ^ result asBag adds result result | selector superClasses | selector := aMethodDefinition selector. superClasses := aMethodDefinition realClass allSuperclasses. result := OrderedCollection new. (superClasses select: [ :eachClass | eachClass hasProtocolFor: selector]) do: [ :eachClass | (eachClass includesSelector: selector) ifTrue: [ result add: (self whichCategoryIncludesSelector: selector)]]. ^ result asBag stef

Aug. 11, 2013

latest VM seems stable

by StÃ©phane Ducasse

Hi esteban I did a massive amount of loads (basically loading Moose in Pharo20 all day long) and I used exclusively the latest vm with guille changes on top of latest of Eliot. And I got no smalltinteger problems so far. So this sounds good. Stef

Aug. 11, 2013

Re: [Pharo-dev] Pharo VM latest on the Debian 7

by Andres Valloud

Ok, thank you. At the risk of being too inquisitive, what do you mean when you say "add a slave into our build server"? Is the implication that a release will include N binaries compiled on N Linux versions? On 8/8/13 8:02 , Esteban Lorenzano wrote: > well... no. > something happened with the build, because it should be executable in a 1.5 years old linux. > > in the middle term, we are going to adopt an approach similar to VW (one VM for one image version), and we will support some years of backward compatibility. > But not infinite, of course, because work is too much :) > > Now... the "latest" VM is unstable. Is not a release and of course it will be problems. > > When we release it, it will be version to run in several versions... it should be as simple as add a slave into our build server. > > cheers, > Esteban > > > On Aug 8, 2013, at 4:54 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> On 8 August 2013 15:40, Andres Valloud >> <avalloud(a)smalltalk.comcastbiz.net> wrote: >>> Are you saying the Pharo VM requires glibc version 2.15 of March 2012, and >>> that consequently the Pharo VM as compiled won't run on any Linux distro >>> older than 17 months? >>> >> >> You are not forced to use latest VM, you can always download and use >> 5-year old VM, which will (hopefully) >> work for you. >> :) >> >> Now if platform (linux) moves, we must follow. And that is not a question to me. >> >> -- >> Best regards, >> Igor Stasenko. >> > > . >

Aug. 11, 2013

Re: [Pharo-dev] Understanding Versionner repository selection

by StÃ©phane Ducasse

On Aug 11, 2013, at 6:04 AM, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: > El 10/08/2013 14:55, HernÃ¡n Morales Durand escribiÃ³: >> Hi folks, >> I have a *very* simple package with no dependencies whatsoever. Now I'm >> trying to understand Versionner, these are the steps: >> >> 1. I set the ConfigurationOf name >> 2. I choose I don't want to use squeaksource.com >> <http://squeaksource.com>, ok >> 3. Select a repository... >> >> Now that is not clear for me. Which repository are you talking about? >> the repository where I store MY code, or the repository where I would >> like to publish the configuration so is displayed in the Configuration >> Browser (like the MetaRepoForPharo)? >> > > Ok, I choose the MetaRepoForPharo. The ConfigurationOf class is generated with its methods. I consider myself this package as stable, but there is no generated method for #'stable'. Do I need to create it by hand and then Commit to repository? normally not but I do not know the status of Versioner and christophe is on vacation. > > This is another doubt. Where I should add meta information about my package? I just want to put a little description of what it does. Hi all, I wish I could release a first beta of Versionner before my holidays but I'am a bit short. Nevertheless, you will find an archive on this page http://chercheurs.lille.inria.fr/~demarey/Tech/Versionner containing the current status of Versionner. If you want, you can play a bit with it and give me feedback. There are a lot of missing features but tit will come time after time. >From now you can create a new config, release a dev version, update dependencies. See you in 3 weeks, Christophe.

Aug. 11, 2013

Re: [Pharo-dev] Understanding Versionner repository selection

by HernÃ¡n Morales Durand

El 10/08/2013 14:55, HernÃ¡n Morales Durand escribiÃ³: > Hi folks, > I have a *very* simple package with no dependencies whatsoever. Now I'm > trying to understand Versionner, these are the steps: > > 1. I set the ConfigurationOf name > 2. I choose I don't want to use squeaksource.com > <http://squeaksource.com>, ok > 3. Select a repository... > > Now that is not clear for me. Which repository are you talking about? > the repository where I store MY code, or the repository where I would > like to publish the configuration so is displayed in the Configuration > Browser (like the MetaRepoForPharo)? > Ok, I choose the MetaRepoForPharo. The ConfigurationOf class is generated with its methods. I consider myself this package as stable, but there is no generated method for #'stable'. Do I need to create it by hand and then Commit to repository? This is another doubt. Where I should add meta information about my package? I just want to put a little description of what it does. HernÃ¡n

Aug. 11, 2013

about new class organization

by StÃ©phane Ducasse

Hi esteban/ben I'm trying to understand the new class organisation. Now would it be possible to (beside the backward compatibility part) only use protocol instead of category? Because this is quite confusing to have categories that manipulate Protocol objects. I would like to add some queries hasProtocolFor: aSymbol And may be we should do a pass and add some comments to the methods because I could get what some do but by putting a break point. For example, realCategories ^ self protocolOrganizer protocolsNames So tell me what you think because may be I too tired now. Stef

Aug. 10, 2013

Understanding Versionner repository selection

by HernÃ¡n Morales Durand

Hi folks, I have a *very* simple package with no dependencies whatsoever. Now I'm trying to understand Versionner, these are the steps: 1. I set the ConfigurationOf name 2. I choose I don't want to use squeaksource.com, ok 3. Select a repository... Now that is not clear for me. Which repository are you talking about? the repository where I store MY code, or the repository where I would like to publish the configuration so is displayed in the Configuration Browser (like the MetaRepoForPharo)? Cheers, HernÃ¡n

Aug. 10, 2013

Re: [Pharo-dev] pattern for configuration definition

by Erwan Douaille

2013/8/10 Erwan Douaille <douailleerwan(a)gmail.com> > Maybe it's already existing, but why not create a GUI to create > configurations ? > oops, it's called Versionner :) > It will be more easier and Camillo's pattern will be respected > > When i was dealing with configurations on ci, i've seen many > configurations and no ones was similar. > > Force users/dev to create a correct configuration implementing dev/stable > is needed. Of course, one of the first step of the ci project is testing if > the configuration is correct. Else stop process and throw errors. > > I already have a similar discussion with Camillo :) > > > 2013/8/10 Camillo Bruni <camillobruni(a)gmail.com> > >> Before I get into details, >> >> if you create a new Configuration in Pharo, you will get now a pre-filled >> template with lots of comments. >> >> Summary: >> ======== >> >> - only 1 version for development which is updated manually (typically on >> each new commit) >> - for the DEV version, there is a DEV baseline >> - if a new release happens, the dev version and it's baseline are copied, >> the baseline has the same version number as the first version it was >> introduced with. >> - all external projects in separate methods for readability (plus it's >> easier to change the main repos) >> >> It's not much actually, but basically I treat the configuration as normal >> ST code and avoid duplication :). >> I hope my explanation is not clear enough. >> >> On 2013-08-10, at 04:35, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >> wrote: >> >> > Hi camillo >> > >> > I like the pattern damien told me you are applying for your >> configuration. >> > Could you explain them? >> > I understood: >> > >> > baseline48: spec >> > <version: '4.8-baseline'> >> > >> > spec repository: 'http://www.smalltalkhub.com/mc/Moose/Moose/main'. >> > â¦ >> > spec project: 'Metanool' with: [ >> > spec >> > className: >> 'ConfigurationOfMetanool'; >> > version: #development; >> > file: 'ConfigurationOfMetanool'; >> > repository: ' >> http://www.smalltalkhub.com/mc/Moose/Metanool/main' ]. >> > >> > â¦ >> > >> > => >> > >> > baseline48: spec >> > <version: '4.8-baseline'> >> > >> > spec repository: self repositoryUrlString >> > â¦ >> > spec project: 'Metanool' with: [ >> > spec >> > className: >> 'ConfigurationOfMetanool'; >> > version: #development; >> > file: 'ConfigurationOfMetanool'; >> > repository: ' >> http://www.smalltalkhub.com/mc/Moose/Metanool/main' ]. >> > >> > â¦ >> > >> > repositoryUrlString >> > ^ 'http://www.smalltalkhub.com/mc/Moose/Moose/main'. >> > >> > specMetanoolConfiguration: spec >> > >> > spec >> > className: >> 'ConfigurationOfMetanool'; >> > version: #development; >> > file: 'ConfigurationOfMetanool'; >> > repository: ' >> http://www.smalltalkhub.com/mc/Moose/Metanool/main' >> > >> > >> > >> > >> > I like the idea to avoid duplication at the configuration level. >> > Now damien mention a dev and stable baseline >> > >> > Stef >> > >> > >> > >> >> >> > > > -- > Best regards, > > Douaille Erwan <douaille.erwan(a)gmail.com> > -- Best regards, Douaille Erwan <douaille.erwan(a)gmail.com>

Aug. 10, 2013

Re: [Pharo-dev] pattern for configuration definition

by Erwan Douaille

Maybe it's already existing, but why not create a GUI to create configurations ? It will be more easier and Camillo's pattern will be respected When i was dealing with configurations on ci, i've seen many configurations and no ones was similar. Force users/dev to create a correct configuration implementing dev/stable is needed. Of course, one of the first step of the ci project is testing if the configuration is correct. Else stop process and throw errors. I already have a similar discussion with Camillo :) 2013/8/10 Camillo Bruni <camillobruni(a)gmail.com> > Before I get into details, > > if you create a new Configuration in Pharo, you will get now a pre-filled > template with lots of comments. > > Summary: > ======== > > - only 1 version for development which is updated manually (typically on > each new commit) > - for the DEV version, there is a DEV baseline > - if a new release happens, the dev version and it's baseline are copied, > the baseline has the same version number as the first version it was > introduced with. > - all external projects in separate methods for readability (plus it's > easier to change the main repos) > > It's not much actually, but basically I treat the configuration as normal > ST code and avoid duplication :). > I hope my explanation is not clear enough. > > On 2013-08-10, at 04:35, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > wrote: > > > Hi camillo > > > > I like the pattern damien told me you are applying for your > configuration. > > Could you explain them? > > I understood: > > > > baseline48: spec > > <version: '4.8-baseline'> > > > > spec repository: 'http://www.smalltalkhub.com/mc/Moose/Moose/main'. > > â¦ > > spec project: 'Metanool' with: [ > > spec > > className: > 'ConfigurationOfMetanool'; > > version: #development; > > file: 'ConfigurationOfMetanool'; > > repository: ' > http://www.smalltalkhub.com/mc/Moose/Metanool/main' ]. > > > > â¦ > > > > => > > > > baseline48: spec > > <version: '4.8-baseline'> > > > > spec repository: self repositoryUrlString > > â¦ > > spec project: 'Metanool' with: [ > > spec > > className: > 'ConfigurationOfMetanool'; > > version: #development; > > file: 'ConfigurationOfMetanool'; > > repository: ' > http://www.smalltalkhub.com/mc/Moose/Metanool/main' ]. > > > > â¦ > > > > repositoryUrlString > > ^ 'http://www.smalltalkhub.com/mc/Moose/Moose/main'. > > > > specMetanoolConfiguration: spec > > > > spec > > className: > 'ConfigurationOfMetanool'; > > version: #development; > > file: 'ConfigurationOfMetanool'; > > repository: ' > http://www.smalltalkhub.com/mc/Moose/Metanool/main' > > > > > > > > > > I like the idea to avoid duplication at the configuration level. > > Now damien mention a dev and stable baseline > > > > Stef > > > > > > > > > -- Best regards, Douaille Erwan <douaille.erwan(a)gmail.com>

Aug. 10, 2013

Re: [Pharo-dev] pattern for configuration definition

by Camillo Bruni

Before I get into details, if you create a new Configuration in Pharo, you will get now a pre-filled template with lots of comments. Summary: ======== - only 1 version for development which is updated manually (typically on each new commit) - for the DEV version, there is a DEV baseline - if a new release happens, the dev version and it's baseline are copied, the baseline has the same version number as the first version it was introduced with. - all external projects in separate methods for readability (plus it's easier to change the main repos) It's not much actually, but basically I treat the configuration as normal ST code and avoid duplication :). I hope my explanation is not clear enough. On 2013-08-10, at 04:35, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi camillo > > I like the pattern damien told me you are applying for your configuration. > Could you explain them? > I understood: > > baseline48: spec > <version: '4.8-baseline'> > > spec repository: 'http://www.smalltalkhub.com/mc/Moose/Moose/main'. > â¦ > spec project: 'Metanool' with: [ > spec > className: 'ConfigurationOfMetanool'; > version: #development; > file: 'ConfigurationOfMetanool'; > repository: 'http://www.smalltalkhub.com/mc/Moose/Metanool/main' ]. > > â¦ > > => > > baseline48: spec > <version: '4.8-baseline'> > > spec repository: self repositoryUrlString > â¦ > spec project: 'Metanool' with: [ > spec > className: 'ConfigurationOfMetanool'; > version: #development; > file: 'ConfigurationOfMetanool'; > repository: 'http://www.smalltalkhub.com/mc/Moose/Metanool/main' ]. > > â¦ > > repositoryUrlString > ^ 'http://www.smalltalkhub.com/mc/Moose/Moose/main'. > > specMetanoolConfiguration: spec > > spec > className: 'ConfigurationOfMetanool'; > version: #development; > file: 'ConfigurationOfMetanool'; > repository: 'http://www.smalltalkhub.com/mc/Moose/Metanool/main' > > > > > I like the idea to avoid duplication at the configuration level. > Now damien mention a dev and stable baseline > > Stef > > >

Aug. 10, 2013

Re: [Pharo-dev] Put issues from cog issue tracker into pharo issue tracker

by Camillo Bruni

Nicolas Cellier, Are you willing to report and maintain VM bugs on the fogbugz issue tracker? Since you already filed reports on pharo.fogbugz.com I think this is not much of a change. thank you. On 2013-08-09, at 09:33, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 9 August 2013 13:28, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> thanks, perfect! >> >> that's very nice, now we have everything in one place. >> Nobody besides Pharo guys touched this issue tracker anyway :) >> > if that would be true, i wouldn't say anything.. > > The truth is that pharo team is most active on it.. yes. But does that > give us right to decide > what to do with it? > > > -- > Best regards, > Igor Stasenko. > <Screen Shot 2013-08-09 at 2.31.15 PM.png>

Aug. 10, 2013

pattern for configuration definition

by StÃ©phane Ducasse

Hi camillo I like the pattern damien told me you are applying for your configuration. Could you explain them? I understood: baseline48: spec <version: '4.8-baseline'> spec repository: 'http://www.smalltalkhub.com/mc/Moose/Moose/main'. â¦ spec project: 'Metanool' with: [ spec className: 'ConfigurationOfMetanool'; version: #development; file: 'ConfigurationOfMetanool'; repository: 'http://www.smalltalkhub.com/mc/Moose/Metanool/main' ]. â¦ => baseline48: spec <version: '4.8-baseline'> spec repository: self repositoryUrlString â¦ spec project: 'Metanool' with: [ spec className: 'ConfigurationOfMetanool'; version: #development; file: 'ConfigurationOfMetanool'; repository: 'http://www.smalltalkhub.com/mc/Moose/Metanool/main' ]. â¦ repositoryUrlString ^ 'http://www.smalltalkhub.com/mc/Moose/Moose/main'. specMetanoolConfiguration: spec spec className: 'ConfigurationOfMetanool'; version: #development; file: 'ConfigurationOfMetanool'; repository: 'http://www.smalltalkhub.com/mc/Moose/Metanool/main' I like the idea to avoid duplication at the configuration level. Now damien mention a dev and stable baseline Stef

Aug. 10, 2013

Re: [Pharo-dev] Keyboard events is broken.

by StÃ©phane Ducasse

I will retry and be careful about which vm I use because I had around 3/4 images open to tests snapshotcello. So I may have open it with the old one. Stef > yes, this latest vm should have the problem solved > > On Aug 9, 2013, at 6:02 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> >> On Aug 7, 2013, at 7:06 PM, StÃ©phane Ducasse <Stephane.Ducasse(a)inria.fr> wrote: >> >>> >>> On Aug 7, 2013, at 5:59 PM, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: >>> >>>> now can we get a working keyboard? >>> Yes here >>> >>> Hi, >>> >>> Guille built a new vm with an attept of fixing the key combinations problem. >>> Can you test it? >>> >>> http://files.pharo.org/vm/pharo/ >>> >>> (and pick the latest for your platform) >>> >>> Thanks, >>> Esteban >>> >> Esteban did this vm get the fix for SmallInteger? >> Because in the latest moose image >> >> (ConfigurationOfMoose project version: #development) record >> led to problem >> >> Stef >> >

Aug. 9, 2013

Re: [Pharo-dev] Consequence of NBExternalStructure refactorings

by StÃ©phane Ducasse

>> >>> well if the bug entry is not tag as ready to include the chance to get it loaded is really low. >>> If people do not pay attention to basics like thatâ¦.We will not make progress. >>> >> it is not ready yet because it is not ready. i will tag it when it will. >> > i meant not *tagged* ready on purpose. ok :)

Aug. 9, 2013

Re: [Pharo-dev] Keyboard events is broken.

by Esteban Lorenzano

yes, this latest vm should have the problem solved On Aug 9, 2013, at 6:02 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Aug 7, 2013, at 7:06 PM, StÃ©phane Ducasse <Stephane.Ducasse(a)inria.fr> wrote: > >> >> On Aug 7, 2013, at 5:59 PM, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: >> >>> now can we get a working keyboard? >> Yes here >> >> Hi, >> >> Guille built a new vm with an attept of fixing the key combinations problem. >> Can you test it? >> >> http://files.pharo.org/vm/pharo/ >> >> (and pick the latest for your platform) >> >> Thanks, >> Esteban >> > Esteban did this vm get the fix for SmallInteger? > Because in the latest moose image > > (ConfigurationOfMoose project version: #development) record > led to problem > > Stef >

Aug. 9, 2013

Re: [Pharo-dev] Consequence of NBExternalStructure refactorings

by Igor Stasenko

On 9 August 2013 18:04, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 9 August 2013 17:49, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> well if the bug entry is not tag as ready to include the chance to get it loaded is really low. >> If people do not pay attention to basics like thatâ¦.We will not make progress. >> > it is not ready yet because it is not ready. i will tag it when it will. > i meant not *tagged* ready on purpose. >> Stef >> >> On Aug 9, 2013, at 5:18 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >>> Hello, >>> >>> lately we changed the object format of subject class from variableByte >>> to normal one. >>> >>> All projects which using NBExternalStructure can meet certain problems with it, >>> and first which comes is that it may load code cleanly but in fact >>> result in bogus >>> variable subclasses of NBExternalStructure , while it can't because >>> superclass has instance variable. >>> (i suspecting classbuilder bug, but need to verify first). >>> >>> To address that, you need to manually go over all subclasses and double-check. >>> >>> Another thing: since now instances NBExternalStructure can also point >>> to external memory, >>> special care should be taken for #copying. >>> Sending #copy to instance which uses external memory, will create a >>> copy on object memory >>> (and copy all data from external memory into it). This is same >>> behavior as in NBExternalArray. >>> >>> - there is a bugs in #initialize and #postCopy (fixed but not intergated yet) >>> https://pharo.fogbugz.com/default.asp?11395#83020 >>> will do that in nearest time. >>> >>> also note, that in callouts, you cannot pass an instance of >>> NBExternalStructure anymore >>> to function, which uses raw pointer (like void*) anymore. >>> >>> For passing a pointer to structure data for callouts, use >>> myStructure address >>> idiom (or use right struct type, which is preferable). >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> >> > > > > -- > Best regards, > Igor Stasenko. -- Best regards, Igor Stasenko.

Aug. 9, 2013

Re: [Pharo-dev] Consequence of NBExternalStructure refactorings

by Igor Stasenko

On 9 August 2013 17:49, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > well if the bug entry is not tag as ready to include the chance to get it loaded is really low. > If people do not pay attention to basics like thatâ¦.We will not make progress. > it is not ready yet because it is not ready. i will tag it when it will. > Stef > > On Aug 9, 2013, at 5:18 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> Hello, >> >> lately we changed the object format of subject class from variableByte >> to normal one. >> >> All projects which using NBExternalStructure can meet certain problems with it, >> and first which comes is that it may load code cleanly but in fact >> result in bogus >> variable subclasses of NBExternalStructure , while it can't because >> superclass has instance variable. >> (i suspecting classbuilder bug, but need to verify first). >> >> To address that, you need to manually go over all subclasses and double-check. >> >> Another thing: since now instances NBExternalStructure can also point >> to external memory, >> special care should be taken for #copying. >> Sending #copy to instance which uses external memory, will create a >> copy on object memory >> (and copy all data from external memory into it). This is same >> behavior as in NBExternalArray. >> >> - there is a bugs in #initialize and #postCopy (fixed but not intergated yet) >> https://pharo.fogbugz.com/default.asp?11395#83020 >> will do that in nearest time. >> >> also note, that in callouts, you cannot pass an instance of >> NBExternalStructure anymore >> to function, which uses raw pointer (like void*) anymore. >> >> For passing a pointer to structure data for callouts, use >> myStructure address >> idiom (or use right struct type, which is preferable). >> >> -- >> Best regards, >> Igor Stasenko. >> > > -- Best regards, Igor Stasenko.

Aug. 9, 2013

Re: [Pharo-dev] Keyboard events is broken.

by StÃ©phane Ducasse

On Aug 7, 2013, at 7:06 PM, StÃ©phane Ducasse <Stephane.Ducasse(a)inria.fr> wrote: > > On Aug 7, 2013, at 5:59 PM, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: > >> now can we get a working keyboard? > Yes here > > Hi, > > Guille built a new vm with an attept of fixing the key combinations problem. > Can you test it? > > http://files.pharo.org/vm/pharo/ > > (and pick the latest for your platform) > > Thanks, > Esteban > Esteban did this vm get the fix for SmallInteger? Because in the latest moose image (ConfigurationOfMoose project version: #development) record led to problem Stef

Aug. 9, 2013

Re: [Pharo-dev] Consequence of NBExternalStructure refactorings

by StÃ©phane Ducasse

well if the bug entry is not tag as ready to include the chance to get it loaded is really low. If people do not pay attention to basics like thatâ¦.We will not make progress. Stef On Aug 9, 2013, at 5:18 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > Hello, > > lately we changed the object format of subject class from variableByte > to normal one. > > All projects which using NBExternalStructure can meet certain problems with it, > and first which comes is that it may load code cleanly but in fact > result in bogus > variable subclasses of NBExternalStructure , while it can't because > superclass has instance variable. > (i suspecting classbuilder bug, but need to verify first). > > To address that, you need to manually go over all subclasses and double-check. > > Another thing: since now instances NBExternalStructure can also point > to external memory, > special care should be taken for #copying. > Sending #copy to instance which uses external memory, will create a > copy on object memory > (and copy all data from external memory into it). This is same > behavior as in NBExternalArray. > > - there is a bugs in #initialize and #postCopy (fixed but not intergated yet) > https://pharo.fogbugz.com/default.asp?11395#83020 > will do that in nearest time. > > also note, that in callouts, you cannot pass an instance of > NBExternalStructure anymore > to function, which uses raw pointer (like void*) anymore. > > For passing a pointer to structure data for callouts, use > myStructure address > idiom (or use right struct type, which is preferable). > > -- > Best regards, > Igor Stasenko. >

Aug. 9, 2013

Re: [Pharo-dev] Fwd: Consequence of NBExternalStructure refactorings

by Martin Dias

On Fri, Aug 9, 2013 at 5:18 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > Hello, > > lately we changed the object format of subject class from variableByte > to normal one. > > All projects which using NBExternalStructure can meet certain problems > with it, > and first which comes is that it may load code cleanly but in fact > result in bogus > variable subclasses of NBExternalStructure , while it can't because > superclass has instance variable. > > (i suspecting classbuilder bug, but need to verify first). > I can help with classbuilder if you confirm the bug cheers, MartÃn

Aug. 9, 2013

Fwd: Consequence of NBExternalStructure refactorings

by Igor Stasenko

Hello, lately we changed the object format of subject class from variableByte to normal one. All projects which using NBExternalStructure can meet certain problems with it, and first which comes is that it may load code cleanly but in fact result in bogus variable subclasses of NBExternalStructure , while it can't because superclass has instance variable. (i suspecting classbuilder bug, but need to verify first). To address that, you need to manually go over all subclasses and double-check. Another thing: since now instances NBExternalStructure can also point to external memory, special care should be taken for #copying. Sending #copy to instance which uses external memory, will create a copy on object memory (and copy all data from external memory into it). This is same behavior as in NBExternalArray. - there is a bugs in #initialize and #postCopy (fixed but not intergated yet) https://pharo.fogbugz.com/default.asp?11395#83020 will do that in nearest time. also note, that in callouts, you cannot pass an instance of NBExternalStructure anymore to function, which uses raw pointer (like void*) anymore. For passing a pointer to structure data for callouts, use myStructure address idiom (or use right struct type, which is preferable). -- Best regards, Igor Stasenko.

Aug. 9, 2013

[update 3.0] #30329

by Esteban Lorenzano

Aug. 9, 2013

Re: [Pharo-dev] Mariano & Behavior>>methodDict

by Nicolas Cellier

+my own 2 cents on this one 2013/8/9 Igor Stasenko <siguctua(a)gmail.com> > my 2 cents. > the method should be like that: > > Behavior>>methodDict > ^ methodDict > > the tools should be aware that it is low-level accessor and result can be > nil. > Or use higher-level accessors provided by Class api (like #selectors > etc) to avoid hacky coding. > > On 9 August 2013 14:33, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > Hello Mariano and others, > > > > In Pharo there is a method: > > > > Behavior>>methodDict > > methodDict == nil ifTrue: [^ MethodDictionary new ]. > > ^ methodDict > > > > It seems (according to the latest author) that it is Mariano who changed > it > > from: > > > > Behavior>>methodDict > > methodDict == nil ifTrue: [self error: 'MethodDict is nil']. > > ^ methodDict > > > > A comment is present: > > > > "The method dictionary of a class can be nil when we want to use > the > > #cannotInterpret: hook. Indeed when a class dictionary is nil, the VM > sends > > the message cannotInterpret: to the receiver but starting the look up in > the > > superclass of the class whose method dictionary was nil. > > Now the system relies that when the message methodDict is sent to a > class a > > method dictionary is returned. In order to prevent the complaints of > tools > > and IDE unaware of this feature, we fool them by providing an empty > > MethodDictionary. This will hopefully work in most cases, but the tools > will > > loose the ability to modify the behavior of this behavior. The user of > > #cannotInterpret: should be aware of this." > > > > Now my problem is when I do: > > > > MyClass methodDict: nil. > > MyClass new name. > > > > It crashes the image in latest Pharo 3. > > > > Mariano, do you have an idea on how to fix it ? I ask you because you are > > the latest author and it seems tat the bug comes from this method. > > > > Thanks for any answer. > > > > -- > Best regards, > Igor Stasenko. > >

Aug. 9, 2013

Re: [Pharo-dev] Mariano & Behavior>>methodDict

by Igor Stasenko

my 2 cents. the method should be like that: Behavior>>methodDict ^ methodDict the tools should be aware that it is low-level accessor and result can be nil. Or use higher-level accessors provided by Class api (like #selectors etc) to avoid hacky coding. On 9 August 2013 14:33, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > Hello Mariano and others, > > In Pharo there is a method: > > Behavior>>methodDict > methodDict == nil ifTrue: [^ MethodDictionary new ]. > ^ methodDict > > It seems (according to the latest author) that it is Mariano who changed it > from: > > Behavior>>methodDict > methodDict == nil ifTrue: [self error: 'MethodDict is nil']. > ^ methodDict > > A comment is present: > > "The method dictionary of a class can be nil when we want to use the > #cannotInterpret: hook. Indeed when a class dictionary is nil, the VM sends > the message cannotInterpret: to the receiver but starting the look up in the > superclass of the class whose method dictionary was nil. > Now the system relies that when the message methodDict is sent to a class a > method dictionary is returned. In order to prevent the complaints of tools > and IDE unaware of this feature, we fool them by providing an empty > MethodDictionary. This will hopefully work in most cases, but the tools will > loose the ability to modify the behavior of this behavior. The user of > #cannotInterpret: should be aware of this." > > Now my problem is when I do: > > MyClass methodDict: nil. > MyClass new name. > > It crashes the image in latest Pharo 3. > > Mariano, do you have an idea on how to fix it ? I ask you because you are > the latest author and it seems tat the bug comes from this method. > > Thanks for any answer. -- Best regards, Igor Stasenko.

Aug. 9, 2013

Mariano & Behavior>>methodDict

by ClÃ©ment Bera

Hello Mariano and others, In Pharo there is a method: Behavior>>methodDict methodDict == nil ifTrue: [^ MethodDictionary new ]. ^ methodDict It seems (according to the latest author) that it is Mariano who changed it from: Behavior>>methodDict methodDict == nil ifTrue: [self error: 'MethodDict is nil']. ^ methodDict A comment is present: "The method dictionary of a class can be nil when we want to use the #cannotInterpret: hook. Indeed when a class dictionary is nil, the VM sends the message cannotInterpret: to the receiver but starting the look up in the superclass of the class whose method dictionary was nil. Now the system relies that when the message methodDict is sent to a class a method dictionary is returned. In order to prevent the complaints of tools and IDE unaware of this feature, we fool them by providing an empty MethodDictionary. This will hopefully work in most cases, but the tools will loose the ability to modify the behavior of this behavior. The user of #cannotInterpret: should be aware of this." Now my problem is when I do: MyClass methodDict: nil. MyClass new name. It crashes the image in latest Pharo 3. Mariano, do you have an idea on how to fix it ? I ask you because you are the latest author and it seems tat the bug comes from this method. Thanks for any answer.

Aug. 9, 2013

Re: [Pharo-dev] Put issues from cog issue tracker into pharo issue tracker

by Igor Stasenko

On 9 August 2013 13:28, Camillo Bruni <camillobruni(a)gmail.com> wrote: > thanks, perfect! > > that's very nice, now we have everything in one place. > Nobody besides Pharo guys touched this issue tracker anyway :) > if that would be true, i wouldn't say anything.. The truth is that pharo team is most active on it.. yes. But does that give us right to decide what to do with it? -- Best regards, Igor Stasenko.

Aug. 9, 2013

Re: [Pharo-dev] Put issues from cog issue tracker into pharo issue tracker

by Camillo Bruni

thanks, perfect! that's very nice, now we have everything in one place. Nobody besides Pharo guys touched this issue tracker anyway :) On 2013-08-07, at 12:56, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > https://pharo.fogbugz.com/default.asp?pre=preSaveFilterProject&ixProject=6 > > They are under the Pharo-VM project. > > That way we can handle them easily. > > Guille

Aug. 9, 2013

Re: [Pharo-dev] Put issues from cog issue tracker into pharo issue tracker

by Igor Stasenko

I must admit, that even despite that most of us grinding teeth when using it, it is quite good and people using it a lot. And service quality is also impressive: i don't remember we had any downtime, system errors or any other outages since started using it. -- Best regards, Igor Stasenko.

Aug. 9, 2013