February 2018 - Pharo-dev - lists.pharo.org

[Pharo 7.0-dev] Build #610: 21409 NECTestClass should use utilities categories

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

There is a new Pharo build available! The status of the build #610 was: SUCCESS. The Pull Request #958 was integrated: "21409 NECTestClass should use utilities categories" Pull request url: https://github.com/pharo-project/pharo/pull/958 Issue Url: https://pharo.fogbugz.com/f/cases/21409 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Feb. 26, 2018

[Pharo 7.0-dev] Build #609: 21416 Cleanup AssocationTest

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

There is a new Pharo build available! The status of the build #609 was: SUCCESS. The Pull Request #965 was integrated: "21416 Cleanup AssocationTest" Pull request url: https://github.com/pharo-project/pharo/pull/965 Issue Url: https://pharo.fogbugz.com/f/cases/21416 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Feb. 26, 2018

Re: [Pharo-dev] [Vm-dev] OSSubprocess 0.2.5 fails in Pharo 6.1 64 bits (macOS)

by Mariano Martinez Peck

Hi guys, Thanks Guille for the spin and the rest for asking. I just answered everything into the related github issues. On Mon, Feb 26, 2018 at 6:32 AM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > > Could you check this version? > > https://github.com/marianopeck/OSSubprocess/pull/30 > > On Mon, Feb 26, 2018 at 10:19 AM, Guillermo Polito < > guillermopolito(a)gmail.com> wrote: > >> I'll try making a PR now to fix that. >> >> On Mon, Feb 26, 2018 at 10:19 AM, Guillermo Polito < >> guillermopolito(a)gmail.com> wrote: >> >>> Hmm, wait, I think these are two different issues :) >>> >>> I managed to successfully use OSSubprocess in 64bits with some tweaks. >>> The problem is that OSSubprocess does some manual type coertions like >>> assumming 32 bits: >>> >>> collectArgumentPointersInto: aPointer >>> [...] >>> aPointer nbUInt32AtOffset: (self argVArguments size - 1) * self >>> systemAccessor sizeOfPointer put: 0 >>> >>> That should probably be replaced by: >>> >>> aPointer platformUnsignedLongAt: (self argVArguments size - 1) * >>> self systemAccessor sizeOfPointer put: 0. >>> >>> >>> Now, those methods depend on UFFI, having UFFI is a must for >>> OSSubprocess. >>> >>> On Thu, Feb 22, 2018 at 7:07 PM, Alistair Grant <akgrant0710(a)gmail.com> >>> wrote: >>> >>>> >>>> Hi Eliot, >>>> >>>> On 21 February 2018 at 18:56, Eliot Miranda <eliot.miranda(a)gmail.com> >>>> wrote: >>>> > >>>> > Hi Alistair, >>>> > >>>> > On Wed, Feb 21, 2018 at 9:31 AM, Alistair Grant < >>>> akgrant0710(a)gmail.com> wrote: >>>> >> >>>> >> Yep, OSSubprocess doesn't work on 64 bit VMs at the moment. >>>> >> >>>> >> Eliot, Mariano has indicated he's waiting on >>>> >> https://github.com/pharo-project/pharo-vm/pull/142 >>>> >> Do you know of a reason why it shouldn't be merged? >>>> > >>>> > >>>> > Well, the changes to FilePlugin.class belong in VMMaker.oscog. >>>> >>>> Good point. I'm embarrassed to say I didn't look at the code, just >>>> the comments. >>>> >>>> >>>> > And cfileRecordSize doesn't make sense , since all pointers are of >>>> the same size in C: >>>> > >>>> > cfileRecordSize >>>> > + "Return the size of a stdio FILE* handle" >>>> > + <option: #PharoVM> >>>> > + <static: false> >>>> > + ^self sizeof: #'FILE*' >>>> > >>>> > I would simple use (self sizeof: #'void *') or (self sizeof: #'FILE >>>> *'). >>>> >>>> Yep - although this could use <inline: #always>. >>>> >>>> >>>> > Other than that I can't see any problems. >>>> >>>> I've sent Mariano a message asking him to clarify what he needs from >>>> this PR. I'll follow up again after he replies (I'm keen to see >>>> OSSubprocess on the 64 bit VM). >>>> >>>> Thanks! >>>> Alistair >>>> >>>> >>>> >> >>>> >> Thanks, >>>> >> Alistair >>>> >> >>>> >> >>>> >> >>>> >> On 21 February 2018 at 18:22, phideaux <jcasler(a)cdix.org> wrote: >>>> >> > When trying the simple example (ls -la /Users) in Pharo 6.1 64bit >>>> you get a >>>> >> > talkback because >>>> >> > ExternalAddress integerAt:put:size:signed: fails using >>>> >> > 'primitiveFFIIntegerAtPut' in module 'SqueakFFIPrims' >>>> >> > >>>> >> > Something to do with OSSubprocess not accommodating 64 bit >>>> pointers perhaps? >>>> >> > >>>> >> > Same code works fine on 32bit version. >>>> >> > >>>> >> > VM is CoInterpreter VMMaker.oscog-eem.2254 Jul 20 2017 for macOS >>>> downloaded >>>> >> > from pharo.org/downloaded page >>>> >> > >>>> >> > Regards, >>>> >> > Jay+ >>>> >> > >>>> >> > >>>> >> > >>>> >> > -- >>>> >> > Sent from: http://forum.world.st/Pharo-Sm >>>> alltalk-Developers-f1294837.html >>>> >> > >>>> >> >>>> > >>>> > >>>> > >>>> > -- >>>> > _,,,^..^,,,_ >>>> > best, Eliot >>>> > >>>> >>> >>> >>> >>> -- >>> >>> >>> >>> Guille Polito >>> >>> Research Engineer >>> >>> Centre de Recherche en Informatique, Signal et Automatique de Lille >>> >>> CRIStAL - UMR 9189 >>> >>> French National Center for Scientific Research - *http://www.cnrs.fr >>> <http://www.cnrs.fr>* >>> >>> >>> *Web:* *http://guillep.github.io* <http://guillep.github.io> >>> >>> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >>> >> >> >> >> -- >> >> >> >> Guille Polito >> >> Research Engineer >> >> Centre de Recherche en Informatique, Signal et Automatique de Lille >> >> CRIStAL - UMR 9189 >> >> French National Center for Scientific Research - *http://www.cnrs.fr >> <http://www.cnrs.fr>* >> >> >> *Web:* *http://guillep.github.io* <http://guillep.github.io> >> >> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >> > > > > -- > > > > Guille Polito > > Research Engineer > > Centre de Recherche en Informatique, Signal et Automatique de Lille > > CRIStAL - UMR 9189 > > French National Center for Scientific Research - *http://www.cnrs.fr > <http://www.cnrs.fr>* > > > *Web:* *http://guillep.github.io* <http://guillep.github.io> > > *Phone: *+33 06 52 70 66 13 <06%2052%2070%2066%2013> > > -- Mariano http://marianopeck.wordpress.com

