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

Re: [Pharo-project] beta 1.4 documentation online

by Guillermo Polito

BTW, cool :) On Tue, Mar 12, 2013 at 2:49 PM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > > On Tue, Mar 12, 2013 at 2:18 PM, Camillo Bruni <camillobruni(a)gmail.com>wrote: > >> finally, after the 100th attempt I managed to export the documentation on >> 1.4 >> >> http://pharo.gforge.inria.fr/doc/1.4 >> >> this weekend I will tackle 2.0 :) and of course, it still needs some love! >> >> > - How can I export it myself too? > - We should report issues about it in the foogzbuz (or whatever it is > called I cannot reproduce yet :P). >

March 12, 2013

Re: [Pharo-project] beta 1.4 documentation online

by Guillermo Polito

On Tue, Mar 12, 2013 at 2:18 PM, Camillo Bruni <camillobruni(a)gmail.com>wrote: > finally, after the 100th attempt I managed to export the documentation on > 1.4 > > http://pharo.gforge.inria.fr/doc/1.4 > > this weekend I will tackle 2.0 :) and of course, it still needs some love! > > - How can I export it myself too? - We should report issues about it in the foogzbuz (or whatever it is called I cannot reproduce yet :P).

March 12, 2013

Re: [Pharo-project] Zeroconf: config command issue - oops

by Camillo Bruni

aah good. On 2013-03-12, at 14:04, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: > yep, works. Thanks. Issue(s) submitted. > > 2013/3/12 Camillo Bruni <camillobruni(a)gmail.com>: >> >> On 2013-03-12, at 13:49, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: >> >>> account please. >> >> I added you with phil(a)highoctane.be already a while ago. >> >

March 12, 2013

[Pharo-project] beta 1.4 documentation online

by Camillo Bruni

finally, after the 100th attempt I managed to export the documentation on 1.4 http://pharo.gforge.inria.fr/doc/1.4 this weekend I will tackle 2.0 :) and of course, it still needs some love!

March 12, 2013

[Pharo-project] When is 2.0 shipping?

by phil＠highoctane.be

As I saw 11/3 in the fogbugz tracker, I wondered. BTW, hi there, Penelope :-) Funny! Phil

March 12, 2013

Re: [Pharo-project] Zeroconf: config command issue - oops

by phil＠highoctane.be

yep, works. Thanks. Issue(s) submitted. 2013/3/12 Camillo Bruni <camillobruni(a)gmail.com>: > > On 2013-03-12, at 13:49, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: > >> account please. > > I added you with phil(a)highoctane.be already a while ago. >

March 12, 2013

Re: [Pharo-project] [Moose-dev] Re: where to report vm crashes? (while running Moose tests)

by phil＠highoctane.be

Yes, this headless thing is really building traction. Phil 2013/3/12 Sven Van Caekenberghe <sven(a)stfx.eu>: > > On 12 Mar 2013, at 12:15, Camillo Bruni <camillobruni(a)gmail.com> wrote: > >> On 2013-03-12, at 10:17, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >>> Camillo, >>> >>> On 12 Mar 2013, at 09:39, Camillo Bruni <camillobruni(a)gmail.com> wrote: >>> >>>> from that point of view, it is just a warning. Unless you do some fancy >>>> new FileSystem stuff it will continue to work with 2.0 and for a while with >>>> 3.0. >>> >>> Is it not possible to clarify *exactly* what is missing and will not work well. >>> >>> Right now this is like a mystery. >>> >>> We are all developers and capable of understanding a technical explanation ;-) >>> >>> Which primitives are we talking about, how are they used and what end user effect do they have ? >>> >>> I know that NativeBoost is an important difference. The question is, will the image start without proper NB support and will something be broken if NB is non-functional (apart from NB code itself, I mean high level normal stuff) ? > > Thanks for the answers, Camillo. > > First off: I am absolutely for a Pharo vm - we need to take maximal control over this crucial element. Incredible progress has been made the last year, year and a half, and that is fantastic and has to continue. The bin directory is cleaner and all the scripting is much better. > >> Well so far there is only some FileSystem primitives, and besides the tests nobody >> ever relied on getting the permissions or checks if a file is an symlink. But we >> can do that now. > > But you still did not answer exactly which primitives, which methods. I think this is important knowledge that has to be public and documented. > >> NativeBoost is shipped with 2.0 but not yet used in the Kernel, but this is going >> to change in 3.0 where we hope to rewrite the UI driver talking to Cairo using >> an NativeBoost-FFI binding. >> >> The thing is, I don't want to care and define which external VMs work with which >> Pharo version. (Still, yes you can run Pharo 20 on CogVM, we just don't like it :P ) > > I agree that we should maximally use the same Pharo VM to get the best possible testing exposure and to improve the quality. > > But it is very important to be able to diagnose strange VM crashes by using different VM's. The JIT code is still under active development and we need Eliot in the loop. He needs the option that the large Pharo community uses/tests his work, we need his help. > > Maybe given a clear description of the primitives situation will result in enough users asking for them to be included in the standard Cog VM as well. > >> Pharo ships and runs only with the Pharo and the PharoS VM. >> Currently the situation is not perfect with our VMs being unstable > > I was doing some more builds today with the headless Pharo VM on Linux and these went fine. I like the config handler more and more ! > > Sven > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > >

