December 2017 - Pharo-dev - lists.pharo.org

Dotted selectors?

by Stephane Ducasse

Hi I would like to know if this is a well known iceberg bug because I have many removal of selector with the period at the end and I have no idea what to do? stef

Dec. 21, 2017

Re: [Pharo-dev] Credentials for Metacello

by Sean P. DeNigris

NorbertHartl wrote > - I cannot use filetree:// to load the project because the dependent > projects are loaded as zip via https and there seems to be no way to > specify credentials IIRC I made a patch for this at some point, but then lost interest because I was ultimately unwilling to have plain text credentials floating around in my image, so I moved everything to git with plain filetree:// URLs in my baselines. Of course, I ran into similar problems as you did once I tried to get all the CI working. Although, from your answer in the other thread, it seems that I can now get everything working on GitLab with SmalltalkCI (delta the VM instability issue). If you need HTTPS credentials, maybe Dale remembers something about the fix (I may have sent it to him) or I can look on my machine and see if I still have it. ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Dec. 21, 2017

Re: [Pharo-dev] Download Pharo for GNU/Linux - wrong info on that page

by Marcus Denker

Thanks, I updated the page (and the 64 bit page, too) > On 21 Dec 2017, at 14:30, Petr Fischer <petr.fischer(a)me.com> wrote: > > Hello, this page: > > https://pharo.org/gnu-linux-installation > > 1) in examples, there is a usage of "yum-config-manager" command, add a note that "yum-utils" package must be installed > > 2) correct all paths to the opensuse repos please, at least this is wrong: > > CentOS 7 (only 64bit): > http://download.opensuse.org/repositories/devel:/languages:/pharo:/stable/C… > > Correct URL is probably: > http://download.opensuse.org/repositories/devel:/languages:/pharo:/stable/C… > > pf >

Dec. 21, 2017

Download Pharo for GNU/Linux - wrong info on that page

by Petr Fischer

Hello, this page: https://pharo.org/gnu-linux-installation 1) in examples, there is a usage of "yum-config-manager" command, add a note that "yum-utils" package must be installed 2) correct all paths to the opensuse repos please, at least this is wrong: CentOS 7 (only 64bit): http://download.opensuse.org/repositories/devel:/languages:/pharo:/stable/C… Correct URL is probably: http://download.opensuse.org/repositories/devel:/languages:/pharo:/stable/C… pf

Dec. 21, 2017

Re: [Pharo-dev] Problem with ZipArchive (probably bug due to large file)

by Pavel Krivanek

Pharo does not support Zip64 file format so it cannot work with big files nor files with huge amount of files. -- Pavel 2017-12-21 12:54 GMT+01:00 Mariano Martinez Peck <marianopeck(a)gmail.com>: > Hi guys, > > I discovered a problem with ZipArchive when using Metacello to download a > zipball of a github project. The project in question is HighchartsSt (soon > we will make a new release and ANN) and this repo has *a lot* of > autogenerated code. By a lot, I mean that the ZIP file is about 90MB. > > I do understand the recommended approach with git is to clone (either > externally or with Iceberg), then work with your local clone via filetree > or tonel, and finally lock it. When you do this, ZipArchive is not used and > hence I have no problem. > > However, even if not the recommended path, I know there are people still > getting projects with Metacello from remote urls from github and hence the > zipball download is in play. > > The problem in question is an error reading the zip signature. We believe > it happens only with very big zips (smaller zips do work) and one way to > reproduce it is as simple as this: > > > outputFileName := '/tmp/test.zip'. > ZnClient new > url: 'https://github.com/ba-st/HighchartsSt/zipball/ > highchart6-import'; > downloadTo: outputFileName. > ZipArchive new > readFrom: outputFileName asFileReference > > > Some info I could get is that the zip itself looks good: > > Curl is able to download: > > â¯ curl -L https://github.com/ba-st/HighchartsSt/zipball/highchart6-import > > highcharts.zip > > â¯ ls -lah highcharts.zip > [23:18:06] > -rw-r--r-- 1 mariano staff 79M Dec 18 23:14 highcharts.zip > > and zip seems valid: > > â¯ unzip -q -t highcharts.zip > [23:18:33] > No errors detected in compressed data of highcharts.zip. > > > Anyway, if there is someone with some knowledge in ZipArchive that could > give us a hand.... > > Thank you very much in advance, > > > > -- > Mariano > http://marianopeck.wordpress.com >

Dec. 21, 2017

Problem with ZipArchive (probably bug due to large file)

by Mariano Martinez Peck

