February 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] fully self-contained Linux VM

by Nicolai Hess

2016-02-23 13:35 GMT+01:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: > Hi, > > is it possible to have fully self-contained Linux VM? > > Right now if you want to use Pharo on Linux you have to install some > libraries directly in the system, which isn't particularly user-friendly. > > I know that for example libcairo (needed by Roassal) has hard-coded > library paths, but maybe this can be changed so the library can be in the > zip. > > Could something like that be done also for the remaining lib32 libraries > required to run the VM? > > Even if it had to be a special bundle for each linux distribution. > If you have a 64Bit linux, you may to have include *a lot* of extra libraries. libcairo (for 32Bit) alone is not enough. You need all the other 32Bit libraries, cairo depends on. > > Thanks, > Peter >

Feb. 23, 2016

Re: [Pharo-dev] [Bloc] Do we want <return: #Point> or <return: Point>

by Tudor Girba

> On Feb 23, 2016, at 1:17 PM, stepharo <stepharo(a)free.fr> wrote: > > I do not think that Pharo will become a static language :) Certainly not a static language! :)) > For the moment we can let it as a documentation. > Now I would prefer to have tests because such annotations may be obsolete. Certainly. They should come. > Anyway the code quality of aleksei is really good. :) Doru > Le 23/2/16 10:33, Tudor Girba a Ã©crit : >> Hi, >> >> At the moment, it is used for documentation purposes in Bloc. It is part of the effort of Alex to document Bloc thoroughly. I think it is an interesting idea, in that we would have a significant case study for that can be used later as optional types information to improve static tool support. And it does not hurt at the moment. >> >> What do you think? >> >> Cheers, >> Doru >> >> >>> On Feb 23, 2016, at 10:25 AM, Alain Plantec via Pharo-dev <pharo-dev(a)lists.pharo.org> wrote: >>> >>> >>> From: Alain Plantec <alain.plantec(a)yahoo.com> >>> Subject: Re: [Pharo-dev] [Bloc] Do we want <return: #Point> or <return: Point> >>> Date: February 23, 2016 at 10:23:33 AM GMT+1 >>> To: Pharo Development List <pharo-dev(a)lists.pharo.org> >>> >>> >>> I donât like it too. >>> Alain >>> >>>> Le 23 fÃ©vr. 2016 Ã 09:50, Nicolai Hess <nicolaihess(a)gmail.com> a Ã©crit : >>>> >>>> >>>> >>>> 2016-02-23 9:47 GMT+01:00 stepharo <stepharo(a)free.fr>: >>>> Hi >>>> >>>> I saw that something <return: #Point> or <return: Point> >>>> I do not know why but I have the impression that <return: #Point> is better. >>>> Because we may have code not present and still want to load the code. >>>> >>>> I would like to know for what this is used. >>>> I don't like it. >>>> >>>> Stef >>>> >>>> >>> >>> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "We are all great at making mistakes." >> >> >> >> >> >> >> >> >> >> > > -- www.tudorgirba.com www.feenk.com "If you can't say why something is relevant, it probably isn't."

Feb. 23, 2016

fully self-contained Linux VM

by Peter UhnÃ¡k

Hi, is it possible to have fully self-contained Linux VM? Right now if you want to use Pharo on Linux you have to install some libraries directly in the system, which isn't particularly user-friendly. I know that for example libcairo (needed by Roassal) has hard-coded library paths, but maybe this can be changed so the library can be in the zip. Could something like that be done also for the remaining lib32 libraries required to run the VM? Even if it had to be a special bundle for each linux distribution. Thanks, Peter

Feb. 23, 2016

Re: [Pharo-dev] [Bloc] Do we want <return: #Point> or <return: Point>

by Esteban Lorenzano

