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

Re: [Pharo-dev] Compiler Explorer (for the Compiler guys) #offtopic

by ClÃ©ment Bera

On Wed, Oct 18, 2017 at 1:42 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > > > On Wed, Oct 18, 2017 at 3:36 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> Hi, >> >> This is already available since some time in the GTInspector. You can >> just inspect a compiled method. You will get both the bytecode and the AST >> (with source tracking, too). In fact, this was one of the original reasons >> why GTInspector exists: I wanted to figure out how the AST is structured so >> that I can write queries against it :). >> > > > Sure, we just miss machine code :) > Yeah the machine code is what matters. > But...AFAIR to get the machine code of a method it needs VMMaker to be > loaded.... > I was thinking of changing that, adding a primitive which answers a CogMethod as a bytearray, but you still need to use external libs such as gdb/lldb to disassemble your binary (which is possible but not working out of the box everywhere and it does not make sense to include that as part of the VM), and you still need something extracted from VMMaker to make sense out of the CogMethod header and CogMethod map, which has a lot of dependencies, so likely the whole VMMaker itself. And I'm not talking about all the different CogMethod flavors. With VMMaker loaded you can do it with in-image compilation but you will have the machine code with only unlinked sends. With linked send it's more difficult as you need to really simulate the whole runtime. Overall there's no amazing solution. In the example shown it's easier as in C++ the code is not modified while it runs and you've already have gdb/lldb APIs to show what they show. > > > > > >> >> >> Cheers, >> Doru >> >> >> On Oct 17, 2017, at 10:03 PM, Esteban A. Maringolo <emaringolo(a)gmail.com> >> wrote: >> >> I'm sure we could do this with ease, because we already can see the >> bytecodes. >> >> https://godbolt.org/ >> >> Regards! >> >> Esteban A. Maringolo >> >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "The coherence of a trip is given by the clearness of the goal." >> >> >> >> >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > -- ClÃ©ment BÃ©ra Pharo consortium engineer https://clementbera.wordpress.com/ BÃ¢timent B 40, avenue Halley 59650 Villeneuve d'Ascq

Oct. 18, 2017

Re: [Pharo-dev] Compiler Explorer (for the Compiler guys) #offtopic

by Esteban A. Maringolo

Dolphin's debugger was what came to my mind, it had the "dissasembly" way of debugging VM bytecode. It doesn't provide was native code ASM, and as I understand GTInspector neither. Regards! Esteban A. Maringolo 2017-10-18 6:55 GMT-03:00 Dimitris Chloupis <kilon.alios(a)gmail.com>: > Yeap GTInspector was the first thing that came to my mind , great tool :) > > On Wed, Oct 18, 2017 at 9:37 AM Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> Hi, >> >> This is already available since some time in the GTInspector. You can >> just inspect a compiled method. You will get both the bytecode and the AST >> (with source tracking, too). In fact, this was one of the original reasons >> why GTInspector exists: I wanted to figure out how the AST is structured so >> that I can write queries against it :). >> >> >> Cheers, >> Doru >> >> >> On Oct 17, 2017, at 10:03 PM, Esteban A. Maringolo <emaringolo(a)gmail.com> >> wrote: >> >> I'm sure we could do this with ease, because we already can see the >> bytecodes. >> >> https://godbolt.org/ >> >> Regards! >> >> Esteban A. Maringolo >> >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "The coherence of a trip is given by the clearness of the goal." >> >> >> >> >> >>

Oct. 18, 2017

Re: [Pharo-dev] Compiler Explorer (for the Compiler guys) #offtopic

by Mariano Martinez Peck

