November 2017 - Pharo-users

Re: [Pharo-users] files.pharo.org downloads => needs testers

by stephan

On 29-11-17 04:29, Ben Coman wrote: > Performance from Western Australia... From the Netherlands curl -o 1.zip http://files2.pharo.org/image/70/Pharo-7.0.0-alpha.build.328.sha.c366633.ar… --next -o 2.zip http://file-pharo.inria.fr/image/70/Pharo-7.0.0-alpha.build.328.sha.c366633… --next -o 3.zip http://files.pharo.org/image/70/Pharo-7.0.0-alpha.build.328.sha.c366633.arc… % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 17.7M 100 17.7M 0 0 4418k 0 0:00:04 0:00:04 --:--:-- 4419k 100 17.7M 100 17.7M 0 0 4150k 0 0:00:04 0:00:04 --:--:-- 4859k 100 17.7M 100 17.7M 0 0 4619k 0 0:00:03 0:00:03 --:--:-- 4786k Stephan

Nov. 29, 2017

Re: [Pharo-users] files.pharo.org downloads => needs testers

by Christophe Demarey

Thanks Ben and John for the first feedbacks. I also run a test on Travis CI: https://travis-ci.org/demarey/test-files-pharo-org/builds/308846128?utm_sou… <https://travis-ci.org/demarey/test-files-pharo-org/builds/308846128?utm_sou…> Average speed difference is amazing â¦ I really wonder what could be the problem. On Travis, old files.phaor.org looks to be more than 10 times faster than the server hosted at Inria ...

Nov. 29, 2017

Re: [Pharo-users] Strange behaviour when commit+push with Iceberg

by Alistair Grant

Hi Julien, On 28 November 2017 at 21:34, Julien <julien.delplanque(a)inria.fr> wrote: > Hello, > > Sometimes, when I do Â« commit and push Â» with Iceberg, I got this strange > behaviour (see1st screenshot). > > I **must** interrupt the process to stop this madness. Then, I get even > weirder things related to morphic (see the other screenshot). > > Then my image come back to a normal state and the commit + push have been > performed. Similar screen corruption has been reported when there are two or more Morphic UI Processes. If you open a process browser (world menu -> Tools -> Process Browser), look for "Morphic UI Process". Terminate all the processes that aren't "Morphic UI Process: nil". Cheers, Alistair

Nov. 29, 2017

Re: [Pharo-users] files.pharo.org downloads => needs testers

by Marcus Denker

> On 28 Nov 2017, at 20:06, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > What is the relationship between this and http://mirror.pharo.org? <http://mirror.pharo.org/?> no relationshipâ¦ that was another idea (to put a CDN in front). Better to replace the server itself. > > Considering you are already working around these servers, would it be possible to add HTTPS? > One of the solutions has SSL enabled, which kind of makes this the more likely solution to be used. For testing, this runs with SSL with the http://files2.pharo.org <http://files2.pharo.org/> server: https://books.pharo.org > > On Tue, Nov 28, 2017 at 5:43 PM, Christophe Demarey <christophe.demarey(a)inria.fr <mailto:christophe.demarey@inria.fr>> wrote: > Hi all, > > We set up 2 new servers to replace (at least for some time) the problematic files.pharo.org <http://files.pharo.org/> server (slow downloads, bad CRC). > Please, could you test these new servers and give us feedback to see if downloads are fast and nom ore CRC errors? > * http://file-pharo.inria.fr/ <http://file-pharo.inria.fr/> > * http://files2.pharo.org <http://files2.pharo.org/> (hosted on the cloud) > > Data might be a bit outdated (sync last friday) but is just for testing now. > > According to your feedbacks, we will switch official URLs to one of these servers. > The situation should be back to normal soon. > > Christophe >

Nov. 29, 2017

Re: [Pharo-users] I love the launcher!!!!

by Christophe Demarey

> Le 28 nov. 2017 Ã 22:00, Stephane Ducasse <stepharo.self(a)gmail.com> a Ã©crit : > > Christophe > > I think that we should remove the blessed folder. After we moved the file-server, I will do a big cleanup of pharo launcher files. I think I will only publish OS-packages (win,linux, OS X) and create a pharo-luacher folder at the root of the file-server. It will be more clear.

