- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Why can't we use * in protocol for package extension?

by Sean P. DeNigris

Stephane Ducasse-3 wrote > you are mixing and other concerns True, they are not the same issue. I guess the connection for me is that they are both examples of overloading a single mechanism to accomplish at best orthogonal and often conflicting goals. Right now we're using dumb strings to define: 1) method visibility (e.g. "private") 2) extension package 3) categorization. It seems way overdue for a real model. Thus I was surprised that there seemed to be resistance to change. ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

April 13, 2018

Re: [Pharo-dev] Why can't we use * in protocol for package extension?

by Denis Kudriashov

2018-04-12 20:46 GMT+02:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > Eliot > > We do not want to go the road of overrides. We want to keep our > engineer task forces. > We will need support this anyway. It's very similar to loading methods extending undefined class (you already have prototype, right?). Imagine that you load project which overrides your package which already includes many changes. It should be safe to commit package. Overridden methods should not be removed. And to support it we will need model for package overrides which will bring features which Eliot describes. > > Stef > > On Thu, Apr 12, 2018 at 7:31 PM, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > > Hi Sean, > > > > On Thu, Apr 12, 2018 at 9:49 AM, Sean P. DeNigris <sean(a)clipperadams.com > > > > wrote: > >> > >> Stephane Ducasse-3 wrote > >> > You see. You pushed this idea and at then end we will have to handle > the > >> > mess. > >> > I do not see why we cannot simply support *. > >> > >> I'm surprised by this resistance. The *Xyz was always an ugly hack, part > >> of > >> Squeak's overloading the same mechanism for both system categorization > and > >> packaging, and exposing and limiting protocols as "just dumb strings", > all > >> of which IMHO makes the system much less understandable (no real > "private" > >> tagging, extension methods can't show up in proper protocol, etc). We're > >> not > >> in a feature freeze, so what is the problem with tackling part of this > >> mess > >> now? Sure, maybe the UI support can be improved, but let's focus on some > >> concrete suggestions. > >> > >> Denis and I just happened to be talking about this larger issue the > other > >> day. Here are a few snippets I dug up during that conversations of some > of > >> my many posts about this over the yearsâ¦ > >> > >> > we have overloaded system categories to package code for SCM. System > >> > categories should be tags (preferably multiple allowed) > >> > which offer a logical view of the system. Packages, the POV we show > now, > >> > are orthogonal and much less useful for users. > >> (edited) > >> and another: > >> > I feel more and more that the standard "Package" pane is only useful > >> > for... packaging, and when one takes off the dependency management hat > >> > and > >> > puts the user hat on (i.e. most of the time), what you really want > there > >> > is a logical view of the system. So I see three use cases: > >> - Logical view of the system - I guess this was the original intention > of > >> Categories, but has been hijacked by Monticello > >> - By project - which, as you just showed, we have now, yay! > >> - By package - the least useful, but primary (up til now), view > >> (edited) > >> and regarding Nautilus' tree package pane (when it first arrived): > >> I noticed that right now, separate packages within the same project are > >> not > >> collapsed. E.g. if I have MyProject-Core and MyProject-Platform, they > will > >> be siblings in the tree, instead of both under MyProject. It seems like > it > >> would be more useful to have > >> - MyProject > >> - Core > >> - Platform > >> in the tree > > > > > > If you and Denis are "going radical" and going to do the right thing then > > please also give thought to overrides and unloading. Allowing a package > to > > override a set of methods on load is a useful facility, fraught with > > difficulties (being able to browse the overridden versions being the main > > one). Having things organized so that the overridden versions are saved, > > don't get lost when source is rewritten, etc, etc (made much easier by > > keeping source in methods), but most importantly, get restored in the > right > > order when packages are unloaded. I believe it's as simple as > associating > > the methods that are overridden with the packages to which they belong, > and > > maintaining a load order (so that if PkgA B & C implement C>>foo, and are > > loaded in the order A, B, C, then we can compute easily that unloading C > > restores PkgB's C>>foo, and that unloading B does not affect C>>foo). > > > >> > >> > >> > it seems that the tree is primarily about chunking information into > >> > manageable pieces. > >> > >> A primary difficulty here is that packages are often divided for reasons > >> that have nothing to do with the domain model, e.g. the ubiquitous > >> MyPackage-Platform, which is an artifact of Metacello that is not all > that > >> relevant to a user wanting to understand the system. > >> > >> From the naive user perspective, if I'm exploring from the top level of > >> the > >> system, I want to see things like: > >> - CodeImport > >> - Collections > >> - Compiler > >> > >> From this perspective, the 14 entries for Collections, multiplied by a > few > >> dozen top-level categories make the list unwieldy and only marginally > less > >> daunting than the flattened list we used to have (see > >> http://en.wikipedia.org/wiki/The_Magical_Number_Seven,_ > Plus_or_Minus_Two ) > >> > >> > >> > >> ----- > >> Cheers, > >> Sean > >> -- > >> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837. > html > >> > > > > > > > > -- > > _,,,^..^,,,_ > > best, Eliot > >

