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

Re: [Pharo-dev] [REMEMBER] TechTalk tomorrow 16UTC

by Dale Henrichs

Hmmm... since Esteban sent the email at 1 am my time and this _is_ tomorrow for me ... but perhaps Esteban means Tuesday? since I think this is still _today_ in Europe? Dale On 10/24/16 7:31 AM, Dale Henrichs wrote: > Since time is short (for me) and I still have to get out ouf bed, > shower eat and maybe get into the office before the meeting ... could > someone drop me an email with the details I need to find and install > (?) discord and find the techtalk ... I'll be out of pocket for about > an hour getting ready --- as this is short notice (for me) --- > > Thanks, > > Dale > > On 10/24/16 12:58 AM, Esteban Lorenzano wrote: >> Hello fellow pharoers, >> >> The time has come (1 month passes so fast!). And tomorrow we will be >> handling another TechTalk. >> This time we propose to talk about the new Bootstrap process. >> >> For this, Iâd ask Guille, Pavel and/or Christophe to be present. They >> are the ones actually working on it, so weâll all learn from what >> they have to say :) >> >> Meeting will be handled with discord, as last time. >> >> And as always, this will also be a place to ask anything about pharo >> development (statuses, proposals, etc., etc., etc.) >> >> See you tomorrow ! >> >> Esteban >

Oct. 24, 2016

Re: [Pharo-dev] [REMEMBER] TechTalk tomorrow 16UTC

by Dale Henrichs

Since time is short (for me) and I still have to get out ouf bed, shower eat and maybe get into the office before the meeting ... could someone drop me an email with the details I need to find and install (?) discord and find the techtalk ... I'll be out of pocket for about an hour getting ready --- as this is short notice (for me) --- Thanks, Dale On 10/24/16 12:58 AM, Esteban Lorenzano wrote: > Hello fellow pharoers, > > The time has come (1 month passes so fast!). And tomorrow we will be handling another TechTalk. > This time we propose to talk about the new Bootstrap process. > > For this, Iâd ask Guille, Pavel and/or Christophe to be present. They are the ones actually working on it, so weâll all learn from what they have to say :) > > Meeting will be handled with discord, as last time. > > And as always, this will also be a place to ask anything about pharo development (statuses, proposals, etc., etc., etc.) > > See you tomorrow ! > > Esteban

Oct. 24, 2016

Re: [Pharo-dev] [ANN] Scale

by Santiago Bragagnolo

