- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Jenkins down

by Pavel Krivanek

It's working again... Now you can look at the first tests results from Gulle's bootstrapped image :-) https://ci.lille.inria.fr/pharo/view/Seed%20Project/job/Seed%20-%20SUnit%20… -- Pavel On Fri, Jun 29, 2012 at 9:50 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > Hi, > > Jenkins (https://ci.lille.inria.fr/pharo/) seems to be down. It > stopped responding when the job Seed - SUnit Tests was finishing. > > -- Pavel

June 29, 2012

[Pharo-project] Jenkins down

by Pavel Krivanek

Hi, Jenkins (https://ci.lille.inria.fr/pharo/) seems to be down. It stopped responding when the job Seed - SUnit Tests was finishing. -- Pavel

June 29, 2012

Re: [Pharo-project] EvaluateCommandLineHandler changes

by Guillermo Polito

But why another handler if you could put that in the CommandLineArguments? On Fri, Jun 29, 2012 at 9:06 AM, Camillo Bruni <camillobruni(a)gmail.com>wrote: > On 2012-06-29, at 08:40, Guillermo Polito wrote: > > On Fri, Jun 29, 2012 at 8:40 AM, Guillermo Polito < > guillermopolito(a)gmail.com > >> wrote: > > > >> What if the fileIn is just joined at the end of the argument list for > >> every handler? That way you will be able to do > >> > >> meant stdin :) > > > > > >> echo "-eval blabla" | Vm Image > >> > >> or > >> > >> echo blabla | Vm Image -eval > >> > >> ls | grep fuel | vm image > >> > > why not :) We can easily do that with another command-line class which > always > returns true for #isReponsible: but has a very low priority :) > > >

June 29, 2012

Re: [Pharo-project] EvaluateCommandLineHandler changes

by Camillo Bruni

On 2012-06-29, at 08:40, Guillermo Polito wrote: > On Fri, Jun 29, 2012 at 8:40 AM, Guillermo Polito <guillermopolito(a)gmail.com >> wrote: > >> What if the fileIn is just joined at the end of the argument list for >> every handler? That way you will be able to do >> >> meant stdin :) > > >> echo "-eval blabla" | Vm Image >> >> or >> >> echo blabla | Vm Image -eval >> >> ls | grep fuel | vm image >> why not :) We can easily do that with another command-line class which always returns true for #isReponsible: but has a very low priority :)

June 29, 2012

Re: [Pharo-project] EvaluateCommandLineHandler changes

by Guillermo Polito

On Fri, Jun 29, 2012 at 8:40 AM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > What if the fileIn is just joined at the end of the argument list for > every handler? That way you will be able to do > > meant stdin :) > echo "-eval blabla" | Vm Image > > or > > echo blabla | Vm Image -eval > > ls | grep fuel | vm image > > > > On Thu, Jun 28, 2012 at 10:06 PM, Guillermo Polito < > guillermopolito(a)gmail.com> wrote: > >> :3 great. BTW, los command line handlers son la papa :). >> >> >> On Thu, Jun 28, 2012 at 10:03 PM, Camillo Bruni <camillobruni(a)gmail.com>wrote: >> >>> >>> On 2012-06-28, at 22:01, Camillo Bruni wrote: >>> >>> > >>> > On 2012-06-28, at 21:31, Guillermo Polito wrote: >>> > >>> >> Hi Camillo, >>> >> >>> >> the latest introduction of this: >>> >> >>> >> "check if we have an opened stdin" >>> >> FileStream stdin ifNotNilDo:[ :stream| >>> >> stream atEnd ifFalse: [ ^ true ]]. >>> >> >>> >> (I assume for piping?) >>> > >>> > exactly.... >>> > >>> >> Is messing with my other command line args... lets say I have another >>> >> command line argument that runs tests and I do: >>> >> >>> >> Vm image --tests >>> >> >>> >> It tries to open it with the EvaluateCommandLineHandler :S... >>> >> >>> >> Args is: >>> >> >>> >> an OrderedCollection('--test') >>> >> >>> >> And the command line handlers after selecting the responsibles are: >>> >> >>> >> an OrderedCollection(EvaluateCommandLineHandler >>> >> RunTestsCommandLineHandler DefaultCommandLineHandler) >>> >> >>> >> By now I'll try putting my handler a higher priority (1 :P), but, is >>> >> this the expected behavior? >>> > >>> > >>> > >>> > you're right, that's broken (AKA we should add some tests there :P) >>> > >>> > I wanted to write something different there... >>> >>> maybe the filestream test should simply be removed, then piping in >>> commands only works when explicitely specifying the "eval" handler >>> >>> >> >