On Wed, Oct 18, 2017 at 3:36 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > This is already available since some time in the GTInspector. You can just > inspect a compiled method. You will get both the bytecode and the AST (with > source tracking, too). In fact, this was one of the original reasons why > GTInspector exists: I wanted to figure out how the AST is structured so > that I can write queries against it :). > Sure, we just miss machine code :) But...AFAIR to get the machine code of a method it needs VMMaker to be loaded.... > > > Cheers, > Doru > > > On Oct 17, 2017, at 10:03 PM, Esteban A. Maringolo <emaringolo(a)gmail.com> > wrote: > > I'm sure we could do this with ease, because we already can see the > bytecodes. > > https://godbolt.org/ > > Regards! > > Esteban A. Maringolo > > > -- > www.tudorgirba.com > www.feenk.com > > "The coherence of a trip is given by the clearness of the goal." > > > > > > -- Mariano http://marianopeck.wordpress.com

Oct. 18, 2017

Re: [Pharo-dev] StringMorph removing Text styling

by Pavel Krivanek

Personally I would expect that the second version should be fixed to discard formatting. We have the TextMorph for such cases. -- Pavel 2017-10-18 11:40 GMT+02:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: > Hi, > > I am not sure if this is a bug or a feature, but converting Text to > StringMorph clears some of the formating. > > Compare: > > |text| > text := 'hello' asText makeAllColor: Color red. > > text asStringMorph openInWindow. "no color" > (StringMorph contents: text) openInWindow. "with color" > > Bug? Feature? > > Thanks, > Peter >

Oct. 18, 2017

[Spec] Improved way of linking presenters to domain model objects

by Pavel Krivanek

Hi, this is a simple use-case for the chagnes proposed in the pull request 374 (20551-Improve-way-how-Spec-presenters-are-linked-with-domain-models). https://github.com/pharo-project/pharo/pull/374 I would like to know your comments on it. Situation: You have a presenter that shows a form with information about a person. This form contains a submit button and restore button. Next to it it shows a table with currently saved results. It is only a demo so the domain object is stored directly in this presenter. ComposablePresenterWithModel subclass: #FormPresenter instanceVariableNames: 'form table' The instance variable "form" is a presenter of a form subcomponent, the "table" is a fast table. The ComposablePresenterWithModel stores the model in an instance variable named "specCompatibleModel". This can be a Model or a NewValueHolder (as it is a subclass of Model). We have our domain model class FormModel which contains information about a person like name, surname etc. It is a subclass of Object. Object subclass: #FormModel instanceVariableNames: 'name surname ...' At the beginning we create a new instance of this class as a model for our presenter: FormPresenter>>initialize self model: FormModel new. super initialize. This will create in the instance variable "specCompatibleModel" a value holder that will contain our domain object and subscribes yourself to announcements of this value holder. We need to have this model ready before we will initialize subpresenters because we will provide this model to our form. FormPresenter>>initializeWidgets form := self instantiate: StandaloneFormPresenter on: self specCompatibleModel ... We use here "self specCompatibleModel" and not "self model" because we want to use our value holder directly. If we would use "self model", the form would create a new value holder and then we would need to synchronize the data between the form and parent presenter manually. When the model of the presenter will change, we will fill the table. FormPresenter>>imodelChanged table items: { self model name. self model surname. } The presenter for the form is a subclass of ComposablePresenterWithModel too. It contains input boxes for name and surname. Then it includes buttons for submitting and restoring of the form content. It contains an instance variable "workingModel" to store current state of the form. It is different from the model because we want to be able to restore original data. ComposablePresenterWithModel subclass: #StandaloneFormPresenter instanceVariableNames: 'workingModel nameTextInput surnameTextInput submitButton restoreButton' To create the form is straightforward and there is nothing special on it: StandaloneFormPresenter>>initializeWidgets nameTextInput := self newTextInput autoAccept: true. surnameTextInput := self newTextInput autoAccept: true. StandaloneFormPresenter>>initializePresenter self submitButton action: [self submit]. self restoreButton action: [self restore]. When we obtain a new model, we will create a new working model as copy of it and we will fill the form with its data StandaloneFormPresenter>>modelChanged workingModel := self model copy. self fillFormWithWorkingModel. StandaloneFormPresenter>>fillFormWithWorkingModel self nameTextInput text: workingModel name. self surnameTextInput text: workingModel surname. When we restore the form, we will only do the same as in case of model change - create a new working copy and update the form StandaloneFormPresenter>>restore self modelChanged When we submit the form we obtain the current data from the inputs, store them in the working model. Then we will replace the model with it and announce change of the model to other components. submit workingModel name: self nameTextInput text. workingModel surname: self surnameTextInput text. self model: workingModel. self specCompatibleModel valueChanged. This operation will force update of the parent presenter (that will update the table). The form itself will be updated too (and a new working copy will be created). In this simple case we can make it work without need of a the model working copy. In the simpler approach we wil create parent presenter model as a subclass of Model. Model subclass: #FormModel instanceVariableNames: 'name surname ...' The instantiation of StandaloneFormPresenter can be done on the model directly but it is optional because "self model" and "self specCompatibleModel" return the same object here. self instantiate: StandaloneFormPresenter on: self model When the model will change, we will simply fill the form StandaloneFormPresenter>>modelChanged self fillForm StandaloneFormPresenter>>fillForm self nameTextInput text: self model name. self surnameTextInput text: self model surname. When the form will be submitted, we fill the model with new data and announce changes. StandaloneFormPresenter>>submit self model name: self nameTextInput text. self model surname: self surnameTextInput text. self model valueChanged. So the difference here is in absence of the value holder that will store the domain object. Instead of it we use directly announcer that is provided by the Model class and modify the domain object directly. The original version with the working copy makes more sense in case when you modify the working copy directly on the fly when the user changes data. nameTextInput := self newTextInput autoAccept: true; whenTextChanged: [ self workingModel name: nameTextInput text ]. Then during submitting you can use the the working copy directly to replace the model. submit self model: workingModel. self specCompatibleModel valueChanged. Sometimes for more complex applications it may be handy to use value holders with subinstances of Model inside, when you need to subscribe some presenters directly to models and in the same time to be able to swap then (and be notified about it). This combination is possible too, just use code linke: self model: (NewValueHolder value: FormModel new). ...but then you need to take care if you are wokring with the value holder or with the model inside. submit self specCompatibleModel value: self workingModel. self specCompatibleModel valueChanged. So I hope this proposed changes are quite flexible and will make using of Spec much easier. I'm not sure with the naming of "specCompatibleModel". Cheers, -- Pavel