Hi Denis! Thanks. There is an class called SCImageBundle. It represents the folder where you downloaded a pharo+vm. So you can instantiate it by hand SCImageBundle new directory: 'path' asFileReference. in any case, this is also the return of the following messages of the system object: #loadPharo: aVersion into: aFileReference #loadBaseline: aPackageName from: aRepository into: anImageBundle andSaveItAt: aDirectory #loadBaselineUI: aPackageName from: aRepository into: anImageBundle andSaveItAt: aDirectory So you can do something like (system home / #pharo) ensureCreateDirectory. pharo5 := system loadPharo: 50 into: system home / #pharo. pharo5WithScale := system loadBaseline: 'Scale' from: 'github://path' into: pharo5. Save after run just sets a flag. If to the end of the execution is on, it saves the image before shutting it down. If the script you are running is supposed to update the same image that is running you have to use this method (and run as sudo) On Mon, 24 Oct 2016 at 11:49 Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Really nice project, Santiago. > > I have few questions: > > - what "system saveAfterRun" actually do? > > As I understand it saves image when script completes. Imaging during > script I loaded Seaside. Does this command makes Seaside accessible from > any scale scripts? > > - system execute: aString into: anImageBundle > > What is anImageBundle here? > > - What you think to make scripts working as workspace? All undeclared > variables will be added to environment automatically. And in case of > saveAfterRun they will became accessible from any scale scripts. > > > 2016-10-23 20:34 GMT+02:00 Santiago Bragagnolo < > santiagobragagnolo(a)gmail.com>: > > Hi everybody. > > We are officially releasing a first version of scale. > > Scale is a command line handler that is there for making easier the life > of the people that uses scripting in linux. As such, we only tested it so > far in linux. It will be for sure easy to adapt it to mac because its a > *nix, but not for windoze. > > *IMPORTANT REMARK*: scale is not meant to develop applications, it is > meant to develop scripts in Pharo, to be launched from the command line. > This means that scale does not provide a top level syntax to declare > classes or methods: people should do that as any normal Pharo application. > Scale should be used to invoke such applications. > > When would you use scale? > - For example, to replace some bash scripts used for common boring tasks > (and you are using python or ruby there :P) > - Another example, would be when you want to replace bash scripts that > chain things like: > ./pharo eval --save "something" > ./pharo eval --save "other something" > ... > > Github: https://github.com/guillep/Scale > Oneliner to install: (note it needs sudo) > > wget -O- https://raw.githubusercontent.com/guillep/Scale/master/setupScale.sh | sudo bash > > > In the repository there is some user level documentation based on examples > and a list of available methods on the magical variable system. There are > many examples as well on the repository. > > Last but not least, I'm using this project in others two projects, where > it proof it self quite powerful what keeps me on maintaining Scale. > > These projects are: > > *Pharo Android VM building *https://github.com/sbragagnolo/pharo-vm > > Here I use it for automating the creation of a > * new building image, > * the creation of new resource image (for deploying on the android > apk), > * linking the android sources into the building directory > * generating the code from the console > > *MakrosTool* https://github.com/sbragagnolo/MakrosTool > > MakrosTool is an extension of scale that adds a second magical variable > for building up component reification in a ROS based environment. > > > Santiago & Guille > > > > > > >

Oct. 24, 2016

Re: [Pharo-dev] Fwd: Call for design for a literal programming doc similar to PythonDocTest

by phil＠highoctane.be

