- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] PharoMinimal ?

by Guillermo Polito

That's still not enough ;) That will work when the loaded package has no dependencies. Otherwise, imagine projects A and B, and A depending on B's release. every time you release B you need to release all dependencies... And, if you use a tag or exact committish to get the Baseline you want to install, still that baseline needs to point to the exact tag/committish of it's dependencies. Or! If you know the dependencies of your baseline you can explicitly use a Metacello's lock. I still believe this is an overkill and I'd like to simplify it, but that's what we have right now. On Sun, Oct 8, 2017 at 6:47 PM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > Hi Guille, > > Le 08/10/2017 Ã 18:24, Guillermo Polito a Ã©crit : > >> For a really high-level explanation, check the slides in here: >> >> https://www.slideshare.net/GuillePolito1/understanding-the- >> pharo-dev-process-79632181 >> > > Thanks for the pointers. I tried to do something in the Pharo4 days (I > still have probably somewhere a start of baselines and package to add to a > minimal pharo4 image, then the external project integration changed and > this approach would have failed...) > > Now, as Pavel says, minimal is an image with metacello (+ its dependencies >> of course). >> >> This means that you could try to install packages on top of it using >> baselines. >> > > Cool. > > Still, lot of work to do in that front, mainly >> - modularisation of the minimal-image packages, so we can build even >> smaller images >> - modularisation and baselines for all full-image packages, so we can >> build incremental images on a per-user flavour >> > > This is really interesting. > > This means of course >> - cleaning/sorting initializations >> - refactoring packages >> - Uncovering hidden and runtime dependencies >> - making some analyses on how space is taken (most is methods, tons in >> kernel and collections ;)) >> >> What is not so clear yet from the top of my head: if we distribute >> minimal images, how can we distribute the pharo libraries that you can load >> on top of them easily. So far, people using pharo minimal are aware that >> they are using an alpha version. That means that if they want to load on >> top of it, let's say, Morphic, they will need to do something like >> >> Metacello new >> baseline: 'Morphic'; >> repository: 'github://pharo-project/pharo:development/src'; >> load >> >> But that means that we'll be loading the so called 'bleeding-edge' of it >> all the time, and that version may not correspond with the image they are >> using. >> >> This makes me think we have at some point to revisit the release process >> so we can have releases internal of libraries such as morphic, athens, >> fuel, etc, more often. >> > > I think I can suggest a solution. When building an image on the command > line (as us Makefile users are keen to do), it is easy to customize the > additional packages/baselines you load based on some internal state of > the image being built. > > So, for example, if you tag the minimal image when built with, say v70123, > then one can write on the command line: > > pharo/pharo pharo/Pharo.image --no-default-preferences eval --save > Metacello new baseline: \'Morphic\'\; repository: > \'github://pharo-project/pharo:\'\, SystemVersion current buildNumber > printString\, \'/src\'\; load > > Et hop, voilÃ : you get the right Morphic for the minimal image with a > minimum amount of distortion. > > If not, then it could be enough to have the short commit ID of the pharo > repository when the minimal image was built: it is enough to get a > github:// url to work. > > Well, if you keep naming your images like that: > > Pharo7.0-metacello-32bit-d13eed2.image > > Then we could even do it this way in the image building makefile (and you > don't have anything to do)(*). > > I'll have a try at it. > > Thierry > > (*) External projects would have to sort it out, still. But, IMHO, it is a > duty of an external project to be in sync if it wants to stay external... > > On Sun, Oct 8, 2017 at 4:34 PM, Thierry Goubier <thierry.goubier(a)gmail.com >> <mailto:thierry.goubier@gmail.com>> wrote: >> >> Hi Pavel, >> >> I'd probably see some interest in building the >> GitFileTree-MergeDriver with it. It only requires Monticello. >> >> Thierry >> >> Le 08/10/2017 Ã 12:41, Pavel Krivanek a Ã©crit : >> >> Hi Sven, >> >> 2017-10-07 16:18 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu >> <mailto:sven@stfx.eu> <mailto:sven@stfx.eu <mailto:sven@stfx.eu >> >>>: >> >> >> Hi, >> >> What is the story around PharoMinimal and related images ? >> >> Is there a writeup somewhere with instructions ? >> >> >> Right now the minimal (Metacello) image based on Pharo 7 is used >> only as intermediate step in building of the full Pharo and the >> only real (successful) attempt to use it for something else is >> PharoLambda (https://gitlab.com/macta/PharoLambda >> <https://gitlab.com/macta/PharoLambda>). >> >> >> In general it can be used for building of own (server) >> applications. E.g. this way you can install and run Teapot on it: >> >> ./pharo Pharo7.0-metacello-32bit-d13eed2.image config >> http://smalltalkhub.com/mc/zeroflag/Teapot/main >> <http://smalltalkhub.com/mc/zeroflag/Teapot/main> >> ConfigurationOfTeapot --install=stable >> ./pharo Pharo7.0-metacello-32bit-d13eed2.image eval --no-quit >> "Teapot on GET: '/welcome' -> 'Hello World'; start." >> >> You can load baselines from the Git repositories too but we >> currently do not have any command line handler for it so you >> need to do it using "eval" command or *.st flile. Something like >> this: >> >> Metacello new >> baseline: 'Seaside3'; >> repository: 'github://SeasideSt/Seaside:master/repository'; >> load >> >> To make it more usable we probably should extend it with SUnit >> and Fuel. If you want to extend it with some packages from >> vanilla Pharo, you should load them using FileTree from your >> local Pharo repository clone. >> >> Gofer it >> url: 'filetree:///path-to-my-pharo-repository-clone/pharo/src'; >> package: 'Multilingual-OtherLanguages'; >> package: 'Multilingual-TextConverterOtherLanguages'; >> load. >> >> It still needs some care. E.g. some classes from Zinc are not >> properly initialized (I know about DigitalSignatureAlgorithm >> MD5NonPrimitive RxMatcher RxParser RxsPredicate SHA1 >> ZnByteEncoder ZnConstants ZnMimeType ZnNetworkingUtils ZnServer >> ZnSingleThreadedServer TextConstants TextAction TextStyle). >> >> I tried to load Seaside into it today (from the example above) >> and it failed (some strange error probalby related to Unicode >> processing). But we will fix it. If you will tell me what >> exactly you need we can make it work together as in case of >> PharoLambda. >> >> >> I see that we get **FANTASTIC** startup speed with it: >> >> $ cat /etc/issue >> Ubuntu 16.04.3 LTS >> >> $ ./pharo --version >> 5.0-201708271955 Sun Aug 27 20:09:20 UTC 2017 gcc 4.6.3 >> [Production >> Spur VM] >> CoInterpreter VMMaker.oscog-eem.2265 uuid: >> 76b62109-629a-4c39-9641-67b53321df9a Aug 27 2017 >> StackToRegisterMappingCogit VMMaker.oscog-eem.2262 uuid: >> 8b531242-de02-48aa-b418-8d2dde0bec6c Aug 27 2017 >> VM: 201708271955 >> https://github.com/OpenSmalltalk/opensmalltalk-vm.git >> <https://github.com/OpenSmalltalk/opensmalltalk-vm.git> >> <https://github.com/OpenSmalltalk/opensmalltalk-vm.git >> <https://github.com/OpenSmalltalk/opensmalltalk-vm.git>> $ Date: >> Sun >> Aug 27 21:55:26 2017 +0200 $ >> Plugins: 201708271955 >> https://github.com/OpenSmalltalk/opensmalltalk-vm.git >> <https://github.com/OpenSmalltalk/opensmalltalk-vm.git> >> <https://github.com/OpenSmalltalk/opensmalltalk-vm.git >> <https://github.com/OpenSmalltalk/opensmalltalk-vm.git>> $ >> Linux testing-gce-ebf45dd8-6a4c-43a5-abd0-e5d8673d05a4 >> 3.13.0-115-generic #162~precise1-Ubuntu SMP Fri Mar 24 >> 16:47:06 UTC >> 2017 i686 i686 i386 GNU/Linux >> plugin path: >> /home/audio359/pharo7/pharo-vm/lib/pharo/5.0-201708271955 >> [default: >> /home/audio359/pharo7/pharo-vm/lib/pharo/5.0-201708271955/] >> >> $ curl get.pharo.org/70-minimal >> <http://get.pharo.org/70-minimal> >> <http://get.pharo.org/70-minimal >> >> <http://get.pharo.org/70-minimal>> | bash >> >> ... >> >> $ ./pharo Pharo.image printVersion >> [version] 'Pharo7.0' >> 'Pharo-7.0+alpha.build.172.sha >> .d13eed2f80fe19f29fd85ede8c4809d6a6986d4f >> (32 Bit)' >> >> $ time ./pharo Pharo.image eval '5 factorial' >> 120 >> real 0m0.083s >> user 0m0.034s >> sys 0m0.042s >> >> That is less than 1/10 of a second on a simple server ! Wow. >> >> Loading new code in that image seem hard though. >> >> I see that in http://files.pharo.org/image/70/ >> <http://files.pharo.org/image/70/> >> <http://files.pharo.org/image/70/ >> <http://files.pharo.org/image/70/>> there are Pharomonticello & >> Pharometacello variants. >> >> Any pointers on usage/meaning ? >> >> >> Monticello is bootstrapped Pharo image with Monticello loaded. >> This image then loads Metacello and the generated image is the >> image that we call "minimal". It is minimal in sense minimal for >> common usage. >> >> During Pharo building process we generate: >> - bootstrapped image >> - image with Opal that is loaded as binary packages using Hermes >> - Monticello with only local repositories support >> - Monticello with network and remote repositories support >> - Metacello >> - full Pharo IDE (which is loaded as sequence of several >> standalone baselines) >> >> Cheers, >> -- Pavel >> >> Thx, >> >> Sven >> >> >> >> >> >> >> >> -- >> >> >> >> Guille Polito >> >> Research Engineer >> >> Centre de Recherche en Informatique, Signal et Automatique de Lille >> >> CRIStAL - UMR 9189 >> >> French National Center for Scientific Research - _http://www.cnrs.fr_ >> >> >> *Web:* _http://guillep.github.io_ >> >> *Phone: *+33 06 52 70 66 13 >> >> > > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Oct. 8, 2017

