April 2020 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Cover for PBE8

by Sven Van Caekenberghe

Not bad at all, made me smile. > On 7 Apr 2020, at 12:21, Nicolas Anquetil <nicolas.anquetil(a)inria.fr> wrote: > > > :-) > > > > > On Tue, 2020-04-07 at 09:45 +0200, StÃ©phane Ducasse wrote: >> Hello >> >> We are working on PBE80 and we are looking for a new cool cover. >> If you think that you can do this we are all ears. >> >> S >> -------------------------------------------- >> StÃ©phane Ducasse >> http://stephane.ducasse.free.fr / http://www.pharo.org >> 03 59 35 87 52 >> Assistant: Julie Jonas >> FAX 03 59 57 78 50 >> TEL 03 59 35 86 16 >> S. Ducasse - Inria >> 40, avenue Halley, >> Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza >> Villeneuve d'Ascq 59650 >> France >> > -- > Nicolas Anquetil > RMod team -- Inria Lille > <pbe.png>

April 7, 2020

Re: [Pharo-dev] Cover for PBE8

by Nicolas Anquetil

:-) On Tue, 2020-04-07 at 09:45 +0200, StÃ©phane Ducasse wrote: > Hello > > We are working on PBE80 and we are looking for a new cool cover. > If you think that you can do this we are all ears. > > S > -------------------------------------------- > StÃ©phane Ducasse > http://stephane.ducasse.free.fr / http://www.pharo.org > 03 59 35 87 52 > Assistant: Julie Jonas > FAX 03 59 57 78 50 > TEL 03 59 35 86 16 > S. Ducasse - Inria > 40, avenue Halley, > Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza > Villeneuve d'Ascq 59650 > France > -- Nicolas Anquetil RMod team -- Inria Lille

April 7, 2020

[Pharo 9.0] Build #226: CatalogSettings displayCatalogProjectsInSpotter:

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #226 was: SUCCESS. The Pull Request #6095 was integrated: "CatalogSettings displayCatalogProjectsInSpotter:" Pull request url: https://github.com/pharo-project/pharo/pull/6095 Issue Url: https://github.com/pharo-project/pharo/issues/6059 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

April 7, 2020

Cover for PBE8

by StÃ©phane Ducasse

Hello We are working on PBE80 and we are looking for a new cool cover. If you think that you can do this we are all ears. S -------------------------------------------- StÃ©phane Ducasse http://stephane.ducasse.free.fr / http://www.pharo.org 03 59 35 87 52 Assistant: Julie Jonas FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza Villeneuve d'Ascq 59650 France

April 7, 2020

[ANN] RewriteTool has successfully ported to Spec2

by Juan Pablo Sandoval Alcocer

Dear friends, I would like to announce that Sebastian, an intern of my company, just ported the RewriteTool to Spec2. You may find the install instructions in the following link :) https://github.com/jordanmontt/RewriteTool-Spec2 Please, help us to test it, any feedback is welcome. Regards, Juan P. SEMANTICS SRL http://semantics.bo/ https://jpsandoval.github.io/

April 6, 2020

[Pharo 9.0] Build #225: 2608-PathprintOn-is-overriden-by-all-its-subclasses-and-none-call-super-printOn

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #225 was: FAILURE. The Pull Request #6139 was integrated: "2608-PathprintOn-is-overriden-by-all-its-subclasses-and-none-call-super-printOn" Pull request url: https://github.com/pharo-project/pharo/pull/6139 Issue Url: https://github.com/pharo-project/pharo/issues/2608 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

April 6, 2020

Re: [Pharo-dev] [Spec] Selected item in a list off screen

by Hilaire

So ? -- Dr. Geo http://drgeo.eu

April 6, 2020

Re: [Pharo-dev] [Mm10s] 2020-04-06

by tesonep＠gmail.com

