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

Re: [Pharo-dev] Sources location inconsistency between WIndows and OSX

by Ben Coman

On Thu, Jun 29, 2017 at 1:10 AM, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > Hi, > > I just realised that on OSX it is enough to put .sources in the same > folder with Pharo.app which is extremely cool because there is no need to > carry them around with images. > IIUC this won't work with Pharo 7, since a new sources file will be delivered with each new build. cheers -ben > > However, in case of Window it is different. I tried to put .source in the > same folder with Pharo.exe but got a notification that sources in the > *image* folder were not found. > > It would be great to unify this behaviour among platforms :) > I prefer OSX .sources location strategy. > > Cheers, > Alex >

June 29, 2017

Re: [Pharo-dev] A better way to serialise methods?

by Eliot Miranda

Hi Alex, > On Jun 28, 2017, at 10:38 AM, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > > Hi, > > Smalltalk is famous for tiny methods with just a few parameters. However, sometimes libraries written in C have methods that accept many arguments. In my case I have a method that requires to pass exactly 15 arguments, luckily 15 is maximum possible amount of arguments in Pharo, so my day was saved. Until I tried to load the same code in Window. Here is my ffi call method: > > primMeasure: aTextRun start: aStart length: aMaxLength breakBefore: aLineBreakBefore width: aWidth provider: aProvider suppress: aSuppressBreak whitespace: aTrimWhitespace metrics: aMetrics boxType: aBoundingBoxType canvas: aCanvas hyphen: aUsedHyphenation lastBreak: aLastBreak wordWrap: aCanWordWrap breakPriority: aBreakPriorityPointer > > ^ self ffiCall: #(uint32 text_run_break_and_measure ( > TextRun aTextRun, > uint32 aStart, > uint32 aMaxLength, > bool aLineBreakBefore, > double aWidth, > TextPropertyProvider aProvider, > TextSuppressBreak aSuppressBreak, > ExternalAddress aTrimWhitespace, > NativeTextMetrics aMetrics, > TextBoundingBoxType aBoundingBoxType, > Canvas aCanvas, > ExternalAddress aUsedHyphenation, > ExternalAddress aLastBreak, > bool aCanWordWrap, > ExternalAddress aBreakPriorityPointer)) > > If I try to commit it using filetree/gitfiletree/Iceberg I get an .st method source file with the following name (138 characters): >> primMeasure.start.length.breakBefore.width.provider.suppress.whitespace.metrics.boxType.canvas.hyphen.lastBreak.wordWrap.breakPriority..st > > And of course trying to clone the repo using git fails on Window because filename is too long. > So here comes the question: Is it really necessary to name method source file according to the method's #sender? Would it make sense to trim the filename and append a short hash to avoid collisions? IMO file per class with methods ordered by selector makes even more sense. Provided methods are ordered by selector then incidental changes such as protocol or version stamp won't cause false differences to be shown. > > Cheers, > Alex

June 28, 2017

Re: [Pharo-dev] debug vm windows?

by Andrei Chis

On Mon, Jun 19, 2017 at 1:20 PM, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > Hi, > > the instructions are not merged yet and I am not sure whether something > has changed since I wrote it (April 8), but I wrote down instructions and > created scripts for building the VM on Windows (7+) > > https://github.com/pharo-project/pharo-vm/pull/128 > https://github.com/peteruhnak/pharo-vm/blob/windows-build/README-Win32.md > https://github.com/peteruhnak/pharo-vm/tree/windows-build/scripts/windows > By the way, thanks for publishing these scripts. I found them a while back and they were quite useful in figuring out how to configure cygwin. Cheers, Andrei in particular the Manual Compilation at the end; iirc `mvm -a` creates > asserting VM, `mvm -d` debug, `mvm -f` regular, and `mvm -A` all of them. > > Peter > > > On Tue, Jun 13, 2017 at 10:57:45PM +0200, phil(a)highoctane.be wrote: > > Not at the moment. > > > > On Tue, Jun 13, 2017 at 10:08 PM, Andrei Chis < > chisvasileandrei(a)gmail.com> > > wrote: > > > > > Thanks! Any chance you can redo the build to get also a debug vm for > > > the latest version? > > > > > > Cheers, > > > Andrei > > > > > > On Tue, Jun 13, 2017 at 8:02 PM, phil(a)highoctane.be < > phil(a)highoctane.be> > > > wrote: > > > > I have an older build here. > > > > > > > > https://ci.appveyor.com/project/philippeback/pharo-vm > > > > > > > > https://bintray.com/pharophile/pharo-vm/build/ > > > view/files?sort=name&order=asc#files/ > > > > > > > > There is an normal, assert and debug vm in there. > > > > > > > > Phil > > > > > > > > On Tue, Jun 13, 2017 at 7:14 PM, Andrei Chis < > chisvasileandrei(a)gmail.com > > > > > > > > wrote: > > > >> > > > >> Hi, > > > >> > > > >> Is there a Pharo debug vm for windows already build and available > > > >> somewhere? > > > >> > > > >> Cheers, > > > >> Andrei > > > >> > > > > > > > > > > > >

