- Pharo-dev - lists.pharo.org

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

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

by Guillermo Polito

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-Smalltalk-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

Feb. 26, 2018

Re: [Pharo-dev] "curl https://get.pharo.org/64 | bash" does not work (on Mac)

by Guillermo Polito

These pages are wrong (at least): http://pharo.org/download https://pharo.org/gnu-linux-installation-64 https://pharo.org/gnu-linux-installation On Sun, Feb 25, 2018 at 9:36 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > which page? > > https://pharo.fogbugz.com/f/cases/21407/should-update- > curl-L-https-get-pharo-org-64-bash-to-have-the-L > > On Sun, Feb 25, 2018 at 5:49 PM, K K Subbu <kksubbu.ml(a)gmail.com> wrote: > > On Sunday 25 February 2018 09:54 PM, Bernhard Pieber wrote: > >> > >> Hi all, > >> > >> Here is the output: > >> % Total % Received % Xferd Average Speed Time Time Time > >> Current > >> Dload Upload Total Spent Left > >> Speed > >> 100 237 100 237 0 0 899 0 --:--:-- --:--:-- --:--:-- > >> 901 > >> bash: line 1: syntax error near unexpected token `newline' > >> bash: line 1: `<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">' > >> > >> "curl https://get.pharo.org/64/ | bash" does work, though. It is just > that > >> in the documentation (https://get.pharo.org/64/) the link has no > trailing > >> slash. > > > > > > The URL https://get.pharo.org/64 will return a 301 (Moved permanently) > > redirect reply. Unlike wget, curl will follow the redirect only if -L > option > > is given, so > > > > curl -L https://get.pharo.org/64 | bash > > > > will also work fine. The document needs to be updated to use -L option > for > > curl. > > > > HTH .. Subbu > > > > -- 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] Pull Request 20898-MultiByteFileStream-upToAll-does-not-work-correctly-with-UTF-8

by Guillermo Polito

Well, It looks like when you read tonel files with your changes there are some "invisible" characters left over in the stream. I think that first you should be able to reproduce the issue locally without bootstrapping by trying to import a tonel file in an image with your changes. Just take any of the files inside Pharo's src/ directory and try: reader := TonelReader on: stream fileName: '...'. reader loadDefinitions. Once with the monticello definitions you can try to compile them or check if the source code in the methods have something strange... If that fails, come back and we can do a skype trying to show you how to bootstrap :) Guille On Sun, Feb 25, 2018 at 9:37 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Hi bernhard > > sorry. Yes we should have a look. > > Stef > > On Sun, Feb 25, 2018 at 4:12 PM, Bernhard Pieber <bernhard(a)pieber.com> > wrote: > > Hi all, > > > > Can somebody please help me get my bugfix from December integrated? For > some reason CI fails and I have no idea how to debug that. :-( > > https://github.com/pharo-project/pharo/pull/632 > > > > Bernhard > > -- 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] Monticello file out bug during bootstrap

by Guillermo Polito

Hi Alistair, Can you provide some more context on what are you trying to do and how? 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. 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...) 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 <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Feb. 26, 2018

[Pharo 7.0-dev] Build #606: 21408 MCTool should use utilities category

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

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

Feb. 26, 2018

Re: [Pharo-dev] Simplified AST "Suggestions" menu definitions

by Marcus Denker

> On 25 Feb 2018, at 21:30, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > Marcus I thought that the context was about to represent what the > tools selected like the class currently selected. > You have this information in the AST? > The AST as coming from the Parser: no. The AST after name Analysis: yes. Which means you actually need the class to do name analysis (âSemantic Analysisâ, implemented by OCASTSemanticAnalyzer). I think it will be easy: -> there is RubSmalltalkCodeMode / RubSmalltalkScriptingMode which models if the editor. is editing Doits or Methods (important for parsing!). -> RubSmalltalkCodeMode does have an ivar classOrMetaclass already. It is not set by most tools yet, though. -> we can easily add there (or in RubSmalltalkEditor) an âast â ivar and re-parse at every keystroke. So as soon as we make sure that all users of RubSmalltalkCodeMode correctly set the class, this will be all very simple. Marcus

Feb. 26, 2018