June 29, 2012

Re: [Pharo-project] EvaluateCommandLineHandler changes

by Guillermo Polito

What if the fileIn is just joined at the end of the argument list for every handler? That way you will be able to do echo "-eval blabla" | Vm Image or echo blabla | Vm Image -eval ls | grep fuel | vm image On Thu, Jun 28, 2012 at 10:06 PM, Guillermo Polito < guillermopolito(a)gmail.com> wrote: > :3 great. BTW, los command line handlers son la papa :). > > > On Thu, Jun 28, 2012 at 10:03 PM, Camillo Bruni <camillobruni(a)gmail.com>wrote: > >> >> On 2012-06-28, at 22:01, Camillo Bruni wrote: >> >> > >> > On 2012-06-28, at 21:31, Guillermo Polito wrote: >> > >> >> Hi Camillo, >> >> >> >> the latest introduction of this: >> >> >> >> "check if we have an opened stdin" >> >> FileStream stdin ifNotNilDo:[ :stream| >> >> stream atEnd ifFalse: [ ^ true ]]. >> >> >> >> (I assume for piping?) >> > >> > exactly.... >> > >> >> Is messing with my other command line args... lets say I have another >> >> command line argument that runs tests and I do: >> >> >> >> Vm image --tests >> >> >> >> It tries to open it with the EvaluateCommandLineHandler :S... >> >> >> >> Args is: >> >> >> >> an OrderedCollection('--test') >> >> >> >> And the command line handlers after selecting the responsibles are: >> >> >> >> an OrderedCollection(EvaluateCommandLineHandler >> >> RunTestsCommandLineHandler DefaultCommandLineHandler) >> >> >> >> By now I'll try putting my handler a higher priority (1 :P), but, is >> >> this the expected behavior? >> > >> > >> > >> > you're right, that's broken (AKA we should add some tests there :P) >> > >> > I wanted to write something different there... >> >> maybe the filestream test should simply be removed, then piping in >> commands only works when explicitely specifying the "eval" handler >> >> >

June 29, 2012

Re: [Pharo-project] VM , modules, packages and plugins

by Dale Henrichs