Nice, seems to work. Now, I tried to click on a package tag and add a comment at that level. For sure it erased the previous one. We may not allow people to edit package level comment when on a package tag. Also manifest >>description is like description ^ 'some desc' Would be nicer like description ^ 'some desc' Just sayin' b/c this is what the formatter does when asked. Phil Phil On Mon, Oct 24, 2016 at 9:35 AM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > 2016-10-10 21:29 GMT+02:00 phil(a)highoctane.be <phil(a)highoctane.be>: > >> Whatever would be better than what we have now. >> I like what you propose, makes sense and doesn't loads the UI with more >> stuff. >> >> I am willing to test your implementation for sure. >> > > > it is in now (Pharo 60267). If anything is missing, not working or > whatever, please report back. > (Packages without package manifest class show just nothing, but you can > add a new package comment (package manifest class will be created). > If a package manifest class exists, but without a #description you text > appears in the comment pane ("No package comment in this manifest .... > please add a comment"). > > >> >> Phil >> >> On Mon, Oct 10, 2016 at 6:56 PM, Nicolai Hess <nicolaihess(a)gmail.com> >> wrote: >> >>> >>> ---------- Forwarded message ---------- >>> From: Nicolai Hess <nicolaihess(a)gmail.com> >>> Date: 2016-09-16 17:01 GMT+02:00 >>> Subject: Re: [Pharo-dev] Call for design for a literal programming doc >>> similar to PythonDocTest >>> To: Pharo Development List <pharo-dev(a)lists.pharo.org> >>> >>> >>> >>> >>> 2016-09-16 0:19 GMT+02:00 phil(a)highoctane.be <phil(a)highoctane.be>: >>> >>>> I'd be more interested with a package level doc than a class doc or >>>> test. >>>> >>>> Package level doc is quite useful to outline how some things are >>>> working together, something which is quite hard to figure out except by >>>> reading external doc or inferring things by walking through the code or a >>>> running test. >>>> >>> >>> >>> Why don't we have yet package comments ? >>> I see there is some support for it in PackageManifest, I remember there >>> was some work (people working) on support for Nautilus, no? >>> >>> maybe something like this, (see attached file) >>> Nautilus comment pane >>> on class selection -> show class comment >>> no class selection -> show package comment (class side #description of >>> package manifest of this package) >>> you can even add or change the (package) comment, it will compile a >>> proper #description method on the manifest class) >>> >>> >>> Anyone looked at this ? >>> Is this what we can use for supporting and editing package comments? I >>> am not sure if the >>> use of package manifests is how we wanted to implement package comments. >>> Any other ideas? >>> >>> I can open a fogbugzs issue and refine this implementation a little bit. >>> >>> >>> >>>> Having the ability to read about a package would be very useful. >>>> Basically, this is what Java provides. >>>> >>>> http://docs.oracle.com/javase/7/docs/technotes/tools/solaris >>>> /javadoc.html#packagecomment >>>> >>>> Phil >>>> >>>> >>>> On Thu, Sep 15, 2016 at 8:45 PM, stepharo <stepharo(a)free.fr> wrote: >>>> >>>>> Hi all >>>>> >>>>> I want something similar in the spirit to PythonDocTest >>>>> https://docs.python.org/2/library/doctest.html >>>>> >>>>> I'm talking about >>>>> >>>>> basename >>>>> "Returns the base of the basename, >>>>> i.e. >>>>> /foo/gloops.taz basename is 'gloops.taz' >>>>> / basename is '/'" >>>>> >>>>> Pragmas do not work well i.e., >>>>> basename >>>>> "Returns the base of the basename" >>>>> <expr: '''/foo/gloops.taz'' asFileReference basename' result: >>>>> 'gloops.taz'> >>>>> >>>>> >>>>> We should invent a syntax to be put inside comments and that we can >>>>> easily parse because we need to improve >>>>> the use and discovery of the library. >>>>> >>>>> I was thinking about >>>>> >>>>> basename >>>>> "Returns the base of the basename" >>>>> " >>>>> '/foo/gloops.taz' asFileReference basename >>>>> >>> 'gloops.taz' >>>>> " >>>>> >>>>> Do you have any idea? >>>>> >>>>> I cannot not do anything and just complain that our methods are not >>>>> that well documented. >>>>> We as a community should take this and build an super cool system. >>>>> >>>>> I tried and defined >>> on Object to see if it works! >>>>> >>>>> Object >>> aResultingObject >>>>> "If the method comment contains >>> then it is a pharo >>>>> documentated test. We can check that it is true." >>>>> >>>>> " >>>>> '/foo/gloops.taz' asFileReference basename >>>>> >>> 'gloops.taz' >>>>> " >>>>> >>>>> ^ self = aResultingObject >>>>> >>>>> >>>>> Stef >>>>> >>>>> >>>>> >>>> >>> >>> >> >

Oct. 24, 2016

Re: [Pharo-dev] [ANN] Scale

by Denis Kudriashov

2016-10-24 11:48 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > What you think to make scripts working as workspace? All undeclared > variables will be added to environment automatically. And in case of > saveAfterRun they will became accessible from any scale scripts. > It makes me feel that it could allow things which are impossible with ruby, python or whatever.

Oct. 24, 2016

Re: [Pharo-dev] [ANN] Scale

by Denis Kudriashov

Really nice project, Santiago. I have few questions: - what "system saveAfterRun" actually do? As I understand it saves image when script completes. Imaging during script I loaded Seaside. Does this command makes Seaside accessible from any scale scripts? - system execute: aString into: anImageBundle What is anImageBundle here? - What you think to make scripts working as workspace? All undeclared variables will be added to environment automatically. And in case of saveAfterRun they will became accessible from any scale scripts. 2016-10-23 20:34 GMT+02:00 Santiago Bragagnolo <santiagobragagnolo(a)gmail.com >: > Hi everybody. > > We are officially releasing a first version of scale. > > Scale is a command line handler that is there for making easier the life > of the people that uses scripting in linux. As such, we only tested it so > far in linux. It will be for sure easy to adapt it to mac because its a > *nix, but not for windoze. > > *IMPORTANT REMARK*: scale is not meant to develop applications, it is > meant to develop scripts in Pharo, to be launched from the command line. > This means that scale does not provide a top level syntax to declare > classes or methods: people should do that as any normal Pharo application. > Scale should be used to invoke such applications. > > When would you use scale? > - For example, to replace some bash scripts used for common boring tasks > (and you are using python or ruby there :P) > - Another example, would be when you want to replace bash scripts that > chain things like: > ./pharo eval --save "something" > ./pharo eval --save "other something" > ... > > Github: https://github.com/guillep/Scale > Oneliner to install: (note it needs sudo) > > wget -O- https://raw.githubusercontent.com/guillep/Scale/master/setupScale.sh | sudo bash > > > In the repository there is some user level documentation based on examples > and a list of available methods on the magical variable system. There are > many examples as well on the repository. > > Last but not least, I'm using this project in others two projects, where > it proof it self quite powerful what keeps me on maintaining Scale. > > These projects are: > > *Pharo Android VM building *https://github.com/sbragagnolo/pharo-vm > > Here I use it for automating the creation of a > * new building image, > * the creation of new resource image (for deploying on the android > apk), > * linking the android sources into the building directory > * generating the code from the console > > *MakrosTool* https://github.com/sbragagnolo/MakrosTool > > MakrosTool is an extension of scale that adds a second magical variable > for building up component reification in a ROS based environment. > > > Santiago & Guille > > > > > >

Oct. 24, 2016

CI's down ?

by Sven Van Caekenberghe

It seems that since a couple of days the CI's are down ? https://ci.inria.fr/pharo-contribution/

Oct. 24, 2016

Re: [Pharo-dev] [Ann] Stack Android VM

by Nicolas Passerini

This is great! 2016-10-23 23:08 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > Great. > Do you have prebuilt apk file? > > 2016-10-23 22:03 GMT+02:00 Santiago Bragagnolo < > santiagobragagnolo(a)gmail.com>: > >> Still far from production. But since i would happy to have some >> feedback, I'm happy to show you some progress on the android VM. Not yet >> release. But we have already a way of compiling and deploying an image into >> an android device. >> >> You can check it in this repo github. >> https://github.com/sbragagnolo/pharo-vm/ >> >> The building steps are detailed on the README-Android.md file. >> Building the Stack AndroidVM >> >> 1. >> >> Download the sources from github >> <https://github.com/sbragagnolo/pharo-vm> >> >> git clone --depth=1 https://github.com/sbragagnolo/pharo-vmcd pharo-vm >> >> 2. >> >> Set-up your environment: This script will download the SDK installer >> and NDK R10 >> >> cd android/scripts >> ./setupAndroidEnvironment.st >> >> This script downloads the content from >> - 'http://dl.google.com/android/repository/android-ndk-r10e-li >> nux-x86_64.zip'. >> - 'http://dl.google.com/android/android-sdk_r24.4.1-linux.tgz'. >> >> After this process you should have available the environment >> variables ANDROID_NDK_HOME and ANDROID_SDK_HOME. Ensure this by checking >> your .bashrc file at the user's home directory. >> 3. >> >> Create a new image: this image will be created by pointing to this >> local git repository >> >> cd android/scripts >> ./newImage.st >> >> 4. >> >> Link sources to the build folder: The Android vm relies on a Java >> wrapper. This sources must be accessible from the build folder. >> >> cd android/scripts >> ./linkSources.st >> >> 5. >> >> Generate the sources of the stack vm: This script executes the >> generator of the image created on int the 3rd step. >> >> cd android/scripts >> ./generateStackAndroidMake.st >> >> 6. >> >> Generate the resource image for deployment: This script download and >> suites up an image for deployment on the folder >> build/assets/SmalltalkRessources >> >> cd android/scripts >> ./newResourceImage.st >> >> This image created in this point is downloaded with it related VM for >> editing and loading the code you want to deploy, or configure the things >> you want. >> 7. >> >> The VM compilation: This script generates the libraries with the VM >> code. >> >> cd build >> ./build.sh >> >> 8. >> >> The Java wrapper compilation and Android Application packaging >> >> cd build >> ./package.sh >> >> 9. >> >> Installing into your device. If you want to generate an APK file with >> your custom name, you will need to deal with the AndroidManifest.xml before >> runing the package.sh script :) >> >> cd build/bin >> adb install -r StackActivity-debug.apk >> >> >> >> - Im currently working on the JIT version of the VM, that still avoiding >> me :). >> But you have as well the instruction on the same README-Android.me file. >> >> >> Santiago >> >> >> >> >> >> >> >> >

Oct. 24, 2016

Re: [Pharo-dev] [ANN] Scale

by Guillermo Polito

Hi all, and thanks Santi for rescuing Scale from the Limbo :). I saw already some discussions pointing to this thread indirectly. I want to answer some philosophical aspects, just to remove some burden from Santi who is the real one that should take credit for pushing this to the light ^^. 1) Why scale and not "pharo scripting". I saw an email from Norbert about this. Well, I remember we discussed this with Santi a couple of years ago about this, when we started and brainstormed about it, but I am not able to remember the exact details right now. But, I can still think about some arguments in favor of the current decision (which we may not keep in the future, hey :)) - First, Pharo is different from ruby and python in terms of deployment. In ruby and python, you have the main libraries that are shared and your application is deployed locally as files. We can think that the script becomes the application. In Pharo, to write an application we need to interact and change with the environment. Thus we cannot share it. You can think about scale as a read-only pharo environment deployed in your machine for scripting purposes. - Second, Scale is Pharo, but not only. Scale introduces a new command line handler to manage scripts. Scale introduces an interpreter that is the one that is in charge of executing the code, provide special bindings and syntax sugar to scripts (see e.g. the 'system' instance in scripts). Scale requires TaskIt and OSSubprocess to provide easy-to-use interaction with the system. Should all this be part of Pharo? Well I do not know but I prefer to keep it as a separate entity. Maybe we can call it a separate distribution, installation or whatever. - Third, if it is a matter of naming (which I think it is), something that comes out of the second point is that #! /usr/bin/local/scale => #! /usr/bin/local/pharo scale or better => #! /usr/bin/env pharo scale ? 2) We would appreciate if feedback is not lost in the mailing list but is converted in issues instead: https://github.com/guillep/Scale/issues Fell free to contribute, provide feedback or even check the code, it is really a simple and short project. It was nice that Santi implemented scale installation in scale :) Cheers, Guille On Sun, Oct 23, 2016 at 11:04 PM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > Ok thanks, that will do for me. > > Phil > > On Sun, Oct 23, 2016 at 10:11 PM, Santiago Bragagnolo < > santiagobragagnolo(a)gmail.com> wrote: > >> Thanks Phil! That's not easy to do now, Is mean to be a feature for the >> next version. >> >> By the moment you have to add the variable to SCScriptRunner and >> initialize the value maybe in initialize. >> >> This SCScriptRunner is the context of execution of the script. >> >> >> >> On Sun, 23 Oct 2016 at 21:48 phil(a)highoctane.be <phil(a)highoctane.be> >> wrote: >> >>> Ah, this is just *beautiful* >>> >>> Thank you thank you thank you for making this available. >>> >>> Question: How is one creating a new scripting object and making it >>> available? (like system etc). >>> >>> Phil >>> >>> >>> >>> >>> >>> On Sun, Oct 23, 2016 at 8:34 PM, Santiago Bragagnolo < >>> santiagobragagnolo(a)gmail.com> wrote: >>> >>> Hi everybody. >>> >>> We are officially releasing a first version of scale. >>> >>> Scale is a command line handler that is there for making easier the life >>> of the people that uses scripting in linux. As such, we only tested it so >>> far in linux. It will be for sure easy to adapt it to mac because its a >>> *nix, but not for windoze. >>> >>> *IMPORTANT REMARK*: scale is not meant to develop applications, it is >>> meant to develop scripts in Pharo, to be launched from the command line. >>> This means that scale does not provide a top level syntax to declare >>> classes or methods: people should do that as any normal Pharo application. >>> Scale should be used to invoke such applications. >>> >>> When would you use scale? >>> - For example, to replace some bash scripts used for common boring >>> tasks (and you are using python or ruby there :P) >>> - Another example, would be when you want to replace bash scripts that >>> chain things like: >>> ./pharo eval --save "something" >>> ./pharo eval --save "other something" >>> ... >>> >>> Github: https://github.com/guillep/Scale >>> Oneliner to install: (note it needs sudo) >>> >>> wget -O- https://raw.githubusercontent.com/guillep/Scale/master/setupScale.sh | sudo bash >>> >>> >>> In the repository there is some user level documentation based on >>> examples and a list of available methods on the magical variable system. >>> There are many examples as well on the repository. >>> >>> Last but not least, I'm using this project in others two projects, where >>> it proof it self quite powerful what keeps me on maintaining Scale. >>> >>> These projects are: >>> >>> *Pharo Android VM building *https://github.com/sbragagnolo/pharo-vm >>> >>> Here I use it for automating the creation of a >>> * new building image, >>> * the creation of new resource image (for deploying on the >>> android apk), >>> * linking the android sources into the building directory >>> * generating the code from the console >>> >>> *MakrosTool* https://github.com/sbragagnolo/MakrosTool >>> >>> MakrosTool is an extension of scale that adds a second magical variable >>> for building up component reification in a ROS based environment. >>> >>> >>> Santiago & Guille >>> >>> >>> >>> >>> >>> >>> >