June 28, 2017

Re: [Pharo-dev] Sources location inconsistency between WIndows and OSX

by Aliaksei Syrel

Aha! I found the problem... very strange. So, there is a difference: If I run Pharo.exe from Coherence mode in Parallels then VM directory is given relative to \Mac and sources can not be found: [image: Inline images 1] If I run Pharo.exe from "Virtual machine" mode in Parallels then VM directory is correct and source work from VM folder: [image: Inline images 2] I think it is an interesting discovery :) Cheers, Alex On 28 June 2017 at 20:20, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > Hi Henrik, > > Here is what `OSPlatform current potentialLocationsOfSourcesFile` gives > me: > > [image: Inline images 2] > > Are you sure you have the correct version of .sources? > > Yes, I use v60 sources with 60503 Pharo and stable VM. If I put sources > in the image folder it works... Very strange. > > Cheers, > Alex > > > On 28 June 2017 at 19:59, Henrik Nergaard <draagren(a)outlook.com> wrote: > > > > Are you sure you have the correct version of .sources?. > > > > It has allways been possible to have the .sources at the .exe (I have > allways done it that way), (are you sure that the right vm is started, > clicking on an image might launch a different vm if you have multiple). > > > > > > What is the output of `OSPlatform current potentialLocationsOfSourcesFile` > ? > > > > > > To debug: > > > > Change PharoFilesOpener>>#ignoreIfFail: no not send ifError: []. and > the do `SourceFiles ensureOpen` > > > > > > Best regards, > > > > Henrik > > > > > > > > ________________________________ > > Fra: Pharo-dev <pharo-dev-bounces(a)lists.pharo.org> pÃ¥ vegne av Aliaksei > Syrel <alex.syrel(a)gmail.com> > > Sendt: 28. juni 2017 19:10:19 > > Til: Pharo Development List > > Emne: [Pharo-dev] Sources location inconsistency between WIndows and OSX > > > > Hi, > > > > I just realised that on OSX it is enough to put .sources in the same > folder with Pharo.app which is extremely cool because there is no need to > carry them around with images. > > > > However, in case of Window it is different. I tried to put .source in > the same folder with Pharo.exe but got a notification that sources in the > *image* folder were not found. > > > > It would be great to unify this behaviour among platforms :) > > I prefer OSX .sources location strategy. > > > > Cheers, > > Alex >

June 28, 2017

Re: [Pharo-dev] Sources location inconsistency between WIndows and OSX

by Aliaksei Syrel

Hi Henrik, Here is what `OSPlatform current potentialLocationsOfSourcesFile` gives me: [image: Inline images 2] Are you sure you have the correct version of .sources? Yes, I use v60 sources with 60503 Pharo and stable VM. If I put sources in the image folder it works... Very strange. Cheers, Alex On 28 June 2017 at 19:59, Henrik Nergaard <draagren(a)outlook.com> wrote: > > Are you sure you have the correct version of .sources?. > > It has allways been possible to have the .sources at the .exe (I have allways done it that way), (are you sure that the right vm is started, clicking on an image might launch a different vm if you have multiple). > > > What is the output of `OSPlatform current potentialLocationsOfSourcesFile` ? > > > To debug: > > Change PharoFilesOpener>>#ignoreIfFail: no not send ifError: []. and the do `SourceFiles ensureOpen` > > > Best regards, > > Henrik > > > > ________________________________ > Fra: Pharo-dev <pharo-dev-bounces(a)lists.pharo.org> pÃ¥ vegne av Aliaksei Syrel <alex.syrel(a)gmail.com> > Sendt: 28. juni 2017 19:10:19 > Til: Pharo Development List > Emne: [Pharo-dev] Sources location inconsistency between WIndows and OSX > > Hi, > > I just realised that on OSX it is enough to put .sources in the same folder with Pharo.app which is extremely cool because there is no need to carry them around with images. > > However, in case of Window it is different. I tried to put .source in the same folder with Pharo.exe but got a notification that sources in the *image* folder were not found. > > It would be great to unify this behaviour among platforms :) > I prefer OSX .sources location strategy. > > Cheers, > Alex

