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

Re: [Pharo-dev] French speaking Pharo company

by Norbert Hartl

> Am 09.04.2015 um 10:44 schrieb FranÃ§ois Stephany <tulipe.moutarde(a)gmail.com>: > > Hi there, > > I'm writing a proposal for a potential customer. Given the complex model, I'd like to implement the backend and webservice in Pharo (instead of Ruby on Rails). > > Is there any of you working in a service company doing Pharo Development for backends? The customer is french and might be more comfortable going with Pharo if he knows that there are backups in case we disappear. > We (2denker GmbH in cologne) are a service company that develops backends in pharo for years now. None of us speaks french. So if english is fine we are always interested. Norbert

April 9, 2015

Re: [Pharo-dev] French speaking Pharo company

by phil＠highoctane.be

moi ;-) Phil Le 9 avr. 2015 10:45, "FranÃ§ois Stephany" <tulipe.moutarde(a)gmail.com> a Ã©crit : > Hi there, > > I'm writing a proposal for a potential customer. Given the complex model, > I'd like to implement the backend and webservice in Pharo (instead of Ruby > on Rails). > > Is there any of you working in a service company doing Pharo Development > for backends? The customer is french and might be more comfortable going > with Pharo if he knows that there are backups in case we disappear. > > Cheers, > Francois >

April 9, 2015

French speaking Pharo company

by FranÃ§ois Stephany

Hi there, I'm writing a proposal for a potential customer. Given the complex model, I'd like to implement the backend and webservice in Pharo (instead of Ruby on Rails). Is there any of you working in a service company doing Pharo Development for backends? The customer is french and might be more comfortable going with Pharo if he knows that there are backups in case we disappear. Cheers, Francois

April 9, 2015

Re: [Pharo-dev] Inspecting Slots raises an error

by Marcus Denker

> On 09 Apr 2015, at 03:38, Juraj Kubelka <juraj.kubelka(a)gmail.com> wrote: > > Hi, > > I have tried to inspect > Model allSlots > and if I click on a slot it raises an error "WordLayout does not understand #definesSlot:â > > Is it problem of Slots or of GT-Inspector definition? a bug in Slotâ¦ #definesSlot: should be defines higher in the hierarchy. Fix: https://pharo.fogbugz.com/f/cases/15315/Inspecting-Slots-raises-an-error Marcus

April 9, 2015

Re: [Pharo-dev] Can we have basicRaw in GTInspector?

by Tudor Girba