Igor, embedded comments... ----- Original Message ----- | From: "Igor Stasenko" <siguctua(a)gmail.com> | To: Pharo-project(a)lists.gforge.inria.fr | Sent: Thursday, June 28, 2012 1:10:50 PM | Subject: Re: [Pharo-project] VM , modules, packages and plugins | | On 28 June 2012 21:14, Dale Henrichs <dhenrich(a)vmware.com> wrote: | > Igor, | > | > As you may or may not know, I am currently in the process of | > teaching Metacello to work with git/github and one of the pieces | > involves downloading and unzipping directory structure ... at the | > moment Metacello only works with package dependencies, but it | > wouldn't be a big leap to be able to manage non-source related | > dependencies so it might be possible for a configuration to | > declare a dependency upon a plugin which could be downloaded and | > moved to the appropriate location via Metacello ... | > | | > If that type of facility would be useful, now is a good time to let | > me know, since I'm hip deep in that code as we speak:) | | Hi, Dale. | Yes, i think this can be one part of the puzzle. I am unsure however, | how you can do that nicely across dialects, | because different VMs having different requirements.. | | But i think this not a big deal, because i know that Metacello | already | deals with dialect-specific-ness in some way :) Yes we have options there ... I do have access to the Metacello internals:), so we shouldn't try to shoehorn the requirements into existing slots (unless they fit nicely) ... pre&post load actions already exist ... conditional platform logic already exists ... the main challenge for a `plugin` entity would be to avoid trying to load it ... so I think it would be something that could be done given a compelling use case. | | So, here my thoughts about it: | actually what we need is to formalize 2 aspects about VM plugins | (or/and external libraries in general): | - a way to detect what is available | - a way to install if that not available Yes, these are the challenges. The idea behind Metacello is that the primary developer is able to make the decision ("detect what is available") and specify the explicit version and location of the plugin for download. Which leaves "a way to install if that not available" ... which is presumably challenge enough:) | | And, We should not assume that we having some centralized | "repository" | or "registry", because | it is futile, considering the zoo of dialects*platforms*different | versions.... so defining what/where to download (and making sure it | works) should be the responsibility of developer, but not some | committee of high priests who deciding what goes/fits into distro and | what not. Exactly ... for "optional plugins" it has to be the project maintainer(s) who are responsible for vetting the which plugin works with their code as the coupling between the plugin and code is pretty tight ... | | | And, of course i like it to be | a) simple | b) flexible | | :) Don't we all:) | | > | > Dale | > | > ----- Original Message ----- | > | From: "Igor Stasenko" <siguctua(a)gmail.com> | > | To: Pharo-project(a)lists.gforge.inria.fr | > | Sent: Thursday, June 28, 2012 11:36:21 AM | > | Subject: Re: [Pharo-project] VM , modules, packages and plugins | > | | > | On 28 June 2012 06:43, Torsten Bergmann <astares(a)gmx.de> wrote: | > | >>What i would like to see one day is when i installing new code | > | >>into | > | >>image, it pops up a message: | > | >>"Your VM missing an XYZ plugin for running this cool code, | > | >>would | > | >>you | > | >>like to download and install it? Yes No " | > | > | > | > The first problem is that there is no consolidated way to find | > | > the plugins. Or am I'm missing something. | > | | > | Yes. But we should not tolerate a current status quo.. | > | it starting really pedaling our efforts to improve the situation. | > | | > | > | > | > Remember this: | > | > | > | > http://code.google.com/p/pharo/wiki/VMPluginOverview | > | > http://web.archiveorange.com/archive/v/omFiNcYAwvI6GB8z7r1j | > | > | > | yes, thanks for reminder. | > | | > | > As ever it is a question of time to define and implement a | > | > working process. | > | > | > | | > | So, my vision that it should not be something external which | > | user(s) | > | must download | > | and install separately and manually. Does everyone knows that | > | page | > | exists? | > | Or, actually, why users must be concerned about those details: if | > | they | > | found a way to load | > | the code which using plugin, the rest should be NOT of their | > | concern, | > | a system must | > | do the rest automatically. | > | | > | The code, which using the plugin SHOULD have the Â knowledge about | > | how | > | to locate the plugin | > | and install it, and of course, which version of it to use. | > | This , i think, could kill many hurdles in distribution process | > | and | > | improve user's experience. | > | | > | > Bye | > | > T. | > | > -- | > | > NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone! | > | > Jetzt informieren: | > | > http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a | > | > | > | | > | | > | | > | -- | > | Best regards, | > | Igor Stasenko. | > | | > | | > | | | | -- | Best regards, | Igor Stasenko. | |

June 28, 2012

Re: [Pharo-project] VM , modules, packages and plugins

by Guillermo Polito

