- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [IMPORTANT] PHARO CONTRIBUTION PROCESS UPDATED! PLEASE READ!

by Esteban Lorenzano

> On 19 Jan 2018, at 13:00, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > On Fri, Jan 19, 2018 at 8:39 AM, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: >> hi :) >> >> On 18 Jan 2018, at 18:39, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >> >> Thanks Luke for your feedback >> Guillermo and Pablo are working on a new Iceberg model and UI. >> >> >> Model is done, we will integrate it as 0.7 version. >> UIâ¦ is harder. We could do a simple UI that allows just ONE path but at the >> end, no one will use it, because almost no use-case follows that. Believe >> me, I made a research on thatâ¦ and if you do not believe me, go and try >> github desktop, which basically does that (and nobody uses it ;) ) >> >> true story: actually the UI of iceberg was pretty simple when we started. It >> became the mess it is now just adding what people asked to have. >> but also true story: it *is* a mess, so we have to get it right before >> release of Pharo7 :) > > > Esteban there are central problems in Iceberg current UI. I know. > If we do not try something else we will not have feedback. Iâm working on simplifying/fixing the UI. But is a permanent work, not something that can be done in short time :( Esteban > > >> >> May be >> we can ask you if you want to give them feedback >> and try the new version. >> It is important for us that people can contribute. >> >> Stef >> >> On Wed, Jan 17, 2018 at 12:20 PM, Luke Gorrie <luke(a)snabb.co> wrote: >> >> Just one data point... >> >> I am completely overwhelmed by all of the different ways to manage source >> code in the Pharo universe. I would love to contribute to upstream but this >> seems way out of reach: I'm not even managing to keep track of the code in >> my own home directory properly yet. >> >> >> there are just two ways: >> >> - iceberg >> - monticello >> >> compare with the amount of ways you have in other languages. >> you can use either way you want to keep yours sources. >> >> but to contribute to Pharo there is just *one* way, following this >> instructions: >> https://github.com/pharo-project/pharo/wiki/Contribute-a-fix-to-Pharo >> >> people has reported this version is a lot easier than previous ones (and is >> not much different on how to contribute to other languages) but we are still >> looking for ways to simplify it (I want to test github issue tracker soon, >> for example, to enhance communication that today is broken in two partsâ¦ and >> honest reality check: people finds easier to discuss on github over the PR >> than over fogbugz). >> >> Just now I am looking at upstream code that should be fixed: CairoLibrary >> unix32ModuleName and unix64ModuleName are giving higher priority to guessed >> hard-coded paths than to LD_LIBRARY_PATH and this is backwards i.e. the >> carefully selected paths a user supplies with LD_LIBRARY_PATH should come >> first (imho.) >> >> >> follow the contribution instructions ;) >> >> On the one hand it would be fine to dive into the upstream contribution >> process to work out how to do this. On the other hand I am still trying to >> master tools like Epica to recover useful code that I have written and lost >> track of when images crash and get rebuilt etc. I really need to get this >> under control before spending time learning Iceberg, FogBugz, etc. >> >> >> wellâ¦ not so much to say here. My only advice is to save often you image, >> when you are working with things that you know may crash the VM (like using >> FFI). >> >> cheers! >> Esteban >> >> >> >> >> >> On 14 December 2017 at 13:19, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> >> Hi! >> >> Iâm working on simplifying the contribution process, after collecting >> opinions/experiences last couple of months. >> As you know, Pharo contribution process is still WIP and we aim to have it >> as smooth as possible for Pharo 7.0 release. Now, after observe the idea of >> the âsystem repositoriesâ was a bad idea because it introduced extra and non >> standard âpathâ to contribution, I managed to remove that to reestablish >> âthe regular wayâ: you will now need to add pharo repository just as any >> other repository you add, by cloning or adding local repository. >> >> I took Guilleâs doc and moved it to pharo project (it does not has sense >> to have it living in a contributorâs repository when is so important). You >> can find it here: >> >> https://github.com/pharo-project/pharo/wiki/Contribute-a-fix-to-Pharo >> >> This document is also updated to reveal this new process, please read it. >> >> How to update your startup scripts? >> Some people has added startup scripts to easy the first part of >> contribution. Instead enabling system repositories, etc. you now need to >> replace that with this: >> >> (IceRepositoryCreator new >> location: '/path/to/pharo-project/pharo' asFileReference; >> subdirectory: 'src'; >> createRepository) >> register >> >> PLEASE, PLEASE, PLEASEâ¦ take a moment to read and try the document. Is >> very important that document reflects new process and works reliable in >> different scenarios (I validated it on macOS and Windows, and assumed it >> worked fine on linux but you knowâ¦ bad assumptions is the base of failure ;) >> ) >> >> Iâm eager to hear your feedback and continue enhancing the process. >> >> (yes, Stef, I know UI is still cumbersomeâ¦ Iâm working on that :) ) >> >> cheers! >> Esteban

Jan. 19, 2018

Re: [Pharo-dev] [IMPORTANT] PHARO CONTRIBUTION PROCESS UPDATED! PLEASE READ!

by Stephane Ducasse

On Fri, Jan 19, 2018 at 8:39 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > hi :) > > On 18 Jan 2018, at 18:39, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > Thanks Luke for your feedback > Guillermo and Pablo are working on a new Iceberg model and UI. > > > Model is done, we will integrate it as 0.7 version. > UIâ¦ is harder. We could do a simple UI that allows just ONE path but at the > end, no one will use it, because almost no use-case follows that. Believe > me, I made a research on thatâ¦ and if you do not believe me, go and try > github desktop, which basically does that (and nobody uses it ;) ) > > true story: actually the UI of iceberg was pretty simple when we started. It > became the mess it is now just adding what people asked to have. > but also true story: it *is* a mess, so we have to get it right before > release of Pharo7 :) Esteban there are central problems in Iceberg current UI. If we do not try something else we will not have feedback. > > May be > we can ask you if you want to give them feedback > and try the new version. > It is important for us that people can contribute. > > Stef > > On Wed, Jan 17, 2018 at 12:20 PM, Luke Gorrie <luke(a)snabb.co> wrote: > > Just one data point... > > I am completely overwhelmed by all of the different ways to manage source > code in the Pharo universe. I would love to contribute to upstream but this > seems way out of reach: I'm not even managing to keep track of the code in > my own home directory properly yet. > > > there are just two ways: > > - iceberg > - monticello > > compare with the amount of ways you have in other languages. > you can use either way you want to keep yours sources. > > but to contribute to Pharo there is just *one* way, following this > instructions: > https://github.com/pharo-project/pharo/wiki/Contribute-a-fix-to-Pharo > > people has reported this version is a lot easier than previous ones (and is > not much different on how to contribute to other languages) but we are still > looking for ways to simplify it (I want to test github issue tracker soon, > for example, to enhance communication that today is broken in two partsâ¦ and > honest reality check: people finds easier to discuss on github over the PR > than over fogbugz). > > Just now I am looking at upstream code that should be fixed: CairoLibrary > unix32ModuleName and unix64ModuleName are giving higher priority to guessed > hard-coded paths than to LD_LIBRARY_PATH and this is backwards i.e. the > carefully selected paths a user supplies with LD_LIBRARY_PATH should come > first (imho.) > > > follow the contribution instructions ;) > > On the one hand it would be fine to dive into the upstream contribution > process to work out how to do this. On the other hand I am still trying to > master tools like Epica to recover useful code that I have written and lost > track of when images crash and get rebuilt etc. I really need to get this > under control before spending time learning Iceberg, FogBugz, etc. > > > wellâ¦ not so much to say here. My only advice is to save often you image, > when you are working with things that you know may crash the VM (like using > FFI). > > cheers! > Esteban > > > > > > On 14 December 2017 at 13:19, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > Hi! > > Iâm working on simplifying the contribution process, after collecting > opinions/experiences last couple of months. > As you know, Pharo contribution process is still WIP and we aim to have it > as smooth as possible for Pharo 7.0 release. Now, after observe the idea of > the âsystem repositoriesâ was a bad idea because it introduced extra and non > standard âpathâ to contribution, I managed to remove that to reestablish > âthe regular wayâ: you will now need to add pharo repository just as any > other repository you add, by cloning or adding local repository. > > I took Guilleâs doc and moved it to pharo project (it does not has sense > to have it living in a contributorâs repository when is so important). You > can find it here: > > https://github.com/pharo-project/pharo/wiki/Contribute-a-fix-to-Pharo > > This document is also updated to reveal this new process, please read it. > > How to update your startup scripts? > Some people has added startup scripts to easy the first part of > contribution. Instead enabling system repositories, etc. you now need to > replace that with this: > > (IceRepositoryCreator new > location: '/path/to/pharo-project/pharo' asFileReference; > subdirectory: 'src'; > createRepository) > register > > PLEASE, PLEASE, PLEASEâ¦ take a moment to read and try the document. Is > very important that document reflects new process and works reliable in > different scenarios (I validated it on macOS and Windows, and assumed it > worked fine on linux but you knowâ¦ bad assumptions is the base of failure ;) > ) > > Iâm eager to hear your feedback and continue enhancing the process. > > (yes, Stef, I know UI is still cumbersomeâ¦ Iâm working on that :) ) > > cheers! > Esteban > > > > >

