[Pharo-dev] [Pharo 8.0] Build #850: FAILURE
There is a new Pharo build available! The status of the build #850 was: FAILURE. Could not extract further issue information from commit message: Update stale.yml - both issues and PRs have the same timeout for stale - moved it up to 250 days / 1 week to close - reduces the actions per hour to 2 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/Pharo8.0/850/
[Pharo-dev] [Pharo 8.0] Build #849: Compiler: Document and simplify #lookupVar:
There is a new Pharo build available! The status of the build #849 was: SUCCESS. The Pull Request #4868 was integrated: "Compiler: Document and simplify #lookupVar:" Pull request url: https://github.com/pharo-project/pharo/pull/4868 Issue Url: https://github.com/pharo-project/pharo/issues/backstop Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/Pharo8.0/849/
[Pharo-dev] PhD starting in January/February 2020 on Advanced debugging with Pharo
Dear Friends We just learned that we have a PhD grant for three years in the RMOD team. The problem is that the PhD should start January or February of 2020. We are looking for potential candidates. Please contact Steven Costiou The topics are around the following theme: - On-the-fly debugging of concurrent and unstoppable progams - Live back-in-time debugging - Concurrent object-centric debugging - Dynamic and unanticipated VM upgrades with new debugging primitives for the debugging of unstoppable programs - Transforming debugging instrumentation into unit tests - Transforming debugging instrumentation into software updates / patches (in unstoppable programs) - English - Good communication - Good oop and Pharo is a big plus :) Here is some information about the PhD - 108 000 KEuros for three years (around 1600 Euros monthly netto) - Typical rent is around 400-600 Euros - Food is good and not expensive - Metro/buses is 21 Euros per month - Lille is located 30 min from Brussels, 1 hour from Paris, 1,3 hours of train from London. - 120 000 students over two large campuses and multiple schools - The team has a long experience of working with foreigners: Mariano MartinezPeck, Nick Papoulias, Pablo Tesone, Guillermo Polito…. all did a PhD with us. We have around 10 nationalities in the tearm. Some old interviews of RMOD people - https://nicolas.petton.fr/blog/interview-jean-baptiste.html - https://nicolas.petton.fr/blog/interview-clara.html#orgaa9e1b8 -https://www.letudiant.fr/palmares/palmares-des-villes-etudiantes/lille.html 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 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
Re: [Pharo-dev] What is a GlobalIdentifier
Thanks Andrei Yes this is case. > On 9 Oct 2019, at 11:03, Andrei Chis wrote: > > Hi, > > I think we mostly added it for the GTEventCollector, as a way to > detect if events coming from different images were from the same > machine. > > Cheers, > Andrei > > On Fri, Oct 4, 2019 at 9:27 PM Stéphane Ducasse > wrote: >> >> Hi >> >> We have a package SystemIdentification and I would like to know if this is >> still in use. >> >> >> Here is the comment of the class. >> >> I keep global IDs that are used for tracking user activity, e.g. computer >> id. By default, you should access me by calling #uniqueInstance. >> >> Responsibility: >> The IDs that are important to store onto disk (and shared by all images) >> should be placed in persistedInformation instance variable. On other hand, >> if you do not want to store it onto disk, create a new instance variable. I >> can #loadPreferences and #savePreferences onto a disk. >> >> I know computer ID and secret ID. Computer ID is a global UUID that is share >> among all the images. It is stored on a local disk. Secret ID is use for >> encrypting information, e.g., class names, method names. You can use >> #hashForText: method. >> >> Collaborators: I do not collaborate with other classes. I only offer the >> basic IDs for other frameworks. >> >> Public API and Key Messages >> >> - computerUUID >> - ensureComputerUUID >> - hashForText: >> - loadPreferences >> - savePreferences. >> >> Before using #computerUUID, you should call #ensureComputerUUID. It will >> update UUID from the disk or stores existing one if it is not stored yet. I >> behave like this as automatic storing data to disk on image start-up leads >> to errors. >> >> >> It looks like it is used by the GTEventCollector and I wonder if it is used >> and useful anymore. >> >> Stef >> >> >> >> >> Stéphane Ducasse >> http://stephane.ducasse.free.fr >> http://www.synectique.eu / 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 >> >
Re: [Pharo-dev] What is a GlobalIdentifier
Hi, I think we mostly added it for the GTEventCollector, as a way to detect if events coming from different images were from the same machine. Cheers, Andrei On Fri, Oct 4, 2019 at 9:27 PM Stéphane Ducasse wrote: > > Hi > > We have a package SystemIdentification and I would like to know if this is > still in use. > > > Here is the comment of the class. > > I keep global IDs that are used for tracking user activity, e.g. computer id. > By default, you should access me by calling #uniqueInstance. > > Responsibility: > The IDs that are important to store onto disk (and shared by all images) > should be placed in persistedInformation instance variable. On other hand, if > you do not want to store it onto disk, create a new instance variable. I can > #loadPreferences and #savePreferences onto a disk. > > I know computer ID and secret ID. Computer ID is a global UUID that is share > among all the images. It is stored on a local disk. Secret ID is use for > encrypting information, e.g., class names, method names. You can use > #hashForText: method. > > Collaborators: I do not collaborate with other classes. I only offer the > basic IDs for other frameworks. > > Public API and Key Messages > > - computerUUID > - ensureComputerUUID > - hashForText: > - loadPreferences > - savePreferences. > > Before using #computerUUID, you should call #ensureComputerUUID. It will > update UUID from the disk or stores existing one if it is not stored yet. I > behave like this as automatic storing data to disk on image start-up leads to > errors. > > > It looks like it is used by the GTEventCollector and I wonder if it is used > and useful anymore. > > Stef > > > > > Stéphane Ducasse > http://stephane.ducasse.free.fr > http://www.synectique.eu / 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 >
[Pharo-dev] [Pharo 8.0] Build #848: Simplify TempVector Offset from IR
There is a new Pharo build available! The status of the build #848 was: FAILURE. The Pull Request #4857 was integrated: "Simplify TempVector Offset from IR" Pull request url: https://github.com/pharo-project/pharo/pull/4857 Issue Url: https://github.com/pharo-project/pharo/issues/SimplifyTempVectorOffset Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/Pharo8.0/848/
Re: [Pharo-dev] [ANN] Roadmap progress report. September 2019
Thanks for the roadmap. I am particularly excited about the underlying improvements, such as VM, TaskIT and TFFI, that might capture less headlines. About TaskIT, are these: > • Implement a prototype of a distributed backend to execute tasks. > • Implement a communication layer using Rabbit MQ > • Implement the first version of a process manager for handling > multiples images and workers. already available? Cheers, Doru > On Oct 7, 2019, at 4:02 PM, Esteban Lorenzano wrote: > > > Hi all, > > Since some time we wanted to start with this report to keep you all informed > on what we are doing to achieve our goals for the release. > After ESUG we took some time to organise and we managed to put this in > movement. > The idea is to post one the first week of each month (but it may vary, as you > see with this one who came a bit later :P) > > Actions reportes are just dots, since we do not have the time to add a big > explanation and we hope you are already involved and more or less know what > we are talking about. > But do not hesitate to ask if you want more details :) > > Roadmap progress report. > September 2019 > > > Image > > Code Loading > • Profiling the time spent to load code > • Reimplementing a better Read/Write Buffered Stream > • Improving the performance of Source writing and reading, > • Improving in at least 20% the time of loading code using Metacello. > > Spec 2 > • Pass on SpMillerColumnPresenter to made it of general use. > • Implement a specific SpMillerLayout to handle Miller columns. > • Pass on regular input ports (transmissions subsystem) to implement > activation ports. > • Pass on SpStyle subsystem (kind of STON based stylesheets for > Morphic). > • Fix SpGridLayout horizontal cell calculous. (It was broken). > • Fix SpBoxLayout berderWith and padding. (It was broken). > • Added contextual menus to widgets. > • This functionality was completely revamped to make it work in > all backends. > • It was generalised to all widgets (even if not all should use > it!) > • Added focus order to presenters. > • This is also a full revamp of old existing functionality. > • it accepts you to change the default order, but it has a > default order (previous implementations forced you to do the focusing by > hand). > • Added key binding support for all widgets. > • This is also a full revamp of old exiting functionality. > > Spec2+GTK3 > • callbacks can now be chained. This requires some explanation: In Gtk3 > you connect to signals. And you can connect just one callback to one signal. > Thankfully we control the callbacks in our side, so we modified signal > callbacks to accept to chain other callbacks (then we can connect several > actions to one single event, for example "keypress" or “hide"). > • along with this, we reworked the callback hierarchy. > • implemented inheritance in Pharo of Gtk3 objects and interfaces (this > is needed to enhance control of tables and many others). > • added autocompletion capabilities to SpCodePresenter. > • added a mechanism to avoid duplicate signalling between the backend > and the adaptors. > • Fix an important leak on GtkFormView. > > NewTools > • Inspector > • it now implements Miller columns > • Using TaskIt as backend for stepping. > • extensions migrated (we are at 10% of the total of migrations > needed, we will enhance this in iterative way). > • Debugger > • Almost complete revamp of UI. > • Fix context updating (to allow commands to actually work) > • Integrate new inspector. > • Work on new layouts for debugger > • Make an experimental tool: "playbook", to concentrate playgrounds and > test some UI ideas. > > UFFI > • Adding Tests > • Support for kind of literals and support type definitions in literals > • Documentation > • Measuring performance issues on large images. > > TaskIT > • Implement a prototype of a distributed backend to execute tasks. > • Implement a communication layer using Rabbit MQ > • Implement the first version of a process manager for handling > multiples images and workers. > > VM > • Fixing problem with LibGIT and Windows 1903. > • Fixing the performance issues of Windows 1903 with File accesses when > using solid-state 4k physical sector disks. > • XCode integration > • Adding an initial version to detect invalid order in the return from > concurrent callbacks. > • Improving the implementation of TFFI to run 50% faster in callouts. > • Build of StackVM > -- feenk.com "Some battles are better lost than fought."