Feb. 26, 2018

Re: [Pharo-dev] Esteban's ChangeLog week of 19 February 2018

by Esteban Lorenzano

btwâ¦ reason why inform is being so small is because Iâm investing a lot of time on a new UI for iceberg. and thatâs a âmeta-taskâ. I will try to split tasks on smaller ones :) Esteban > On 26 Feb 2018, at 11:47, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > EstebanLM wrote >> >> Now it should be there ;) > > Yes, it works. Thanks!! > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

Feb. 26, 2018

[Pharo 7.0-dev] Build #608: 21402-Removing-Transcript-Core-from-the-Bootstraped-Image

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

There is a new Pharo build available! The status of the build #608 was: SUCCESS. The Pull Request #951 was integrated: "21402-Removing-Transcript-Core-from-the-Bootstraped-Image" Pull request url: https://github.com/pharo-project/pharo/pull/951 Issue Url: https://pharo.fogbugz.com/f/cases/21402 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Feb. 26, 2018

Re: [Pharo-dev] Esteban's ChangeLog week of 19 February 2018

by Sean P. DeNigris

EstebanLM wrote > > Now it should be there ;) Yes, it works. Thanks!! ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Feb. 26, 2018

Re: [Pharo-dev] Monticello file out bug during bootstrap

by Alistair Grant