Jan. 19, 2018

Re: [Pharo-dev] [IMPORTANT] PHARO CONTRIBUTION PROCESS UPDATED! PLEASE READ!

by Esteban Lorenzano

> On 19 Jan 2018, at 10:53, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > Hi Luke, > > On 19 January 2018 at 10:39, Luke Gorrie <luke(a)snabb.co> wrote: >> Thanks Esteban. It's a relief to know that eveything is my fault. >> >> Have a nice life... > > I think you're reading this more negatively than intended. > > Esteban's point was that when he refers to the pharo contribution > process he only means contributing to the image, and that there's no > formal (Pharo) process for the VM (there is the vm-dev mailing list, > of course). :( I do not understand where I say it was your fault. As Alistair said, I was pointing you are talking about something that may be problematic, but is not part of the regular pharo process. then I pointed you to the official vm sources and the official pharo sources (different things) both of them with instructions that work on how to build (but not on NixOS, but as you said, currently is not a supported platform). So, as I saidâ¦ your problems are *not* related to the contribution to pharo but to the particularities of what you are doing. the mail where you are are answering was about contributing changes to pharo, hence not related to your problems. I remain: process to contribute to pharo is not the point of problem here. And figure out where the problems come from is the first step to fix them (and again, I *pointed* where your problems come, according your description: the VM building). Esteban > > Cheers, > Alistair > > > >> On 19 January 2018 at 10:28, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>> >>> >>> >>> On 19 Jan 2018, at 10:17, Luke Gorrie <luke(a)snabb.co> wrote: >>> >>> Hi Esteban, >>> >>> I am really happy that everything is working so well for you and I hope >>> that other people are having a similar experience. >>> >>> For me it's another story. I'm on an unsupported platform (NixOS Linux), >>> I'm building the VM from random git commits because the source releases are >>> all antiquated, Iceberg segfaults the moment I start it, and >>> epica+monticello+metacello+iceberg+fogbugz+jenkins feels like a series of >>> obstacles between me and maintaining my application. >>> >>> The way I am coping is to scale back my ambitions. I spent a lot of time >>> making a complete packaging for NixOS but without proper source releases >>> from upstream that was too much work so I abandoned it. I take the >>> non-reproducible builds from Jenkins and import them as binary-blobs into >>> the build environment that I actually want to use. I accumulate fixes as >>> changesets in a patches/ directory instead of sending them upstream. >>> >>> To me it's a slap in the face when you tell me that it's so simple, there >>> is only one true way to contribute to Pharo, and the first step of that >>> procedure is to *install a binary that is not compatible with my Linux >>> distribution.* >>> >>> >>> because you are mixing âcontribute to pharoâ with âbuilding the VM in >>> another platformâ :) >>> the image itself (hence, the pharo process) does not has anything to do >>> with using NixOS as target platform. In this last effort (that I salute), >>> you are basically by your ownâ¦ >>> nevertheless, I have to point: >>> >>> - there are proper source for the VM: >>> https://github.com/OpenSmalltalk/opensmalltalk-vm (releases is another >>> point, but you can take the Cog branch as âstableâ. This has all sources you >>> need to compile the VM. I have no idea how packaging for NixOS works, but I >>> guess you can adapt from there. >>> - once VM is built, the Pharo image will runâ¦ you do not have to build an >>> image for being able to use it. Now, if you want to do it, here: >>> https://github.com/pharo-project/pharo are âproperâ Pharo sources along with >>> the way to bootstrap. We are doing that in linux and macOS every day, so is >>> a proven script that works. Again no idea how to do it on NixOS, but again, >>> no idea why you care. >>> - once you have all that working, for *your own sources*: use monticello >>> or iceberg, the one you prefer. >>> - for contribute to pharo, follow the process pointed. >>> >>> cheers! >>> Esteban >>> >>> ps: but all you describe as problematic has *nothing* to do with pharo >>> process but with your building of the VM (and probably the image) in macOS. >>> >>> >>> >>> >> >

Jan. 19, 2018

Re: [Pharo-dev] [IMPORTANT] PHARO CONTRIBUTION PROCESS UPDATED! PLEASE READ!

by Alistair Grant

Hi Luke, On 19 January 2018 at 10:39, Luke Gorrie <luke(a)snabb.co> wrote: > Thanks Esteban. It's a relief to know that eveything is my fault. > > Have a nice life... I think you're reading this more negatively than intended. Esteban's point was that when he refers to the pharo contribution process he only means contributing to the image, and that there's no formal (Pharo) process for the VM (there is the vm-dev mailing list, of course). Cheers, Alistair > On 19 January 2018 at 10:28, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> >> >> On 19 Jan 2018, at 10:17, Luke Gorrie <luke(a)snabb.co> wrote: >> >> Hi Esteban, >> >> I am really happy that everything is working so well for you and I hope >> that other people are having a similar experience. >> >> For me it's another story. I'm on an unsupported platform (NixOS Linux), >> I'm building the VM from random git commits because the source releases are >> all antiquated, Iceberg segfaults the moment I start it, and >> epica+monticello+metacello+iceberg+fogbugz+jenkins feels like a series of >> obstacles between me and maintaining my application. >> >> The way I am coping is to scale back my ambitions. I spent a lot of time >> making a complete packaging for NixOS but without proper source releases >> from upstream that was too much work so I abandoned it. I take the >> non-reproducible builds from Jenkins and import them as binary-blobs into >> the build environment that I actually want to use. I accumulate fixes as >> changesets in a patches/ directory instead of sending them upstream. >> >> To me it's a slap in the face when you tell me that it's so simple, there >> is only one true way to contribute to Pharo, and the first step of that >> procedure is to *install a binary that is not compatible with my Linux >> distribution.* >> >> >> because you are mixing âcontribute to pharoâ with âbuilding the VM in >> another platformâ :) >> the image itself (hence, the pharo process) does not has anything to do >> with using NixOS as target platform. In this last effort (that I salute), >> you are basically by your ownâ¦ >> nevertheless, I have to point: >> >> - there are proper source for the VM: >> https://github.com/OpenSmalltalk/opensmalltalk-vm (releases is another >> point, but you can take the Cog branch as âstableâ. This has all sources you >> need to compile the VM. I have no idea how packaging for NixOS works, but I >> guess you can adapt from there. >> - once VM is built, the Pharo image will runâ¦ you do not have to build an >> image for being able to use it. Now, if you want to do it, here: >> https://github.com/pharo-project/pharo are âproperâ Pharo sources along with >> the way to bootstrap. We are doing that in linux and macOS every day, so is >> a proven script that works. Again no idea how to do it on NixOS, but again, >> no idea why you care. >> - once you have all that working, for *your own sources*: use monticello >> or iceberg, the one you prefer. >> - for contribute to pharo, follow the process pointed. >> >> cheers! >> Esteban >> >> ps: but all you describe as problematic has *nothing* to do with pharo >> process but with your building of the VM (and probably the image) in macOS. >> >> >> >> >

Jan. 19, 2018

Re: [Pharo-dev] [IMPORTANT] PHARO CONTRIBUTION PROCESS UPDATED! PLEASE READ!

by Alistair Grant

Hi Luke, On 19 January 2018 at 10:17, Luke Gorrie <luke(a)snabb.co> wrote: > Hi Esteban, > > I am really happy that everything is working so well for you and I hope that > other people are having a similar experience. > > For me it's another story. I'm on an unsupported platform (NixOS Linux), I'm > building the VM from random git commits because the source releases are all > antiquated, Iceberg segfaults the moment I start it, Are you building 32 or 64 bit VMs? My experience has been that 64 bit VMs on linux have problems with libgit2. If you can use 32 bit VMs for now you might get better stability. I'm currently running: 5.0-201801110739 Thursday 11 January 09:30:12 CET 2018 gcc 4.8.5 [Production Spur VM] CoInterpreter VMMaker.oscog-eem.2302 uuid: 55ec8f63-cdbe-4e79-8f22-48fdea585b88 Jan 11 2018 StackToRegisterMappingCogit VMMaker.oscog-eem.2302 uuid: 55ec8f63-cdbe-4e79-8f22-48fdea585b88 Jan 11 2018 VM: 201801110739 alistair@alistair-xps13:snap/pharo-snap/pharo-vm/opensmalltalk-vm $ Date: Wed Jan 10 23:39:30 2018 -0800 $ Plugins: 201801110739 alistair@alistair-xps13:snap/pharo-snap/pharo-vm/opensmalltalk-vm $ Linux b07d7880072c 4.13.0-26-generic #29~16.04.2-Ubuntu SMP Tue Jan 9 22:00:44 UTC 2018 i686 i686 i686 GNU/Linux plugin path: /snap/core/3748/lib/i386-linux-gnu/ [default: /snap/core/3748/lib/i386-linux-gnu/] without any problems. I've tried looking at the libgit2 issue in a debug vm, but (with my meagre skills): - the memory corruption isn't consistent, i.e. the crash occurs in different places on multiple runs - the crash doesn't occur until sometime after the corruption :-( HTH, Alistair > and > epica+monticello+metacello+iceberg+fogbugz+jenkins feels like a series of > obstacles between me and maintaining my application. > > The way I am coping is to scale back my ambitions. I spent a lot of time > making a complete packaging for NixOS but without proper source releases > from upstream that was too much work so I abandoned it. I take the > non-reproducible builds from Jenkins and import them as binary-blobs into > the build environment that I actually want to use. I accumulate fixes as > changesets in a patches/ directory instead of sending them upstream. > > To me it's a slap in the face when you tell me that it's so simple, there is > only one true way to contribute to Pharo, and the first step of that > procedure is to *install a binary that is not compatible with my Linux > distribution.* > >

Jan. 19, 2018

Re: [Pharo-dev] [IMPORTANT] PHARO CONTRIBUTION PROCESS UPDATED! PLEASE READ!

by Luke Gorrie

Thanks Esteban. It's a relief to know that eveything is my fault. Have a nice life... On 19 January 2018 at 10:28, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > On 19 Jan 2018, at 10:17, Luke Gorrie <luke(a)snabb.co> wrote: > > Hi Esteban, > > I am really happy that everything is working so well for you and I hope > that other people are having a similar experience. > > For me it's another story. I'm on an unsupported platform (NixOS Linux), > I'm building the VM from random git commits because the source releases are > all antiquated, Iceberg segfaults the moment I start it, and > epica+monticello+metacello+iceberg+fogbugz+jenkins feels like a series of > obstacles between me and maintaining my application. > > The way I am coping is to scale back my ambitions. I spent a lot of time > making a complete packaging for NixOS but without proper source releases > from upstream that was too much work so I abandoned it. I take the > non-reproducible builds from Jenkins and import them as binary-blobs into > the build environment that I actually want to use. I accumulate fixes as > changesets in a patches/ directory instead of sending them upstream. > > To me it's a slap in the face when you tell me that it's so simple, there > is only one true way to contribute to Pharo, and the first step of that > procedure is to *install a binary that is not compatible with my Linux > distribution.* > > > because you are mixing âcontribute to pharoâ with âbuilding the VM in > another platformâ :) > the image itself (hence, the pharo process) does not has anything to do > with using NixOS as target platform. In this last effort (that I salute), > you are basically by your ownâ¦ > nevertheless, I have to point: > > - there are proper source for the VM: https://github.com/ > OpenSmalltalk/opensmalltalk-vm (releases is another point, but you can > take the Cog branch as âstableâ. This has all sources you need to compile > the VM. I have no idea how packaging for NixOS works, but I guess you can > adapt from there. > - once VM is built, the Pharo image will runâ¦ you do not have to build an > image for being able to use it. Now, if you want to do it, here: > https://github.com/pharo-project/pharo are âproperâ Pharo sources along > with the way to bootstrap. We are doing that in linux and macOS every day, > so is a proven script that works. Again no idea how to do it on NixOS, but > again, no idea why you care. > - once you have all that working, for *your own sources*: use monticello > or iceberg, the one you prefer. > - for contribute to pharo, follow the process pointed. > > cheers! > Esteban > > ps: but all you describe as problematic has *nothing* to do with pharo > process but with your building of the VM (and probably the image) in macOS. > > > > >