March 12, 2013

Re: [Pharo-project] [Moose-dev] Re: where to report vm crashes? (while running Moose tests)

by Sven Van Caekenberghe

On 12 Mar 2013, at 12:15, Camillo Bruni <camillobruni(a)gmail.com> wrote: > On 2013-03-12, at 10:17, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> Camillo, >> >> On 12 Mar 2013, at 09:39, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> >>> from that point of view, it is just a warning. Unless you do some fancy >>> new FileSystem stuff it will continue to work with 2.0 and for a while with >>> 3.0. >> >> Is it not possible to clarify *exactly* what is missing and will not work well. >> >> Right now this is like a mystery. >> >> We are all developers and capable of understanding a technical explanation ;-) >> >> Which primitives are we talking about, how are they used and what end user effect do they have ? >> >> I know that NativeBoost is an important difference. The question is, will the image start without proper NB support and will something be broken if NB is non-functional (apart from NB code itself, I mean high level normal stuff) ? Thanks for the answers, Camillo. First off: I am absolutely for a Pharo vm - we need to take maximal control over this crucial element. Incredible progress has been made the last year, year and a half, and that is fantastic and has to continue. The bin directory is cleaner and all the scripting is much better. > Well so far there is only some FileSystem primitives, and besides the tests nobody > ever relied on getting the permissions or checks if a file is an symlink. But we > can do that now. But you still did not answer exactly which primitives, which methods. I think this is important knowledge that has to be public and documented. > NativeBoost is shipped with 2.0 but not yet used in the Kernel, but this is going > to change in 3.0 where we hope to rewrite the UI driver talking to Cairo using > an NativeBoost-FFI binding. > > The thing is, I don't want to care and define which external VMs work with which > Pharo version. (Still, yes you can run Pharo 20 on CogVM, we just don't like it :P ) I agree that we should maximally use the same Pharo VM to get the best possible testing exposure and to improve the quality. But it is very important to be able to diagnose strange VM crashes by using different VM's. The JIT code is still under active development and we need Eliot in the loop. He needs the option that the large Pharo community uses/tests his work, we need his help. Maybe given a clear description of the primitives situation will result in enough users asking for them to be included in the standard Cog VM as well. > Pharo ships and runs only with the Pharo and the PharoS VM. > Currently the situation is not perfect with our VMs being unstable I was doing some more builds today with the headless Pharo VM on Linux and these went fine. I like the config handler more and more ! Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

March 12, 2013

Re: [Pharo-project] Zeroconf: config command issue - oops

by phil＠highoctane.be

Ok, never saw that I guess. Anyway, asking for a new password right away. 2013/3/12 Camillo Bruni <camillobruni(a)gmail.com>: > > On 2013-03-12, at 13:49, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: > >> account please. > > I added you with phil(a)highoctane.be already a while ago. >

March 12, 2013

Re: [Pharo-project] Zeroconf: config command issue - oops

by Camillo Bruni

On 2013-03-12, at 13:49, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: > account please. I added you with phil(a)highoctane.be already a while ago.

March 12, 2013