Hi Guille and Stef, Stef, thanks also for your reply. All the information I was going to put there I've included below, so please treat is a combined reply. On 26 February 2018 at 09:51, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > Hi Alistair, > > Can you provide some more context on what are you trying to do and how? I'm working on integrating the changes I've made to FileSystem to properly support symbolic links and all the other attributes returned by libc stat(). There's a slightly dated but more detailed description of the changes in http://forum.world.st/FileSystem-file-attributes-and-isSymlink-patch-tt4956… The patch introduces a number of new classes to the FileSystem package: - FileAttributesPluginPrims with Unx and Windows subclasses - Subclasses of FileSystemDirectoryEntry for symbolic links - FileAttributeNotSupported > Generally you should not change anything in the bootstrap, just modify the > classes you want to modify and commit them into the repository. The > bootstrap will take care of it. That's true, but as mentioned this introduces new classes, which also should be handled automatically, but there is a bug in the Monticello file out code that is causing it to fail. I haven't gone through the bootstrap process in great detail, but my understanding is that it reads in the Pharo 7 code from the repository and writes out key classes to .st files to file in as part of the build, i.e.: ${VM70} "${COMPILER_IMAGE_NAME}.image" st ${ST_CACHE}/Multilingual.st ${ST_CACHE}/DeprecatedFileStream.st ${ST_CACHE}/FileSystem.st --no-source --quit --save The bug is only triggered because the new classes, e.g. FileAttributesPluginPrim, are not part of the running image. You can see the code here: MCMethodDefinition>>fullClassName "Using #class selector for classes for backwards compatibility" ^ self classIsMeta ifFalse: [self className] ifTrue: [ (self actualClass isNil or: [ self actualClass isTrait ]) ifFalse: [self className, ' class'] ifTrue: [self className, ' classSide']] Because FileAttributesPluginPrims isn't in the image, #actualClass returns nil, and the method answers "classSide" resulting in a chunk that looks like: !FileAttributesPluginPrims classSide methodsFor: 'initialize' stamp: 'nil'! reset "Reload the masks" Default := nil.! ! This then quietly fails to load, resulting in a DNU when the method is called (later on in the bootstrap process). A quick test of filing out a trait suggests this code isn't called as it uses "classTrait" in the chunk: !TestTrait classTrait methodsFor: 'testing' stamp: 'AlistairGrant 2/25/2018 15:37'! testTrait ^'testing'! ! I'm not familiar with the monticello code base, but #fullClassName is used in a number of different places, so I'm wondering whether it is OK to change MCStWriter>>writeMethodPreamble to always use "class". The would solve this bootstrap issue (there's one more below). > The only cases when you need to change bootstrap code are: > - your code modifies the API of the class builder, the binary > representation of compiled methods, requires changing some class > initialization or if it adds/removes some VM special object (as the ones in > the special objects array) > - you want to add a new package to pharo. In this case you need to add your > package to the repository and update the corresponding baseline so it is > loaded in the image (otherwise it will be in disk but ignored...) Or the new code is dependent on functionality introduced in the Pharo 7 VM. The Pharo 7 image is currently built using the Pharo 6 VM. Adding FileAttributesPlugin to the VM will require the bootstrap to use the Pharo 7 VM in build.sh. Thanks! Alistair > Guille > > On Sun, Feb 25, 2018 at 9:47 PM, Stephane Ducasse <stepharo.self(a)gmail.com> > wrote: >> >> Now I do not understand what is this classSide here. >> If we have a trait apparently we do not file out a class method as >> class but as classSide.... Super strange. >> >> Stef >> >> On Sun, Feb 25, 2018 at 9:46 PM, Stephane Ducasse >> <stepharo.self(a)gmail.com> wrote: >> > Apparently this method was like that in Pharo 60 so this is not my edit. >> > >> > fullClassName >> > "Using #class selector for classes for backwards compatibility" >> > >> > ^ self classIsMeta >> > ifFalse: [self className] >> > ifTrue: [ >> > (self actualClass isNil or: [ self actualClass isTrait ]) >> > ifFalse: [self className, ' class'] >> > ifTrue: [self className, ' classSide']] >> > >> > Now it does not mean that this is not a bug I introduced. >> > >> > >> > >> > >> > On Sun, Feb 25, 2018 at 9:42 PM, Stephane Ducasse >> > <stepharo.self(a)gmail.com> wrote: >> >> the problem is here of course but I need my mind back (In the train to >> >> home). ... >> >> >> >> >> >> MCMethodDefinition>>fullClassName >> >> "Using #class selector for classes for backwards compatibility" >> >> >> >> ^ self classIsMeta >> >> ifFalse: [self className] >> >> ifTrue: [ >> >> (self actualClass isNil or: [ self actualClass isTrait ]) >> >> ifFalse: [self className, ' class'] >> >> ifTrue: [self className, ' classSide']] >> >> >> >> >> >> >> >> >> >> >> >> On Sun, Feb 25, 2018 at 9:41 PM, Stephane Ducasse >> >> <stepharo.self(a)gmail.com> wrote: >> >>> Hi Alistair >> >>> >> >>> This is my mistake! I introduced this bug when I transformed >> >>> theMetaClass to classSide >> >>> Now I was paying super attention and I did not touch theMetaClass even >> >>> when class would have been far enough. >> >>> So do you have a scenario? So that I can try to have a look. >> >>> Unfortunately I was away from home and lab since a week and I may have >> >>> problem to allocate concentrated time. >> >>> But I will try. >> >>> Tx for reporting this! >> >>> >> >>> Stef >> >>> >> >>> >> >>> On Sun, Feb 25, 2018 at 3:48 PM, Alistair Grant >> >>> <akgrant0710(a)gmail.com> wrote: >> >>>> Hi Everyone, >> >>>> >> >>>> I'm working on integrating the file attribute primitives in to the >> >>>> main >> >>>> code during bootstrap. >> >>>> >> >>>> Class methods for FileAttributesPluginPrims are written out as: >> >>>> >> >>>> >> >>>> >> >>>> !FileAttributesPluginPrims classSide methodsFor: 'initialize' stamp: >> >>>> 'nil'! >> >>>> reset >> >>>> "Reload the masks" >> >>>> >> >>>> Default := nil.! ! >> >>>> >> >>>> >> >>>> As you can see, the class name is written with "classSide" instead of >> >>>> "class", resulting in the method quietly being ignored during file >> >>>> in. >> >>>> >> >>>> This comes about in: >> >>>> >> >>>> >> >>>> MCStWriter>>writeMethodPreamble: definition >> >>>> self chunkContents: [:str | >> >>>> stream bang. >> >>>> str nextPutAll: definition fullClassName; >> >>>> nextPutAll: ' methodsFor: '; >> >>>> nextPutAll: definition category asString printString; >> >>>> nextPutAll: ' stamp: '; >> >>>> nextPutAll: definition timeStamp asString printString >> >>>> ] >> >>>> >> >>>> >> >>>> which calls: >> >>>> >> >>>> >> >>>> MCMethodDefinition>>fullClassName >> >>>> "Using #class selector for classes for backwards compatibility" >> >>>> >> >>>> ^ self classIsMeta >> >>>> ifFalse: [self className] >> >>>> ifTrue: [ >> >>>> (self actualClass isNil or: [ self actualClass isTrait ]) >> >>>> ifFalse: [self className, ' class'] >> >>>> ifTrue: [self className, ' classSide']] >> >>>> >> >>>> >> >>>> >> >>>> Because FileAttributesPluginPrims doesn't exist in the image (the >> >>>> code >> >>>> is read in from the git repository and being written out to a .st >> >>>> file), >> >>>> #actualClass returns nil, resulting in "classSide" being used instead >> >>>> of >> >>>> "class". >> >>>> >> >>>> I've never seen "classSide" used in chunk format. Is there any time >> >>>> "classSide" is valid, and any suggestions on how this should be >> >>>> fixed? >> >>>> (My first thought is to just change MCStWriter>>writeMethodPreamble: >> >>>> to >> >>>> only write "class"). >> >>>> >> >>>> >> >>>> >> >>>> Thanks, >> >>>> Alistair >> >>>> >> > > > > -- > > > > Guille Polito > > Research Engineer > > Centre de Recherche en Informatique, Signal et Automatique de Lille > > CRIStAL - UMR 9189 > > French National Center for Scientific Research - http://www.cnrs.fr > > > Web: http://guillep.github.io > > Phone: +33 06 52 70 66 13