Jan. 19, 2018

[JOB][Research] Inria Research CRCN Position

by Marcus Denker

FULL TIME PERMANENT RESEARCH POSITIONS IN LILLE, FRANCE Inria opens on January 15, 2018 nine competitions of normal class researchers. 23 positions will be filled in the 8 research centers of the Institute. The deadline for submitting applications is 19 February 2018 midnight French time. CRCN âYoung graduate scientistâ The CRCN position is a research position for both Junior (old CR2) and Senior (old CR1) level researchers. No teaching, permanent position with tenure after a probation period of 12 Months. Requirements: â¢ Holders of a doctorate or equivalent degree; â¢ Applicants able to prove publications and scientific work deemed equivalent. There are no age limits or nationality requirements for the recruitment of young graduated scientists. More information: https://www.inria.fr/en/institute/recruitment/offers/young-graduate-scienti… PROFILE The candidate must have a doctoral degree, a strong background in Computer Science, and internationally significant research achievements in software engineering (particularly software evolution) and/or programming languages. Duties include: â¢ Research (no teaching). â¢ Help manage the RMoD Research group. â¢ Be involved with the self-governance of the Inria Lab and Inria as a whole. â¢ Guide PhD students (and therefore get a French habilitation to be able to formally supervise PhD students). â¢ Help acquire additional funds for PhD students, Postdocs and Engineers. â¢ Transfer research results to the real world. MISSION Join one of our two lines of research: Tools for Software Maintenance or New Programming Language Constructs for Software Evolution. THE REGION Lille is strategically located in Northern Europe with train connections to Paris (1h) , London (1h30) and Brussels (30 min.) The Nord Pas de Calais region is a dynamic area in both industry and research for computer science with companies that are european leaders in their branch. Lille, the capital of northern France is an attractive metropolis of over 1 million inhabitants. Cost of living in Lille is lower than that of very big cities such as Paris and London. THE TEAM RMoD is an Inria research project team. It consists of 6 permant researchers (Inria CR and DR, as well as University Assistant Professors) and Engineers, postdocs and students (Master and PhD). RMoD is an international team with more than 20 members from six countries. LINKS: â¢ RMoD: http://rmod.lille.inria.fr â¢ INRIA Lille: http://www.inria.fr/lille/ â¢ INRIA in General: http://www.inria.fr â¢ Lille: â¢ http://en.wikipedia.org/wiki/Lille â¢ http://wikitravel.org/en/Lille APPLICATION Please contact the head of the research team: Stephane.Ducasse(a)inria.fr or one of the following group members: Nicolas.Anquetil(a)inria.fr, Marcus.Denker(a)inria.fr