### Last Week - Fixing PRs to be integrated (Tonel / Spotter integration) - Making space in Jenkins servers - Reviewing PRs - Crash when executing a Metacello from github in the minimal image with the headless vm - Adding tests to https://github.com/pharo-project/pharo/pull/6057 - Checking Moose generator error with Traits - When everything integrated in the image, release of LargeImageSupport - Fixing issue https://github.com/pharo-vcs/iceberg/issues/1356 - Fixing Spotter issue and removing the hiding of errors below the carpet. - [VM] Improve the usage of Stdout and Stderr, in a correct way - [VM] Writing tests for JIT generation - Fixing flaky tests - Writing documentation: Posts ### This week (starting 2020-04-06): - [PharoCOM] Pharo 7 errors. - Port to Pharo 8: Traits in class side fix - New iceberg release: Issue 1356 - [VM] Fix symbolic links in Pharo8 VM - Improving the crash report of the VM - Fixing Package List / Categories in Calypso - [VM] Fixing Tests in Idle. - Adding a label to a PR when it has no test errors. - [VM] Check the crash dumps in an endless loop- On Mon, Apr 6, 2020 at 9:59 AM Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > Morning. > Last week was kind of slow. Lots of (personal) things to take care that took more time than expected: kids, basement flood, etc. > Anyway, this is what I managed to achieve: > > ### Last week > > * [spec2] add "align" property to box layouts (so you can center, or align right, etc.). > * [spec2] SpTextPresenter now respond also to âeditableâ property (different than âreadonlyâ. > * [spec2] add popover component (took more time than expected ;) ). > * [spec2] SpCodePresenter now accepts insertPopoverAfterSelection: > * review and accept (most) of all pending PRs from Spec2 > > ### This week (starting 2020-05-06): > > (Still stuck in the same) > > * [idlevm] more on the revamp of callbacks > * [spec2] enhance SpMenuPresenter (to allow checkboxes and etc.) > * [spec2] more on SpCodePresenter > * [newtools] more on StPlayground > -- Pablo Tesone. tesonep(a)gmail.com

April 6, 2020

[Mm10s] 2020-04-06

by Esteban Lorenzano

Morning. Last week was kind of slow. Lots of (personal) things to take care that took more time than expected: kids, basement flood, etc. Anyway, this is what I managed to achieve: ### Last week * [spec2] add "align" property to box layouts (so you can center, or align right, etc.). * [spec2] SpTextPresenter now respond also to âeditableâ property (different than âreadonlyâ. * [spec2] add popover component (took more time than expected ;) ). * [spec2] SpCodePresenter now accepts insertPopoverAfterSelection: * review and accept (most) of all pending PRs from Spec2 ### This week (starting 2020-05-06): (Still stuck in the same) * [idlevm] more on the revamp of callbacks * [spec2] enhance SpMenuPresenter (to allow checkboxes and etc.) * [spec2] more on SpCodePresenter * [newtools] more on StPlayground

April 6, 2020

Re: [Pharo-dev] FW: [Pharo-users] Latest PharoJS Success Story; Wasm/WASI; very keen on Pony for the Pharo VM

by Ronie Salgado