Re: [Pharo-dev] PharoMinimal ?

by Thierry Goubier

Hi Guille, Le 08/10/2017 Ã 18:24, Guillermo Polito a Ã©critÂ : > For a really high-level explanation, check the slides in here: > > https://www.slideshare.net/GuillePolito1/understanding-the-pharo-dev-proces… Thanks for the pointers. I tried to do something in the Pharo4 days (I still have probably somewhere a start of baselines and package to add to a minimal pharo4 image, then the external project integration changed and this approach would have failed...) > Now, as Pavel says, minimal is an image with metacello (+ its > dependencies of course). > > This means that you could try to install packages on top of it using > baselines. Cool. > Still, lot of work to do in that front, mainly > Â - modularisation of the minimal-image packages, so we can build even > smaller images > Â - modularisation and baselines for all full-image packages, so we can > build incremental images on a per-user flavour This is really interesting. > This means of course > Â - cleaning/sorting initializations > Â - refactoring packages > Â - Uncovering hidden and runtime dependencies > Â - making some analyses on how space is taken (most is methods, tons in > kernel and collections ;)) > > What is not so clear yet from the top of my head: if we distribute > minimal images, how can we distribute the pharo libraries that you can > load on top of them easily. So far, people using pharo minimal are aware > that they are using an alpha version. That means that if they want to > load on top of it, let's say, Morphic, they will need to do something like > > MetacelloÂ new > baseline: 'Morphic'; > repository: 'github://pharo-project/pharo:development/src'; > load > > But that means that we'll be loading the so called 'bleeding-edge' of it > all the time, and that version may not correspond with the image they > are using. > > This makes me think we have at some point to revisit the release process > so we can have releases internal of libraries such as morphic, athens, > fuel, etc, more often. I think I can suggest a solution. When building an image on the command line (as us Makefile users are keen to do), it is easy to customize the additional packages/baselines you load based on some internal state of the image being built. So, for example, if you tag the minimal image when built with, say v70123, then one can write on the command line: pharo/pharo pharo/Pharo.image --no-default-preferences eval --save Metacello new baseline: \'Morphic\'\; repository: \'github://pharo-project/pharo:\'\, SystemVersion current buildNumber printString\, \'/src\'\; load Et hop, voilÃ : you get the right Morphic for the minimal image with a minimum amount of distortion. If not, then it could be enough to have the short commit ID of the pharo repository when the minimal image was built: it is enough to get a github:// url to work. Well, if you keep naming your images like that: Pharo7.0-metacello-32bit-d13eed2.image Then we could even do it this way in the image building makefile (and you don't have anything to do)(*). I'll have a try at it. Thierry (*) External projects would have to sort it out, still. But, IMHO, it is a duty of an external project to be in sync if it wants to stay external... > On Sun, Oct 8, 2017 at 4:34 PM, Thierry Goubier > <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> wrote: > > Hi Pavel, > > I'd probably see some interest in building the > GitFileTree-MergeDriver with it. It only requires Monticello. > > Thierry > > Le 08/10/2017 Ã 12:41, Pavel Krivanek a Ã©critÂ : > > Hi Sven, > > 2017-10-07 16:18 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu > <mailto:sven@stfx.eu> <mailto:sven@stfx.eu <mailto:sven@stfx.eu>>>: > > > Â Â Hi, > > Â Â What is the story around PharoMinimal and related images ? > > Â Â Is there a writeup somewhere with instructions ? > > > Right now the minimal (Metacello) image based on Pharo 7 is used > only as intermediate step in building of the full Pharo and the > only real (successful) attempt to use it for something else is > PharoLambda (https://gitlab.com/macta/PharoLambda > <https://gitlab.com/macta/PharoLambda>). > > In general it can be used for building of own (server) > applications. E.g. this way you can install and run Teapot on it: > > ./pharo Pharo7.0-metacello-32bit-d13eed2.image config > http://smalltalkhub.com/mc/zeroflag/Teapot/main > <http://smalltalkhub.com/mc/zeroflag/Teapot/main> > ConfigurationOfTeapot --install=stable > ./pharo Pharo7.0-metacello-32bit-d13eed2.image eval --no-quit > "Teapot on GET: '/welcome' -> 'Hello World'; start." > > You can load baselines from the Git repositories too but we > currently do not have any command line handler for it so you > need to do it using "eval" command or *.st flile. Something like > this: > > Metacello new > baseline: 'Seaside3'; > repository: 'github://SeasideSt/Seaside:master/repository'; > load > > To make it more usable we probably should extend it with SUnit > and Fuel. If you want to extend it with some packages from > vanilla Pharo, you should load them using FileTree from your > local Pharo repository clone. > > Gofer it > url: 'filetree:///path-to-my-pharo-repository-clone/pharo/src'; > package: 'Multilingual-OtherLanguages'; > package: 'Multilingual-TextConverterOtherLanguages'; > load. > > It still needs some care. E.g. some classes from Zinc are not > properly initialized (I know about DigitalSignatureAlgorithm > MD5NonPrimitive RxMatcher RxParser RxsPredicate SHA1 > ZnByteEncoder ZnConstants ZnMimeType ZnNetworkingUtils ZnServer > ZnSingleThreadedServer TextConstants TextAction TextStyle). > > I tried to load Seaside into it today (from the example above) > and it failed (some strange error probalby related to Unicode > processing). But we will fix it. If you will tell me what > exactly you need we can make it work together as in case of > PharoLambda. > > > Â Â I see that we get **FANTASTIC** startup speed with it: > > Â Â $ cat /etc/issue > Â Â Ubuntu 16.04.3 LTS > > Â Â $ ./pharo --version > Â Â 5.0-201708271955Â Sun Aug 27 20:09:20 UTC 2017 gcc 4.6.3 > [Production > Â Â Spur VM] > Â Â CoInterpreter VMMaker.oscog-eem.2265 uuid: > Â Â 76b62109-629a-4c39-9641-67b53321df9a Aug 27 2017 > Â Â StackToRegisterMappingCogit VMMaker.oscog-eem.2262 uuid: > Â Â 8b531242-de02-48aa-b418-8d2dde0bec6c Aug 27 2017 > Â Â VM: 201708271955 > https://github.com/OpenSmalltalk/opensmalltalk-vm.git > <https://github.com/OpenSmalltalk/opensmalltalk-vm.git> > Â Â <https://github.com/OpenSmalltalk/opensmalltalk-vm.git > <https://github.com/OpenSmalltalk/opensmalltalk-vm.git>> $ Date: Sun > Â Â Aug 27 21:55:26 2017 +0200 $ > Â Â Plugins: 201708271955 > https://github.com/OpenSmalltalk/opensmalltalk-vm.git > <https://github.com/OpenSmalltalk/opensmalltalk-vm.git> > Â Â <https://github.com/OpenSmalltalk/opensmalltalk-vm.git > <https://github.com/OpenSmalltalk/opensmalltalk-vm.git>> $ > Â Â Linux testing-gce-ebf45dd8-6a4c-43a5-abd0-e5d8673d05a4 > Â Â 3.13.0-115-generic #162~precise1-Ubuntu SMP Fri Mar 24 > 16:47:06 UTC > Â Â 2017 i686 i686 i386 GNU/Linux > Â Â plugin path: > Â Â /home/audio359/pharo7/pharo-vm/lib/pharo/5.0-201708271955 > [default: > Â Â /home/audio359/pharo7/pharo-vm/lib/pharo/5.0-201708271955/] > > Â Â $ curl get.pharo.org/70-minimal > <http://get.pharo.org/70-minimal> > <http://get.pharo.org/70-minimal > <http://get.pharo.org/70-minimal>> | bash > > Â Â ... > > Â Â $ ./pharo Pharo.image printVersion > Â Â [version] 'Pharo7.0' > > 'Pharo-7.0+alpha.build.172.sha.d13eed2f80fe19f29fd85ede8c4809d6a6986d4f > Â Â (32 Bit)' > > Â Â $ time ./pharo Pharo.image eval '5 factorial' > Â Â 120 > Â Â realÂ Â 0m0.083s > Â Â userÂ Â 0m0.034s > Â Â sysÂ Â Â 0m0.042s > > Â Â That is less than 1/10 of a second on a simple server ! Wow. > > Â Â Loading new code in that image seem hard though. > > Â Â I see that in http://files.pharo.org/image/70/ > <http://files.pharo.org/image/70/> > Â Â <http://files.pharo.org/image/70/ > <http://files.pharo.org/image/70/>> there are Pharomonticello & > Â Â Pharometacello variants. > > Â Â Any pointers on usage/meaning ? > > > Monticello is bootstrapped Pharo image with Monticello loaded. > This image then loads Metacello and the generated image is the > image that we call "minimal". It is minimal in sense minimal for > common usage. > > During Pharo building process we generate: > - bootstrapped image > - image with Opal that is loaded as binary packages using Hermes > - Monticello with only local repositories support > - Monticello with network and remote repositories support > - Metacello > - full Pharo IDE (which is loaded as sequence of several > standalone baselines) > > Cheers, > -- Pavel > > Â Â Thx, > > Â Â Sven > > > > > > > > -- > > > > Guille Polito > > Research Engineer > > Centre de Recherche en Informatique, Signal et Automatique de Lille > > CRIStAL - UMR 9189 > > French National Center for Scientific Research - _http://www.cnrs.fr_ > > > *Web:* _http://guillep.github.io_ > > *Phone: *+33 06 52 70 66 13 >