Jan. 19, 2018

Re: [Pharo-dev] [IMPORTANT] PHARO CONTRIBUTION PROCESS UPDATED! PLEASE READ!

by Esteban Lorenzano

> On 19 Jan 2018, at 10:17, Luke Gorrie <luke(a)snabb.co> wrote: > > Hi Esteban, > > I am really happy that everything is working so well for you and I hope that other people are having a similar experience. > > For me it's another story. I'm on an unsupported platform (NixOS Linux), I'm building the VM from random git commits because the source releases are all antiquated, Iceberg segfaults the moment I start it, and epica+monticello+metacello+iceberg+fogbugz+jenkins feels like a series of obstacles between me and maintaining my application. > > The way I am coping is to scale back my ambitions. I spent a lot of time making a complete packaging for NixOS but without proper source releases from upstream that was too much work so I abandoned it. I take the non-reproducible builds from Jenkins and import them as binary-blobs into the build environment that I actually want to use. I accumulate fixes as changesets in a patches/ directory instead of sending them upstream. > > To me it's a slap in the face when you tell me that it's so simple, there is only one true way to contribute to Pharo, and the first step of that procedure is to *install a binary that is not compatible with my Linux distribution.* because you are mixing âcontribute to pharoâ with âbuilding the VM in another platformâ :) the image itself (hence, the pharo process) does not has anything to do with using NixOS as target platform. In this last effort (that I salute), you are basically by your ownâ¦ nevertheless, I have to point: - there are proper source for the VM: https://github.com/OpenSmalltalk/opensmalltalk-vm <https://github.com/OpenSmalltalk/opensmalltalk-vm> (releases is another point, but you can take the Cog branch as âstableâ. This has all sources you need to compile the VM. I have no idea how packaging for NixOS works, but I guess you can adapt from there. - once VM is built, the Pharo image will runâ¦ you do not have to build an image for being able to use it. Now, if you want to do it, here: https://github.com/pharo-project/pharo <https://github.com/pharo-project/pharo> are âproperâ Pharo sources along with the way to bootstrap. We are doing that in linux and macOS every day, so is a proven script that works. Again no idea how to do it on NixOS, but again, no idea why you care. - once you have all that working, for *your own sources*: use monticello or iceberg, the one you prefer. - for contribute to pharo, follow the process pointed. cheers! Esteban ps: but all you describe as problematic has *nothing* to do with pharo process but with your building of the VM (and probably the image) in macOS. > >