April 12, 2018

Re: [Pharo-dev] Why can't we use * in protocol for package extension?

by Eliot Miranda

Hi Stephane, On Thu, Apr 12, 2018 at 11:46 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Eliot > > We do not want to go the road of overrides. We want to keep our > engineer task forces. > There are overrides anyway. In general overrides are unavoidable in some circumstances. The issue is not whether they exist, it's whether they work reliably. Right now they don't; they rely on changes file technology that is extremely fragile. Sean and Denis' move to reimplement extensions is an opportunity to implement overrides correctly. > > Stef > > On Thu, Apr 12, 2018 at 7:31 PM, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > > Hi Sean, > > > > On Thu, Apr 12, 2018 at 9:49 AM, Sean P. DeNigris <sean(a)clipperadams.com > > > > wrote: > >> > >> Stephane Ducasse-3 wrote > >> > You see. You pushed this idea and at then end we will have to handle > the > >> > mess. > >> > I do not see why we cannot simply support *. > >> > >> I'm surprised by this resistance. The *Xyz was always an ugly hack, part > >> of > >> Squeak's overloading the same mechanism for both system categorization > and > >> packaging, and exposing and limiting protocols as "just dumb strings", > all > >> of which IMHO makes the system much less understandable (no real > "private" > >> tagging, extension methods can't show up in proper protocol, etc). We're > >> not > >> in a feature freeze, so what is the problem with tackling part of this > >> mess > >> now? Sure, maybe the UI support can be improved, but let's focus on some > >> concrete suggestions. > >> > >> Denis and I just happened to be talking about this larger issue the > other > >> day. Here are a few snippets I dug up during that conversations of some > of > >> my many posts about this over the yearsâ¦ > >> > >> > we have overloaded system categories to package code for SCM. System > >> > categories should be tags (preferably multiple allowed) > >> > which offer a logical view of the system. Packages, the POV we show > now, > >> > are orthogonal and much less useful for users. > >> (edited) > >> and another: > >> > I feel more and more that the standard "Package" pane is only useful > >> > for... packaging, and when one takes off the dependency management hat > >> > and > >> > puts the user hat on (i.e. most of the time), what you really want > there > >> > is a logical view of the system. So I see three use cases: > >> - Logical view of the system - I guess this was the original intention > of > >> Categories, but has been hijacked by Monticello > >> - By project - which, as you just showed, we have now, yay! > >> - By package - the least useful, but primary (up til now), view > >> (edited) > >> and regarding Nautilus' tree package pane (when it first arrived): > >> I noticed that right now, separate packages within the same project are > >> not > >> collapsed. E.g. if I have MyProject-Core and MyProject-Platform, they > will > >> be siblings in the tree, instead of both under MyProject. It seems like > it > >> would be more useful to have > >> - MyProject > >> - Core > >> - Platform > >> in the tree > > > > > > If you and Denis are "going radical" and going to do the right thing then > > please also give thought to overrides and unloading. Allowing a package > to > > override a set of methods on load is a useful facility, fraught with > > difficulties (being able to browse the overridden versions being the main > > one). Having things organized so that the overridden versions are saved, > > don't get lost when source is rewritten, etc, etc (made much easier by > > keeping source in methods), but most importantly, get restored in the > right > > order when packages are unloaded. I believe it's as simple as > associating > > the methods that are overridden with the packages to which they belong, > and > > maintaining a load order (so that if PkgA B & C implement C>>foo, and are > > loaded in the order A, B, C, then we can compute easily that unloading C > > restores PkgB's C>>foo, and that unloading B does not affect C>>foo). > > > >> > >> > >> > it seems that the tree is primarily about chunking information into > >> > manageable pieces. > >> > >> A primary difficulty here is that packages are often divided for reasons > >> that have nothing to do with the domain model, e.g. the ubiquitous > >> MyPackage-Platform, which is an artifact of Metacello that is not all > that > >> relevant to a user wanting to understand the system. > >> > >> From the naive user perspective, if I'm exploring from the top level of > >> the > >> system, I want to see things like: > >> - CodeImport > >> - Collections > >> - Compiler > >> > >> From this perspective, the 14 entries for Collections, multiplied by a > few > >> dozen top-level categories make the list unwieldy and only marginally > less > >> daunting than the flattened list we used to have (see > >> http://en.wikipedia.org/wiki/The_Magical_Number_Seven,_ > Plus_or_Minus_Two ) > >> > >> > >> > >> ----- > >> Cheers, > >> Sean > >> -- > >> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837. > html > >> > > > > > > > > -- > > _,,,^..^,,,_ > > best, Eliot > > -- _,,,^..^,,,_ best, Eliot