Feb. 26, 2018

[Pharo 7.0-dev] Build #607: 21410 Structure DebuggerActions package with Tags

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

There is a new Pharo build available! The status of the build #607 was: SUCCESS. The Pull Request #959 was integrated: "21410 Structure DebuggerActions package with Tags" Pull request url: https://github.com/pharo-project/pharo/pull/959 Issue Url: https://pharo.fogbugz.com/f/cases/21410 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Feb. 26, 2018

Re: [Pharo-dev] [Vm-dev] OSSubprocess 0.2.5 fails in Pharo 6.1 64 bits (macOS)

by Guillermo Polito

Could you check this version? https://github.com/marianopeck/OSSubprocess/pull/30 On Mon, Feb 26, 2018 at 10:19 AM, Guillermo Polito < guillermopolito(a)gmail.com> wrote: > I'll try making a PR now to fix that. > > On Mon, Feb 26, 2018 at 10:19 AM, Guillermo Polito < > guillermopolito(a)gmail.com> wrote: > >> Hmm, wait, I think these are two different issues :) >> >> I managed to successfully use OSSubprocess in 64bits with some tweaks. >> The problem is that OSSubprocess does some manual type coertions like >> assumming 32 bits: >> >> collectArgumentPointersInto: aPointer >> [...] >> aPointer nbUInt32AtOffset: (self argVArguments size - 1) * self >> systemAccessor sizeOfPointer put: 0 >> >> That should probably be replaced by: >> >> aPointer platformUnsignedLongAt: (self argVArguments size - 1) * self >> systemAccessor sizeOfPointer put: 0. >> >> >> Now, those methods depend on UFFI, having UFFI is a must for OSSubprocess. >> >> On Thu, Feb 22, 2018 at 7:07 PM, Alistair Grant <akgrant0710(a)gmail.com> >> wrote: >> >>> >>> Hi Eliot, >>> >>> On 21 February 2018 at 18:56, Eliot Miranda <eliot.miranda(a)gmail.com> >>> wrote: >>> > >>> > Hi Alistair, >>> > >>> > On Wed, Feb 21, 2018 at 9:31 AM, Alistair Grant <akgrant0710(a)gmail.com> >>> wrote: >>> >> >>> >> Yep, OSSubprocess doesn't work on 64 bit VMs at the moment. >>> >> >>> >> Eliot, Mariano has indicated he's waiting on >>> >> https://github.com/pharo-project/pharo-vm/pull/142 >>> >> Do you know of a reason why it shouldn't be merged? >>> > >>> > >>> > Well, the changes to FilePlugin.class belong in VMMaker.oscog. >>> >>> Good point. I'm embarrassed to say I didn't look at the code, just >>> the comments. >>> >>> >>> > And cfileRecordSize doesn't make sense , since all pointers are of >>> the same size in C: >>> > >>> > cfileRecordSize >>> > + "Return the size of a stdio FILE* handle" >>> > + <option: #PharoVM> >>> > + <static: false> >>> > + ^self sizeof: #'FILE*' >>> > >>> > I would simple use (self sizeof: #'void *') or (self sizeof: #'FILE >>> *'). >>> >>> Yep - although this could use <inline: #always>. >>> >>> >>> > Other than that I can't see any problems. >>> >>> I've sent Mariano a message asking him to clarify what he needs from >>> this PR. I'll follow up again after he replies (I'm keen to see >>> OSSubprocess on the 64 bit VM). >>> >>> Thanks! >>> Alistair >>> >>> >>> >> >>> >> Thanks, >>> >> Alistair >>> >> >>> >> >>> >> >>> >> On 21 February 2018 at 18:22, phideaux <jcasler(a)cdix.org> wrote: >>> >> > When trying the simple example (ls -la /Users) in Pharo 6.1 64bit >>> you get a >>> >> > talkback because >>> >> > ExternalAddress integerAt:put:size:signed: fails using >>> >> > 'primitiveFFIIntegerAtPut' in module 'SqueakFFIPrims' >>> >> > >>> >> > Something to do with OSSubprocess not accommodating 64 bit pointers >>> perhaps? >>> >> > >>> >> > Same code works fine on 32bit version. >>> >> > >>> >> > VM is CoInterpreter VMMaker.oscog-eem.2254 Jul 20 2017 for macOS >>> downloaded >>> >> > from pharo.org/downloaded page >>> >> > >>> >> > Regards, >>> >> > Jay+ >>> >> > >>> >> > >>> >> > >>> >> > -- >>> >> > Sent from: http://forum.world.st/Pharo-Sm >>> alltalk-Developers-f1294837.html >>> >> > >>> >> >>> > >>> > >>> > >>> > -- >>> > _,,,^..^,,,_ >>> > best, Eliot >>> > >>> >> >> >> >> -- >> >> >> >> Guille Polito >> >> Research Engineer >> >> Centre de Recherche en Informatique, Signal et Automatique de Lille >> >> CRIStAL - UMR 9189 >> >> French National Center for Scientific Research - *http://www.cnrs.fr >> <http://www.cnrs.fr>* >> >> >> *Web:* *http://guillep.github.io* <http://guillep.github.io> >> >> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >> > > > > -- > > > > Guille Polito > > Research Engineer > > Centre de Recherche en Informatique, Signal et Automatique de Lille > > CRIStAL - UMR 9189 > > French National Center for Scientific Research - *http://www.cnrs.fr > <http://www.cnrs.fr>* > > > *Web:* *http://guillep.github.io* <http://guillep.github.io> > > *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Feb. 26, 2018