Oct. 8, 2017

Re: [Pharo-dev] Reproducible VM Crash using UFFI

by Guillermo Polito

Yeh, the most important thing is what Jan says there. What you want to ensure is that you don't corrupt your memory (and particularly the heap). If you do so (i.e., corruption) the only way you can come back is that you remember the old uncorrupted value and, given that everything is still working, you put it back where it belongs. In any case, Hernan, I think this discussion belongs to the vm-dev list. On Sun, Oct 8, 2017 at 1:32 PM, Jan Vrany <jan.vrany(a)fit.cvut.cz> wrote: > > > So I think we are talking about different things here. I don't want > > to > > save "bad memory block" errors nor dream about bullet proof VM, but > > if > > we know the bullet then let's use a nice bulletproof vest :) > > > > This can be done and has been done. > > Following code would clearly result in segmentation violation: > > bytes := ExternalBytes address: 16r10 size: 100. > bytes byteAt: 1 put: 10. > > There are smalltalk implementations out there that handle > this and open a (smalltalk) debugger (see the screenshot). > Of course, you can just abort, fix your code and > try again. > > Of course, if you happen to overwrite your object memory > or VM internal structures, you're screwed. > > As you said, you can still be shot and die, but the west can > save your life in some cases :-) > > Best, Jan > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Oct. 8, 2017