On Thu, Jun 28, 2012 at 10:10 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 28 June 2012 21:14, Dale Henrichs <dhenrich(a)vmware.com> wrote: > > Igor, > > > > As you may or may not know, I am currently in the process of teaching > Metacello to work with git/github and one of the pieces involves > downloading and unzipping directory structure ... at the moment Metacello > only works with package dependencies, but it wouldn't be a big leap to be > able to manage non-source related dependencies so it might be possible for > a configuration to declare a dependency upon a plugin which could be > downloaded and moved to the appropriate location via Metacello ... > > > > > If that type of facility would be useful, now is a good time to let me > know, since I'm hip deep in that code as we speak:) > > Hi, Dale. > Yes, i think this can be one part of the puzzle. I am unsure however, > how you can do that nicely across dialects, > because different VMs having different requirements.. > > But i think this not a big deal, because i know that Metacello already > deals with dialect-specific-ness in some way :) > > So, here my thoughts about it: > actually what we need is to formalize 2 aspects about VM plugins > (or/and external libraries in general): > - a way to detect what is available > - a way to install if that not available > > And, We should not assume that we having some centralized "repository" > or "registry", because > it is futile, considering the zoo of dialects*platforms*different > versions.... so defining what/where to download (and making sure it > works) should be the responsibility of developer, but not some > committee of high priests who deciding what goes/fits into distro and > what not. > > > And, of course i like it to be > a) simple > b) flexible > > :) > This (binary storage problem) will apply to fuel packages in the near future also. And It'll be massive (not something about 30 plugins only). > > > > Dale > > > > ----- Original Message ----- > > | From: "Igor Stasenko" <siguctua(a)gmail.com> > > | To: Pharo-project(a)lists.gforge.inria.fr > > | Sent: Thursday, June 28, 2012 11:36:21 AM > > | Subject: Re: [Pharo-project] VM , modules, packages and plugins > > | > > | On 28 June 2012 06:43, Torsten Bergmann <astares(a)gmx.de> wrote: > > | >>What i would like to see one day is when i installing new code into > > | >>image, it pops up a message: > > | >>"Your VM missing an XYZ plugin for running this cool code, would > > | >>you > > | >>like to download and install it? Yes No " > > | > > > | > The first problem is that there is no consolidated way to find > > | > the plugins. Or am I'm missing something. > > | > > | Yes. But we should not tolerate a current status quo.. > > | it starting really pedaling our efforts to improve the situation. > > | > > | > > > | > Remember this: > > | > > > | > http://code.google.com/p/pharo/wiki/VMPluginOverview > > | > http://web.archiveorange.com/archive/v/omFiNcYAwvI6GB8z7r1j > > | > > > | yes, thanks for reminder. > > | > > | > As ever it is a question of time to define and implement a > > | > working process. > > | > > > | > > | So, my vision that it should not be something external which user(s) > > | must download > > | and install separately and manually. Does everyone knows that page > > | exists? > > | Or, actually, why users must be concerned about those details: if > > | they > > | found a way to load > > | the code which using plugin, the rest should be NOT of their concern, > > | a system must > > | do the rest automatically. > > | > > | The code, which using the plugin SHOULD have the knowledge about how > > | to locate the plugin > > | and install it, and of course, which version of it to use. > > | This , i think, could kill many hurdles in distribution process and > > | improve user's experience. > > | > > | > Bye > > | > T. > > | > -- > > | > NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone! > > | > Jetzt informieren: > > | > http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a > > | > > > | > > | > > | > > | -- > > | Best regards, > > | Igor Stasenko. > > | > > | > > > > > > -- > Best regards, > Igor Stasenko. > >

June 28, 2012

Re: [Pharo-project] VM , modules, packages and plugins

by Igor Stasenko