> On 23 Feb 2016, at 13:20, Alain Plantec via Pharo-dev <pharo-dev(a)lists.pharo.org> wrote: > > > From: Alain Plantec <alain.plantec(a)yahoo.com> > Subject: Re: [Pharo-dev] [Bloc] Do we want <return: #Point> or <return: Point> > Date: 23 February 2016 at 13:19:34 GMT+1 > To: Pharo Development List <pharo-dev(a)lists.pharo.org> > > > Hello Doru, > >> On 23 Feb 2016, at 10:33, Tudor Girba <tudor(a)tudorgirba.com <mailto:tudor@tudorgirba.com>> wrote: >> >> Hi, >> >> At the moment, it is used for documentation purposes in Bloc. It is part of the effort of Alex to document Bloc thoroughly. I think it is an interesting idea, in that we would have a significant case study for that can be used later as optional types information to improve static tool support. And it does not hurt at the moment. >> >> What do you think? > > Experimenting optional types is a good idea. We could have Tools to dynamically check them. > What about a separate typing model that could be used to add/remove the types annotations ? > Also, I wonder if Bloc is the good package to experiment optional types. Maybe it is not stable enough. > Cheers > Alain please, please, please keep the scope of those experiments aside the main effort who is to have Block/Brick running as soon as possible. Esteban ps: â¦ optional typesâ¦ at the end, we will realise Gilad was right all this time :) > > >> >> Cheers, >> Doru >> >> >>> On Feb 23, 2016, at 10:25 AM, Alain Plantec via Pharo-dev <pharo-dev(a)lists.pharo.org <mailto:pharo-dev@lists.pharo.org>> wrote: >>> >>> >>> From: Alain Plantec <alain.plantec(a)yahoo.com <mailto:alain.plantec@yahoo.com>> >>> Subject: Re: [Pharo-dev] [Bloc] Do we want <return: #Point> or <return: Point> >>> Date: February 23, 2016 at 10:23:33 AM GMT+1 >>> To: Pharo Development List <pharo-dev(a)lists.pharo.org <mailto:pharo-dev@lists.pharo.org>> >>> >>> >>> I donât like it too. >>> Alain >>> >>>> Le 23 fÃ©vr. 2016 Ã 09:50, Nicolai Hess <nicolaihess(a)gmail.com <mailto:nicolaihess@gmail.com>> a Ã©crit : >>>> >>>> >>>> >>>> 2016-02-23 9:47 GMT+01:00 stepharo <stepharo(a)free.fr <mailto:stepharo@free.fr>>: >>>> Hi >>>> >>>> I saw that something <return: #Point> or <return: Point> >>>> I do not know why but I have the impression that <return: #Point> is better. >>>> Because we may have code not present and still want to load the code. >>>> >>>> I would like to know for what this is used. >>>> I don't like it. >>>> >>>> >>>> Stef >>>> >>>> >>> >>> >>> >> >> -- >> www.tudorgirba.com <http://www.tudorgirba.com/> >> www.feenk.com <http://www.feenk.com/> >> >> "We are all great at making mistakes." > > >

Feb. 23, 2016

Re: [Pharo-dev] [pharo-project/pharo-core] a1da99: 50599

by Esteban Lorenzano

> On 23 Feb 2016, at 11:42, Ben Coman <btc(a)openInWorld.com> wrote: > > but these log messages *should* include all the linked issues. > cheers -ben this is a bug in the integrator build of log message :P Esteban > > On Tue, Feb 23, 2016 at 4:17 PM, stepharo <stepharo(a)free.fr> wrote: >> The session manager is managed as a configuration? >> Impressed! >> >> Stef >> >> Le 22/2/16 18:26, GitHub a Ã©crit : >> >>> >>> Log Message: >>> ----------- >>> 50599 >>> ConfigurationOfSessionManager >>> >>> http://files.pharo.org/image/50/50599.zip >>> >>> >> >> >

Feb. 23, 2016

Re: [Pharo-dev] [Bloc] Do we want <return: #Point> or <return: Point>

by Alain Plantec

Hello Doru, > On 23 Feb 2016, at 10:33, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > At the moment, it is used for documentation purposes in Bloc. It is part of the effort of Alex to document Bloc thoroughly. I think it is an interesting idea, in that we would have a significant case study for that can be used later as optional types information to improve static tool support. And it does not hurt at the moment. > > What do you think? Experimenting optional types is a good idea. We could have Tools to dynamically check them. What about a separate typing model that could be used to add/remove the types annotations ? Also, I wonder if Bloc is the good package to experiment optional types. Maybe it is not stable enough. Cheers Alain > > Cheers, > Doru > > >> On Feb 23, 2016, at 10:25 AM, Alain Plantec via Pharo-dev <pharo-dev(a)lists.pharo.org <mailto:pharo-dev@lists.pharo.org>> wrote: >> >> >> From: Alain Plantec <alain.plantec(a)yahoo.com <mailto:alain.plantec@yahoo.com>> >> Subject: Re: [Pharo-dev] [Bloc] Do we want <return: #Point> or <return: Point> >> Date: February 23, 2016 at 10:23:33 AM GMT+1 >> To: Pharo Development List <pharo-dev(a)lists.pharo.org> >> >> >> I donât like it too. >> Alain >> >>> Le 23 fÃ©vr. 2016 Ã 09:50, Nicolai Hess <nicolaihess(a)gmail.com> a Ã©crit : >>> >>> >>> >>> 2016-02-23 9:47 GMT+01:00 stepharo <stepharo(a)free.fr>: >>> Hi >>> >>> I saw that something <return: #Point> or <return: Point> >>> I do not know why but I have the impression that <return: #Point> is better. >>> Because we may have code not present and still want to load the code. >>> >>> I would like to know for what this is used. >>> I don't like it. >>> >>> >>> Stef >>> >>> >> >> >> > > -- > www.tudorgirba.com <http://www.tudorgirba.com/> > www.feenk.com <http://www.feenk.com/> > > "We are all great at making mistakes."

Feb. 23, 2016

Re: [Pharo-dev] [Bloc] Do we want <return: #Point> or <return: Point>

by stepharo