Re: [Pharo-dev] PharoMinimal ?

by Guillermo Polito

For a really high-level explanation, check the slides in here: https://www.slideshare.net/GuillePolito1/understanding-the-pharo-dev-proces… Now, as Pavel says, minimal is an image with metacello (+ its dependencies of course). This means that you could try to install packages on top of it using baselines. Still, lot of work to do in that front, mainly - modularisation of the minimal-image packages, so we can build even smaller images - modularisation and baselines for all full-image packages, so we can build incremental images on a per-user flavour This means of course - cleaning/sorting initializations - refactoring packages - Uncovering hidden and runtime dependencies - making some analyses on how space is taken (most is methods, tons in kernel and collections ;)) What is not so clear yet from the top of my head: if we distribute minimal images, how can we distribute the pharo libraries that you can load on top of them easily. So far, people using pharo minimal are aware that they are using an alpha version. That means that if they want to load on top of it, let's say, Morphic, they will need to do something like Metacello new baseline: 'Morphic'; repository: 'github://pharo-project/pharo:development/src'; load But that means that we'll be loading the so called 'bleeding-edge' of it all the time, and that version may not correspond with the image they are using. This makes me think we have at some point to revisit the release process so we can have releases internal of libraries such as morphic, athens, fuel, etc, more often. On Sun, Oct 8, 2017 at 4:34 PM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > Hi Pavel, > > I'd probably see some interest in building the GitFileTree-MergeDriver > with it. It only requires Monticello. > > Thierry > > Le 08/10/2017 Ã 12:41, Pavel Krivanek a Ã©crit : > >> Hi Sven, >> >> 2017-10-07 16:18 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu <mailto: >> sven(a)stfx.eu>>: >> >> >> Hi, >> >> What is the story around PharoMinimal and related images ? >> >> Is there a writeup somewhere with instructions ? >> >> >> Right now the minimal (Metacello) image based on Pharo 7 is used only as >> intermediate step in building of the full Pharo and the only real >> (successful) attempt to use it for something else is PharoLambda ( >> https://gitlab.com/macta/PharoLambda) >> >> In general it can be used for building of own (server) applications. E.g. >> this way you can install and run Teapot on it: >> >> ./pharo Pharo7.0-metacello-32bit-d13eed2.image config >> http://smalltalkhub.com/mc/zeroflag/Teapot/main ConfigurationOfTeapot >> --install=stable >> ./pharo Pharo7.0-metacello-32bit-d13eed2.image eval --no-quit "Teapot on >> GET: '/welcome' -> 'Hello World'; start." >> >> You can load baselines from the Git repositories too but we currently do >> not have any command line handler for it so you need to do it using "eval" >> command or *.st flile. Something like this: >> >> Metacello new >> baseline: 'Seaside3'; >> repository: 'github://SeasideSt/Seaside:master/repository'; >> load >> >> To make it more usable we probably should extend it with SUnit and Fuel. >> If you want to extend it with some packages from vanilla Pharo, you should >> load them using FileTree from your local Pharo repository clone. >> >> Gofer it >> url: 'filetree:///path-to-my-pharo-repository-clone/pharo/src'; >> package: 'Multilingual-OtherLanguages'; >> package: 'Multilingual-TextConverterOtherLanguages'; >> load. >> >> It still needs some care. E.g. some classes from Zinc are not properly >> initialized (I know about DigitalSignatureAlgorithm MD5NonPrimitive >> RxMatcher RxParser RxsPredicate SHA1 ZnByteEncoder ZnConstants ZnMimeType >> ZnNetworkingUtils ZnServer ZnSingleThreadedServer TextConstants TextAction >> TextStyle). >> >> I tried to load Seaside into it today (from the example above) and it >> failed (some strange error probalby related to Unicode processing). But we >> will fix it. If you will tell me what exactly you need we can make it work >> together as in case of PharoLambda. >> >> >> I see that we get **FANTASTIC** startup speed with it: >> >> $ cat /etc/issue >> Ubuntu 16.04.3 LTS >> >> $ ./pharo --version >> 5.0-201708271955 Sun Aug 27 20:09:20 UTC 2017 gcc 4.6.3 [Production >> Spur VM] >> CoInterpreter VMMaker.oscog-eem.2265 uuid: >> 76b62109-629a-4c39-9641-67b53321df9a Aug 27 2017 >> StackToRegisterMappingCogit VMMaker.oscog-eem.2262 uuid: >> 8b531242-de02-48aa-b418-8d2dde0bec6c Aug 27 2017 >> VM: 201708271955 >> https://github.com/OpenSmalltalk/opensmalltalk-vm.git >> <https://github.com/OpenSmalltalk/opensmalltalk-vm.git> $ Date: Sun >> Aug 27 21:55:26 2017 +0200 $ >> Plugins: 201708271955 >> https://github.com/OpenSmalltalk/opensmalltalk-vm.git >> <https://github.com/OpenSmalltalk/opensmalltalk-vm.git> $ >> Linux testing-gce-ebf45dd8-6a4c-43a5-abd0-e5d8673d05a4 >> 3.13.0-115-generic #162~precise1-Ubuntu SMP Fri Mar 24 16:47:06 UTC >> 2017 i686 i686 i386 GNU/Linux >> plugin path: >> /home/audio359/pharo7/pharo-vm/lib/pharo/5.0-201708271955 [default: >> /home/audio359/pharo7/pharo-vm/lib/pharo/5.0-201708271955/] >> >> $ curl get.pharo.org/70-minimal <http://get.pharo.org/70-minimal> | >> bash >> >> ... >> >> $ ./pharo Pharo.image printVersion >> [version] 'Pharo7.0' >> 'Pharo-7.0+alpha.build.172.sha.d13eed2f80fe19f29fd85ede8c480 >> 9d6a6986d4f >> (32 Bit)' >> >> $ time ./pharo Pharo.image eval '5 factorial' >> 120 >> real 0m0.083s >> user 0m0.034s >> sys 0m0.042s >> >> That is less than 1/10 of a second on a simple server ! Wow. >> >> Loading new code in that image seem hard though. >> >> I see that in http://files.pharo.org/image/70/ >> <http://files.pharo.org/image/70/> there are Pharomonticello & >> Pharometacello variants. >> >> Any pointers on usage/meaning ? >> >> >> Monticello is bootstrapped Pharo image with Monticello loaded. This image >> then loads Metacello and the generated image is the image that we call >> "minimal". It is minimal in sense minimal for common usage. >> >> During Pharo building process we generate: >> - bootstrapped image >> - image with Opal that is loaded as binary packages using Hermes >> - Monticello with only local repositories support >> - Monticello with network and remote repositories support >> - Metacello >> - full Pharo IDE (which is loaded as sequence of several standalone >> baselines) >> >> Cheers, >> -- Pavel >> >> Thx, >> >> Sven >> >> >> > > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Oct. 8, 2017