Oct. 18, 2017

Re: [Pharo-dev] Techtalk today: AI

by Marcus Denker

Hi, The tech talk recording is now in the archive: http://pharo.org/TechTalk > On 17 Oct 2017, at 16:43, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > Hello! > The tech talk starts in 20 minutes (17h europe time). > > Slides (pdf) can be downloaded here <https://github.com/AgileArtificialIntelligence/AgileArtificialIntelligence.…>. > > Invite for Discord (for Q&A after): > > http://discord.gg/Sj2rhxn <http://discord.gg/Sj2rhxn> > The talk will be on Youtube, follow this link: > > https://www.youtube.com/c/AlexandreBergel/live <https://www.youtube.com/c/AlexandreBergel/live> >

Oct. 18, 2017

Re: [Pharo-dev] UnifiedFFI Docs

by Dimitris Chloupis

Sure the documentation could be better, that is definetly important, but is already good enough and UFFI is a very technical subject much more suited to a mailing list . Its not physical possible to cover the massive potential of UFFI. On Wed, Oct 18, 2017 at 9:32 AM Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Please do not hesitate to do Pull Requests. > Luc told me that he wants to do a pass on it and Esteban promises that to > me > but he is super busy. > > Stef > > > On Wed, Oct 18, 2017 at 5:54 AM, Todd Blanchard <tblanchard(a)mac.com> > wrote: > > Wonderful! Thanks. > > > >> On Oct 17, 2017, at 3:45 PM, stephan <stephan(a)stack.nl> wrote: > >> > >> On 17-10-17 23:06, Todd Blanchard wrote: > >>> Anyone know what happened to this? > >>> > https://ci.inria.fr/pharo-contribution/view/Books/job/PharoBookWorkInProgre… > >> > >> https://github.com/SquareBracketAssociates/Booklet-uFFI > >> > >> has a link to a bintray pdf download > >> > >> Stephan > >> > >> > >> > > > > > >