Hi guys, I discovered a problem with ZipArchive when using Metacello to download a zipball of a github project. The project in question is HighchartsSt (soon we will make a new release and ANN) and this repo has *a lot* of autogenerated code. By a lot, I mean that the ZIP file is about 90MB. I do understand the recommended approach with git is to clone (either externally or with Iceberg), then work with your local clone via filetree or tonel, and finally lock it. When you do this, ZipArchive is not used and hence I have no problem. However, even if not the recommended path, I know there are people still getting projects with Metacello from remote urls from github and hence the zipball download is in play. The problem in question is an error reading the zip signature. We believe it happens only with very big zips (smaller zips do work) and one way to reproduce it is as simple as this: outputFileName := '/tmp/test.zip'. ZnClient new url: ' https://github.com/ba-st/HighchartsSt/zipball/highchart6-import'; downloadTo: outputFileName. ZipArchive new readFrom: outputFileName asFileReference Some info I could get is that the zip itself looks good: Curl is able to download: â¯ curl -L https://github.com/ba-st/HighchartsSt/zipball/highchart6-import > highcharts.zip â¯ ls -lah highcharts.zip [23:18:06] -rw-r--r-- 1 mariano staff 79M Dec 18 23:14 highcharts.zip and zip seems valid: â¯ unzip -q -t highcharts.zip [23:18:33] No errors detected in compressed data of highcharts.zip. Anyway, if there is someone with some knowledge in ZipArchive that could give us a hand.... Thank you very much in advance, -- Mariano http://marianopeck.wordpress.com

Dec. 21, 2017

Re: [Pharo-dev] Credentials for Metacello

by Thierry Goubier

gitfiletree:// urls support https credentials, but the current 64 bits vm reliably segfaults. Regards, Thierry Le 21 dÃ©c. 2017 11:23 AM, "Norbert Hartl" <norbert(a)hartl.name> a Ã©crit : I have a very annoying problem with projects referenced in metacello that are private. When I try to use that on jenkins â¦ - I cannot use filetree:// to load the project because the dependent projects are loaded as zip via https and there seems to be no way to specify credentials - when using gitlocal:// with the 64bit vm it crashes reliably - when using gitlocal:// with the 32bit vm I have all sorts of no ssh keys found Is there a best practice for that. I even made on repo public so far in order to circumvent the problem. But Iâm not willing to make all our repos public just to be able to load it via metacello Any hints? Norbert

Dec. 21, 2017

Credentials for Metacello

by Norbert Hartl

I have a very annoying problem with projects referenced in metacello that are private. When I try to use that on jenkins â¦ - I cannot use filetree:// to load the project because the dependent projects are loaded as zip via https and there seems to be no way to specify credentials - when using gitlocal:// with the 64bit vm it crashes reliably - when using gitlocal:// with the 32bit vm I have all sorts of no ssh keys found Is there a best practice for that. I even made on repo public so far in order to circumvent the problem. But Iâm not willing to make all our repos public just to be able to load it via metacello Any hints? Norbert

Dec. 21, 2017

Re: [Pharo-dev] [ANN] Pharo Consortium New Bronze Member: Object Profile

by Marcus Denker

I added this to the Pharo news page (http://pharo.org/news <http://pharo.org/news>): [ANN] Pharo Consortium New Bronze Member: Object Profile http://pharo.org/news/consortium-object-profile <http://pharo.org/news/consortium-object-profile> > On 21 Dec 2017, at 08:41, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > The Pharo Consortium is very happy to announce that Object Profile > has joined the Consortium as a Bronze Member. > > About > - Object Profile: http://objectprofile.com > - Pharo Consortium: http://consortium.pharo.org > > The goal of the Pharo Consortium is to allow companies and institutions to > support the ongoing development and future of Pharo. > > Individuals can support Pharo via the Pharo Association: > > - http://association.pharo.org

Dec. 21, 2017

Re: [Pharo-dev] Linux vm packages

by Marcus Denker

Him Thanks to Cyril Ferlicot the 32 bit page now a description for Fedora Linux: https://pharo.org/gnu-linux-installation > On 12 Dec 2017, at 17:15, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > I have added the information to the 64bit download page for now (the other comes next). > > http://pharo.org/web/gnu-linux-installation-64 > > I wonder if we continue to announce a âdefault downloadâ (the zip) if it is much easier to use these? > >> On 27 Nov 2017, at 09:22, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> I can edit the website, I can put al needed infos there. >> >> (but sometimes I am not be able to generate actions out of discussions on the mailing list, >> there is just so much going onâ¦ so if something does not happen this just means I do >> not know that it should happenâ¦) >> >>> On 26 Nov 2017, at 13:52, Norbert Hartl <norbert(a)hartl.name> wrote: >>> >>> Can we change linux installation instructions on the web site? I can't believe they aren't there, yet. Here is the description. >>> >>> http://forum.world.st/Latest-Debian-Ubuntu-and-CentOS-packages-of-the-pharo… >>> >>> This describes what to do for some linux distributions not only ubuntu. In the mail there are opensuse URLs. The all contain the word "latest" which means the development version. If this is exchanged with "stable" you get the stable version. The rest stays the same. >>> >>> I really should have checked this. Because it is just stupid that people spend a lot of work into that and it is not used nor published. >>> >>> If I can help please say so!!!! >>> >>> Norbert >>> >> >

Dec. 21, 2017