Oct. 24, 2016

Re: [Pharo-dev] Spur VM Bug for Chinese Characters?

by Sven Van Caekenberghe

> On 18 Oct 2016, at 07:40, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > >> On 18 Oct 2016, at 03:36, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >> >> Sven Van Caekenberghe-2 wrote >>> You could try doing... allowComplexMapKeys: true >>> ... >> >> Hmm, if the default writing may use complex keys, shouldn't the default >> reading do the same? I found it jarring to write using the defaults, and >> then have the default read fail! > > Yes, you are right, the default should be true, I can't remember why I did not yet do it, it feels as if I am forgetting something, don't see all the consequences. I decided to remove this option all together: === Name: STON-Core-SvenVanCaekenberghe.77 Author: SvenVanCaekenberghe Time: 24 October 2016, 10:36:19.993021 am UUID: cb69cdaa-0065-4014-afa7-67a2a7e445db Ancestors: STON-Core-SvenVanCaekenberghe.76 Remove the option #allowComplexMapKeys from STONReader (to functionally always allow it; leave the accessor #allowComplexMapsKeys: as a no-op for backwards compatibility) - remove all usage, simplify implementation. === Name: STON-Tests-SvenVanCaekenberghe.67 Author: SvenVanCaekenberghe Time: 24 October 2016, 10:36:51.944835 am UUID: 92a94566-972f-4084-aa37-a572de9cfe67 Ancestors: STON-Tests-SvenVanCaekenberghe.66 Remove the option #allowComplexMapKeys from STONReader (to functionally always allow it; leave the accessor #allowComplexMapsKeys: as a no-op for backwards compatibility) - remove all usage, simplify implementation. === Sven >> ----- >> Cheers, >> Sean >> -- >> View this message in context: http://forum.world.st/Spur-VM-Bug-for-Chinese-Characters-tp4918883p4919141.… >> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >> >

Oct. 24, 2016