Re: [Pharo-dev] Call for Ruby, Python, Java, Javascript Guide to Pharo

by Dimitris Chloupis

Yes I know thats what I am saying , that I dont think its a good idea to learn like this a language. In any case I am adding the Python code snippets and leave the teaching to you. It will take some time but will get it done, no big deal. On Sun, Oct 8, 2017 at 5:20 PM Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > Comparing languages in a discussion about Pharo vs the rest is vastly >> different, at least to me , from teaching Pharo. >> > > The pdf that Stef posted I wrote for my students (which know Java and C), > just so it is easier for them to compare/grasp the new syntax based on what > they already know. It wasn't/isn't meant as a language comparison in the > sense that one is better than the other. > > Peter >

Oct. 8, 2017

Re: [Pharo-dev] PharoMinimal ?

by Thierry Goubier

Hi Pavel, I'd probably see some interest in building the GitFileTree-MergeDriver with it. It only requires Monticello. Thierry Le 08/10/2017 Ã 12:41, Pavel Krivanek a Ã©critÂ : > Hi Sven, > > 2017-10-07 16:18 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu > <mailto:sven@stfx.eu>>: > > Hi, > > What is the story around PharoMinimal and related images ? > > Is there a writeup somewhere with instructions ? > > > Right now the minimal (Metacello) image based on Pharo 7 is used only as > intermediate step in building of the full Pharo and the only real > (successful) attempt to use it for something else is PharoLambda > (https://gitlab.com/macta/PharoLambda) > > In general it can be used for building of own (server) applications. > E.g. this way you can install and run Teapot on it: > > ./pharo Pharo7.0-metacello-32bit-d13eed2.image config > http://smalltalkhub.com/mc/zeroflag/Teapot/main ConfigurationOfTeapot > --install=stable > ./pharo Pharo7.0-metacello-32bit-d13eed2.image eval --no-quit "Teapot on > GET: '/welcome' -> 'Hello World'; start." > > You can load baselines from the Git repositories too but we currently do > not have any command line handler for it so you need to do it using > "eval" command or *.st flile. Something like this: > > Metacello new > baseline: 'Seaside3'; > repository: 'github://SeasideSt/Seaside:master/repository'; > load > > To make it more usable we probably should extend it with SUnit and Fuel. > If you want to extend it with some packages from vanilla Pharo, you > should load them using FileTree from your local Pharo repository clone. > > Gofer it > url: 'filetree:///path-to-my-pharo-repository-clone/pharo/src'; > package: 'Multilingual-OtherLanguages'; > package: 'Multilingual-TextConverterOtherLanguages'; > load. > > It still needs some care. E.g. some classes from Zinc are not properly > initialized (I know about DigitalSignatureAlgorithm MD5NonPrimitive > RxMatcher RxParser RxsPredicate SHA1 ZnByteEncoder ZnConstants > ZnMimeType ZnNetworkingUtils ZnServer ZnSingleThreadedServer > TextConstants TextAction TextStyle). > > I tried to load Seaside into it today (from the example above) and it > failed (some strange error probalby related to Unicode processing). But > we will fix it. If you will tell me what exactly you need we can make it > work together as in case of PharoLambda. > > > I see that we get **FANTASTIC** startup speed with it: > > $ cat /etc/issue > Ubuntu 16.04.3 LTS > > $ ./pharo --version > 5.0-201708271955Â Sun Aug 27 20:09:20 UTC 2017 gcc 4.6.3 [Production > Spur VM] > CoInterpreter VMMaker.oscog-eem.2265 uuid: > 76b62109-629a-4c39-9641-67b53321df9a Aug 27 2017 > StackToRegisterMappingCogit VMMaker.oscog-eem.2262 uuid: > 8b531242-de02-48aa-b418-8d2dde0bec6c Aug 27 2017 > VM: 201708271955 > https://github.com/OpenSmalltalk/opensmalltalk-vm.git > <https://github.com/OpenSmalltalk/opensmalltalk-vm.git> $ Date: Sun > Aug 27 21:55:26 2017 +0200 $ > Plugins: 201708271955 > https://github.com/OpenSmalltalk/opensmalltalk-vm.git > <https://github.com/OpenSmalltalk/opensmalltalk-vm.git> $ > Linux testing-gce-ebf45dd8-6a4c-43a5-abd0-e5d8673d05a4 > 3.13.0-115-generic #162~precise1-Ubuntu SMP Fri Mar 24 16:47:06 UTC > 2017 i686 i686 i386 GNU/Linux > plugin path: > /home/audio359/pharo7/pharo-vm/lib/pharo/5.0-201708271955 [default: > /home/audio359/pharo7/pharo-vm/lib/pharo/5.0-201708271955/] > > $ curl get.pharo.org/70-minimal <http://get.pharo.org/70-minimal> | bash > ... > > $ ./pharo Pharo.image printVersion > [version] 'Pharo7.0' > 'Pharo-7.0+alpha.build.172.sha.d13eed2f80fe19f29fd85ede8c4809d6a6986d4f > (32 Bit)' > > $ time ./pharo Pharo.image eval '5 factorial' > 120 > realÂ Â 0m0.083s > userÂ Â 0m0.034s > sysÂ Â Â 0m0.042s > > That is less than 1/10 of a second on a simple server ! Wow. > > Loading new code in that image seem hard though. > > I see that in http://files.pharo.org/image/70/ > <http://files.pharo.org/image/70/> there are Pharomonticello & > Pharometacello variants. > > Any pointers on usage/meaning ? > > > Monticello is bootstrapped Pharo image with Monticello loaded. This > image then loads Metacello and the generated image is the image that we > call "minimal". It is minimal in sense minimal for common usage. > > During Pharo building process we generate: > - bootstrapped image > - image with Opal that is loaded as binary packages using Hermes > - Monticello with only local repositories support > - Monticello with network and remote repositories support > - Metacello > - full Pharo IDE (which is loaded as sequence of several standalone > baselines) > > Cheers, > -- Pavel > > Thx, > > Sven > >