On 28 June 2012 21:14, Dale Henrichs <dhenrich(a)vmware.com> wrote: > Igor, > > As you may or may not know, I am currently in the process of teaching Metacello to work with git/github and one of the pieces involves downloading and unzipping directory structure ... at the moment Metacello only works with package dependencies, but it wouldn't be a big leap to be able to manage non-source related dependencies so it might be possible for a configuration to declare a dependency upon a plugin which could be downloaded and moved to the appropriate location via Metacello ... > > If that type of facility would be useful, now is a good time to let me know, since I'm hip deep in that code as we speak:) Hi, Dale. Yes, i think this can be one part of the puzzle. I am unsure however, how you can do that nicely across dialects, because different VMs having different requirements.. But i think this not a big deal, because i know that Metacello already deals with dialect-specific-ness in some way :) So, here my thoughts about it: actually what we need is to formalize 2 aspects about VM plugins (or/and external libraries in general): - a way to detect what is available - a way to install if that not available And, We should not assume that we having some centralized "repository" or "registry", because it is futile, considering the zoo of dialects*platforms*different versions.... so defining what/where to download (and making sure it works) should be the responsibility of developer, but not some committee of high priests who deciding what goes/fits into distro and what not. And, of course i like it to be a) simple b) flexible :) > > Dale > > ----- Original Message ----- > | From: "Igor Stasenko" <siguctua(a)gmail.com> > | To: Pharo-project(a)lists.gforge.inria.fr > | Sent: Thursday, June 28, 2012 11:36:21 AM > | Subject: Re: [Pharo-project] VM , modules, packages and plugins > | > | On 28 June 2012 06:43, Torsten Bergmann <astares(a)gmx.de> wrote: > | >>What i would like to see one day is when i installing new code into > | >>image, it pops up a message: > | >>"Your VM missing an XYZ plugin for running this cool code, would > | >>you > | >>like to download and install it? Yes No " > | > > | > The first problem is that there is no consolidated way to find > | > the plugins. Or am I'm missing something. > | > | Yes. But we should not tolerate a current status quo.. > | it starting really pedaling our efforts to improve the situation. > | > | > > | > Remember this: > | > > | > http://code.google.com/p/pharo/wiki/VMPluginOverview > | > http://web.archiveorange.com/archive/v/omFiNcYAwvI6GB8z7r1j > | > > | yes, thanks for reminder. > | > | > As ever it is a question of time to define and implement a > | > working process. > | > > | > | So, my vision that it should not be something external which user(s) > | must download > | and install separately and manually. Does everyone knows that page > | exists? > | Or, actually, why users must be concerned about those details: if > | they > | found a way to load > | the code which using plugin, the rest should be NOT of their concern, > | a system must > | do the rest automatically. > | > | The code, which using the plugin SHOULD have the Â knowledge about how > | to locate the plugin > | and install it, and of course, which version of it to use. > | This , i think, could kill many hurdles in distribution process and > | improve user's experience. > | > | > Bye > | > T. > | > -- > | > NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone! > | > Jetzt informieren: > | > http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a > | > > | > | > | > | -- > | Best regards, > | Igor Stasenko. > | > | > -- Best regards, Igor Stasenko.

June 28, 2012

Re: [Pharo-project] EvaluateCommandLineHandler changes

by Guillermo Polito

:3 great. BTW, los command line handlers son la papa :). On Thu, Jun 28, 2012 at 10:03 PM, Camillo Bruni <camillobruni(a)gmail.com>wrote: > > On 2012-06-28, at 22:01, Camillo Bruni wrote: > > > > > On 2012-06-28, at 21:31, Guillermo Polito wrote: > > > >> Hi Camillo, > >> > >> the latest introduction of this: > >> > >> "check if we have an opened stdin" > >> FileStream stdin ifNotNilDo:[ :stream| > >> stream atEnd ifFalse: [ ^ true ]]. > >> > >> (I assume for piping?) > > > > exactly.... > > > >> Is messing with my other command line args... lets say I have another > >> command line argument that runs tests and I do: > >> > >> Vm image --tests > >> > >> It tries to open it with the EvaluateCommandLineHandler :S... > >> > >> Args is: > >> > >> an OrderedCollection('--test') > >> > >> And the command line handlers after selecting the responsibles are: > >> > >> an OrderedCollection(EvaluateCommandLineHandler > >> RunTestsCommandLineHandler DefaultCommandLineHandler) > >> > >> By now I'll try putting my handler a higher priority (1 :P), but, is > >> this the expected behavior? > > > > > > > > you're right, that's broken (AKA we should add some tests there :P) > > > > I wanted to write something different there... > > maybe the filestream test should simply be removed, then piping in > commands only works when explicitely specifying the "eval" handler > >

June 28, 2012