Hi Stef, This Raw view is the result of many debates and negotiations. We can safely say it was designed by committee. As I mentioned before, I think the tree is overkill in this context and it makes things unnecessarily slow. But, we will try better for Pharo 5 :) Cheers, Doru On Fri, Apr 3, 2015 at 7:23 PM, stepharo <stepharo(a)free.fr> wrote: > > The Playground has inspect on Cmd+Shift+i as requested by you. > > > Ok good to know because this is important. > What aboout an help? > > > There is a problem with the update as it does not scale in the current > form. Please see the reply of Andrei. We will likely remove that feature > for the release. > > Just to clarify: When did we ever say that someone is stupid? > > > Esteban told me that it was not freezing when we had to trash the image. > Just that the machine was slow. To me this is a non answer. > > > If we could get a real raw = basic inspect tabe then we can use GT and > work. > To me the raw tab with an explorer inside is counterproductive: we can get > lost, it is slow, it does not work well with navigation of GT. > > Cheers, > Doru > > > > On Thu, Apr 2, 2015 at 5:30 PM, stepharo <stepharo(a)free.fr> wrote: > >> This morning GTInspector was so slow that it blocked the complete system >> on the machine of Cyril. :( >> We can tell him that he is stupid to have a bad machine or we could try >> to use this to see how >> we can help our users. >> >> So we had to use basicInspect to get our job done (once we ctrl-. to >> escape the render hell) >> because raw uses a tree morph. >> >> Why raw cannot reproduce the old simple and working basicInspect >> then we could have a "basic" inspect on double click to avoid to use this >> bad tree and that we can work. >> >> just try to on RubSmalltalkCodeMode class>>#menuOn: to get the feel. Even >> on my superfast machine is >> is sluggish. >> >> I really think that we should support backdoors. >> We need to have a mini browser, a mini debugger and a working inspector. >> >> Setf >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > > -- www.tudorgirba.com "Every thing has its own flow"

April 9, 2015

Re: [Pharo-dev] Existing <script> <example> pragmas and new GT needs

by Tudor Girba

I would not do that. I think that removing the example pragma check is sufficient for now. Could we do it? Cheers, Doru On Wed, Apr 8, 2015 at 5:16 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > 2015-04-08 10:20 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > >> >> And, to have a better chance of having a clean slate discussion later on >> in which to consider the value we associate to names, I would like to >> remove the <example> check from isExampleMethod and continue to preserve >> the treatment of #example* selectors in Nautilus. >> >> > Wouldn't we need to change the check to: > > isExampleMethod > if selector starts with 'example' *AND HAS NOT* a <example> (or > <gtExample>) pragma > > because there are tons of #example* methods, some of them open an example > and some of them with the pragma, create an instance for the inspector? > > > > > -- www.tudorgirba.com "Every thing has its own flow"

April 9, 2015

Inspecting Slots raises an error

by Juraj Kubelka

Hi, I have tried to inspect Model allSlots and if I click on a slot it raises an error "WordLayout does not understand #definesSlot:â Is it problem of Slots or of GT-Inspector definition? Pharo #40597 Cheers, Juraj

April 9, 2015

Re: [Pharo-dev] source code mgmt issues in Pharo4

by Thierry Goubier

Le 08/04/2015 19:41, Johan Brichau a Ã©crit : > Hi all, > > Over the last week, I started working with Pharo4, mostly to make Seaside work cleanly. > > On several occasions, I had severe issues with the package management: > - methods that were changed in a class were not recorded as âchangedâ in monticello and were absent from the published package > - versions of methods disappeared (i.e. no longer accessible in the version history of a method) > - looking at the âchangedâ in Monticello showed all code of the package as changed (though only a single method has changed). > > This makes working with Pharo4 extremely problematic. I cannot trust the source code packaging/publishing and merging anymore. > > I cannot discern a scenario that leads to these issues but I do have an image right now where I only changed a single method and the entire package shows up as âchangedâ. > > Anyone experience similar issues? Hi Johan, Yuriy's issue with Komitter and GitFileTree is the same problem. I'd really need to have the ability to reproduce that. Or have access to an image where it has happened. I'd really like to inspect the relevant package working copy, its ancestry and the associated RPackage. Thierry

April 8, 2015

Re: [Pharo-dev] Can Monticello version message be a Text?

by Thierry Goubier

Uko, you seem to have the same bug Johan is describing. MC seems to loose the contents of a package working copy, and hence is unable to build a correct diff. I've seen it happen at times, but rarely enough so I didn't pay attention to it. Thierry Le 08/04/2015 09:44, Yuriy Tymchuk a Ã©crit : > >> On 07 Apr 2015, at 12:16, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: >> >> Le 07/04/2015 11:01, Yuriy Tymchuk a Ã©crit : >>> Hi, thank you very much for investigating this. >> >> You're working on it too :) >> >>> These are the steps to reproduce: >>> >>> 1. Clone a git repo (e.g. https://github.com/Uko/VnaExporter.git) >>> 2. Add it as gitfiletree repo to the pharo image. >>> 3. Change something, commit part of the changes with Komitter. >>> 4. Change something more. >>> 5. Open Komitter, you should see a strange diff. >>> 6. Select 1 or 2 methods & commit them. >>> 7. Now you should have only 2 methods in your repo. >> >> I did, and I don't see anything suspicious. Browsing the repository at each step gave me the complete package as expected (minus the unsaved changes, of course). >> >> Can you show a screenshot at step 5? > > Iâve done a screen recording https://dl.dropboxusercontent.com/u/83145561/GitKomitter.mov > > Uko > >> >> Thierry >> > > >

April 8, 2015

source code mgmt issues in Pharo4

by Johan Brichau

Hi all, Over the last week, I started working with Pharo4, mostly to make Seaside work cleanly. On several occasions, I had severe issues with the package management: - methods that were changed in a class were not recorded as âchangedâ in monticello and were absent from the published package - versions of methods disappeared (i.e. no longer accessible in the version history of a method) - looking at the âchangedâ in Monticello showed all code of the package as changed (though only a single method has changed). This makes working with Pharo4 extremely problematic. I cannot trust the source code packaging/publishing and merging anymore. I cannot discern a scenario that leads to these issues but I do have an image right now where I only changed a single method and the entire package shows up as âchangedâ. Anyone experience similar issues? Johan

April 8, 2015