Jan. 19, 2018

Re: [Pharo-dev] [IMPORTANT] PHARO CONTRIBUTION PROCESS UPDATED! PLEASE READ!

by Luke Gorrie

Hi Esteban, I am really happy that everything is working so well for you and I hope that other people are having a similar experience. For me it's another story. I'm on an unsupported platform (NixOS Linux), I'm building the VM from random git commits because the source releases are all antiquated, Iceberg segfaults the moment I start it, and epica+monticello+metacello+iceberg+fogbugz+jenkins feels like a series of obstacles between me and maintaining my application. The way I am coping is to scale back my ambitions. I spent a lot of time making a complete packaging for NixOS but without proper source releases from upstream that was too much work so I abandoned it. I take the non-reproducible builds from Jenkins and import them as binary-blobs into the build environment that I actually want to use. I accumulate fixes as changesets in a patches/ directory instead of sending them upstream. To me it's a slap in the face when you tell me that it's so simple, there is only one true way to contribute to Pharo, and the first step of that procedure is to *install a binary that is not compatible with my Linux distribution.*

Jan. 19, 2018

[Pharo 7.0-dev] Build #437: 20992-Use-Stdio-class-instead-of-VTermOutputDriver

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

There is a new Pharo build available! The status of the build #437 was: SUCCESS. The Pull Request #691 was integrated: "20992-Use-Stdio-class-instead-of-VTermOutputDriver" Pull request url: https://github.com/pharo-project/pharo/pull/691 Issue Url: https://pharo.fogbugz.com/f/cases/20992 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Jan. 19, 2018