Oct. 8, 2017

Re: [Pharo-dev] Call for Ruby, Python, Java, Javascript Guide to Pharo

by Peter UhnÃ¡k

> > Comparing languages in a discussion about Pharo vs the rest is vastly > different, at least to me , from teaching Pharo. > The pdf that Stef posted I wrote for my students (which know Java and C), just so it is easier for them to compare/grasp the new syntax based on what they already know. It wasn't/isn't meant as a language comparison in the sense that one is better than the other. Peter

Oct. 8, 2017

Re: [Pharo-dev] Call for Ruby, Python, Java, Javascript Guide to Pharo

by Dimitris Chloupis

Well we certainly have a different way of thinking, I cannot get emotional attached to languages to the level you are passionate about Pharo. To me itâs important to have a general idea of languages and their capabilities as this helps me improve as a coder because obviously each language has its own priorities and as a result also a different style. I started adding Python code to your chapter but will take me some time because I am about to release the commercial Python app I am working on so I donât have the free time I used to. Maybe it would have been better to make this in a table format to make it easier to read but thatâs up to you. Frankly I donât think it would be important for a Python code to see the equivalent code because Smalltalk follow its own mind set while Python prioritizes familiarity and ease of learning. For example in the math.sin() section you make the rightful claim that numbers are objects can be subclassed etc and hence 100 sin. In Python itâs math.sin() but in Python 100 is also an object that can be subclassed. Because Python follows a similar design of everything being an object. So it is possible to have something like (100).sin(), if you subclassed Integer. Python hides its âSmalltalk nessâ inside a very C like appearance to lower the learning curve. So it going to be a looooong comparison and I rather not go there. The best advice I ever got when learning English, from a Greek teacher, was to never try to translate Greek to English inside my mind when I speak or write English. Instead to think in English directly. I would give a Python coder learning Pharo the same advise. Forget anything you know about Python, learn Pharo from scratch step by step and with a lot of practice. Take a look at my videos you will see I never mention Python once or other language when I teach Pharo. Comparing languages in a discussion about Pharo vs the rest is vastly different, at least to me , from teaching Pharo. On Sun, 8 Oct 2017 at 11:34, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Hi Dimitri > > Preambule: If you want to understand why I react like to the other > thread: we are ***FIGHTING*** all day long to build a great system and > this is not easy and I do not need to know how great are the other > systems. If I want to know I can just drop Pharo and go coding in X. > No need to have such discussion on PharoDev where we should be > concentrated. > > Now if you and other want to contribute actively to Pharo here is a simple > idea. > > Create one chapter (I will do the editing) similar to this one (you > can also modify this one) to explain to a Pythoner, Rubbyist, > Javascripter, the syntax and core libraries of Pharo. > > > https://github.com/SquareBracketAssociates/PharoInProgress/tree/master/Java… > > It was on my todo but I would have to refresh my mind on these languages. > > Stef >

