- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] 6.1 Iceberg - how is this supposed to work?

by Todd Blanchard

And how do I do this? I can fetch the repo from the command line Sent from the road > On Nov 12, 2017, at 05:51, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > >> On 11 Nov 2017, at 17:43, Todd Blanchard <tblanchard(a)mac.com> wrote: >> >> >> "No ssh-agent suitable credentials found". Why? Its a public repository. > > because you are using an SSH protocol, regardless itâs public state. You need to identify yourself so the handshake can happen. > > Esteban

Nov. 12, 2017

Re: [Pharo-dev] feenk log

by Denis Kudriashov

2017-11-12 16:10 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>: > > > On Nov 12, 2017, at 4:00 PM, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > > > > 2017-11-11 22:39 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>: > > Hi Denis, > > > > It is not a global function. > > > > It is a class-side method because it relies on the following logic: > > - if the element is attached to a space, it uses that space to dispatch > the event. > > - otherwise, it creates a temporary space and uses that one. > > > > The use case for such simulators is needed in the case of overlapping > elements. In most cases, such as in a grid layout, the elements do not > overlap, so clicking on the position occupied by an element will always > lead to a high level click event dispatched to that element. However, when > we have overlapping elements, clicking on the position of an element might > end up dispatched to another element. In fact, we introduced this testing > ability exactly to write a red test involving overlapping elements. > > > > Ok. Thank's for explanation. > > But still when I see such class side methods I have some bad feeling. > > Do you see another solution in this case? > Sean suggest to ask element for this: element simulateClick But Alex explained why it is done differently. Maybe simulation logic can be extracted to another object. So it can be like: element simulate click where #simulate returns simulator which incapsulates decision what space should be used. It can be even two kind of simulators: existing space simulator and temp space simulator. Also with this approach BlSpace class will be not polluted by all kind of event simulations. >From the other side I don't know the internals. So I can imaging that current solution is more suitable for now. > Doru > > > > > Cheers, > > Doru > > > > > > > On Nov 11, 2017, at 11:35 AM, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > > > > > > Hi Aliaksei > > > > > > 2017-11-10 22:36 GMT+01:00 Aliaksei Syrel <alex.syrel(a)gmail.com>: > > > Hi Sean, > > > > > > Why not `anElement simulateClick`? > > > > > > Good question :) > > > We indeed evaluated a possibility to have (BlElement >> > #simulateClick) but then decided to make BlSpace class to be responsible > for that. > > > > > > First we should realise that when we simulate a click we do literally > simulate user's action which is: mouseDown at some global coordinate in > space and then mouseUp. A process of handing mouse down/up events involves > some complex event processing in order to detect what should happen, for > example, with currently focused element or if we need to send double-click > event. It is a mouse processor who is responsible for all these actions and > it belongs to Space (inst. var in space). Not to mention some weird cases > of overlapped elements, elements with custom elevation (zIndex), custom > mouseDown/up event listeners that do some work too... > > > That is why it is definitely not enough just to send a plain > BlClickEvent directly to the element. Instead, we should involve a space in > the process and actually simulate it by pushing mouseDown and mouseUp > events to the event queue. > > > > > > Next what we realised it the fact that it is not nice to always create > a temporary space and add our element to it in order to simulate a click. > What if an element is already added to the space, what if not? > > > To wrap up, we decided that it should be a responsibility of the Space > class to create a new temporary instance of itself, add an element to it, > simulate click event and then delete itself. In order to show the intent > and a process behind we decided that it would be a good idea to actually > write a code like this: > > > > > > BlSpace simulateClickOn: element. > > > > > > It looks like global function. According to your description I would > expect: > > > aSpace simulateClickOn: element > > > > > > I imaging tests where I create internal space instance, open > application in it and simulate events to check expected behaviour. But > maybe you will explain that it should be done differently? > > > And what is actual use case for such simulations if we can just > #fireEvent: as you wrote below? > > > > > > > > > In english it is quite nice: > > > > > > "dear space class, could you, please, simulate a click event on a > given element?" It is a space who simulates event, not an element. > > > > > > P.S. Users can still send a BlClickEvent directly (informs 'click'): > > > > > > element := BlElement new. > > > element addEventHandlerOn: BlClickEvent do: [ self inform: 'click' ]. > > > element fireEvent: BlClickEvent new > > > > > > Cheers, > > > Alex > > > > > > On 10 November 2017 at 21:22, Sean P. DeNigris <sean(a)clipperadams.com> > wrote: > > > Tudor Girba-2 wrote > > > > - support for programatic testing of bloc mouse events: > > > > https://twitter.com/feenkcom/status/925672206763511808 > > > > > > Why not `anElement simulateClick`? > > > > > > > > > > > > ----- > > > Cheers, > > > Sean > > > -- > > > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837. > html > > > > -- > > www.tudorgirba.com > > www.feenk.com > > > > "Obvious things are difficult to teach." > > > > > > > > > > > > > > -- > www.tudorgirba.com > www.feenk.com > > "Be rather willing to give than demanding to get." > > > > > >

Nov. 12, 2017

Re: [Pharo-dev] Tonel and class definition changes

by Esteban Lorenzano

> On 12 Nov 2017, at 12:07, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > Thank's Esteban. > > Originally I thought that Tonel will be only Pharo format. And in that case I was wondering why it uses old names which will need support in future. hehâ¦ you know this thing about changing paradigms from Kuhn? As architect, I always apply the rule for everything: - for one thing to replace another, the new one has to provide an advantage over the old one (we cannot replace it just because). - but people forgets the second rule it needs to follow, which is IMO the most relevant: for one thing to replace another, it needs not just to have an advantage, but it has to ALSO solve all the problems the previous one solved. So. We want to change filetree with tonel. Then we need have an advantage (we have it). But then Tonel also has to solve all the problems filetree did. And portability is one of them :) Esteban > But for other Smalltalks it is clear: we will need support it anyway. > > 2017-11-11 12:39 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: > > >> On 11 Nov 2017, at 07:48, Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>> wrote: >> >> Hi. >> I extracted my question from previous thread about encoding issue in Tonel. >> >> 2017-11-10 18:08 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: >> On 10 Nov 2017, at 13:05, Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>> wrote: >>> 2017-11-10 16:30 GMT+01:00 Martin McClure <martin(a)hand2mouse.com <mailto:martin@hand2mouse.com>>: >>> Tonel is intended to be, I believe: >>> * For Smalltalk primarily (although there are other languages) >>> * Be for any Smalltalk dialect (although the first implementation is for Pharo, it is being ported to GemStone, and we intend to port it to VW and VA) >>> >>> Interesting how it will be handled when Pharo will use slots abstraction exclusively. And more simple, when there will be only package and tags instead of class categories. >>> >>> To be more clear. Imaging that instead of #instanceVariables field Pharo will use #slots. And instead of #category it will be #package and #tags >> >> what does it has to do with this thread? >> >> My question was related to the sentence that Tonel is intended to be for any Smalltalk dialect. If Pharo will use #slots, #package and #tags names in class definition format it will be not compatible to other smalltalks. > > we will use #slots and other implementations will use #instVars > > platforms will need to translate themâ¦ for example, we will be able to interpret instVars as simple slots and categories as packages, they can do the same (it can be more complicated for slots, but at the end, is also doable) > > tonel is a portable cross dialect format, but that does not means that what is saved for pharo is immediately loadable in other platforms and viceversa. When working for compatibility, framework designers takes the differences into account: they do not use traits and sometimes they need a compatibility layer (Seaside, Iâm watching you). With slots they will need to do the same, and most probably they will not use them, sadly. > > >> >> handling that is trivial: once we actually have slots (bah, we have them, but once we *use* them) and once we move to package+tags, we just adapt the descriptions. Thatâs the advantage of using STON to keep them. >> >> And what will happen then? We will again regenerate all sources/history? >> When we will switch to new names every class will be modified in following commit. > > or incremental (while working). > I still do not decide how to proceed since is a problem we still do not have. > I have plenty of things I need to decide right now, I can wait a bit for this one :) > > Esteban >> > >

Nov. 12, 2017

Re: [Pharo-dev] feenk log

by Tudor Girba

> On Nov 12, 2017, at 4:00 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > 2017-11-11 22:39 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi Denis, > > It is not a global function. > > It is a class-side method because it relies on the following logic: > - if the element is attached to a space, it uses that space to dispatch the event. > - otherwise, it creates a temporary space and uses that one. > > The use case for such simulators is needed in the case of overlapping elements. In most cases, such as in a grid layout, the elements do not overlap, so clicking on the position occupied by an element will always lead to a high level click event dispatched to that element. However, when we have overlapping elements, clicking on the position of an element might end up dispatched to another element. In fact, we introduced this testing ability exactly to write a red test involving overlapping elements. > > Ok. Thank's for explanation. > But still when I see such class side methods I have some bad feeling. Do you see another solution in this case? Doru > > Cheers, > Doru > > > > On Nov 11, 2017, at 11:35 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > > Hi Aliaksei > > > > 2017-11-10 22:36 GMT+01:00 Aliaksei Syrel <alex.syrel(a)gmail.com>: > > Hi Sean, > > > > Why not `anElement simulateClick`? > > > > Good question :) > > We indeed evaluated a possibility to have (BlElement >> #simulateClick) but then decided to make BlSpace class to be responsible for that. > > > > First we should realise that when we simulate a click we do literally simulate user's action which is: mouseDown at some global coordinate in space and then mouseUp. A process of handing mouse down/up events involves some complex event processing in order to detect what should happen, for example, with currently focused element or if we need to send double-click event. It is a mouse processor who is responsible for all these actions and it belongs to Space (inst. var in space). Not to mention some weird cases of overlapped elements, elements with custom elevation (zIndex), custom mouseDown/up event listeners that do some work too... > > That is why it is definitely not enough just to send a plain BlClickEvent directly to the element. Instead, we should involve a space in the process and actually simulate it by pushing mouseDown and mouseUp events to the event queue. > > > > Next what we realised it the fact that it is not nice to always create a temporary space and add our element to it in order to simulate a click. What if an element is already added to the space, what if not? > > To wrap up, we decided that it should be a responsibility of the Space class to create a new temporary instance of itself, add an element to it, simulate click event and then delete itself. In order to show the intent and a process behind we decided that it would be a good idea to actually write a code like this: > > > > BlSpace simulateClickOn: element. > > > > It looks like global function. According to your description I would expect: > > aSpace simulateClickOn: element > > > > I imaging tests where I create internal space instance, open application in it and simulate events to check expected behaviour. But maybe you will explain that it should be done differently? > > And what is actual use case for such simulations if we can just #fireEvent: as you wrote below? > > > > > > In english it is quite nice: > > > > "dear space class, could you, please, simulate a click event on a given element?" It is a space who simulates event, not an element. > > > > P.S. Users can still send a BlClickEvent directly (informs 'click'): > > > > element := BlElement new. > > element addEventHandlerOn: BlClickEvent do: [ self inform: 'click' ]. > > element fireEvent: BlClickEvent new > > > > Cheers, > > Alex > > > > On 10 November 2017 at 21:22, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Tudor Girba-2 wrote > > > - support for programatic testing of bloc mouse events: > > > https://twitter.com/feenkcom/status/925672206763511808 > > > > Why not `anElement simulateClick`? > > > > > > > > ----- > > Cheers, > > Sean > > -- > > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > > -- > www.tudorgirba.com > www.feenk.com > > "Obvious things are difficult to teach." > > > > > > -- www.tudorgirba.com www.feenk.com "Be rather willing to give than demanding to get."

Nov. 12, 2017

Re: [Pharo-dev] Tonel and class definition changes

by Denis Kudriashov

Thank's Esteban. Originally I thought that Tonel will be only Pharo format. And in that case I was wondering why it uses old names which will need support in future. But for other Smalltalks it is clear: we will need support it anyway. 2017-11-11 12:39 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > > > On 11 Nov 2017, at 07:48, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > Hi. > I extracted my question from previous thread about encoding issue in Tonel. > > 2017-11-10 18:08 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > >> On 10 Nov 2017, at 13:05, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >> >> 2017-11-10 16:30 GMT+01:00 Martin McClure <martin(a)hand2mouse.com>: >>>> >>>> Tonel is intended to be, I believe: >>>> * For Smalltalk primarily (although there are other languages) >>>> * Be for any Smalltalk dialect (although the first implementation is >>>> for Pharo, it is being ported to GemStone, and we intend to port it to VW >>>> and VA) >>>> >>> >>> Interesting how it will be handled when Pharo will use slots abstraction >>> exclusively. And more simple, when there will be only package and tags >>> instead of class categories. >>> >> >> To be more clear. Imaging that instead of #instanceVariables field Pharo >> will use #slots. And instead of #category it will be #package and #tags >> >> >> what does it has to do with this thread? >> > > My question was related to the sentence that Tonel is intended to be for > any Smalltalk dialect. If Pharo will use #slots, #package and #tags names > in class definition format it will be not compatible to other smalltalks. > > > we will use #slots and other implementations will use #instVars > > platforms will need to translate themâ¦ for example, we will be able to > interpret instVars as simple slots and categories as packages, they can do > the same (it can be more complicated for slots, but at the end, is also > doable) > > tonel is a portable cross dialect format, but that does not means that > what is saved for pharo is immediately loadable in other platforms and > viceversa. When working for compatibility, framework designers takes the > differences into account: they do not use traits and sometimes they need a > compatibility layer (Seaside, Iâm watching you). With slots they will need > to do the same, and most probably they will not use them, sadly. > > > > >> handling that is trivial: once we actually have slots (bah, we have them, >> but once we *use* them) and once we move to package+tags, we just adapt the >> descriptions. Thatâs the advantage of using STON to keep them. >> > > And what will happen then? We will again regenerate all sources/history? > When we will switch to new names every class will be modified in following > commit. > > > or incremental (while working). > I still do not decide how to proceed since is a problem we still do not > have. > I have plenty of things I need to decide right now, I can wait a bit for > this one :) > > Esteban > > > >

Nov. 12, 2017

Re: [Pharo-dev] feenk log

by Denis Kudriashov

2017-11-11 22:39 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi Denis, > > It is not a global function. > > It is a class-side method because it relies on the following logic: > - if the element is attached to a space, it uses that space to dispatch > the event. > - otherwise, it creates a temporary space and uses that one. > > The use case for such simulators is needed in the case of overlapping > elements. In most cases, such as in a grid layout, the elements do not > overlap, so clicking on the position occupied by an element will always > lead to a high level click event dispatched to that element. However, when > we have overlapping elements, clicking on the position of an element might > end up dispatched to another element. In fact, we introduced this testing > ability exactly to write a red test involving overlapping elements. > Ok. Thank's for explanation. But still when I see such class side methods I have some bad feeling. > > Cheers, > Doru > > > > On Nov 11, 2017, at 11:35 AM, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > > > > Hi Aliaksei > > > > 2017-11-10 22:36 GMT+01:00 Aliaksei Syrel <alex.syrel(a)gmail.com>: > > Hi Sean, > > > > Why not `anElement simulateClick`? > > > > Good question :) > > We indeed evaluated a possibility to have (BlElement >> #simulateClick) > but then decided to make BlSpace class to be responsible for that. > > > > First we should realise that when we simulate a click we do literally > simulate user's action which is: mouseDown at some global coordinate in > space and then mouseUp. A process of handing mouse down/up events involves > some complex event processing in order to detect what should happen, for > example, with currently focused element or if we need to send double-click > event. It is a mouse processor who is responsible for all these actions and > it belongs to Space (inst. var in space). Not to mention some weird cases > of overlapped elements, elements with custom elevation (zIndex), custom > mouseDown/up event listeners that do some work too... > > That is why it is definitely not enough just to send a plain > BlClickEvent directly to the element. Instead, we should involve a space in > the process and actually simulate it by pushing mouseDown and mouseUp > events to the event queue. > > > > Next what we realised it the fact that it is not nice to always create a > temporary space and add our element to it in order to simulate a click. > What if an element is already added to the space, what if not? > > To wrap up, we decided that it should be a responsibility of the Space > class to create a new temporary instance of itself, add an element to it, > simulate click event and then delete itself. In order to show the intent > and a process behind we decided that it would be a good idea to actually > write a code like this: > > > > BlSpace simulateClickOn: element. > > > > It looks like global function. According to your description I would > expect: > > aSpace simulateClickOn: element > > > > I imaging tests where I create internal space instance, open application > in it and simulate events to check expected behaviour. But maybe you will > explain that it should be done differently? > > And what is actual use case for such simulations if we can just > #fireEvent: as you wrote below? > > > > > > In english it is quite nice: > > > > "dear space class, could you, please, simulate a click event on a given > element?" It is a space who simulates event, not an element. > > > > P.S. Users can still send a BlClickEvent directly (informs 'click'): > > > > element := BlElement new. > > element addEventHandlerOn: BlClickEvent do: [ self inform: 'click' ]. > > element fireEvent: BlClickEvent new > > > > Cheers, > > Alex > > > > On 10 November 2017 at 21:22, Sean P. DeNigris <sean(a)clipperadams.com> > wrote: > > Tudor Girba-2 wrote > > > - support for programatic testing of bloc mouse events: > > > https://twitter.com/feenkcom/status/925672206763511808 > > > > Why not `anElement simulateClick`? > > > > > > > > ----- > > Cheers, > > Sean > > -- > > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837. > html > > -- > www.tudorgirba.com > www.feenk.com > > "Obvious things are difficult to teach." > > > > > >

Nov. 12, 2017

Re: [Pharo-dev] 6.1 Iceberg - how is this supposed to work?

by Esteban Lorenzano

> On 11 Nov 2017, at 17:43, Todd Blanchard <tblanchard(a)mac.com> wrote: > > > "No ssh-agent suitable credentials found". Why? Its a public repository. because you are using an SSH protocol, regardless itâs public state. You need to identify yourself so the handshake can happen. Esteban

Nov. 12, 2017

Re: [Pharo-dev] feenk log

by Stephane Ducasse

BTW doru Class comments are important Look at the comment of BlSpace. I did not know that it was limited to a window. On Sat, Nov 11, 2017 at 10:39 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi Denis, > > It is not a global function. > > It is a class-side method because it relies on the following logic: > - if the element is attached to a space, it uses that space to dispatch the event. > - otherwise, it creates a temporary space and uses that one. > > The use case for such simulators is needed in the case of overlapping elements. In most cases, such as in a grid layout, the elements do not overlap, so clicking on the position occupied by an element will always lead to a high level click event dispatched to that element. However, when we have overlapping elements, clicking on the position of an element might end up dispatched to another element. In fact, we introduced this testing ability exactly to write a red test involving overlapping elements. > > Cheers, > Doru > > >> On Nov 11, 2017, at 11:35 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >> >> Hi Aliaksei >> >> 2017-11-10 22:36 GMT+01:00 Aliaksei Syrel <alex.syrel(a)gmail.com>: >> Hi Sean, >> >> Why not `anElement simulateClick`? >> >> Good question :) >> We indeed evaluated a possibility to have (BlElement >> #simulateClick) but then decided to make BlSpace class to be responsible for that. >> >> First we should realise that when we simulate a click we do literally simulate user's action which is: mouseDown at some global coordinate in space and then mouseUp. A process of handing mouse down/up events involves some complex event processing in order to detect what should happen, for example, with currently focused element or if we need to send double-click event. It is a mouse processor who is responsible for all these actions and it belongs to Space (inst. var in space). Not to mention some weird cases of overlapped elements, elements with custom elevation (zIndex), custom mouseDown/up event listeners that do some work too... >> That is why it is definitely not enough just to send a plain BlClickEvent directly to the element. Instead, we should involve a space in the process and actually simulate it by pushing mouseDown and mouseUp events to the event queue. >> >> Next what we realised it the fact that it is not nice to always create a temporary space and add our element to it in order to simulate a click. What if an element is already added to the space, what if not? >> To wrap up, we decided that it should be a responsibility of the Space class to create a new temporary instance of itself, add an element to it, simulate click event and then delete itself. In order to show the intent and a process behind we decided that it would be a good idea to actually write a code like this: >> >> BlSpace simulateClickOn: element. >> >> It looks like global function. According to your description I would expect: >> aSpace simulateClickOn: element >> >> I imaging tests where I create internal space instance, open application in it and simulate events to check expected behaviour. But maybe you will explain that it should be done differently? >> And what is actual use case for such simulations if we can just #fireEvent: as you wrote below? >> >> >> In english it is quite nice: >> >> "dear space class, could you, please, simulate a click event on a given element?" It is a space who simulates event, not an element. >> >> P.S. Users can still send a BlClickEvent directly (informs 'click'): >> >> element := BlElement new. >> element addEventHandlerOn: BlClickEvent do: [ self inform: 'click' ]. >> element fireEvent: BlClickEvent new >> >> Cheers, >> Alex >> >> On 10 November 2017 at 21:22, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >> Tudor Girba-2 wrote >> > - support for programatic testing of bloc mouse events: >> > https://twitter.com/feenkcom/status/925672206763511808 >> >> Why not `anElement simulateClick`? >> >> >> >> ----- >> Cheers, >> Sean >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > > -- > www.tudorgirba.com > www.feenk.com > > "Obvious things are difficult to teach." > > > > >

Nov. 12, 2017

Re: [Pharo-dev] Convention for "reset" methods

by Ben Coman

+1. I think "accessing" sometimes ends up the default catch-all. "Initialization" makes more sense for this. Cheers -ben On Sun, Nov 12, 2017 at 2:31 AM, Cyril Ferlicot <cyril.ferlicot(a)gmail.com> wrote: > Hi, > > Torsten is doing a really cool job by cleaning the protocols of Pharo. > > Smalltalk has a lot of conventions and if we want the users to apply > them we need to have a clean Pharo. > > On that subject I was wonderingâ¦ > > Do we have a real convention for "reset" methods? > > With this script: > > ((RPackageOrganizer default packages flatCollect: #methods) select: [ > :each | each selector = #reset ]) collect: #protocol as: Bag > > We can see that there is different way to do. > > 25 in accessing > 11 in initialization > 10 in positioning > 10 in instance creation > And some others less popular choices. > > So my question is, should we have a conventional protocol for reset > methods? > > For now, most of them are in "accessing", but it cause a violation of > the RBUnaryAccessingMethodWithoutReturnRule. > > Personally I think that "initialization" protocol make the more sens. > > If the community agree on it we could > - Recategorize > - Make sure the automatic categorizer follow the convention > - Add a rule/test to check that > > Waiting for your thoughts :) > > -- > Cyril Ferlicot > https://ferlicot.fr > > http://www.synectique.eu > 2 rue Jacques PrÃ©vert 01, > 59650 Villeneuve d'ascq France > >

Nov. 12, 2017

Re: [Pharo-dev] 6.1 Iceberg - how is this supposed to work?

by Esteban Lorenzano

> On 12 Nov 2017, at 09:28, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > the only thing I can think now is you have a cache problem (older version of sources, older version of image, I don't know). > this is *exactly* what I did and worked: > > $ wget -O- get.pharo.org/64/61+vm <http://get.pharo.org/64/61+vm> | bash ah, and Iâd execute this in an empty dir so Iâm sure there is no caching stuff in the middle. > $ ./pharo-ui Pharo.image --no-default-preferences > > open playground > > LGitExternalStructure allSubclassesDo: #compileFields. > Metacello new > repository: 'github://estebanlm/libclang-pharo-bindings/src <github://estebanlm/libclang-pharo-bindings/src>'; > baseline: 'LibClang'; > load. > > that loaded correctly for me (macOS high sierra). > > Esteban > > >> On 11 Nov 2017, at 17:43, Todd Blanchard <tblanchard(a)mac.com <mailto:tblanchard@mac.com>> wrote: >> >> Executed that. Now tried to do: >> >>> Metacello new >>> repository: 'github://estebanlm/libclang-pharo-bindings/src <github://estebanlm/libclang-pharo-bindings/src>'; >>> baseline: 'LibClang'; >>> load. >> >> >> And I'm back to "Could not resolve 'BaselineOfLibClang' >> >> <Pharo6.1-64.image 2017-11-11 12-41-07.png> >> >> Also tried the iceberg loader. I get... >> >> "No ssh-agent suitable credentials found". Why? Its a public repository. >> >> <Pharo6.1-64.image 2017-11-11 12-43-00.png> >> >> >> >> >>> On Nov 11, 2017, at 3:46 AM, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: >>> >>> got it. >>> I was able to reproduce it. >>> >>> turns out there is a problem in the 32-64 bits conversion and libgit2 bindings. >>> >>> you need to execute this: >>> >>> LGitExternalStructure allSubclassesDo: #compileFields. >>> >>> before execute this: >>> >>> Metacello new >>> repository: 'github://estebanlm/libclang-pharo-bindings/src <github://estebanlm/libclang-pharo-bindings/src>'; >>> baseline: 'LibClang'; >>> load. >>> >>> Esteban >>> >>>> On 11 Nov 2017, at 07:37, Todd Blanchard <tblanchard(a)mac.com <mailto:tblanchard@mac.com>> wrote: >>>> >>>> Any help? >>>> >>>>> On Nov 10, 2017, at 8:49 AM, Todd Blanchard <tblanchard(a)mac.com <mailto:tblanchard@mac.com>> wrote: >>>>> >>>>> Yes, trying to install your libclang. >>>>> >>>>> Pharo is brand new download of whatever is on the website - 6.1-64 bit version (yes I know its not tested - I was going to test it). >>>>> OSX Sierra. >>>>> I have Xcode and all that goes with it installed (my day job is IoT projects with accompanying iPhone apps and occasionally web services development). >>>>> >>>>> Homebrew packages installed include... >>>>> >>>>> appledoc gmp nettle >>>>> autoconf gnutls nmap >>>>> aws-elasticbeanstalk gobject-introspection node >>>>> awscli graphite2 openssl >>>>> basset_ios harfbuzz openssl@1.1 >>>>> bazel icu4c p11-kit >>>>> boot2docker imagemagick pango >>>>> c-ares jpeg pcre >>>>> cairo libcroco pixman >>>>> cmake libffi pkg-config >>>>> coreutils libgcrypt python >>>>> cvs libgpg-error python3 >>>>> dfu-util libpng rbenv >>>>> docker librsvg readline >>>>> fontconfig libssh2 redis >>>>> freetype libtasn1 ruby-build >>>>> gdbm libtiff sqlite >>>>> gdk-pixbuf libtool unar >>>>> geoip libunistring wget >>>>> gettext libusb wireshark >>>>> ghostscript little-cms2 xz >>>>> glib lua >>>>> >>>>> >>>>> >>>>>> On Nov 10, 2017, at 1:24 AM, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: >>>>>> >>>>>> I would need a way to reproduce this. >>>>>> >>>>>> pharo version? (6.1?) >>>>>> vm version? >>>>>> operating system? >>>>>> project you try to install? (I guess is libclang) >>>>>> >>>>>> anything I should know about your environment? (image is clean/new? are you behind a proxy? whatever that can help) >>>>>> >>>>>> Esteban >>>>>> >>>>>>> On 10 Nov 2017, at 00:08, Todd Blanchard <tblanchard(a)mac.com <mailto:tblanchard@mac.com>> wrote: >>>>>>> >>>>>>> #(0 25 1) >>>>>>> >>>>>>>> On Nov 9, 2017, at 5:45 PM, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: >>>>>>>> >>>>>>>> (LGitLibrary uniqueInstance version) >>>>>>> >>>>>> >>>>> >>>> >>> >> >

Nov. 12, 2017