Nov. 29, 2017

Re: [Pharo-users] Unable to update Glamour-Core

by Tudor Girba

Hi, I am not sure I understand your report. The Glamour-Core package is part of ConfigurationOfGlamourCore, and should not be updated separately. What script are you using for loading ConfigurationOfGlamourCore? Cheers, Doru > On Nov 29, 2017, at 3:53 AM, Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com> wrote: > > Hi, > > My image become unresponsive while making some debug, so I decided to > start fresh and reinstall Grafoscopio, but I have some problems, with > XML parser (so I disabled Soup temporarily) and with Glamour-Core, which > provides and important part of the Grafoscopio experience. I tried also > to install it from Monticello, without better results (to the version > Glamour-Core-TudorGirba339). In both cases I get "SubscriptOutOfBounds: > 17808" and this is the trace I get with the "Report" button (sorry I > don't know other way to report): > > https://pastebin.com/wWM24w01 > > I will try with Pharo 7... The procedure is the same that was working > just last week. I know the pains and advantages of having a dynamic > system that is evolving quickly... hopefully a more stable platform will > be there while the upcoming one is evolving. > > Cheers, > > Offray > > > -- www.tudorgirba.com www.feenk.com "Every now and then stop and ask yourself if the war you're fighting is the right one."

Nov. 29, 2017

Re: [Pharo-users] files.pharo.org downloads => needs testers

by john pfersich

Stats from Las Vegas, Nevada, USA on Mac OS curl -o 1.zip http://files2.pharo.org/image/70/Pharo-7.0.0-alpha.build.328.sha.c366633.ar… \ > --next -o 2.zip http://file-pharo.inria.fr/image/70/Pharo-7.0.0-alpha.build.328.sha.c366633… \ > --next -o 3.zip http://files.pharo.org/image/70/Pharo-7.0.0-alpha.build.328.sha.c366633.arc… % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 17.7M 100 17.7M 0 0 3306k 0 0:00:05 0:00:05 --:--:-- 4465k % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 17.7M 100 17.7M 0 0 1411k 0 0:00:12 0:00:12 --:--:-- 2688k % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 17.7M 100 17.7M 0 0 1429k 0 0:00:12 0:00:12 --:--:-- 2510k On Tue, Nov 28, 2017 at 9:38 PM, john pfersich <jpfersich(a)gmail.com> wrote: > Stats from Las Vegas, Nevada, USA > > curl -o 1.zip http://files2.pharo.org/image/70/Pharo-7.0.0-alpha.build. > 328.sha.c366633.arch.32bit.zip --next -o 2.zip http://file-pharo.inria.fr/ > image/70/Pharo-7.0.0-alpha.build.328.sha.c366633.arch.32bit.zip --next -o > 3.zip http://files.pharo.org/image/70/Pharo-7.0.0-alpha.build. > 328.sha.c366633.arch.32bit.zip > % Total % Received % Xferd Average Speed Time Time Time > Current > Dload Upload Total Spent Left > Speed > 100 17.7M 100 17.7M 0 0 270k 0 0:01:07 0:01:07 --:--:-- > 462k > 100 17.7M 100 17.7M 0 0 282k 0 0:01:04 0:01:04 --:--:-- > 312k > 100 17.7M 100 17.7M 0 0 294k 0 0:01:01 0:01:01 --:--:-- > 336k > > > On Tue, Nov 28, 2017 at 7:31 PM, Ben Coman <btc(a)openinworld.com> wrote: > >> and the XLS file in case anyone wants to provide other observations in a >> similar format... >> >> >> On 29 November 2017 at 11:29, Ben Coman <btc(a)openinworld.com> wrote: >> >>> >>> >>> On 29 November 2017 at 00:43, Christophe Demarey < >>> christophe.demarey(a)inria.fr> wrote: >>> > Hi all, >>> > >>> > We set up 2 new servers to replace (at least for some time) the >>> problematic >>> > files.pharo.org server (slow downloads, bad CRC). >>> > Please, could you test these new servers and give us feedback to see if >>> > downloads are fast and nom ore CRC errors? >>> > * http://file-pharo.inria.fr/ >>> > * http://files2.pharo.org (hosted on the cloud) >>> > >>> > Data might be a bit outdated (sync last friday) but is just for >>> testing now. >>> > >>> > According to your feedbacks, we will switch official URLs to one of >>> these >>> > servers. >>> >>> Performance from Western Australia... >>> >>> $ curl -o 1.zip http://files2.pharo.org/image/ >>> 70/Pharo-7.0.0-alpha.build.328.sha.c366633.arch.32bit.zip \ >>> --next -o 2.zip http://file-pharo.inria.fr/ima >>> ge/70/Pharo-7.0.0-alpha.build.328.sha.c366633.arch.32bit.zip \ >>> --next -o 3.zip http://files.pharo.org/image/7 >>> 0/Pharo-7.0.0-alpha.build.328.sha.c366633.arch.32bit.zip >>> >>> % Total % Received % Xferd Average Speed Time Time Time >>> Current >>> Dload Upload Total Spent Left >>> Speed >>> 100 17.7M 100 17.7M 0 0 228k 0 0:01:19 0:01:19 --:--:-- >>> 271k >>> 100 17.7M 100 17.7M 0 0 124k 0 0:02:25 0:02:25 --:--:-- >>> 134k >>> 100 17.7M 100 17.7M 0 0 142k 0 0:02:07 0:02:07 --:--:-- >>> 190k >>> >>> >>> Attached chart built from and screen grabs of `uget-gtk` on Ubuntu >>> 16.04/64bit >>> 1.zip... files2.pharo.org/image/70/Pharo-7.0.0-alpha.build.327.sha.33 >>> fc2a4.arch.32bit.zip >>> 2.zip... fiile-pharo.inria.fr/image/70/Pharo-7.0.0-alpha.build.344.sh >>> a.233512f.arch.32bit.zip >>> 3.zip... files.pharo.org/image/70/Pharo-7.0.0-alpha.build.344.sha.233 >>> 512f.arch.32bit.zip >>> >>> And btw, I'd call this a good day for files.pharo.org. >>> >>> cheers -ben >>> >> >> >

Nov. 29, 2017

Re: [Pharo-users] files.pharo.org downloads => needs testers

by john pfersich

Stats from Las Vegas, Nevada, USA curl -o 1.zip http://files2.pharo.org/image/70/Pharo-7.0.0-alpha.build.328.sha.c366633.ar… --next -o 2.zip http://file-pharo.inria.fr/image/70/Pharo-7.0.0-alpha.build.328.sha.c366633… --next -o 3.zip http://files.pharo.org/image/70/Pharo-7.0.0-alpha.build.328.sha.c366633.arc… % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 17.7M 100 17.7M 0 0 270k 0 0:01:07 0:01:07 --:--:-- 462k 100 17.7M 100 17.7M 0 0 282k 0 0:01:04 0:01:04 --:--:-- 312k 100 17.7M 100 17.7M 0 0 294k 0 0:01:01 0:01:01 --:--:-- 336k On Tue, Nov 28, 2017 at 7:31 PM, Ben Coman <btc(a)openinworld.com> wrote: > and the XLS file in case anyone wants to provide other observations in a > similar format... > > > On 29 November 2017 at 11:29, Ben Coman <btc(a)openinworld.com> wrote: > >> >> >> On 29 November 2017 at 00:43, Christophe Demarey < >> christophe.demarey(a)inria.fr> wrote: >> > Hi all, >> > >> > We set up 2 new servers to replace (at least for some time) the >> problematic >> > files.pharo.org server (slow downloads, bad CRC). >> > Please, could you test these new servers and give us feedback to see if >> > downloads are fast and nom ore CRC errors? >> > * http://file-pharo.inria.fr/ >> > * http://files2.pharo.org (hosted on the cloud) >> > >> > Data might be a bit outdated (sync last friday) but is just for testing >> now. >> > >> > According to your feedbacks, we will switch official URLs to one of >> these >> > servers. >> >> Performance from Western Australia... >> >> $ curl -o 1.zip http://files2.pharo.org/image/ >> 70/Pharo-7.0.0-alpha.build.328.sha.c366633.arch.32bit.zip \ >> --next -o 2.zip http://file-pharo.inria.fr/ima >> ge/70/Pharo-7.0.0-alpha.build.328.sha.c366633.arch.32bit.zip \ >> --next -o 3.zip http://files.pharo.org/image/7 >> 0/Pharo-7.0.0-alpha.build.328.sha.c366633.arch.32bit.zip >> >> % Total % Received % Xferd Average Speed Time Time Time >> Current >> Dload Upload Total Spent Left >> Speed >> 100 17.7M 100 17.7M 0 0 228k 0 0:01:19 0:01:19 --:--:-- >> 271k >> 100 17.7M 100 17.7M 0 0 124k 0 0:02:25 0:02:25 --:--:-- >> 134k >> 100 17.7M 100 17.7M 0 0 142k 0 0:02:07 0:02:07 --:--:-- >> 190k >> >> >> Attached chart built from and screen grabs of `uget-gtk` on Ubuntu >> 16.04/64bit >> 1.zip... files2.pharo.org/image/70/Pharo-7.0.0-alpha.build.327.sha. >> 33fc2a4.arch.32bit.zip >> 2.zip... fiile-pharo.inria.fr/image/70/Pharo-7.0.0-alpha.build.344.sh >> a.233512f.arch.32bit.zip >> 3.zip... files.pharo.org/image/70/Pharo-7.0.0-alpha.build.344.sha. >> 233512f.arch.32bit.zip >> >> And btw, I'd call this a good day for files.pharo.org. >> >> cheers -ben >> > >

Nov. 29, 2017

Re: [Pharo-users] UFFI C basic types passed-by-reference for output

by Ben Coman

On 15 November 2017 at 20:47, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > which could be implemented... > FFIExternalType class >> newBuffer. > ^ByteArray new: (self externalTypeSize) > > testGetPageSizeByIndex > | document page_index widthBuffer heightBuffer width height result| > PDFium FPDF_InitLibrary. > document := PDFium FPDF_LoadDocument__file_path: helloPdf > password: ''. > widthBuffer := FFIFloat64 buffer. > heightBuffer := FFIFloat64 buffer. > page_index := 0. "Its zero based" > result := PDFium FPDF_GetPageSizeByIndex__document: document > page_index: 0 > width: widthBuffer > height: heightBuffer. > width := widthBuffer doubleAt: 1. > height := heightBuffer doubleAt: 1. I'm about to do something similar with for this prototype... void clang_getFileLocation( CXSourceLocation location, CXFile *file, unsigned *line, unsigned *column, unsigned *offset); Now 'uints' are good to work with since they are consistently 4 bytes on all modern platforms (Windows / Linux / Unix) x (32bit / 64bit) http://nickdesaulniers.github.io/blog/2016/05/30/data-models-and-word-size/ So I using this FFI definition... Libclang >> clang_getFileLocation__location: location file: file line: line column: column offset: offset self ffiCall: #(void clang_getFileLocation( CXSourceLocation location, CXFile *file, uint *line, uint *column, uint *offset)) with this application code... lineBuffer := FFIUInt32 newBuffer. columnBuffer := FFIUInt32 newBuffer. offsetBuffer := FFIUInt32 newBuffer. Libclang clang_getFileLocation__location: cxLocation file: cxFile line: lineBuffer column: columnBuffer offset: offsetBuffer. but to unwrap the buffer the following is not available... line := lineBuffer uint32At: 1. Other candidates are senders of #integerAt:size:signed: from which the only one dealing in 4 bytes is... ByteArray >> unsignedLongAt: byteOffset ^self integerAt: byteOffset size: 4 signed: false which (apart from 'ulong' being semantically different from the original 'uint' C definition) seems a poor cross-platform choice, since 'long' is the only integer type whose size that varies between 32-bit & 64-bit. * https://software.intel.com/en-us/articles/size-of-long-integer-type-on-diff… There is ByteArray >> platformUnsignedLongAt: but again the original C declaration was an uint, so it still feels wrong to use 'long' converter. The remaining option is directly using the lower level api, but its a bit ugly... lineBuffer := FFIUInt32 newBuffer. columnBuffer := FFIUInt32 newBuffer. offsetBuffer := FFIUInt32 newBuffer. Libclang clang_getFileLocation__location: cxLocation file: cxFile line: lineBuffer column: columnBuffer offset: offsetBuffer. line := lineBuffer integerAt: 1 size: 4 signed: false. column := columnBuffer integerAt: 1 size: 4 signed: false. offset := offsetBuffer integerAt: 1 size: 4 signed: false. ^{ line . column. offset } So are additional type converters required for ByteArray? Or alternatively, could FFIExternalType get an extra ByteArray instance variable that is usually nil, but is available when we want to deal concretely with an external type while keeping the type info associated, rather needing a raw ByteArray. For example... Object subclass: #FFIExternalType instanceVariableNames: 'pointerArity loader buffer' classVariableNames: '' package: 'UnifiedFFI-Types' FFIExternalType >> buffer ^ buffer ifNil: [ buffer := ByteArray new: (self externalTypeSize) ]. buffer pin. FFIExternalType >> dereference ^ self basicHandle: self buffer at: 1 then presumably I could do "something" like... line := FFIUInt32 new. column := FFIUInt32 new. offset := FFIUInt32 new. Libclang clang_getFileLocation__location: cxLocation file: cxFile line: line buffer column: column buffer offset: offset buffer. ^ { line value . column value . offset value} or maybe #bufferPointer would be better than #buffer I'm experimenting along this line, but I'm currently breaking my Image so I pause to seek feedback on the idea. cheers -ben

Nov. 29, 2017

Re: [Pharo-users] files.pharo.org downloads => needs testers

by Ben Coman

and the XLS file in case anyone wants to provide other observations in a similar format... On 29 November 2017 at 11:29, Ben Coman <btc(a)openinworld.com> wrote: > > > On 29 November 2017 at 00:43, Christophe Demarey < > christophe.demarey(a)inria.fr> wrote: > > Hi all, > > > > We set up 2 new servers to replace (at least for some time) the > problematic > > files.pharo.org server (slow downloads, bad CRC). > > Please, could you test these new servers and give us feedback to see if > > downloads are fast and nom ore CRC errors? > > * http://file-pharo.inria.fr/ > > * http://files2.pharo.org (hosted on the cloud) > > > > Data might be a bit outdated (sync last friday) but is just for testing > now. > > > > According to your feedbacks, we will switch official URLs to one of these > > servers. > > Performance from Western Australia... > > $ curl -o 1.zip http://files2.pharo.org/image/70/Pharo-7.0.0-alpha.build. > 328.sha.c366633.arch.32bit.zip \ > --next -o 2.zip http://file-pharo.inria.fr/image/70/Pharo-7.0.0-alpha. > build.328.sha.c366633.arch.32bit.zip \ > --next -o 3.zip http://files.pharo.org/image/70/Pharo-7.0.0-alpha.build. > 328.sha.c366633.arch.32bit.zip > > % Total % Received % Xferd Average Speed Time Time Time > Current > Dload Upload Total Spent Left > Speed > 100 17.7M 100 17.7M 0 0 228k 0 0:01:19 0:01:19 --:--:-- > 271k > 100 17.7M 100 17.7M 0 0 124k 0 0:02:25 0:02:25 --:--:-- > 134k > 100 17.7M 100 17.7M 0 0 142k 0 0:02:07 0:02:07 --:--:-- > 190k > > > Attached chart built from and screen grabs of `uget-gtk` on Ubuntu > 16.04/64bit > 1.zip... files2.pharo.org/image/70/Pharo-7.0.0-alpha.build.327. > sha.33fc2a4.arch.32bit.zip > 2.zip... fiile-pharo.inria.fr/image/70/Pharo-7.0.0-alpha.build.344. > sha.233512f.arch.32bit.zip > 3.zip... files.pharo.org/image/70/Pharo-7.0.0-alpha.build.344. > sha.233512f.arch.32bit.zip > > And btw, I'd call this a good day for files.pharo.org. > > cheers -ben >

Nov. 29, 2017