June 28, 2017

Re: [Pharo-dev] Sources location inconsistency between WIndows and OSX

by Henrik Nergaard

Are you sure you have the correct version of .sources?. It has allways been possible to have the .sources at the .exe (I have allways done it that way), (are you sure that the right vm is started, clicking on an image might launch a different vm if you have multiple). What is the output of `OSPlatform current potentialLocationsOfSourcesFile` ? To debug: Change PharoFilesOpener>>#ignoreIfFail: no not send ifError: []. and the do `SourceFiles ensureOpen` Best regards, Henrik ________________________________ Fra: Pharo-dev <pharo-dev-bounces(a)lists.pharo.org> pÃ¥ vegne av Aliaksei Syrel <alex.syrel(a)gmail.com> Sendt: 28. juni 2017 19:10:19 Til: Pharo Development List Emne: [Pharo-dev] Sources location inconsistency between WIndows and OSX Hi, I just realised that on OSX it is enough to put .sources in the same folder with Pharo.app which is extremely cool because there is no need to carry them around with images. However, in case of Window it is different. I tried to put .source in the same folder with Pharo.exe but got a notification that sources in the *image* folder were not found. It would be great to unify this behaviour among platforms :) I prefer OSX .sources location strategy. Cheers, Alex

June 28, 2017

A better way to serialise methods?

by Aliaksei Syrel

Hi, Smalltalk is famous for tiny methods with just a few parameters. However, sometimes libraries written in C have methods that accept many arguments. In my case I have a method that requires to pass exactly 15 arguments, luckily 15 is maximum possible amount of arguments in Pharo, so my day was saved. Until I tried to load the same code in Window. Here is my ffi call method: primMeasure: aTextRun start: aStart length: aMaxLength breakBefore: aLineBreakBefore width: aWidth provider: aProvider suppress: aSuppressBreak whitespace: aTrimWhitespace metrics: aMetrics boxType: aBoundingBoxType canvas: aCanvas hyphen: aUsedHyphenation lastBreak: aLastBreak wordWrap: aCanWordWrap breakPriority: aBreakPriorityPointer ^ self ffiCall: #(uint32 text_run_break_and_measure ( TextRun aTextRun, uint32 aStart, uint32 aMaxLength, bool aLineBreakBefore, double aWidth, TextPropertyProvider aProvider, TextSuppressBreak aSuppressBreak, ExternalAddress aTrimWhitespace, NativeTextMetrics aMetrics, TextBoundingBoxType aBoundingBoxType, Canvas aCanvas, ExternalAddress aUsedHyphenation, ExternalAddress aLastBreak, bool aCanWordWrap, ExternalAddress aBreakPriorityPointer)) If I try to commit it using filetree/gitfiletree/Iceberg I get an .st method source file with the following name (138 characters): > > primMeasure.start.length.breakBefore.width.provider.suppress.whitespace.metrics.boxType.canvas.hyphen.lastBreak.wordWrap.breakPriority..st And of course trying to clone the repo using git fails on Window because filename is too long. So here comes the question: *Is it really necessary to name method source file according to the method's #sender? Would it make sense to trim the filename and append a short hash to avoid collisions?* Cheers, Alex

June 28, 2017

Sources location inconsistency between WIndows and OSX

by Aliaksei Syrel

Hi, I just realised that on OSX it is enough to put .sources in the same folder with Pharo.app which is extremely cool because there is no need to carry them around with images. However, in case of Window it is different. I tried to put .source in the same folder with Pharo.exe but got a notification that sources in the *image* folder were not found. It would be great to unify this behaviour among platforms :) I prefer OSX .sources location strategy. Cheers, Alex

June 28, 2017

Re: [Pharo-dev] Working OSProcess configuration for Pharo 6 release (please)

by Aliaksei Syrel