April 12, 2018

Re: [Pharo-dev] Why can't we use * in protocol for package extension?

by Stephane Ducasse

Eliot We do not want to go the road of overrides. We want to keep our engineer task forces. Stef On Thu, Apr 12, 2018 at 7:31 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Sean, > > On Thu, Apr 12, 2018 at 9:49 AM, Sean P. DeNigris <sean(a)clipperadams.com> > wrote: >> >> Stephane Ducasse-3 wrote >> > You see. You pushed this idea and at then end we will have to handle the >> > mess. >> > I do not see why we cannot simply support *. >> >> I'm surprised by this resistance. The *Xyz was always an ugly hack, part >> of >> Squeak's overloading the same mechanism for both system categorization and >> packaging, and exposing and limiting protocols as "just dumb strings", all >> of which IMHO makes the system much less understandable (no real "private" >> tagging, extension methods can't show up in proper protocol, etc). We're >> not >> in a feature freeze, so what is the problem with tackling part of this >> mess >> now? Sure, maybe the UI support can be improved, but let's focus on some >> concrete suggestions. >> >> Denis and I just happened to be talking about this larger issue the other >> day. Here are a few snippets I dug up during that conversations of some of >> my many posts about this over the yearsâ¦ >> >> > we have overloaded system categories to package code for SCM. System >> > categories should be tags (preferably multiple allowed) >> > which offer a logical view of the system. Packages, the POV we show now, >> > are orthogonal and much less useful for users. >> (edited) >> and another: >> > I feel more and more that the standard "Package" pane is only useful >> > for... packaging, and when one takes off the dependency management hat >> > and >> > puts the user hat on (i.e. most of the time), what you really want there >> > is a logical view of the system. So I see three use cases: >> - Logical view of the system - I guess this was the original intention of >> Categories, but has been hijacked by Monticello >> - By project - which, as you just showed, we have now, yay! >> - By package - the least useful, but primary (up til now), view >> (edited) >> and regarding Nautilus' tree package pane (when it first arrived): >> I noticed that right now, separate packages within the same project are >> not >> collapsed. E.g. if I have MyProject-Core and MyProject-Platform, they will >> be siblings in the tree, instead of both under MyProject. It seems like it >> would be more useful to have >> - MyProject >> - Core >> - Platform >> in the tree > > > If you and Denis are "going radical" and going to do the right thing then > please also give thought to overrides and unloading. Allowing a package to > override a set of methods on load is a useful facility, fraught with > difficulties (being able to browse the overridden versions being the main > one). Having things organized so that the overridden versions are saved, > don't get lost when source is rewritten, etc, etc (made much easier by > keeping source in methods), but most importantly, get restored in the right > order when packages are unloaded. I believe it's as simple as associating > the methods that are overridden with the packages to which they belong, and > maintaining a load order (so that if PkgA B & C implement C>>foo, and are > loaded in the order A, B, C, then we can compute easily that unloading C > restores PkgB's C>>foo, and that unloading B does not affect C>>foo). > >> >> >> > it seems that the tree is primarily about chunking information into >> > manageable pieces. >> >> A primary difficulty here is that packages are often divided for reasons >> that have nothing to do with the domain model, e.g. the ubiquitous >> MyPackage-Platform, which is an artifact of Metacello that is not all that >> relevant to a user wanting to understand the system. >> >> From the naive user perspective, if I'm exploring from the top level of >> the >> system, I want to see things like: >> - CodeImport >> - Collections >> - Compiler >> >> From this perspective, the 14 entries for Collections, multiplied by a few >> dozen top-level categories make the list unwieldy and only marginally less >> daunting than the flattened list we used to have (see >> http://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two ) >> >> >> >> ----- >> Cheers, >> Sean >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >> > > > > -- > _,,,^..^,,,_ > best, Eliot

April 12, 2018

Re: [Pharo-dev] Why can't we use * in protocol for package extension?

by Stephane Ducasse

Sean you are mixing and other concerns. The tools could show all the collections as projects. Packages are unit of loading. So small modular packages are good. Stef On Thu, Apr 12, 2018 at 6:49 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Stephane Ducasse-3 wrote >> You see. You pushed this idea and at then end we will have to handle the >> mess. >> I do not see why we cannot simply support *. > > I'm surprised by this resistance. The *Xyz was always an ugly hack, part of > Squeak's overloading the same mechanism for both system categorization and > packaging, and exposing and limiting protocols as "just dumb strings", all > of which IMHO makes the system much less understandable (no real "private" > tagging, extension methods can't show up in proper protocol, etc). We're not > in a feature freeze, so what is the problem with tackling part of this mess > now? Sure, maybe the UI support can be improved, but let's focus on some > concrete suggestions. > > Denis and I just happened to be talking about this larger issue the other > day. Here are a few snippets I dug up during that conversations of some of > my many posts about this over the yearsâ¦ > >> we have overloaded system categories to package code for SCM. System >> categories should be tags (preferably multiple allowed) >> which offer a logical view of the system. Packages, the POV we show now, >> are orthogonal and much less useful for users. > (edited) > and another: >> I feel more and more that the standard "Package" pane is only useful >> for... packaging, and when one takes off the dependency management hat and >> puts the user hat on (i.e. most of the time), what you really want there >> is a logical view of the system. So I see three use cases: > - Logical view of the system - I guess this was the original intention of > Categories, but has been hijacked by Monticello > - By project - which, as you just showed, we have now, yay! > - By package - the least useful, but primary (up til now), view > (edited) > and regarding Nautilus' tree package pane (when it first arrived): > I noticed that right now, separate packages within the same project are not > collapsed. E.g. if I have MyProject-Core and MyProject-Platform, they will > be siblings in the tree, instead of both under MyProject. It seems like it > would be more useful to have > - MyProject > - Core > - Platform > in the tree > >> it seems that the tree is primarily about chunking information into >> manageable pieces. > > A primary difficulty here is that packages are often divided for reasons > that have nothing to do with the domain model, e.g. the ubiquitous > MyPackage-Platform, which is an artifact of Metacello that is not all that > relevant to a user wanting to understand the system. > > From the naive user perspective, if I'm exploring from the top level of the > system, I want to see things like: > - CodeImport > - Collections > - Compiler > > From this perspective, the 14 entries for Collections, multiplied by a few > dozen top-level categories make the list unwieldy and only marginally less > daunting than the flattened list we used to have (see > http://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two ) > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

April 12, 2018

Re: [Pharo-dev] [TechTalk] April 12: GIT with Iceberg

by Bernardo Ezequiel Contreras

Iceberg 0.7 : new UI https://www.youtube.com/watch?v=A9H8jsSnBKM&t=539s On Thu, Apr 12, 2018 at 6:42 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > I will not make it but I really want. Let us know where will be the videos. > > Stef > > On Thu, Apr 12, 2018 at 9:09 AM, Marcus Denker <marcus.denker(a)inria.fr> > wrote: > > This is today > > > > 5:00 PM - 7:00 PM (UTC+02:00) > > > > There is a calendar entry to download at: https://association.pharo.org/ > event-2797068 > > > >> On 10 Apr 2018, at 16:34, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> > >> Hi, > >> > >> There next TechTalk will be April 12: GIT with Iceberg > >> > >> https://association.pharo.org/event-2797068 > >> > >> > >> A regular chat about Pharo. Happens on Discord. > >> > >> The Tech talks are open to both members and non-members! > >> > >> Topic: GIT with Iceberg. Demo of improved UI > >> > >> We will send an information to all subscribers some hours before the > talk starts. > >> > >> > > > > > > -- Bernardo E.C. Sent from a cheap desktop computer in South America.

April 12, 2018

Re: [Pharo-dev] Why can't we use * in protocol for package extension?

by Eliot Miranda

Hi Sean, On Thu, Apr 12, 2018 at 9:49 AM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Stephane Ducasse-3 wrote > > You see. You pushed this idea and at then end we will have to handle the > > mess. > > I do not see why we cannot simply support *. > > I'm surprised by this resistance. The *Xyz was always an ugly hack, part of > Squeak's overloading the same mechanism for both system categorization and > packaging, and exposing and limiting protocols as "just dumb strings", all > of which IMHO makes the system much less understandable (no real "private" > tagging, extension methods can't show up in proper protocol, etc). We're > not > in a feature freeze, so what is the problem with tackling part of this mess > now? Sure, maybe the UI support can be improved, but let's focus on some > concrete suggestions. > > Denis and I just happened to be talking about this larger issue the other > day. Here are a few snippets I dug up during that conversations of some of > my many posts about this over the yearsâ¦ > > > we have overloaded system categories to package code for SCM. System > > categories should be tags (preferably multiple allowed) > > which offer a logical view of the system. Packages, the POV we show now, > > are orthogonal and much less useful for users. > (edited) > and another: > > I feel more and more that the standard "Package" pane is only useful > > for... packaging, and when one takes off the dependency management hat > and > > puts the user hat on (i.e. most of the time), what you really want there > > is a logical view of the system. So I see three use cases: > - Logical view of the system - I guess this was the original intention of > Categories, but has been hijacked by Monticello > - By project - which, as you just showed, we have now, yay! > - By package - the least useful, but primary (up til now), view > (edited) > and regarding Nautilus' tree package pane (when it first arrived): > I noticed that right now, separate packages within the same project are not > collapsed. E.g. if I have MyProject-Core and MyProject-Platform, they will > be siblings in the tree, instead of both under MyProject. It seems like it > would be more useful to have > - MyProject > - Core > - Platform > in the tree > If you and Denis are "going radical" and going to do the right thing then please also give thought to overrides and unloading. Allowing a package to override a set of methods on load is a useful facility, fraught with difficulties (being able to browse the overridden versions being the main one). Having things organized so that the overridden versions are saved, don't get lost when source is rewritten, etc, etc (made much easier by keeping source in methods), but most importantly, get restored in the right order when packages are unloaded. I believe it's as simple as associating the methods that are overridden with the packages to which they belong, and maintaining a load order (so that if PkgA B & C implement C>>foo, and are loaded in the order A, B, C, then we can compute easily that unloading C restores PkgB's C>>foo, and that unloading B does not affect C>>foo). > > > it seems that the tree is primarily about chunking information into > > manageable pieces. > > A primary difficulty here is that packages are often divided for reasons > that have nothing to do with the domain model, e.g. the ubiquitous > MyPackage-Platform, which is an artifact of Metacello that is not all that > relevant to a user wanting to understand the system. > > From the naive user perspective, if I'm exploring from the top level of the > system, I want to see things like: > - CodeImport > - Collections > - Compiler > > From this perspective, the 14 entries for Collections, multiplied by a few > dozen top-level categories make the list unwieldy and only marginally less > daunting than the flattened list we used to have (see > http://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two ) > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > > -- _,,,^..^,,,_ best, Eliot

April 12, 2018

Re: [Pharo-dev] Pharo Launcher on Windows > Failing

by phil＠highoctane.be

Stack added. Thx for the pointer. I actually never fueled out since that "new" debugger (and was using the old one due to stepping errors in the GTDebugger for tests. I think 6.x has solved that, this was in 5.0). Phil On Thu, Apr 12, 2018 at 6:40 PM, <Vincent.Blondeau(a)lamresearch.com> wrote: > Thx for the issue :) > > > > Ps: the fuel out is here: > > > > Vincent > > > > *From:* Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] *On Behalf > Of *phil(a)highoctane.be > *Sent:* Thursday, April 12, 2018 9:31 > *To:* Pharo Development List <pharo-dev(a)lists.pharo.org> > *Subject:* Re: [Pharo-dev] Pharo Launcher on Windows > Failing > > > > https://github.com/pharo-project/pharo-launcher/issues/88 > <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_pharo-2Dpro…> > filled in. > > > > Thx for the help! > > > > Phil > > > > > > > > > > > > > > On Thu, Apr 12, 2018 at 5:18 PM, <Vincent.Blondeau(a)lamresearch.com> wrote: > > Hi Phil, > > > > I can help you to fix this issue. Can you tell me the list of the files in > the folder that is designed by the error? > > And in the parent folder, there should be a zip file with the same name, > can you check if Pharo.exe is here and if the file list is the same? > > It will be nice if you can serialize the stack and send it to me / post it > in a new github issue: https://github.com/pharo- > project/pharo-launcher/issues > <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_pharo-2Dpro…> > . > > > > Thanks, > > > > Vincent > > > > *From:* Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] *On Behalf > Of *phil(a)highoctane.be > *Sent:* Thursday, April 12, 2018 7:58 > *To:* Discusses Development of Pharo <pharo-dev(a)lists.pharo.org> > *Subject:* [Pharo-dev] Pharo Launcher on Windows > Failing > > > > I wanted to try Pharo Laucher before the tech talk > > > > But I get this when asking for an image > > > > > > I do not even know what is going on and I am an "experienced user". > > > > The impression this gives to a newcomer is utterly disastrous. > > > > We are really on a bad path on this. > > > > I'd like to get through this with some Launcher expert and fix this for > good. > > > > Phil > > > > >

April 12, 2018

Re: [Pharo-dev] Pharo Launcher on Windows > Failing

by phil＠highoctane.be

Direct download from pharo.org / Windows. Installed in C:\PharoLauchner20180412 Phil On Thu, Apr 12, 2018 at 7:04 PM, Ben Coman <btc(a)openinworld.com> wrote: > When did you install it? > And what link? > What OS? > Is the VM named "pharo.exe" ? > I had a similar problem when I tried renaming the VM to "PharoLauncher.exe" > since PharoLauncher's VM-version-seach code was searching exactly for > "pharo.exe" > > cheers -ben > > > On 12 April 2018 at 22:57, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > >> I wanted to try Pharo Laucher before the tech talk >> >> But I get this when asking for an image >> >> >> I do not even know what is going on and I am an "experienced user". >> >> The impression this gives to a newcomer is utterly disastrous. >> >> We are really on a bad path on this. >> >> I'd like to get through this with some Launcher expert and fix this for >> good. >> >> Phil >> >> >

April 12, 2018

Re: [Pharo-dev] Pharo Launcher on Windows > Failing

by Ben Coman

When did you install it? And what link? What OS? Is the VM named "pharo.exe" ? I had a similar problem when I tried renaming the VM to "PharoLauncher.exe" since PharoLauncher's VM-version-seach code was searching exactly for "pharo.exe" cheers -ben On 12 April 2018 at 22:57, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > I wanted to try Pharo Laucher before the tech talk > > But I get this when asking for an image > > > I do not even know what is going on and I am an "experienced user". > > The impression this gives to a newcomer is utterly disastrous. > > We are really on a bad path on this. > > I'd like to get through this with some Launcher expert and fix this for > good. > > Phil > >

April 12, 2018