I do not think that Pharo will become a static language :) For the moment we can let it as a documentation. Now I would prefer to have tests because such annotations may be obsolete. Anyway the code quality of aleksei is really good. Le 23/2/16 10:33, Tudor Girba a Ã©crit : > Hi, > > At the moment, it is used for documentation purposes in Bloc. It is part of the effort of Alex to document Bloc thoroughly. I think it is an interesting idea, in that we would have a significant case study for that can be used later as optional types information to improve static tool support. And it does not hurt at the moment. > > What do you think? > > Cheers, > Doru > > >> On Feb 23, 2016, at 10:25 AM, Alain Plantec via Pharo-dev <pharo-dev(a)lists.pharo.org> wrote: >> >> >> From: Alain Plantec <alain.plantec(a)yahoo.com> >> Subject: Re: [Pharo-dev] [Bloc] Do we want <return: #Point> or <return: Point> >> Date: February 23, 2016 at 10:23:33 AM GMT+1 >> To: Pharo Development List <pharo-dev(a)lists.pharo.org> >> >> >> I donât like it too. >> Alain >> >>> Le 23 fÃ©vr. 2016 Ã 09:50, Nicolai Hess <nicolaihess(a)gmail.com> a Ã©crit : >>> >>> >>> >>> 2016-02-23 9:47 GMT+01:00 stepharo <stepharo(a)free.fr>: >>> Hi >>> >>> I saw that something <return: #Point> or <return: Point> >>> I do not know why but I have the impression that <return: #Point> is better. >>> Because we may have code not present and still want to load the code. >>> >>> I would like to know for what this is used. >>> I don't like it. >>> >>> >>> Stef >>> >>> >> >> > -- > www.tudorgirba.com > www.feenk.com > > "We are all great at making mistakes." > > > > > > > > > >

Feb. 23, 2016

Re: [Pharo-dev] [Bloc] Do we want <return: #Point> or <return: Point>

by stepharo

Ok so I will use # Stef Le 23/2/16 11:09, Nicolai Hess a Ã©crit : > Old compiler does not allowed > <return: Point> > only > <return: #Point> > > And I think opal should behave the same (not fixed yet) > > > > 2016-02-23 11:01 GMT+01:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com > <mailto:i.uhnak@gmail.com>>: > > >Because we may have code not present and still want to load the code. > > I think it's just visual, because it's still referenced as string > in the pragma itself. > For example > > Person>>contact > <DCType: Contact multiplicity: #(1 '*')> > ^ contact ifNil: [ contact := OrderedCollection new ] > > But, > (Person>>#contact) pragmas first arguments first class == ByteSymbol > > Does it fail to load otherwise? > > Peter > > On Tue, Feb 23, 2016 at 10:43 AM, Alexandre Bergel > <alexandre.bergel(a)me.com <mailto:alexandre.bergel@me.com>> wrote: > > Just emerging from holidays. Is there an effort to have type > annotations? How these annotations are then used? > > Alexandre > > > > On Feb 23, 2016, at 5:47 AM, stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>> wrote: > > > > Hi > > > > I saw that something <return: #Point> or <return: Point> > > I do not know why but I have the impression that <return: > #Point> is better. > > Because we may have code not present and still want to load > the code. > > > > Stef > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > >

Feb. 23, 2016

Re: [Pharo-dev] [Bloc] Do we want <return: #Point> or <return: Point>

by stepharo

Pablo Tesone Phd was on type inferencing but he accepted another PhD topics with Noury and us. Le 23/2/16 10:43, Alexandre Bergel a Ã©crit : > Just emerging from holidays. Is there an effort to have type annotations? How these annotations are then used? > > Alexandre > > >> On Feb 23, 2016, at 5:47 AM, stepharo <stepharo(a)free.fr> wrote: >> >> Hi >> >> I saw that something <return: #Point> or <return: Point> >> I do not know why but I have the impression that <return: #Point> is better. >> Because we may have code not present and still want to load the code. >> >> Stef >>

Feb. 23, 2016

Re: [Pharo-dev] double selection in the debugger is confusing

by Esteban Lorenzano

> On 23 Feb 2016, at 08:49, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > 2016-02-23 8:46 GMT+01:00 stepharo <stepharo(a)free.fr <mailto:stepharo@free.fr>>: > > > Le 22/2/16 09:50, Nicolai Hess a Ã©crit : >> >> >> 2016-02-21 19:19 GMT+01:00 stepharo <stepharo(a)free.fr <mailto:stepharo@free.fr>>: >> Here this is terribly confusing because we could think that the execution will go inside >> the true block but no in reality it is jumping right after. >> So we must remove this selection of matching terms. >> >> This was always like that, but with rubric, the "second selection" highlight is much more visible. >> In older non-rubric text handling, the second selection was just a pale light color, without border. >> >> Maybe we should remove the border for rubrics "second selection" text highlight. > > Yes! > > Ok, I'll open an issue entry and provide a fix. And you can discuss with Esteban if we want to include this > in the code freeze :-) for me this is a bug, not an enhancement (is super annoying, and then an usability bug). so I vote yes. > > >> >> >> >> Stef >> >> Le 21/2/16 19:04, stepharo a Ã©crit : >> >> Hi guy >> >> we should disable the double selection when we click on a stack element >> because we get selection in frame and in fill and this is confusing because the PC is represented by the filled >> one. >> >> Stef

Feb. 23, 2016