Re: [Pharo-dev] [Vm-dev] OSSubprocess 0.2.5 fails in Pharo 6.1 64 bits (macOS)

by Guillermo Polito

I'll try making a PR now to fix that. On Mon, Feb 26, 2018 at 10:19 AM, Guillermo Polito < guillermopolito(a)gmail.com> wrote: > Hmm, wait, I think these are two different issues :) > > I managed to successfully use OSSubprocess in 64bits with some tweaks. The > problem is that OSSubprocess does some manual type coertions like assumming > 32 bits: > > collectArgumentPointersInto: aPointer > [...] > aPointer nbUInt32AtOffset: (self argVArguments size - 1) * self > systemAccessor sizeOfPointer put: 0 > > That should probably be replaced by: > > aPointer platformUnsignedLongAt: (self argVArguments size - 1) * self > systemAccessor sizeOfPointer put: 0. > > > Now, those methods depend on UFFI, having UFFI is a must for OSSubprocess. > > On Thu, Feb 22, 2018 at 7:07 PM, Alistair Grant <akgrant0710(a)gmail.com> > wrote: > >> >> Hi Eliot, >> >> On 21 February 2018 at 18:56, Eliot Miranda <eliot.miranda(a)gmail.com> >> wrote: >> > >> > Hi Alistair, >> > >> > On Wed, Feb 21, 2018 at 9:31 AM, Alistair Grant <akgrant0710(a)gmail.com> >> wrote: >> >> >> >> Yep, OSSubprocess doesn't work on 64 bit VMs at the moment. >> >> >> >> Eliot, Mariano has indicated he's waiting on >> >> https://github.com/pharo-project/pharo-vm/pull/142 >> >> Do you know of a reason why it shouldn't be merged? >> > >> > >> > Well, the changes to FilePlugin.class belong in VMMaker.oscog. >> >> Good point. I'm embarrassed to say I didn't look at the code, just >> the comments. >> >> >> > And cfileRecordSize doesn't make sense , since all pointers are of the >> same size in C: >> > >> > cfileRecordSize >> > + "Return the size of a stdio FILE* handle" >> > + <option: #PharoVM> >> > + <static: false> >> > + ^self sizeof: #'FILE*' >> > >> > I would simple use (self sizeof: #'void *') or (self sizeof: #'FILE *'). >> >> Yep - although this could use <inline: #always>. >> >> >> > Other than that I can't see any problems. >> >> I've sent Mariano a message asking him to clarify what he needs from >> this PR. I'll follow up again after he replies (I'm keen to see >> OSSubprocess on the 64 bit VM). >> >> Thanks! >> Alistair >> >> >> >> >> >> Thanks, >> >> Alistair >> >> >> >> >> >> >> >> On 21 February 2018 at 18:22, phideaux <jcasler(a)cdix.org> wrote: >> >> > When trying the simple example (ls -la /Users) in Pharo 6.1 64bit >> you get a >> >> > talkback because >> >> > ExternalAddress integerAt:put:size:signed: fails using >> >> > 'primitiveFFIIntegerAtPut' in module 'SqueakFFIPrims' >> >> > >> >> > Something to do with OSSubprocess not accommodating 64 bit pointers >> perhaps? >> >> > >> >> > Same code works fine on 32bit version. >> >> > >> >> > VM is CoInterpreter VMMaker.oscog-eem.2254 Jul 20 2017 for macOS >> downloaded >> >> > from pharo.org/downloaded page >> >> > >> >> > Regards, >> >> > Jay+ >> >> > >> >> > >> >> > >> >> > -- >> >> > Sent from: http://forum.world.st/Pharo-Sm >> alltalk-Developers-f1294837.html >> >> > >> >> >> > >> > >> > >> > -- >> > _,,,^..^,,,_ >> > best, Eliot >> > >> > > > > -- > > > > Guille Polito > > Research Engineer > > Centre de Recherche en Informatique, Signal et Automatique de Lille > > CRIStAL - UMR 9189 > > French National Center for Scientific Research - *http://www.cnrs.fr > <http://www.cnrs.fr>* > > > *Web:* *http://guillep.github.io* <http://guillep.github.io> > > *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Feb. 26, 2018