Oct. 18, 2017

Re: [Pharo-dev] Compiler Explorer (for the Compiler guys) #offtopic

by Dimitris Chloupis

Yeap GTInspector was the first thing that came to my mind , great tool :) On Wed, Oct 18, 2017 at 9:37 AM Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > This is already available since some time in the GTInspector. You can just > inspect a compiled method. You will get both the bytecode and the AST (with > source tracking, too). In fact, this was one of the original reasons why > GTInspector exists: I wanted to figure out how the AST is structured so > that I can write queries against it :). > > > Cheers, > Doru > > > On Oct 17, 2017, at 10:03 PM, Esteban A. Maringolo <emaringolo(a)gmail.com> > wrote: > > I'm sure we could do this with ease, because we already can see the > bytecodes. > > https://godbolt.org/ > > Regards! > > Esteban A. Maringolo > > > -- > www.tudorgirba.com > www.feenk.com > > "The coherence of a trip is given by the clearness of the goal." > > > > > >

Oct. 18, 2017

Re: [Pharo-dev] What is blocking Pharo from supporting long paths on Windows?

by Alistair Grant

Hi Peter, On Tue, Oct 17, 2017 at 09:16:49PM +0200, Peter Uhn??k wrote: > So I wanted to update Iceberg in one of my PharoLauncher managed issues. > Of course the load failed on some missing file... upon further exploration: > > updating Iceberg updates Metacello, and metacello contains content like > > Metacello-metacello-1af26bf/repository/Metacello-ToolBox.package/ > MetacelloToolBox.class/instance/ > modifySection.sectionIndex.repository.requiredProjects.packages.dependencies.includes.files.repositories.preLoadDoIts.postLoadDoIts.supplyingAnswers.groups.versionSpecsDo..st > (271 characters - longest file path) > > or > > Metacello-metacello-1af26bf/repository/Metacello-GemStone-TestsMCB.package/ > MetacelloScriptingRegistryDisableUndefinedSymbolsTestCase.extension/instance/ > (152 characters - longest directory path) > > To that you need to add the path to the image (44 chars for me), name of the > image (35 chars on avg for me), and the local location (github-cache\metacello\ > metacello\Pharo6.1) (41 chars). > > tl;dr: 120 chararacters out of Windows 260 is taken by fixed cost, and I need > to fit 152+ characters (that's just directory, it includes files of course) > into 140 chars. > > I have longPathsEnabled in Windows (10) and some applications indeed can go > beyond the limit --- e.g. I can clone (with git) metacello to the same > directory (and go over the limit), but Pharo will fail if I try to navigate to > it. So clearly my system supports it, but not Pharo. > > In conclusion: > > Anyone familiar with WinAPI knows what needs to be done for Pharo to support > unlimited/long paths? > > Thanks, > Peter I'm not familiar with the Win API, but probably what you are looking for is covered by this comment in sqWin32File.h: Handles paths longer than 260 characters (including NULL) by prepending "\\?\" to encode UNC paths as suggested in http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247%28v=vs.85%… "The maximum path of 32,767 characters is approximate, because the "\\?\" prefix may be expanded to a longer string by the system at run time, and this expansion applies to the total length." FilePlugin already does this, so normal directory traversal, i.e. using FileReference, within Pharo should be working correctly. Cheers, Alistair

Oct. 18, 2017

StringMorph removing Text styling

by Peter UhnÃ¡k

Hi, I am not sure if this is a bug or a feature, but converting Text to StringMorph clears some of the formating. Compare: |text| text := 'hello' asText makeAllColor: Color red. text asStringMorph openInWindow. "no color" (StringMorph contents: text) openInWindow. "with color" Bug? Feature? Thanks, Peter

Oct. 18, 2017