Oct. 8, 2017

Re: [Pharo-dev] Reproducible VM Crash using UFFI

by Jan Vrany

> So I think we are talking about different things here. I don't want > to > save "bad memory block" errors nor dream about bullet proof VM, but > if > we know the bullet then let's use a nice bulletproof vest :) > This can be done and has been done. Following code would clearly result in segmentation violation: bytes := ExternalBytes address: 16r10 size: 100. bytes byteAt: 1 put: 10. There are smalltalk implementations out there that handle this and open a (smalltalk) debugger (see the screenshot). Of course, you can just abort, fix your code andÂ try again. Of course, if you happen to overwrite your object memory or VM internal structures, you're screwed. As you said, you can still be shot and die, but the west canÂ save your life in some cases :-) Best, Jan

Oct. 8, 2017

Re: [Pharo-dev] [ANN] Iceberg 0.6 released

by Esteban Lorenzano

> On 8 Oct 2017, at 01:40, Tim Mackinnon <tim(a)testit.works> wrote: > > I see the answer is due to STON - fine I'll live with it. > > I think we missed a chance to superficially look like more conventional languages on the web in GitHub but that ship had sailed and maybe it's not such a bad thing. I think tonel does a fair job in keeping âPharo flavourâ and not looking completely alien to newcomers/non-pharoers. the method detail is just that, a detail. And even looking for readability, we still need to keep what we are, I think :) > I'll happily take just been able to efficiently use GitHub asap any day. well, thatâs what Iâm working on :) Esteban > > So please keep rolling forward. > > Tim > > Sent from my iPhone > >> On 7 Oct 2017, at 09:08, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >> >> Tim >> >> we talk about this format of methods year ago and we will like it and >> we will not discuss it anymore. >> For the record a method is a named block so it fits and we do not have >> to have {} for method delimiters. >> >> Stef >> >>> On Fri, Oct 6, 2017 at 11:34 PM, Tim Mackinnon <tim(a)testit.works> wrote: >>> Gosh - It actually work quite well to be able to easily browse code online >>> in a more traditional format of seeing an entire class. Hopefully this leads >>> to us being able to share solutions to common language agnostic problems. >>> >>> One small observation - I quickly grokâd the use of class { â¦. } (with the >>> curly braces) - but given that smalltalk methods often have lots of [ ] >>> (square braces in them), I was a bit surprised to see that method >>> declarations in tonal donât use { â¦ } (curly braces) to denote them, but >>> instead use [ ] - which feels slightly strange given the class declaration >>> above has. {}. >>> >>> Was it easier to parse this way, or is there some subtlety I missed? I would >>> have been tempted to use {} for classes and methods and [] for the >>> protocols as this more closely matches what other languages do - and it >>> might actually make it more easily readable for other programmers. Given we >>> have to learn this new format anyway - Iâd be prepared to give a nod to what >>> others doâ¦ >>> >>> Possibly this observation comes to late - and maybe there is compelling >>> reason to go the route we have gone - but maybe its worth a quick double >>> check as its an exciting development. >>> >>> Tim >>> >>> On 6 Oct 2017, at 18:18, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>> >>> Hi all, >>> >>> I released Iceberg version 0.6. It includes a lot of small tweaks and fixes, >>> but the most important inclusion is tonel file format which aims to replace >>> file tree. >>> >>> What is Tonel? (https://github.com/pharo-vcs/tonel) >>> Tonel is a file-per-class file format for monticello repositories. Itâs >>> purpose is to reduce the amount of files touched each operation, make the IO >>> faster an compact the repositories database. >>> It has also as an objective to offer an âeasy-to-readâ format, so people >>> wanting to understand a chunk of code will recognise it easily. >>> For testing, I migrated several of my projects to Tonel and Iâve been using >>> it, you can see some as examples: >>> >>> https://github.com/estebanlm/MUDClient >>> https://github.com/estebanlm/pharo-tonel (this was just an example and it >>> has some minimal errors already fixed) >>> >>> We plan to migrate Pharo development to tonel to address some problems we >>> have: >>> >>> - since it has to read/write a lot of files, IO operations are slow >>> - and even much more slow in Windows >>> - Windows also has a problem with longpaths. >>> >>> Iceberg 0.6 will be integrated to Pharo7 soon :) >>> To update Pharo 6.1, there are instructions in the readme: >>> https://github.com/pharo-vcs/iceberg/blob/master/README.md >>> now, if you wan to migrate your projects to Tonel (from FileTree), here is a >>> script you can use: >>> https://github.com/pharo-vcs/tonel/blob/master/MigrateFromFileTree.md >>> >>> btw, tonel is independent of Iceberg and can be used with plain Monticello >>> (but it is a metadaless format, history will reside on git, not on >>> monticello). >>> >>> cheers, >>> Esteban >>> >>> >> > >

Oct. 8, 2017