- Pharo-users - lists.pharo.org

Re: [Pharo-users] Pharo 6.0 and 6.1 64 bit freeze on MacMini

by stephan

On 31-07-17 16:42, TedVanGaalen wrote: > I've just installed the 32bit version. same problems here. freezes Where did you install what versions of vm and image on what OS X version? Stephan

July 31, 2017

Re: [Pharo-users] Pharo 6.0 and 6.1 64 bit freeze on MacMini

by TedVanGaalen

I've just installed the 32bit version. same problems here. freezes -- View this message in context: http://forum.world.st/Pharo-6-0-and-6-1-64-bit-freeze-on-MacMini-tp4957969p… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

July 31, 2017

Re: [Pharo-users] Iceberg: SCP urls are not limited to 'git@'

by Herby VojÄÃk

I put this hotfix in my script: "Work around scp url hardwired 'git@'" IceScpRemote class compile: 'canHandleUrl: aRepositoryUrl "Very simplistic implementation that does not cover all cases" ^ aRepositoryUrl matchesRegex: ''([\w.-]+@|ssh\://).*'''. IceScpRemote compile: ((IceScpRemote >> #parseUrl) sourceCode copyReplaceAll: 'git@' with: '[\w.-]+@'). Is it ok for Iceberg devs to make those (or similar) changes into Iceberg code itself? Herby Herby VojÄÃk wrote: > Hello! > > Once I finally added remote to my localgit repo, I cannot build my image > any more because Iceberg fails to parse the url. After first error I > tried ssh://, but it is protected as well. > > The problem is, git(a)host.site is just the way to say which user to log > in via ssh into the host. We use on-premise gogs installed via apt, and > it installs 'gogs' user, not 'git' user. As such, we were being able to > successfully use 'gogs@our.site:org/towergame.git' type of remote URLs, > but Iceberg code has 'git@' hardcoded. > > How to overcome this? > > Herby >

July 31, 2017

Re: [Pharo-users] Creating the smallest server runtime footprint

by Pavel Krivanek

2017-07-31 15:28 GMT+02:00 Tim Mackinnon <tim(a)testit.works>: > Ok (I am reading there is a lot going on for you guys to sort out at the > moment). > > It sounds like a more stable conversion of Pharo 6.1 for 64 bit would be > best to give me a stable platform to run on. > > In that minimal image - what can I rely on to load code (in trying the 7.0 > version it seems like Gofer isnât there, and Iâm now wondering if Metacello > isnât there either) - so Iâm wondering how you guys load baselinesOf of > configurationsOf? > Try it again, there was a bug in the job configuration .. Pavel > > Tim > > On 31 Jul 2017, at 14:17, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > H Tim > > 2017-07-31 15:07 GMT+02:00 Tim Mackinnon <tim(a)testit.works>: > >> Hi Pavel - Iâm just revisiting a few of your previous messages on minimal >> images as Iâm trying to get things working again with Pharo 6.1 now that >> you guys have rejigged all of the build pipelines. >> >> I tried a previous suggestion of: >> >> For Pharo 6: https://ci.inria.fr/pharo/job/Pharo-6.0-Update-Step-3.2-M >> inimal/lastSuccessfulBuild/artifact/Pharo-minimal-64.zip >> For Pharo 7: https://ci.inria.fr/pharo/view/7.0/job/70-Bootstrap-32bit >> -Conversion/lastSuccessfulBuild/artifact/latest-minimal-64.zip >> >> However the Pharo 6 version is no longer being built, and it doesnât seem >> to work well with the newer 64bit vm (? I seem to get a load error that I >> didnât have before - although its possible that Iâm loading a new pre-req >> with metacello and this is tipping it over the edge). >> >> Anyway - a prev suggestion for 6.x from you was: >> >> https://ci.inria.fr/pharo/view/6.0-SysConf/job/Pharo-6.0- >> Step-04-01-ConfigurationOfMinimalPharo/ >> >> >> However this is a 32bit image. Is there an equivalent 64bit image for >> 6.1? OR should I use the Pharo 7 one for now (I guess the minimal image >> will probably be pretty stable for a little while as Iâm sure the action is >> higher up the chain?) >> > > You should use an image that is bootstrapped, so version from SysConf jobs > or Pharo 7. For Pharo 7 we are preparing a lot of big changes in the kernel > so do not expect it will be stable. We can do a conversion job of of it to > 64-bit version as soon as the CI infrastructure will be on knees again. > > -- Pavel > > > >> >> Tim >> >> >> On 15 Jul 2017, at 09:35, Pavel Krivanek <pavel.krivanek(a)gmail.com> >> wrote: >> >> If you want to stay with Pharo 6 image, you can try the bootstrapped >> version of the minimal image: >> https://ci.inria.fr/pharo/view/6.0-SysConf/job/Pharo-6.0- >> Step-04-01-ConfigurationOfMinimalPharo/ >> >> -- Pavel >> >> 2017-07-15 10:33 GMT+02:00 Pavel Krivanek <pavel.krivanek(a)gmail.com>: >> >>> Try the Pharo 7 metacello image (=Pharo 7 minimal image that the CI is >>> already converting to 64bit). There should be no problem with STON because >>> whole Pharo is loaded into it using metacello and filetree. Pharo 6 minimal >>> image is done differently (by shrinking) and not so well tested. >>> >>> For the conversion of 32-bit image to 64-bit image you need a VMMaker >>> image: >>> https://ci.inria.fr/pharo/job/Spur-Git-Tracker/lastSuccessfu >>> lBuild/artifact/vmmaker-image.zip >>> and then evaluate: >>> ./pharo generator.image eval "[Spur32to64BitBootstrap new >>> bootstrapImage: 'conversion.image'] on: AssertionFailure do: [ :fail | fail >>> resumeUnchecked: nil ]" >>> >>> -- Pavel >>> >>> >>> >>> 2017-07-15 10:19 GMT+02:00 Tim Mackinnon <tim(a)testit.works>: >>> >>>> Hi Pavel - thanks for getting me to the point where I could even have a >>>> minimal image. As Iâm on the edge of my Pharo knowledge here, Iâll try and >>>> run with this as best I can. >>>> >>>> Iâd been using the 6.0 image you suggested to me - but maybe I could >>>> use a 70 image with Pharo 6 for a while (until the VM diverges) right? >>>> >>>> The bit I havenât quite understood however, is how the 64bit image is >>>> created - as your reference is to a 32bit version? Is the 64bit one >>>> converted from 32 in a later stage? (For AWS Lambda I need 64bit) - am I >>>> right in thinking the pipeline stage after this one is the one you sent me >>>> - and the travis.yml file shows me what it does? But I canât see a >>>> trivis.yml in the conversion stage so Iâm not sure how it does that. >>>> (Question - how do I see what the pipelines do to answer my own questions?) >>>> >>>> I was hoping that there was a basic image that got me up to metacello >>>> baseline level to load git file tree packages/baselines in my own repo as >>>> well baselines on the internet. The one you sent me is fairly close to that >>>> (its just missing STON in the image and seems to have an issue with >>>> resolving undeclared classes that get loaded in - should do a fogbugz on >>>> that?) >>>> >>>> The follow-on from a metacello image is how we can get people to create >>>> better baselines that give you more minimal loading options (e.g. >>>> conditionally leave out the test cases perhaps) >>>> >>>> Tim >>>> >>>> On 15 Jul 2017, at 08:24, Pavel Krivanek <pavel.krivanek(a)gmail.com> >>>> wrote: >>>> >>>> Hi Tim, >>>> >>>> you can base the your work on the bootstrapped image, see >>>> https://ci.inria.fr/pharo/view/7.0/job/70-Bootstrap-32bit/, file >>>> Pharo7.0-core-*.zip >>>> >>>> This image does not have a lot of basic components like Monticello or >>>> network but it has a compiler so the code can be imported as *.st files. >>>> Then we have Pharo7.0-monticello-*.zip which will be easier to use and >>>> probably can fit your needs. Monticello and network support are included. >>>> But you cannot use baselines nor configurations to load your code. >>>> >>>> -- Pavel >>>> >>>> 2017-07-14 9:59 GMT+02:00 Tim Mackinnon <tim(a)testit.works>: >>>> >>>>> Hi - buoyed by the success of a minimal image (thanks Pavel), I'm >>>>> wondering if I can get even smaller. >>>>> >>>>> There are lots of .so's in the vm which wouldn't make sense on a >>>>> server once deployed - sound, maybe libgit ... >>>>> >>>>> Is there a list of the essential ones, or tips on what I can strip out >>>>> of the Linux deployment? I also recall that i can leave out .sources and >>>>> .changes as well right? >>>>> >>>>> Tim >>>>> >>>>> Sent from my iPhone >>>> >>>> >

July 31, 2017

Pharo 6.0 and 6.1 64 bit freeze on MacMini

by Ted F.A.van Gaalen

Hi, I reverted to 5.0 because Pharo 6.0 and 6.1 64 bit hangs on my Mac Mini with UDH 4K screen (may that has to do with?) with its maiden image (at first start after download when: I resize or go to full screen. Maybe VM problem? my mac Mini metrics: Hardware Overview: Model Name: Mac mini Model Identifier: Macmini6,2 Processor Name: Intel Core i7 Processor Speed: 2,6 GHz Number of Processors: 1 Total Number of Cores: 4 L2 Cache (per Core): 256 KB L3 Cache: 6 MB Memory: 4 GB Boot ROM Version: MM61.0106.B1F SMC Version (system): 2.8f0 maybe this problem was already reported, but could find it. Kind Regards TedvG

July 31, 2017

Re: [Pharo-users] Creating the smallest server runtime footprint

by Tim Mackinnon

Ok (I am reading there is a lot going on for you guys to sort out at the moment). It sounds like a more stable conversion of Pharo 6.1 for 64 bit would be best to give me a stable platform to run on. In that minimal image - what can I rely on to load code (in trying the 7.0 version it seems like Gofer isnât there, and Iâm now wondering if Metacello isnât there either) - so Iâm wondering how you guys load baselinesOf of configurationsOf? Tim > On 31 Jul 2017, at 14:17, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > H Tim > > 2017-07-31 15:07 GMT+02:00 Tim Mackinnon <tim(a)testit.works <mailto:tim@testit.works>>: > Hi Pavel - Iâm just revisiting a few of your previous messages on minimal images as Iâm trying to get things working again with Pharo 6.1 now that you guys have rejigged all of the build pipelines. > > I tried a previous suggestion of: > > For Pharo 6: https://ci.inria.fr/pharo/job/Pharo-6.0-Update-Step-3.2-Minimal/lastSuccess… <https://ci.inria.fr/pharo/job/Pharo-6.0-Update-Step-3.2-Minimal/lastSuccess…> > For Pharo 7: https://ci.inria.fr/pharo/view/7.0/job/70-Bootstrap-32bit-Conversion/lastSu… <https://ci.inria.fr/pharo/view/7.0/job/70-Bootstrap-32bit-Conversion/lastSu…> > > However the Pharo 6 version is no longer being built, and it doesnât seem to work well with the newer 64bit vm (? I seem to get a load error that I didnât have before - although its possible that Iâm loading a new pre-req with metacello and this is tipping it over the edge). > > Anyway - a prev suggestion for 6.x from you was: >> https://ci.inria.fr/pharo/view/6.0-SysConf/job/Pharo-6.0-Step-04-01-Configu… <https://ci.inria.fr/pharo/view/6.0-SysConf/job/Pharo-6.0-Step-04-01-Configu…> > However this is a 32bit image. Is there an equivalent 64bit image for 6.1? OR should I use the Pharo 7 one for now (I guess the minimal image will probably be pretty stable for a little while as Iâm sure the action is higher up the chain?) > > You should use an image that is bootstrapped, so version from SysConf jobs or Pharo 7. For Pharo 7 we are preparing a lot of big changes in the kernel so do not expect it will be stable. We can do a conversion job of of it to 64-bit version as soon as the CI infrastructure will be on knees again. > > -- Pavel > > > > Tim > > >> On 15 Jul 2017, at 09:35, Pavel Krivanek <pavel.krivanek(a)gmail.com <mailto:pavel.krivanek@gmail.com>> wrote: >> >> If you want to stay with Pharo 6 image, you can try the bootstrapped version of the minimal image: >> https://ci.inria.fr/pharo/view/6.0-SysConf/job/Pharo-6.0-Step-04-01-Configu… <https://ci.inria.fr/pharo/view/6.0-SysConf/job/Pharo-6.0-Step-04-01-Configu…> >> >> -- Pavel >> >> 2017-07-15 10:33 GMT+02:00 Pavel Krivanek <pavel.krivanek(a)gmail.com <mailto:pavel.krivanek@gmail.com>>: >> Try the Pharo 7 metacello image (=Pharo 7 minimal image that the CI is already converting to 64bit). There should be no problem with STON because whole Pharo is loaded into it using metacello and filetree. Pharo 6 minimal image is done differently (by shrinking) and not so well tested. >> >> For the conversion of 32-bit image to 64-bit image you need a VMMaker image: >> https://ci.inria.fr/pharo/job/Spur-Git-Tracker/lastSuccessfulBuild/artifact… <https://ci.inria.fr/pharo/job/Spur-Git-Tracker/lastSuccessfulBuild/artifact…> >> and then evaluate: >> ./pharo generator.image eval "[Spur32to64BitBootstrap new bootstrapImage: 'conversion.image'] on: AssertionFailure do: [ :fail | fail resumeUnchecked: nil ]" >> >> -- Pavel >> >> >> >> 2017-07-15 10:19 GMT+02:00 Tim Mackinnon <tim(a)testit.works <mailto:tim@testit.works>>: >> Hi Pavel - thanks for getting me to the point where I could even have a minimal image. As Iâm on the edge of my Pharo knowledge here, Iâll try and run with this as best I can. >> >> Iâd been using the 6.0 image you suggested to me - but maybe I could use a 70 image with Pharo 6 for a while (until the VM diverges) right? >> >> The bit I havenât quite understood however, is how the 64bit image is created - as your reference is to a 32bit version? Is the 64bit one converted from 32 in a later stage? (For AWS Lambda I need 64bit) - am I right in thinking the pipeline stage after this one is the one you sent me - and the travis.yml file shows me what it does? But I canât see a trivis.yml in the conversion stage so Iâm not sure how it does that. (Question - how do I see what the pipelines do to answer my own questions?) >> >> I was hoping that there was a basic image that got me up to metacello baseline level to load git file tree packages/baselines in my own repo as well baselines on the internet. The one you sent me is fairly close to that (its just missing STON in the image and seems to have an issue with resolving undeclared classes that get loaded in - should do a fogbugz on that?) >> >> The follow-on from a metacello image is how we can get people to create better baselines that give you more minimal loading options (e.g. conditionally leave out the test cases perhaps) >> >> Tim >> >>> On 15 Jul 2017, at 08:24, Pavel Krivanek <pavel.krivanek(a)gmail.com <mailto:pavel.krivanek@gmail.com>> wrote: >>> >>> Hi Tim, >>> >>> you can base the your work on the bootstrapped image, see https://ci.inria.fr/pharo/view/7.0/job/70-Bootstrap-32bit/ <https://ci.inria.fr/pharo/view/7.0/job/70-Bootstrap-32bit/>, file Pharo7.0-core-*.zip >>> >>> This image does not have a lot of basic components like Monticello or network but it has a compiler so the code can be imported as *.st files. >>> Then we have Pharo7.0-monticello-*.zip which will be easier to use and probably can fit your needs. Monticello and network support are included. But you cannot use baselines nor configurations to load your code. >>> >>> -- Pavel >>> >>> 2017-07-14 9:59 GMT+02:00 Tim Mackinnon <tim(a)testit.works <mailto:tim@testit.works>>: >>> Hi - buoyed by the success of a minimal image (thanks Pavel), I'm wondering if I can get even smaller. >>> >>> There are lots of .so's in the vm which wouldn't make sense on a server once deployed - sound, maybe libgit ... >>> >>> Is there a list of the essential ones, or tips on what I can strip out of the Linux deployment? I also recall that i can leave out .sources and .changes as well right? >>> >>> Tim >>> >>> Sent from my iPhone

July 31, 2017

Re: [Pharo-users] Creating the smallest server runtime footprint

by Pavel Krivanek

H Tim 2017-07-31 15:07 GMT+02:00 Tim Mackinnon <tim(a)testit.works>: > Hi Pavel - Iâm just revisiting a few of your previous messages on minimal > images as Iâm trying to get things working again with Pharo 6.1 now that > you guys have rejigged all of the build pipelines. > > I tried a previous suggestion of: > > For Pharo 6: https://ci.inria.fr/pharo/job/Pharo-6.0-Update-Step-3.2- > Minimal/lastSuccessfulBuild/artifact/Pharo-minimal-64.zip > For Pharo 7: https://ci.inria.fr/pharo/view/7.0/job/70-Bootstrap- > 32bit-Conversion/lastSuccessfulBuild/artifact/latest-minimal-64.zip > > However the Pharo 6 version is no longer being built, and it doesnât seem > to work well with the newer 64bit vm (? I seem to get a load error that I > didnât have before - although its possible that Iâm loading a new pre-req > with metacello and this is tipping it over the edge). > > Anyway - a prev suggestion for 6.x from you was: > > https://ci.inria.fr/pharo/view/6.0-SysConf/job/Pharo-6.0-Step-04-01- > ConfigurationOfMinimalPharo/ > > > However this is a 32bit image. Is there an equivalent 64bit image for > 6.1? OR should I use the Pharo 7 one for now (I guess the minimal image > will probably be pretty stable for a little while as Iâm sure the action is > higher up the chain?) > You should use an image that is bootstrapped, so version from SysConf jobs or Pharo 7. For Pharo 7 we are preparing a lot of big changes in the kernel so do not expect it will be stable. We can do a conversion job of of it to 64-bit version as soon as the CI infrastructure will be on knees again. -- Pavel > > Tim > > > On 15 Jul 2017, at 09:35, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > If you want to stay with Pharo 6 image, you can try the bootstrapped > version of the minimal image: > https://ci.inria.fr/pharo/view/6.0-SysConf/job/Pharo-6.0-Step-04-01- > ConfigurationOfMinimalPharo/ > > -- Pavel > > 2017-07-15 10:33 GMT+02:00 Pavel Krivanek <pavel.krivanek(a)gmail.com>: > >> Try the Pharo 7 metacello image (=Pharo 7 minimal image that the CI is >> already converting to 64bit). There should be no problem with STON because >> whole Pharo is loaded into it using metacello and filetree. Pharo 6 minimal >> image is done differently (by shrinking) and not so well tested. >> >> For the conversion of 32-bit image to 64-bit image you need a VMMaker >> image: >> https://ci.inria.fr/pharo/job/Spur-Git-Tracker/lastSuccessfu >> lBuild/artifact/vmmaker-image.zip >> and then evaluate: >> ./pharo generator.image eval "[Spur32to64BitBootstrap new bootstrapImage: >> 'conversion.image'] on: AssertionFailure do: [ :fail | fail >> resumeUnchecked: nil ]" >> >> -- Pavel >> >> >> >> 2017-07-15 10:19 GMT+02:00 Tim Mackinnon <tim(a)testit.works>: >> >>> Hi Pavel - thanks for getting me to the point where I could even have a >>> minimal image. As Iâm on the edge of my Pharo knowledge here, Iâll try and >>> run with this as best I can. >>> >>> Iâd been using the 6.0 image you suggested to me - but maybe I could use >>> a 70 image with Pharo 6 for a while (until the VM diverges) right? >>> >>> The bit I havenât quite understood however, is how the 64bit image is >>> created - as your reference is to a 32bit version? Is the 64bit one >>> converted from 32 in a later stage? (For AWS Lambda I need 64bit) - am I >>> right in thinking the pipeline stage after this one is the one you sent me >>> - and the travis.yml file shows me what it does? But I canât see a >>> trivis.yml in the conversion stage so Iâm not sure how it does that. >>> (Question - how do I see what the pipelines do to answer my own questions?) >>> >>> I was hoping that there was a basic image that got me up to metacello >>> baseline level to load git file tree packages/baselines in my own repo as >>> well baselines on the internet. The one you sent me is fairly close to that >>> (its just missing STON in the image and seems to have an issue with >>> resolving undeclared classes that get loaded in - should do a fogbugz on >>> that?) >>> >>> The follow-on from a metacello image is how we can get people to create >>> better baselines that give you more minimal loading options (e.g. >>> conditionally leave out the test cases perhaps) >>> >>> Tim >>> >>> On 15 Jul 2017, at 08:24, Pavel Krivanek <pavel.krivanek(a)gmail.com> >>> wrote: >>> >>> Hi Tim, >>> >>> you can base the your work on the bootstrapped image, see >>> https://ci.inria.fr/pharo/view/7.0/job/70-Bootstrap-32bit/, file >>> Pharo7.0-core-*.zip >>> >>> This image does not have a lot of basic components like Monticello or >>> network but it has a compiler so the code can be imported as *.st files. >>> Then we have Pharo7.0-monticello-*.zip which will be easier to use and >>> probably can fit your needs. Monticello and network support are included. >>> But you cannot use baselines nor configurations to load your code. >>> >>> -- Pavel >>> >>> 2017-07-14 9:59 GMT+02:00 Tim Mackinnon <tim(a)testit.works>: >>> >>>> Hi - buoyed by the success of a minimal image (thanks Pavel), I'm >>>> wondering if I can get even smaller. >>>> >>>> There are lots of .so's in the vm which wouldn't make sense on a server >>>> once deployed - sound, maybe libgit ... >>>> >>>> Is there a list of the essential ones, or tips on what I can strip out >>>> of the Linux deployment? I also recall that i can leave out .sources and >>>> .changes as well right? >>>> >>>> Tim >>>> >>>> Sent from my iPhone >>>> >>>> >>> >>> >> > >

July 31, 2017

Re: [Pharo-users] Creating the smallest server runtime footprint

by Tim Mackinnon

Hi Pavel - Iâm just revisiting a few of your previous messages on minimal images as Iâm trying to get things working again with Pharo 6.1 now that you guys have rejigged all of the build pipelines. I tried a previous suggestion of: For Pharo 6: https://ci.inria.fr/pharo/job/Pharo-6.0-Update-Step-3.2-Minimal/lastSuccess… <https://ci.inria.fr/pharo/job/Pharo-6.0-Update-Step-3.2-Minimal/lastSuccess…> For Pharo 7: https://ci.inria.fr/pharo/view/7.0/job/70-Bootstrap-32bit-Conversion/lastSu… <https://ci.inria.fr/pharo/view/7.0/job/70-Bootstrap-32bit-Conversion/lastSu…> However the Pharo 6 version is no longer being built, and it doesnât seem to work well with the newer 64bit vm (? I seem to get a load error that I didnât have before - although its possible that Iâm loading a new pre-req with metacello and this is tipping it over the edge). Anyway - a prev suggestion for 6.x from you was: > https://ci.inria.fr/pharo/view/6.0-SysConf/job/Pharo-6.0-Step-04-01-Configu… <https://ci.inria.fr/pharo/view/6.0-SysConf/job/Pharo-6.0-Step-04-01-Configu…> However this is a 32bit image. Is there an equivalent 64bit image for 6.1? OR should I use the Pharo 7 one for now (I guess the minimal image will probably be pretty stable for a little while as Iâm sure the action is higher up the chain?) Tim > On 15 Jul 2017, at 09:35, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > If you want to stay with Pharo 6 image, you can try the bootstrapped version of the minimal image: > https://ci.inria.fr/pharo/view/6.0-SysConf/job/Pharo-6.0-Step-04-01-Configu… <https://ci.inria.fr/pharo/view/6.0-SysConf/job/Pharo-6.0-Step-04-01-Configu…> > > -- Pavel > > 2017-07-15 10:33 GMT+02:00 Pavel Krivanek <pavel.krivanek(a)gmail.com <mailto:pavel.krivanek@gmail.com>>: > Try the Pharo 7 metacello image (=Pharo 7 minimal image that the CI is already converting to 64bit). There should be no problem with STON because whole Pharo is loaded into it using metacello and filetree. Pharo 6 minimal image is done differently (by shrinking) and not so well tested. > > For the conversion of 32-bit image to 64-bit image you need a VMMaker image: > https://ci.inria.fr/pharo/job/Spur-Git-Tracker/lastSuccessfulBuild/artifact… <https://ci.inria.fr/pharo/job/Spur-Git-Tracker/lastSuccessfulBuild/artifact…> > and then evaluate: > ./pharo generator.image eval "[Spur32to64BitBootstrap new bootstrapImage: 'conversion.image'] on: AssertionFailure do: [ :fail | fail resumeUnchecked: nil ]" > > -- Pavel > > > > 2017-07-15 10:19 GMT+02:00 Tim Mackinnon <tim(a)testit.works <mailto:tim@testit.works>>: > Hi Pavel - thanks for getting me to the point where I could even have a minimal image. As Iâm on the edge of my Pharo knowledge here, Iâll try and run with this as best I can. > > Iâd been using the 6.0 image you suggested to me - but maybe I could use a 70 image with Pharo 6 for a while (until the VM diverges) right? > > The bit I havenât quite understood however, is how the 64bit image is created - as your reference is to a 32bit version? Is the 64bit one converted from 32 in a later stage? (For AWS Lambda I need 64bit) - am I right in thinking the pipeline stage after this one is the one you sent me - and the travis.yml file shows me what it does? But I canât see a trivis.yml in the conversion stage so Iâm not sure how it does that. (Question - how do I see what the pipelines do to answer my own questions?) > > I was hoping that there was a basic image that got me up to metacello baseline level to load git file tree packages/baselines in my own repo as well baselines on the internet. The one you sent me is fairly close to that (its just missing STON in the image and seems to have an issue with resolving undeclared classes that get loaded in - should do a fogbugz on that?) > > The follow-on from a metacello image is how we can get people to create better baselines that give you more minimal loading options (e.g. conditionally leave out the test cases perhaps) > > Tim > >> On 15 Jul 2017, at 08:24, Pavel Krivanek <pavel.krivanek(a)gmail.com <mailto:pavel.krivanek@gmail.com>> wrote: >> >> Hi Tim, >> >> you can base the your work on the bootstrapped image, see https://ci.inria.fr/pharo/view/7.0/job/70-Bootstrap-32bit/ <https://ci.inria.fr/pharo/view/7.0/job/70-Bootstrap-32bit/>, file Pharo7.0-core-*.zip >> >> This image does not have a lot of basic components like Monticello or network but it has a compiler so the code can be imported as *.st files. >> Then we have Pharo7.0-monticello-*.zip which will be easier to use and probably can fit your needs. Monticello and network support are included. But you cannot use baselines nor configurations to load your code. >> >> -- Pavel >> >> 2017-07-14 9:59 GMT+02:00 Tim Mackinnon <tim(a)testit.works <mailto:tim@testit.works>>: >> Hi - buoyed by the success of a minimal image (thanks Pavel), I'm wondering if I can get even smaller. >> >> There are lots of .so's in the vm which wouldn't make sense on a server once deployed - sound, maybe libgit ... >> >> Is there a list of the essential ones, or tips on what I can strip out of the Linux deployment? I also recall that i can leave out .sources and .changes as well right? >> >> Tim >> >> Sent from my iPhone >> >> > > >

July 31, 2017

Re: [Pharo-users] Iceberg and removing packages

by Esteban A. Maringolo

Hi, Yes, I commited. I noticed the package wasn't remove from disk because in Github the MyPackage-Tests.package folder was still there. And in the iceberg local directory it was there as well. I removed it manually with this commit: <https://github.com/eMaringolo/NeoJSONRPC/commit/7d2d7422812216615e684c838f9…> Regards! Esteban A. Maringolo 2017-07-31 9:30 GMT-03:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > Did you commit? > >> On 31 Jul 2017, at 14:06, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: >> >> That's exactly what I did. But after synchronizing the repo, the >> package wasn't listed on Iceberg but it still was in in the repo. >> It happened with another package in another repo as well. >> >> If it happens again I'll let you know.

July 31, 2017

Re: [Pharo-users] Iceberg and removing packages

by Esteban Lorenzano

Did you commit? > On 31 Jul 2017, at 14:06, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > > That's exactly what I did. But after synchronizing the repo, the > package wasn't listed on Iceberg but it still was in in the repo. > It happened with another package in another repo as well. > > If it happens again I'll let you know. > > Regards! > > Esteban A. Maringolo > > > 2017-07-31 7:03 GMT-03:00 Esteban Lorenzano <estebanlm(a)gmail.com>: >> Hi, >> >> In iceberg, you have to go to package tab and say "remove package from disk" >> >> Esteban >> >>> On 30 Jul 2017, at 17:01, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: >>> >>> I got into the pharo-local/iceberg/... and git rm'ed the directory, >>> commited and synchronized the project in Iceberg. >>> >>> I hope it doesn't break anything since I don't know how much "magic" >>> does Iceberg behind the scenes other than automating the git commands >>> and providing a centralized UI. >>> >>> What is the "This is all you need to read to understand Iceberg?" >>> document I should read? I read its wiki, but it seems there is more to >>> go. >>> >>> Regards! >>> >>> Esteban A. Maringolo >>> >>> >>> 2017-07-30 11:28 GMT-03:00 Peter Uhnak <i.uhnak(a)gmail.com>: >>>> This was supposedly fixed in April https://github.com/pharo-vcs/iceberg/issues/317 >>>> >>>> however I had the same issue ~two months ago, so I had to delete the packages by hand. >>>> >>>> P >>>> >>>> >>>>> On Sun, Jul 30, 2017 at 11:04:20AM -0300, Esteban A. Maringolo wrote: >>>>> Hi, >>>>> >>>>> I'm playing around with Iceberg in Pharo 6, and even when I find the >>>>> workflow streamlined, but since it doesn't map 1:1 with git workflow >>>>> from other IDEs or command line, I find myself not knowing how to do >>>>> certain tasks. >>>>> >>>>> One thing that happened is that I published a few packages to one of >>>>> my repos in Github, then I decided to remove one of the packages from >>>>> the repo, then I synchronized it but in the repo there is still is the >>>>> package folder for the package I removed. >>>>> >>>>> What should I do to definitely remove those files from the commit? >>>>> >>>>> Regards! >>>>> >>>>> Esteban A. Maringolo >>>>> >>>> >>> >> >

July 31, 2017