Hi Shaping, I have to admit that that language looks quite interesting, but it is not appropriate for writing an actual VM. One thing is having the actor object model for writing an application that scales where it can be a very desirable property, but another thing is writing a virtual machine where you have time constraints for the just in time compiler in a single CPU to reduce initialization time. In fact, most of the methods are actually interpreted and they are only compiled after being executed several times for reducing this startup time. In this problem domain, the actor model and the thread safeness guaranteed by it does not help you at all, and deadlocks can always be produced. I did have deadlocks problems with synchronous messages in Erlang which forced me to go into using asynchronous messages, but if you do not model your domain state machine you could also end with a deadlock by using asynchronous messages, or even worse, an inconsistent state such as an incomplete credit card transaction in a highly distributed system! You even need to model network and power failures in your state machine. So the programming language may help you a lot with you concurrent, distributed and fault tolerant system programming, but they are not a silver bullet that guarantees that your system is actually going to be correct. Going back to the task of developing a VM, you also need to be able to perform dangerous memory accessing operations for at least the following three tasks: 1. Implementing the garbage collector. 2. Direct access to object slots for implementing the bytecode interpreter. 3. Copying compiled machine code into executable memory and performing position dependent relocations. The machine code generation and installation can be separated in two stage (the current VM just generates the code directly into the executable memory), and in fact having these two separated stages for compilation and installation is a requirement for operating systems that enforce W^X page level permissions, specially if you want a concurrent VM. You need to install the executable code in an atomic way, so you need to suspend the threads while changing the executable permission into the writable permission. You may get away of this restriction if you are allowed to map the same physical memory into different virtual addresses ranges with different permissions (one writeable, and one executable). For these reasons, you need an unsafe language such as C/C++ for at least these tasks, or a language that allows you to turn off the type and memory safeness net. I heard that Rust has an unsafe pointer that you could also for these purposes. The Pharo team is going with the existing virtual machine for quite a while. You cannot just replace something that is not well documented by something new, specially when you do not have that many resources for making a new vm. You first need to document completely the existing one, the semantics of the bytecodes, how they are implemented, and also the same with the primitives. As for myself, I am putting my bets on another language that I am developing (Sysmel: https://github.com/ronsaldo/sysmel ), and in full ahead-of-time compilation, but my problem domain is video game programming, low-level operating system, driver development and embedded programming where I actually want to have control of the machine. Since I have written my compiler in Pharo, I can just reuse the Opal Compiler for doing AST to AST translation and just compile Pharo (with some limitations, for example no thisContext) into my runtime environment. If I want a more dynamic environment, I can also serialize a Pharo CompiledMethod, send it through a socket and then interpret it on the Sysmel side: https://github.com/ronsaldo/sysmel/blob/master/module-sources/Sysmel.Core/S… by just reusing the existing language semantics. Currently although I am just supporting Linux, and Windows support is coming in a couple of weeks after getting a proper module system working for reducing compilation times. For the backend I am using LLVM, wasm is not yet supported because I am generating some IR that are not supported by the wasm backend (vtable layouts, and some intrinsics that I am using for non-local returns), but they should not be that complicated to fix. Best regards, Ronie El lun., 6 abr. 2020 a las 6:05, Shaping (<shaping(a)uurda.org>) escribiÃ³: > I should have initially posted this to the Pharo-dev list, as well. > > > > *From:* Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] *On > Behalf Of *Shaping > *Sent:* Friday, 3 April, 2020 14:05 > *To:* 'Any question about pharo is welcome' <pharo-users(a)lists.pharo.org> > *Subject:* Re: [Pharo-users] Latest PharoJS Success Story; Wasm/WASI; > very keen on Pony for the Pharo VM > > > > All: > > > Brain Treats got stuck during launch on my LG. > > > > > Which android version are you using ? > > > > The phone is old and this is likely the problem. > > > > Android version: 4.4.2 > > Kernel version: 3.4.0 > > > > > Is there a plan to move PharoJS to Wasm/WASI? > > > > > Dave and I talked about it a long time ago. This sounds like a good idea. > > Actually, Dave has a very ambition idea = turn PharoJS into Pharo* where * > can be different targets. > > But, there's a lot to do before reaching this goal. So, don't expect it > any time soon. > > > > Not to change the topic too much, but the following is related and I often > think of itâ¦ > > > > Consider writing the pharo VM in Wasm or, better, with *Pony* (which can > emit Wasm, as needed). Ponyâs reference-capability-based (ref-cap) > concurrency-model guarantees provably that no data-races or deadlocks can > happen if the code compiles; this solves a very large class of extremely > ugly concurrency problems that no one ever wants to face. > > > > Pony gives high-performance concurrency (5 to 15 ns actor-thread switching > time, depending on platform), and solves the most difficult class of > synchronization problems at compile time. It runs as fast as C. It runs > faster than C, as concurrency scales. You canât scale a highly concurrent > app efficiently in C, and really shouldnât try if you wish to remain happy > and mentally healthy. > > > > Pony is still pre-1.0, but the group is very active and competent. I > think we should consider using it to build the VM. Have a look. Some > videos for your amusement and information: > > > > > > https://www.youtube.com/watch?v=ODBd9S1jV2s > > https://www.youtube.com/watch?v=u1JfYa413fY > > https://www.youtube.com/watch?v=fNdnr1MUXp8 > > https://www.ponylang.io/ > > > > There are many others. I mentioned the Pony concurrency architecture > around the holidays, but there was no interest from the listânot a good > time perhaps. > > > > The tentative plan is to do what Google does with Flutter: have the JIT > in support of the usual dynamicity a Smalltalker needs for rapid > development; and have AOT, fully optimized compiling for production or > speed-related reality checks, presumably needed less often during > development. There are other possibilities. > > > > Anyone interested? > > > > I have some ideas for simplifying use of the six ref caps in the context > of Pharo/Smalltalk. If this path is chosen, one must commit to strict > state-machine-based algorithm development, without exception. This should > have happened anyway by now, broadly in the programming space, but didnât. > Iâm working on a programming graphical tool and associated grammar (in VW) > that make state-machine development easy and attractive. This , besides > efficient use of machine resources, is the other reason for pushing in this > direction. > > > > A Pony program is built from a net of asynchronously communicating > actors. You change the state of your program with asynchronous messaging > between actors. There is no blocking--no mutexes or semaphoresâand > therefore no wasted CPU cycles or mushrooming program complexity, as you > try to use mutexes in a fine-grained way (a very bad idea). And as > mentioned, there are never deadlocks or data-races. All cores on all CPUs > stay busy, always, until the program goes idle or exits. The Pony group is > also working on extending the model to the network level, so that all > machine nodes in the network stay busy. In the round, as a start, think of > Pony as Erlang/OTP, but much faster, with no legacy bugs, and provably > no-deadlocking on compile. > > > > The asynchronous actor model is the programming pattern that Kay had in > mind when he said âobject-oriented.â Itâs the one I want to implement in > Pharo. The green threads are light, but donât efficiently use the cores, > and a net of VMs with their respective images still communicate too slowly. > > > > I your time permits, please study Pony for a bit, before rejecting the > idea as too big a change in direction or too complicated. Using Pony looks > like the ideal VM simplification strategy, if our aim is efficient use of > networks of machines, each with at least one CPU (often more), each, in > turn, with many cores (whose numbers are still increasing). This pattern > in hardware probably wonât be changing much, now that speeds are topping > out. Winning the performance game is therefore about efficiently using > many cores at once, *without burdening the programmer*. I donât see a > better way to do this now than with Pony. > > > > Thoughts and suggestions are welcome. > > > > > > Shaping > > > > > > > > > > > -----Original Message----- > > > From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org > <pharo-users-bounces(a)lists.pharo.org>] On > > > Behalf Of N. Bouraqadi > > > Sent: Tuesday, 28 January, 2020 12:18 > > > To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> > > > Subject: [Pharo-users] Latest PharoJS Success Story > > > > > > The latest PharoJS-powered smartphone app is now live. > > > Development has been made using Pharo. > > > Then, javascript code is generated using PharoJS. > > > Last, the app is built to target both iOS and Android thanks to Apache > > > Cordova. > > > > > > Learn more and Download at > > > https://nootrix.com/projects/brain-treats-app/ > > > > > > Noury > > > > > > > > > > >

April 6, 2020

FW: [Pharo-users] Latest PharoJS Success Story; Wasm/WASI; very keen on Pony for the Pharo VM

by Shaping

I should have initially posted this to the Pharo-dev list, as well. From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf Of Shaping Sent: Friday, 3 April, 2020 14:05 To: 'Any question about pharo is welcome' <pharo-users(a)lists.pharo.org> Subject: Re: [Pharo-users] Latest PharoJS Success Story; Wasm/WASI; very keen on Pony for the Pharo VM All: > Brain Treats got stuck during launch on my LG. > Which android version are you using ? The phone is old and this is likely the problem. Android version: 4.4.2 Kernel version: 3.4.0 > Is there a plan to move PharoJS to Wasm/WASI? > Dave and I talked about it a long time ago. This sounds like a good idea. Actually, Dave has a very ambition idea = turn PharoJS into Pharo* where * can be different targets. But, there's a lot to do before reaching this goal. So, don't expect it any time soon. Not to change the topic too much, but the following is related and I often think of it. Consider writing the pharo VM in Wasm or, better, with Pony (which can emit Wasm, as needed). Pony's reference-capability-based (ref-cap) concurrency-model guarantees provably that no data-races or deadlocks can happen if the code compiles; this solves a very large class of extremely ugly concurrency problems that no one ever wants to face. Pony gives high-performance concurrency (5 to 15 ns actor-thread switching time, depending on platform), and solves the most difficult class of synchronization problems at compile time. It runs as fast as C. It runs faster than C, as concurrency scales. You can't scale a highly concurrent app efficiently in C, and really shouldn't try if you wish to remain happy and mentally healthy. Pony is still pre-1.0, but the group is very active and competent. I think we should consider using it to build the VM. Have a look. Some videos for your amusement and information: https://www.youtube.com/watch?v=ODBd9S1jV2s https://www.youtube.com/watch?v=u1JfYa413fY https://www.youtube.com/watch?v=fNdnr1MUXp8 https://www.ponylang.io/ There are many others. I mentioned the Pony concurrency architecture around the holidays, but there was no interest from the list-not a good time perhaps. The tentative plan is to do what Google does with Flutter: have the JIT in support of the usual dynamicity a Smalltalker needs for rapid development; and have AOT, fully optimized compiling for production or speed-related reality checks, presumably needed less often during development. There are other possibilities. Anyone interested? I have some ideas for simplifying use of the six ref caps in the context of Pharo/Smalltalk. If this path is chosen, one must commit to strict state-machine-based algorithm development, without exception. This should have happened anyway by now, broadly in the programming space, but didn't. I'm working on a programming graphical tool and associated grammar (in VW) that make state-machine development easy and attractive. This , besides efficient use of machine resources, is the other reason for pushing in this direction. A Pony program is built from a net of asynchronously communicating actors. You change the state of your program with asynchronous messaging between actors. There is no blocking--no mutexes or semaphores-and therefore no wasted CPU cycles or mushrooming program complexity, as you try to use mutexes in a fine-grained way (a very bad idea). And as mentioned, there are never deadlocks or data-races. All cores on all CPUs stay busy, always, until the program goes idle or exits. The Pony group is also working on extending the model to the network level, so that all machine nodes in the network stay busy. In the round, as a start, think of Pony as Erlang/OTP, but much faster, with no legacy bugs, and provably no-deadlocking on compile. The asynchronous actor model is the programming pattern that Kay had in mind when he said "object-oriented." It's the one I want to implement in Pharo. The green threads are light, but don't efficiently use the cores, and a net of VMs with their respective images still communicate too slowly. I your time permits, please study Pony for a bit, before rejecting the idea as too big a change in direction or too complicated. Using Pony looks like the ideal VM simplification strategy, if our aim is efficient use of networks of machines, each with at least one CPU (often more), each, in turn, with many cores (whose numbers are still increasing). This pattern in hardware probably won't be changing much, now that speeds are topping out. Winning the performance game is therefore about efficiently using many cores at once, without burdening the programmer. I don't see a better way to do this now than with Pony. Thoughts and suggestions are welcome. Shaping > -----Original Message----- > From: Pharo-users [ <mailto:pharo-users-bounces@lists.pharo.org> mailto:pharo-users-bounces@lists.pharo.org] On > Behalf Of N. Bouraqadi > Sent: Tuesday, 28 January, 2020 12:18 > To: Any question about pharo is welcome < <mailto:pharo-users@lists.pharo.org> pharo-users(a)lists.pharo.org> > Subject: [Pharo-users] Latest PharoJS Success Story > > The latest PharoJS-powered smartphone app is now live. > Development has been made using Pharo. > Then, javascript code is generated using PharoJS. > Last, the app is built to target both iOS and Android thanks to Apache > Cordova. > > Learn more and Download at > <https://nootrix.com/projects/brain-treats-app/> https://nootrix.com/projects/brain-treats-app/ > > Noury > >

April 6, 2020

[Spec] Selected item in a list off screen

by Hilaire

Hi, When I programmatically selects an item in a presenter list *and* when this item is off screen -- for example at the end of a long list -- the list widget is not scrolled to make it visible. (DrGScriptBrowser2 new script: DrGeoUserScript allSubclasses last; yourself) openWithSpec Is it a bug or am I missing something Thanks Hilaire -- Dr. Geo http://drgeo.eu

April 4, 2020

[Pharo 9.0] Build #224: Fix a couple of completion glitches

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #224 was: FAILURE. The Pull Request #6132 was integrated: "Fix a couple of completion glitches" Pull request url: https://github.com/pharo-project/pharo/pull/6132 Issue Url: https://github.com/pharo-project/pharo/issues/bottom Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

April 3, 2020

[Pharo 9.0] Build #223: Fixes pharo-project#3430: ifError should accept error instance instead of its properties

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #223 was: SUCCESS. The Pull Request #5471 was integrated: "Fixes pharo-project#3430: ifError should accept error instance instead of its properties" Pull request url: https://github.com/pharo-project/pharo/pull/5471 Issue Url: https://github.com/pharo-project/pharo/issues/3430 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

April 3, 2020

[Pharo 9.0] Build #222: Cleanup: #vectorOffset

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #222 was: FAILURE. The Pull Request #6134 was integrated: "Cleanup: #vectorOffset" Pull request url: https://github.com/pharo-project/pharo/pull/6134 Issue Url: https://github.com/pharo-project/pharo/issues/CleanupVectorOffset Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

April 3, 2020

Re: [Pharo-dev] [rmod] [Pharo-users] [ANN] SmalltalkHub Deprecation Notice

by Guillermo Polito

Hi Renaud, > El 3 abr 2020, a las 16:27, Renaud de Villemeur <renaud.devillemeur(a)tuta.io> escribiÃ³: > > Hi Guille. > > It's a good news to see the community is moving forward. > > What would be the impact on Pharo catalog ? The instruction still advise to upload information to smalltalkhub: http://catalog.pharo.org/catalog/note-for-developers?_s=bHk4XDBcH9mb0muM&_k… <http://catalog.pharo.org/catalog/note-for-developers?_s=bHk4XDBcH9mb0muM&_k…> > Will it be deprecated as well ? My *personal* take on this is is that we can migrate easily the catalog, without deprecating it: - the catalog repositories will stay alive as read-only, so it will be no problem to access old catalog entries (unless they depend on private projects, but that would be odd) - a low-energy solution for this is to migrate these repositories to squeaksource3. This should be mostly straight-forward. - a high-energy solution is to rethink the catalog. I know there have been some community efforts from Christophe Demarey for example, Esteban has also interesting ideas on how to attack this. Thoughts? > > Thanks > Renaud > > > > > Apr. 3, 2020, 05:55 by guillermopolito(a)gmail.com: > SmalltalkHub Deprecation Notice > SmalltalkHub is now getting old and it is time to deprecate it. We plan to replace it by a static file server during 2020. The public data will still be readable and consumable from monticello clients, but modifications will not be allowed in the near future. SmalltalkHub users should move their projects to git repositories or other monticello repository services. > What is changing? > If you currently host a project in SmalltalkHub, you should migrate your projects to another platform as soon as possible. If you depend on a project hosted on SmalltalkHub, you should contact the owner of that project to schedule a migration. > If you have documentation or tutorials using SmalltalkHub, we recommend to update those after a migration. > An archive of all public projects in SmalltalkHub will be made available in read-only mode. This archive will be readable through monticello clients for compatibility reasons. > Private projects, due to privacy reasons, will not be published in the public archive and will be removed to protect their owners. > Why are RMoD and Inria making this change? > SmalltalkHub has finished its cycle. The arrival of git integration in the past years caused the move of most users in the Pharo community to git hosting services. They now use exclusively other platforms. Furthermore, RMoD and Inria lack the manpower to properly maintain the SmalltalkHub service and keep it up to date. Smalltalkhub has no added value compared to other code source hosting platforms. > How much time do I have to adapt to this change? > > The SmalltalkHub deprecation will follow the next timetable: > Monday 04 of may 2020: SmalltalkHub will be read-only. Creation of new users and projects will be forbidden. New commits will be rejected. All existing users, projects (public and private) and their commits will remain available and visible, but their settings will become read-only. > Monday 02 of november 2020: SmalltalkHub will be migrated to a static file server archive. Private projects and their commits will not be available anymore. > > The RMoD team and Inria plan to keep the static file server alive for, at least, 5 years from the date of its creation. > What will happen if I do nothing? > Your public projects will become read-only and you will not be able to commit anymore. > Your private projects will become unavailable. > What alternatives do I have? > > Those wanting to keep using monticello can migrate their projects to other monticello hostings such as http://squeaksource.com <http://squeaksource.com/> or http://ss3.gemstone.com <http://ss3.gemstone.com/> > > Those wanting to migrate to git, Peter Uhnakâs git migration tool (https://github.com/peteruhnak/git-migration <https://github.com/peteruhnak/git-migration>) automates monticello to git migration in tonel format. > > Cheers, > Guille on behalf of the RMoD team >

April 3, 2020

[Pharo 9.0] Build #221: Compiler: Use better names for syntetic temps

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #221 was: FAILURE. The Pull Request #6135 was integrated: "Compiler: Use better names for syntetic temps" Pull request url: https://github.com/pharo-project/pharo/pull/6135 Issue Url: https://github.com/pharo-project/pharo/issues/CompilerUseBetterNamesForSynt… Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

April 3, 2020

[Pharo 9.0] Build #220: SycRefactoringPreviewSelection

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #220 was: FAILURE. The Pull Request #6136 was integrated: "SycRefactoringPreviewSelection" Pull request url: https://github.com/pharo-project/pharo/pull/6136 Issue Url: https://github.com/pharo-project/pharo/issues/SycRefactoringPreviewSelection Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

April 3, 2020

[ANN] SmalltalkHub Deprecation Notice

by Guillermo Polito

SmalltalkHub Deprecation Notice SmalltalkHub is now getting old and it is time to deprecate it. We plan to replace it by a static file server during 2020. The public data will still be readable and consumable from monticello clients, but modifications will not be allowed in the near future. SmalltalkHub users should move their projects to git repositories or other monticello repository services. What is changing? If you currently host a project in SmalltalkHub, you should migrate your projects to another platform as soon as possible. If you depend on a project hosted on SmalltalkHub, you should contact the owner of that project to schedule a migration. If you have documentation or tutorials using SmalltalkHub, we recommend to update those after a migration. An archive of all public projects in SmalltalkHub will be made available in read-only mode. This archive will be readable through monticello clients for compatibility reasons. Private projects, due to privacy reasons, will not be published in the public archive and will be removed to protect their owners. Why are RMoD and Inria making this change? SmalltalkHub has finished its cycle. The arrival of git integration in the past years caused the move of most users in the Pharo community to git hosting services. They now use exclusively other platforms. Furthermore, RMoD and Inria lack the manpower to properly maintain the SmalltalkHub service and keep it up to date. Smalltalkhub has no added value compared to other code source hosting platforms. How much time do I have to adapt to this change? The SmalltalkHub deprecation will follow the next timetable: Monday 04 of may 2020: SmalltalkHub will be read-only. Creation of new users and projects will be forbidden. New commits will be rejected. All existing users, projects (public and private) and their commits will remain available and visible, but their settings will become read-only. Monday 02 of november 2020: SmalltalkHub will be migrated to a static file server archive. Private projects and their commits will not be available anymore. The RMoD team and Inria plan to keep the static file server alive for, at least, 5 years from the date of its creation. What will happen if I do nothing? Your public projects will become read-only and you will not be able to commit anymore. Your private projects will become unavailable. What alternatives do I have? Those wanting to keep using monticello can migrate their projects to other monticello hostings such as http://squeaksource.com <http://squeaksource.com/> or http://ss3.gemstone.com <http://ss3.gemstone.com/> Those wanting to migrate to git, Peter Uhnakâs git migration tool (https://github.com/peteruhnak/git-migration <https://github.com/peteruhnak/git-migration>) automates monticello to git migration in tonel format. Cheers, Guille on behalf of the RMoD team

April 3, 2020

[Pharo 9.0] Build #219: 6091-Fleaky-Spotter-tests

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #219 was: FAILURE. The Pull Request #6129 was integrated: "6091-Fleaky-Spotter-tests" Pull request url: https://github.com/pharo-project/pharo/pull/6129 Issue Url: https://github.com/pharo-project/pharo/issues/6091 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

April 3, 2020

[Pharo 9.0] Build #218: 6122-isPrimitive-deserves-tests

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #218 was: FAILURE. The Pull Request #6123 was integrated: "6122-isPrimitive-deserves-tests" Pull request url: https://github.com/pharo-project/pharo/pull/6123 Issue Url: https://github.com/pharo-project/pharo/issues/6122 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

April 2, 2020

[Pharo 9.0] Build #217: Skip Epicea fleaky test

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #217 was: SUCCESS. The Pull Request #6127 was integrated: "Skip Epicea fleaky test" Pull request url: https://github.com/pharo-project/pharo/pull/6127 Issue Url: https://github.com/pharo-project/pharo/issues/fix/5938 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

April 2, 2020

[Pharo 9.0] Build #216: 2146-Hardcode-class-rewriter-in-RB-class

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #216 was: SUCCESS. The Pull Request #6061 was integrated: "2146-Hardcode-class-rewriter-in-RB-class" Pull request url: https://github.com/pharo-project/pharo/pull/6061 Issue Url: https://github.com/pharo-project/pharo/issues/Fix#2146 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

April 2, 2020

[Pharo 9.0] Build #215: Lint clean HashTesterTest

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #215 was: FAILURE. The Pull Request #6075 was integrated: "Lint clean HashTesterTest" Pull request url: https://github.com/pharo-project/pharo/pull/6075 Issue Url: https://github.com/pharo-project/pharo/issues/6074 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

April 2, 2020

[Pharo 9.0] Build #214: Codegeneration: generate code for Blocks for effect

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #214 was: SUCCESS. The Pull Request #6096 was integrated: "Codegeneration: generate code for Blocks for effect" Pull request url: https://github.com/pharo-project/pharo/pull/6096 Issue Url: https://github.com/pharo-project/pharo/issues/CodegenerationGenerateBlocksF… Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

April 2, 2020