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

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

[Pharo 7.0-dev] Build #605: 21411 Cleanup DebugSession>>resumeProcess

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

There is a new Pharo build available! The status of the build #605 was: SUCCESS. The Pull Request #960 was integrated: "21411 Cleanup DebugSession>>resumeProcess" Pull request url: https://github.com/pharo-project/pharo/pull/960 Issue Url: https://pharo.fogbugz.com/f/cases/21411 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:44, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > This is cool! > > Could this "help" also be included in Pharo's Help Browser? > I added it to the class comment of SugsSuggestion.. for a Help Topic, it might be interesting to add some general âAST and how it is used by toolsâ sectionâ¦ Marcus

Feb. 26, 2018

Esteban's ChangeLog week of 19 February 2018

by estebanlm＠gmail.com

Hello! This is my weekly ChangeLog, from 19 February 2018 to 25 February 2018. You can see it in a better format by going here: http://log.smallworks.eu/web/search?from=19/2/2018&to=25/2/2018 ChangeLog ========= 21 February 2018: ----------------- * So well... I spent some hours yesterday to make the backport of Iceberg 0.6.8 to Pharo 6.1 to actually happen. Now it should be there ;) cheers! Esteban

Feb. 26, 2018

Re: [Pharo-dev] Pharo 7.0 does not includes "Metacello support for GitFileTree metadata-less mode"

by Cyril Ferlicot D.

Le 20/02/2018 Ã 14:29, Juraj Kubelka a Ã©critÂ : > Hi, > > > In the following email [1], Dale Henrichs explains that there was an update to support correctly GitFileTree metadata-less mode. While I can see the mentioned class MetacelloCypressBaselineProject in Pharo 6.1, I cannot find it in Pharo 7.0. > > Is it supposed to include the Metacello update to Pharo 7.0 too? > > Thanks! > Juraj > > [1] http://forum.world.st/ANN-Metacello-support-for-GitFileTree-metadata-less-m… > Hi! This support is in this PR: https://github.com/pharo-project/pharo/pull/950 It was not added in Pharo 7 during the last sync but was in Pharo 6.1. I hope in the future we will depend on Metacello as a project during the bootstrap instead of having the sources directly in the Pharo repository. It will help but it needs work. -- Cyril Ferlicot https://ferlicot.fr

Feb. 25, 2018