But now OSX latest VM (http://files.pharo.org/vm/pha ro-spur32/mac/pharo-mac-i386-201706280928-1bd79a7.zip) crashes when trying to load a project using Iceberg without crash.dmp. I only get the following in terminal: Pharo(4280,0xa6f3b1c0) malloc: *** error for object 0x8416a314: incorrect checksum for freed object - object was probably modified after being freed. *** set a breakpoint in malloc_error_break to debug I tested with both 60501 and 60503 images to prove that it is a VM problem, because it works well with 60501 and Stable :) Maybe it is somehow related to the new version of libgit in the latest vm... Cheers, Alex On 28 June 2017 at 18:26, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > Hi Eliot, > > I confirm that OSX performance issue is fixed in latest VM ( > http://files.pharo.org/vm/pharo-spur32/mac/pharo-mac-i386-2 > 01706280928-1bd79a7.zip). > Thanks a lot! > > Cheers, > Alex > > On 22 June 2017 at 08:39, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > >> >> >> On Thu, Jun 22, 2017 at 8:03 AM, Stephane Ducasse < >> stepharo.self(a)gmail.com> wrote: >> >>> Clement why you cannot load OSSubprocess? >>> >>> >> 1) project has to work on itimer Linux VM. >> 2) existing project working with OSProcess and I don't want to spend time >> migrating. >> 3) code base has to work at least in Squeak and Pharo, I don't want to >> add extra code so it uses different frameworks in different platforms and >> then maintain this extra code. >> >> >>> >>> >>> On Tue, Jun 20, 2017 at 3:10 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> >>> wrote: >>> > Hi Thierry, hi all, >>> > >>> > The Pharo catalog version of OSProcess is not working in the Pharo 6 >>> release >>> > and I need to load OSProcess in one of my projects. I cannot load >>> > OSSubProcess instead, so no need to answer this mail talking about it. >>> > >>> > In-between version 2231 and 2241 of VMMaker, the vm parameter 1002 (os >>> > version), has changed on Mac from '1011.6' to '10.11.6'. OSProcess >>> tests the >>> > version number against 1000, and should now test against 10. >>> > >>> > I checked the SqueakSource repo of OSProcess, I can see that the last >>> > version is 4.6.8 and the catalog configuration loads an older version, >>> but I >>> > cannot see any fix related to the version number ? >>> > >>> > Can someone update the OSProcess configuration in the Pharo catalog so >>> that >>> > it loads a working version in the Pharo 6 release or point me to an >>> > OSProcess configuration, outside of the catalog, which works in the >>> release >>> > of Pharo 6 please ? >>> > >>> > Thank you very much. >>> > >>> > Clement >>> >>> >> >

June 28, 2017

Re: [Pharo-dev] Working OSProcess configuration for Pharo 6 release (please)

by Aliaksei Syrel

Hi Eliot, I confirm that OSX performance issue is fixed in latest VM ( http://files.pharo.org/vm/pharo-spur32/mac/pharo-mac-i386-201706280928-1bd7… ). Thanks a lot! Cheers, Alex On 22 June 2017 at 08:39, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > > On Thu, Jun 22, 2017 at 8:03 AM, Stephane Ducasse <stepharo.self(a)gmail.com > > wrote: > >> Clement why you cannot load OSSubprocess? >> >> > 1) project has to work on itimer Linux VM. > 2) existing project working with OSProcess and I don't want to spend time > migrating. > 3) code base has to work at least in Squeak and Pharo, I don't want to add > extra code so it uses different frameworks in different platforms and then > maintain this extra code. > > >> >> >> On Tue, Jun 20, 2017 at 3:10 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> >> wrote: >> > Hi Thierry, hi all, >> > >> > The Pharo catalog version of OSProcess is not working in the Pharo 6 >> release >> > and I need to load OSProcess in one of my projects. I cannot load >> > OSSubProcess instead, so no need to answer this mail talking about it. >> > >> > In-between version 2231 and 2241 of VMMaker, the vm parameter 1002 (os >> > version), has changed on Mac from '1011.6' to '10.11.6'. OSProcess >> tests the >> > version number against 1000, and should now test against 10. >> > >> > I checked the SqueakSource repo of OSProcess, I can see that the last >> > version is 4.6.8 and the catalog configuration loads an older version, >> but I >> > cannot see any fix related to the version number ? >> > >> > Can someone update the OSProcess configuration in the Pharo catalog so >> that >> > it loads a working version in the Pharo 6 release or point me to an >> > OSProcess configuration, outside of the catalog, which works in the >> release >> > of Pharo 6 please ? >> > >> > Thank you very much. >> > >> > Clement >> >> >

June 28, 2017